Re: [Cake] cake, codel5.h, ecn marking & dropping. Confused

[Jonathan Morton <chromatix99@gmail.com>]

> On 4 May, 2016, at 12:57, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> In essence my (mis)understanding of this code is something like: We've
> got here because we've been dropping and codel is telling is to continue
> to drop.  With that decided we enter a do..while, the first thing to
> happen is to ECN mark and let that marked packet escape to send the
> signal.  Otherwise we appear to iterate around the loop.  So here's the
> nub of my question: the INET_ECN_set_ce is done on every iteration of
> that loop...with its potential early escape..do we escape on every
> iteration?  Do we need to twiddle the ECN bits on every packet that
> we're about to drop?  And we seem to mark the packet on exit of the loop
> anyway.

It’s rather oddly structured code, to be sure.

The vital clue for you may be that you can only set CE on an IPv{4,6} packet which already has something *other* than Not-ECT set; it’s impossible for non-IP packets, and not ECN compliant for Not-ECT IP packets.  So INET_ECN_set_ce() returns true only when it succeeds.

On a UDP flood stream, typically Not-ECT is set, so the early-out never triggers.  Instead Codel drops a packet, schedules the next drop, and checks whether the next drop schedule has already been reached (which can happen for high drop rates and/or slow transmission rates).

It then attempts to set CE on the first packet transmitted after a drop sequence, just in case it was a mixed ECT/Not-ECT stream; strenuous efforts to get the congestion signal heard as early as possible.  This is more likely when flow isolation isn’t in use, or when it is per-host instead of per-flow.  That’s also why the first attempt to set CE is within the drop loop.

 - Jonathan Morton