[Bloat] [Codel] Exploring the potential of codel, fq_codel, and qfq

[Rick Jones]

On 05/16/2012 12:46 AM, Eric Dumazet wrote:
> On Wed, 2012-05-16 at 00:20 -0700, Dave Taht wrote:
>
>> With ecn:
>>
>> 64 bytes from 149.20.63.18: icmp_req=46 ttl=64 time=10.6 ms
>> 64 bytes from 149.20.63.18: icmp_req=47 ttl=64 time=5.66 ms
>> 64 bytes from 149.20.63.18: icmp_req=48 ttl=64 time=11.8 ms
>> 64 bytes from 149.20.63.18: icmp_req=49 ttl=64 time=3.68 ms
>> 64 bytes from 149.20.63.18: icmp_req=50 ttl=64 time=10.2 ms
>> 64 bytes from 149.20.63.18: icmp_req=51 ttl=64 time=12.8 ms
>> 64 bytes from 149.20.63.18: icmp_req=52 ttl=64 time=2.62 ms
>> 64 bytes from 149.20.63.18: icmp_req=53 ttl=64 time=7.86 ms
>>
>> TCP_RR: 102
>>
>> All of these sets of results need more rigor attached.
>
> On TCP_RR pure workload, you have one packet in flight per flow.
>
> ECN adds nothing in this case, only that no 'drops' occurs at all.
>
> It might be good to change fq_codel to perform ECN mark only if flow
> queue has more packets.
>
> If not, plain drop.

I like netperf as much as anyone :)  but keep in mind that the TCP_RR 
test has only one segment outstanding at a time only when the 
request/response size is < MSS and/or one has not enabled burst mode to 
have multiple transactions in flight at one time.

Are we really likely to see a situation where all the flows are one 
packet at a time?   If all the flows are either that way naturally, or 
have gotten there thanks to a one segment cwnd are we not already in a 
very pathological situation?

For the impossible to define "fair" question, is it fair to drop a 
flow's only packet if there are other, multiple-packet flows around?

rick jones