Re: [Codel] The next slice of cake

[Jonathan Morton <chromatix99@gmail.com>]

> On 31 Mar, 2015, at 10:12, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
>>> I thought the main argument was, that interval needs to be roughly in the right range and target is supposed to be between 5 to 10 percent of interval.
>> 
>> Yes, but why?
> 
> I think this is explained well in sections 4.3 and 4.4 of https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=1
> 
>> I have seen other arguments, both recently and otherwise, which modify target to accommodate the MAC grant latency of some medium, while interval is still described as a rough estimate of the RTT.
> 
> According to Kathleen Nichols http://pollere.net/Pdfdocs/noteburstymacs.pdf the reasoning of the RFC draft should also apply to the MAC issue.

Cake's shaper has no significant access grant latency (typical scheduling latency in Linux is on the order of 1ms), so while the discussion of that case is enlightening, it isn’t relevant to my work right now.  (Might become relevant in other contexts.)

But having just re-read those papers carefully, the argument over target actually boils down to the fact that - at the time of writing - there was a special case which would avoid marking or dropping the final MTU’s worth of the queue, regardless of the target or latency settings.  This is actually quoted in the I-D as the mechanism by which Codel scales down to 64Kbps.  See "non-starvation drop inhibit”.

That special case is *not* present in the more recent versions of Codel, including the version used for the original version of cake.  Some versions of Codel have an alternative mechanism, where they special-case the last packet in the queue rather than the last MTU’s worth.  But this doesn’t work very well for cake (or for fq_codel) which often delivers the last packet in that sub-queue while there are still other packets in the overall queue - and the latter is what is tested.

As a result, I saw truly excessive marking if I selected a very slow shaping rate (eg. 64Kbps) without adjusting the target.  The congestion window was already at minimum size, so such aggressive congestion signalling just resulted in reduced throughput and (when talking to servers without ECN) more retransmissions.

So what cake does is to adjust the target to roughly match the behaviour of that special case, and then adjusts the interval to be compatible with the revised target and the assumed RTT.  Since cake implements sophisticated flow isolation - which is getting more sophisticated with each version - a slightly higher sojourn time in fat flows isn’t a problem, because sparse flows get to bypass them.  One of the things I really like about flow-queuing and ECN is that it enables smooth, consistent delivery of the various assets that make up a web page, and those benefits were noticeably compromised with cake2 (which left out those adjustments).

>> Yes - I could make it capable of dropping multiple packets to cope better with the latter case.

>> Codel already has such a protection mechanism, but I haven’t yet converted it to byte mode.
> 
> Ah, good this is one more important step to make smallish routers survive a udp flood; not that I think a router should work great during a flood/attack, but it certainly should not crash…

By the time I read this, I’d already implemented these.  :-)

Now to update iproute2 - again - to deal with the new statistics outputs, and I might be in a position to start sending patches.

 - Jonathan Morton