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

["Rodney W. Grimes" <[e-mail]>]

Ingermar,

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

I am having difficutly here with the lack of any
rational for your conclusion.

Regards,
Rod

> 
> > 
> > > 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
> > *************************************

-- 
Rod Grimes                                                 [e-mail]