Re: [Bloat] Fwd: Did *bufferbloat* cause the 2010 flashcrash?

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

>>> [1] For the purposes of the question, the “BitTorrent problem” is when you and
>>> I are on the same network, and your 200+ BitTorrent upload sessions makes it
>>> impossible for me to upload my single cat video to YouTube.
>>
>> Isn't this dependent on the upload speed? I would imagine that if it's 5-10
>> megabit/s, then using Codel or similar technique that doesn't allow the buffer
>> to grow to hundreds of milliseconds, would improve things a lot?
>>
>> For a 500 kilobit/s link, I'm not sure even that would work...?
>
> There are two separate issues: 

(three if you count me hitting send too soon...)

1. When you turn on bittorrent, everything becomes unbearably slow
   because you have huge amounts of bloat. I.e. web browsing doesn't
   work, your voice calls drop, etc. fq_codel solves this pretty nicely
   (I don't even notice when bittorent is on anymore).

2. Bandwidth sharing between bittorrent and other protocols. Bittorrent
   uses utp to try to be a scavenger that will back off and not use
   bandwidth if other traffic needs it. fq_codel breaks this by
   isolating flows and taking away the signal utp uses to back off.
   Diffserv with a suitable scheduler (cake, for instance) can fix this
   if the bittorrent client is configured correctly; or you could use
   deep(er) packet inspection to try to figure out which traffic is
   bittorent. But we don't have a shrinkwrap solution to this presently,
   AFAIK.

I believe the cat video upload falls into category 2.

-Toke