From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E30E821F304 for ; Mon, 22 Jun 2015 12:29:49 -0700 (PDT) Received: by oiyy130 with SMTP id y130so112117337oiy.0 for ; Mon, 22 Jun 2015 12:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0um0HsMNzFUFpTytdbq6BQ12sn3ym+dHqCYEp8RPK1k=; b=U+WVmiolU/lTm+fyuibgQfIuW9HQDKzDya1vQyu3C6hG2No4BzIdjvBHEFh8rT27mD jR7rlcN2XXY/wmjjew/uh4+ApHeP9iu628L7kvGOZk8IY/aOGmvtshYnaTnvn/hQqowo 47znv1fZkgRLGGXcKu4MNnrFlQSyC7aGsnTm/95GXtOTg87t0VUnYJVDpkrpAhh4Tt8W 8piwJ4GbBJXfoZjoOT9Z+d/Helys/YRouO/IGgx8BPb4RAD731dbttPkzD3VpcUtDx7g PJLD9hx6/GO12N2SMhp+OzdA9bxBVwm+9n4gjBcLlfbQzfDL+OPv+jzpar35/z5wVWJ0 8c8A== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr26114398oec.11.1435001388584; Mon, 22 Jun 2015 12:29:48 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Mon, 22 Jun 2015 12:29:48 -0700 (PDT) In-Reply-To: <87wpyx3wnc.wl-jch@pps.univ-paris-diderot.fr> References: <87wpyx3wnc.wl-jch@pps.univ-paris-diderot.fr> Date: Mon, 22 Jun 2015 12:29:48 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] BitTorrent and IPv6 [was: tackling torrent...] X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:30:18 -0000 On Sun, Jun 21, 2015 at 8:32 AM, Juliusz Chroboczek wrote: > [Removed AQM from CC.] > >> 4) *All* the traffic was udp. (uTP) > > > Yes, modern BitTorrent implementations prefer =C2=B5TP to TCP. Unfortuna= tely, > the implementation of =C2=B5TP in Transmission doesn't perform PMTUD, and= gets > packet sizes wrong most of the time. (Yes, I spoke about this to Arvid. > No, he wasn't particularly concerned.) At least in the comcast cable world, path mtu is 1500 bytes. I have in general, longed to see a ledbat like protocol go back to shrinkin= g packet sizes to 300-500 bytes under contention or with excessive loss, keeping the signal strength "high", while impact low. This was how one version or another of bittorrent also reduced it's impact on the network, but a decade ago the smaller packet size put stress on many a network. >> Despite ipv6 being enabled (with two source specific ipv6 ips), I did no= t >> see any ipv6 peers connect. Bug? Death of torrent over ipv6? Blocking? >> What? > > > Please check that you allow incoming IPv6 to your peer, for both TCP and > UDP. Obviously, setting port forwarding for IPv4 is not enough for that = =E2=80=94 > you'll need to explicitly set up a hole in your IPv6 firewall. If using > OpenWRT: The core differentiator here turned out to be the type of torrent. Switchin= g to downloading ubuntu's various distros showed a HUGE percentage using ipv6 (and transmission as the server). It also appeared to show that transmission chose one and only one of the ipv6 addresses available on this box. (I only got 10MByte/sec on the download where I could have got as much as 150Mbyte/sec out of my two (configured) source specific gateways. Given the huge number of seeders for the ubuntu torrents, there are very connections (2 tops) extant now that they are downloaded. This was not the case for the more normal torrents, which ended up with 15 or more peers each after downloaded. ... With 196 mostly ipv6 peers (I upped the defaults), I got the expected download throughput for each flow for a fq'd environment with cake, with a "normal" tcp. e.g. ledbat made no difference, as expected. This is me capturing the last 30 seconds of an ubuntu download: http://snapon.lab.bufferbloat.net/~d/withtorrents/last30secondsoftorrentvs1= upload.png As comcast (mis)marks a huge percentage of traffic as CS1, trying to distinguish between inbound traffic types based on diffserv marking alone was futile. I am not sure how often 6696 is used... On the other hand, even beating up the link as hard as this was barely noticible for normal web, mosh, ssh traffic, and maximum induced delays for cross traffic stayed quite low. (above) And on the gripping hand, using rrul, and classifying all outbound torrent traffic as CS1 led to normal (non-torrent) downloads going much faster, and slowing down torrent (making it ack limited) in the download direction, when it was in it's download phase. And classification on the upload direction, managed by cake, knocks it out of the way so it is unnoticible during ordinary use. I would still argue for capping the number of outbound torrent flows relative to loss or delay at some value lower than 50 and thinking about how to make ledbat less impactful in a world with 5ms delay... http://snapon.lab.bufferbloat.net/~d/withtorrents/competing_rrul_be_during_= 196torrents_classified.png the periodic 5ms latency spikes are "interesting", but it's noisy data, a new qdisc, and other factors.... A bit more flent data here: http://snapon.lab.bufferbloat.net/~d/withtorrents/ I will clean up my patches a bit more and submit somewhere when I get time.= ... It is still pretty amazing how fast I can get an entire OS at 100Mbit. The initial discovery and seeding and startup process takes a significant chunk of the time required. > > config rule > option target 'ACCEPT' > option src 'wan' > option name 'Transmission-v6' > option family 'ipv6' > option dest '*' > option dest_port '12345' > > for the right value of 12345. 6969 was the most common inbound port. > > If you set the logging level in Transmission to Debug and let it run for > twenty minutes or so, you should see periodic "Starting IPv6 DHT announce > (... good ...)". If you keep seeing "firewalled" instead of "good", you'= ve > got an issue. > > Once you're positive you don't have firewalling issues, the following mig= ht > be of interest. > > I've done quite a bit of work a few years ago to improve IPv6 support in > Transmission. The main problem is how to learn the IPv6 addresses of you= r > peers: Yep, I see your name across every file I have wanted to modify slightly. :) > 1. Many trackers don't support IPv6. > > 2. IPv6 is supported by PEX (gossip, peer-exchange). I'm not sure if oth= er > peers honour IPv6 PEX when connected over IPv4, but Transmission certainl= y > does. > > 3. I've implemented a protocol extension that allows peers connected over > IPv4 to exchange their IPv6 addresses. This is only marginally useful, b= ut > can sometimes allow bootstrapping IPv6 PEX without tracker support. > > 4. Most importantly, I've implemented IPv6 support for the DHT (BEP-32) [= 1]. > BEP-32 is now implemented by Transmission, Vuze, Tixati, KTorrent and > Shareaza. In light of source specific routing, perhaps that BEP needs an addendum. > Points (1) through (3) are interoperable with =C2=B5Torrent/BitTorrent an= d > libtorrent, which constitute the vast majority of deployed BitTorrent pee= rs. > Unfortunately, =C2=B5Torrent and libtorrent do not implement BEP-32, and = since > these implementations constitute the vast majority of deployed BitTorrent > peers outside China, this seriously limits the effectiveness of the IPv6 > DHT. (Yes, I've spoken to the =C2=B5Torrent developers, and while they r= eviewed > BEP-32 favourably, they had no plans at the time to implement it.) > > [1] http://www.bittorrent.org/beps/bep_0032.html All good to know. Thank you. > -- Juliusz --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast