[Cake] ECN is off on retransmit by default, upstreaming a bug fix, and some patch cleanup
dave.taht at gmail.com
Mon Aug 5 12:00:11 EDT 2019
I burned yesterday attempting to forward port chromi's SCE branch to
be part of net-next + bbrv2, and I'm mostly there.
(I have a few other non-related kernel things I'm doing)
Three notes thus far:
A) This looks to me to be a generic bug to a nonce OR SCE OR L4S
deployment and should go upstream
static inline int INET_ECN_is_capable(__u8 dsfield)
- return dsfield & INET_ECN_ECT_0;
+ return dsfield & INET_ECN_MASK;
In terms of upstreaming other stuff, sch_cake should stop filtering
out the nonce in the ack filter (?), and I'd like to add support for
new LE codepoint to cake and the sqm-scripts this round. The rfc
depreciates CS1 however, and I don't think that's a good idea.
Cleaning up the former patch a little bit....
#define CAKE_ACK_IGNORE (TCP_FLAG_ECE | TCP_FLAG_CWR | TCP_FLAG_ESCE)
(but it was ironic there wasn't even a define for the NS in the first
C) I'd essentially forgotten than on a retransmit, the existing RFCs
turn off ECN capability entirely (falling back to lossy
retransmits in an ancient attempt to keep the impact of ecn lower) -
which bodes ill for the conflicts between L4S and SCE,
and not shown in various prior dctcp benchmarks that previously had no
reaction to loss at all and presumably no or few circumstances
where a loss and retransmit were triggered. (another win for not using
ect1 as an identifier, in that in SCE we don't HAVE to change
I had suggested in a prior mail that when cwnd falls below 2 that ECN
be disabled also in a prior email. Don't know if that's ever been
In some experimental RFC or another setting ECN even on retransmits is
suggested, which I think was a L4S requirement?
/* Funny extension: if ECT is not set on a segment,
* and we already seen ECT on a previous segment,
* it is probably a retransmit.
if (tp->ecn_flags & TCP_ECN_SEEN)
CTO, TekLibre, LLC
More information about the Cake