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

[Kevin Darbyshire-Bryant]

On 04/05/16 12:41, Jonathan Morton wrote:
>> On 4 May, 2016, at 12:57, Kevin Darbyshire-Bryant <kevin at 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
>
Thanks Jonathan.  Appreciate the time taken for the explanation.  Much
happier :-)

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20160504/8ca7df98/attachment-0001.bin>