Re: [Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

[Mario Hock <mario.hock@kit.edu>]

Am 05.06.2018 um 09:49 schrieb Jonathan Morton:
>> On 5 Jun, 2018, at 10:44 am, Mario Hock <mario.hock@kit.edu> wrote:
>>
>> Just to make sure that I got your answer correctly. The benefit for endsystems comes from the "fq" (flow queuing) part, not from the "codel" part of fq_codel?
> 
> That's a fair characterisation, yes.
> 
> In fact, even for middleboxes, the "flow isolation" semantics of FQ have the most impact on reducing inter-flow induced latency.  The "codel" part (AQM) helps with intra-flow latency, which is usually much less important once flow isolation is in place, but is still worth having.

Thanks for the confirmation.

A potential drawback of using the codel part (of fq_codel) in the 
endsystems is that it can cause packet drops already at the sender.

I could actually confirm this assumption with a very simple experiment 
consisting of two servers connected over a 1Gbit/s link and 100 parallel 
flows (iperf3). With fq_codel I had 5,000-10,000 retransmissions within 
60s. With fq (or pfifo_fast) no packets are dropped. (I presume either 
"TCP small queues" or backpressure keeps the queues from overflowing.)

Also, ping times (delays for short flows) were similar with fq and 
fq_codel (mostly <= 1ms).

Is there any advantage of using fq_codel over fq at the endsystems?

Mario Hock