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

[Ingemar Johansson S <[e-mail]>]

Hi
I have now read #16, #17 and #21 several times and my conclusion is that #21
can be closed. 

/Ingemar

> 
> > 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
> 
> 
> 
> End of tsvwg Digest, Vol 194, Issue 4
> *************************************