Re: [tsvwg] L4S vs SCE

[Jonathan Morton <[e-mail]>]

> On 20 Nov, 2019, at 12:03 pm, G Fairhurst <[e-mail]> wrote:
> 
> Would an SCE router likely preserve or change the queueing of ECT(1) L4S traffic? - is this behvaiour different to any existing ECN-marking router?

SCE middleboxes don't queue or handle ECN(1)-marked or CE-marked traffic any differently from ECT(0) traffic.  The a-priori ECT(1) marking merely removes the option of applying an SCE mark.

CE marking on L4S traffic will be as per RFC-3168; it is already incumbent upon L4S to cope with that.

> And would SCE traffic arriving at the L4S queue meet L4S expectations in terms of responsiveness?

Yes, since the MD response to CE is actually more severe/conservative than what L4S expects.

> Have we thoughts on what would happen with SCE?

The current Linux implementations all have SCE functionality gated behind a non-default setting, so users have to explicitly turn it on.  I think this should make it relatively easy to clean up an abortive deployment, should it be required.  Specifically:

- The sch_cake, sch_fq_codel, and sch_cnq_cobalt qdiscs each require a non-default tc parameter to enable SCE marking.  Without it, they purely support RFC-3168 and will not increase the incidence of ECT(1) codepoints.

- Receiver echoing of SCE marks into the ESCE flag is controlled by the net.ipv4.tcp_sce sysctl.  This behaviour differs from that of Nonce Sum receivers but involves the same codepoint and flag bit.

- Sender responses to the ESCE flag are enabled by explicitly selecting one of the modified TCP algorithms.  If these are selected but no ESCE flags appear, they behave like ordinary RFC-3168 compliant Reno or CUBIC implementations.

Is that sufficient, or does a more detailed analysis need to be organised?

 - Jonathan Morton