Re: [tsvwg] planning to close L4S issue #21

[Jonathan Morton <[e-mail]>]

> On 5 Jun, 2020, at 5:20 pm, Wesley Eddy <[e-mail]> wrote:
> 
> If there's a specific aspect of #21 that justifies keeping it separate, that's what I'm hoping someone will bring up.  This is without any regard to engineering philosophy or workload optics.

Referring back to notes I took for the Montreal meeting, which IIRC was where these issues were first drawn up, each issue corresponds roughly to a line item on some slides provided by the Chairs, then referred to by a letter code.  I recall standing up and talking specifically about a linked group of four such points:

F: RFC-8311 does not in itself modify RFC-3168 to permit the redefinitions of ECT(1) and CE that L4S demands.  Instead it refers to a requirement for specific IETF approval before that may be done, specifically with respect to Congestion Response Differences.  This is essentially issue #21.

No such approval with respect to CE has been given to date, as far as I know.  Even if we accept the recent decision to go forward with development of ECT(1) as an input (which, incidentally, I do not), that cannot be taken as an explicit confirmation that the alternate response to CE proposed by L4S is also accepted.  By contrast the modified Multiplicative Decrease response specified by RFC-8511 *has* been officially approved, by publication in an RFC, on the grounds that it is sufficiently compatible with existing practice.

G: Incremental deployment requires compatibility with RFC-3168 AQMs, which (still) has not been demonstrated satisfactorily.  We had serious theoretical concerns which we had been able to validate by experiment, partly at the Montreal Hackathon.  Of course we have refined those results further since then.  I think this may refer to issue #22.

A: This was essentially issue #16.

B: This was essentially issue #17.

It is clear that there's a lot of common ground between the above four points, which is why I addressed them together in a single narrative at Montreal.  It might have been sensible to combine them into a single issue for tracking at that time, but I think the points that were substantiated at that meeting were just mechanically transcribed into the issue tracker.

Philosophically you could regard issue #16 (at least) as subordinate to #21, in that the latter essentially causes the former.  Solve #21 by adopting a different, non-ambiguous signalling mechanism for the high-fidelity congestion signal, and it seems likely (especially given our practical evidence to that effect) that issue #16 will also be solved.

Alternatively, we could regard #16 as the essential problem that must be solved, and #21 as the most likely culprit.  This would make #21 the more specific issue, and #16 the more general one, the reverse of what was suggested.

 - Jonathan Morton