Re: [Codel] fq_codel: revenge of the standing queue

[Kathleen Nichols <nichols@pollere.com>]

I can't keep up with the pace here, but I'm compelled to express puzzlement
at the notion that fq_codel gives *longer* standing queues than codel. The
opposite happens with sfq_codel which is, I believe, doing the same basic
things as fq_codel (a similar approach to that below for queues/bins that go
empty) except for being packet scheduled rather than byte scheduled.  I
see this wonderful, well-controlled behavior without "reverse traffic"
issues.
This is why I think Eric's work on this rocks.

	imho,
		Kathie


On 9/4/12 11:50 AM, Eric Dumazet wrote:
> On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote:
> 
>> 2) New flows
>>
>> The next issue (at these 10 and 100Mbit rates) is the "new flow" idea
>> in fq_codel. It is VERY useful pushing sparse flows to the fore of the
>> queues, and also provided a boost to long RTT flows. However at high
>> levels of occupancy and low bandwidth, flows empty their queue
>> rapidly, become "new flows", and then mislead codel for that flow into
>> resetting itself again, since we end up with a short delay for the
>> re-entrance. This isn't a particularly horrible behavior, but as my
>> own hope for this feature was to make voip better primarily, and
>> everything else we got from it was a bonus.
>>
>> TSQ really made this oddity show up big.  I think on routed traffic it
>> will be less of an issue.
> 
> This is simply not true, and based on misunderstanding on what does
> fq_codel.
> 
> A flow never leaves the new flow list before doing a full RR cycle in
> old flow list (even without any packet in this flow)
> 
> _IF_ we did a full RR cycle, then we accumulated a full quantum of
> credit, and lost our rank the 'fq_codel RR queue' (the combination of
> the 2 internal queues, new and old)
> 
> Therefore, we allow the flow to be queued in 'new flow', to recover a
> bit of the lost rank in queue.
> 
> Basically you dont interpret correctly the 'new_flow_count' counter.
> 
> It means almost nothing at all, since for a given TCP flow, we _can_
> increment this counter several time.
> 
> 
> 
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>