Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems

[Jonathan Morton <chromatix99@gmail.com>]

> On 18 May, 2015, at 18:09, dpreed@reed.com wrote:
> 
> I'm curious as to why one would need low priority class if you were using fq_codel?  Are the LEDBAT flows indistinguishable?  Is there no congestion signalling (no drops, no ECN)? The main reason I ask is that end-to-end flows should share capacity well enough without magical and rarely implemented things like diffserv and intserv.

The Cloonan paper addresses this question.  http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf

Let me summarise, with some more up-to-date additions:

Consider a situation where a single application is downloading using many (say 50) flows in parallel.  It’s rather easy to provoke BitTorrent into doing exactly this.  BitTorrent also happens to use LEDBAT by default (via uTP).

With a dumb FIFO, LEDBAT will sense the queue depth via the increased latency, and will tend to back off when some other traffic arrives to share that queue.

With AQM, the queue depth doesn’t increase much before ECN marks and/or packet drops appear.  LEDBAT then behaves like a conventional TCP, since it has lost the delay signal.  Hence LEDBAT is indistinguishable from conventional TCP under AQM.

With FQ, each flow gets a fair share of the bandwidth.  But the *application* using 50 flows gets 50 times as much bandwidth as the application using only 1 flow.  If the single-flow application is something elastic like a Web browser or checking e-mail, that might be tolerable.

But if the single-flow application is inelastic (as VoIP usually is), and needs more than 2% of the link bandwidth to work properly, that’s a problem if it’s competing against 50 flows.  That’s one of the Cloonan paper’s results; what they recommended was to use FQ with a small number of queues, so that this drawback was mitigated by way of hash collisions.

Adding Diffserv and recommending that LEDBAT applications use the “background” traffic class (CS1 DSCP) solves this problem more elegantly.  The share of bandwidth used by BitTorrent (say) is then independent of the number of flows it uses, and it also makes sense to configure FQ for ideal flow isolation rather than for mitigation.

 - Jonathan Morton