[Bloat] BitTorrent and IPv6 [was: tackling torrent...]

[Dave Taht]

On Sun, Jun 21, 2015 at 8:32 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> [Removed AQM from CC.]
>
>> 4) *All* the traffic was udp. (uTP)
>
>
> Yes, modern BitTorrent implementations prefer µTP to TCP.  Unfortunately,
> the implementation of µTP 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 shrinking
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 not
>> 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 —
> 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. Switching 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/last30secondsoftorrentvs1upload.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 might
> 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 your
> 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 other
> peers honour IPv6 PEX when connected over IPv4, but Transmission certainly
> does.
>
> 3. I've implemented a protocol extension that allows peers connected over
> IPv4 to exchange their IPv6 addresses.  This is only marginally useful, but
> 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 µTorrent/BitTorrent and
> libtorrent, which constitute the vast majority of deployed BitTorrent peers.
> Unfortunately, µTorrent 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 µTorrent developers, and while they reviewed
> 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



-- 
Dave Täht
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