Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

[Jonathan Morton <[e-mail]>]

On 18 Nov 2019 10:19, "Scheffenegger, Richard" <[e-mail]> wrote:
>
> Hi Jonathan,
>
>
> > I believe DCTCP made a fundamental error in deciding to redefine CE,
> and that's the problem that L4S is presently running into.  We do have
> (since IETF-104 @ Prague) an alternative version of DCTCP using SCE
> signalling, and that could illustrate a starting point for merging the
> two experiments.  I believe that would solve an awful lot of problems at
> a stroke.
>
>
> Being in a position of having no immediate control over the ECN marking
> strategy, and having to reuse existing silicon's RED implementation,
> that choice of DCTCP was IMHO reasonable. (Also, IMHO it is not
> realistic to see a timely implementation of more modern AQMs in very
> high speed chipsets - but others would be in a better position to
> discuss, if the SCE codepoint transitions could be implemented with
> little effort in those asics).
>
> I agree that this was not a choice that lends itself to good, backwards
> compatible interoperability. As such, a clean slate approach (such as
> SCE) is more free in using "proper" codepoints. However, that allowed
> the immediate deployment using existing RED AQM (and an additonal
> classifier so that non-DCTCP is not using the queue with the aggressive
> marking).
>
>
>
> However, because of the different reaction of the CC (1/cwnd vs
> 1/sqrt(cwnd) ), these two will not coexist with each other in the same
> (non-FQ) queue, correct?

It's the same class of problem as having plain RFC-3168 compliant traffic
in the same single queue as SCE traffic, regardless of which response to
SCE is chosen.  The same solutions should apply:

- Dropping or RFC-3168 marking AQMs will cause the same congestion response
in Not-ECT, RFC-3168, DCTCP-SCE and ELR-SCE flows, so they will coexist
naturally.  This is also true of dumb FIFOs.  So the problem only manifests
when actively upgrading the middlebox to perform SCE marking.

- Adding FQ at the same time as adding SCE marking solves the fairness
problem, and has its own benefits - and costs.

- CNQ offers a way to limit the extent to which SCE flows give way to other
traffic, as well as allowing sparse traffic to bypass the queue, with
minimal added complexity compared to a FIFO AQM.  As a halfway house
between a FIFO and true FQ, this might be a good choice for high capacity
deployments, especially where persistent saturation is expected to be rare.

- Jonathan Morton