Re: [tsvwg] Scope of the L4S Experiment (was: Guard DSCP)

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

Hi Jonathan

The comment round the IANA registry was left without comments, so I repeat
it again

>>https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml   
>>The latter lists ECT(1) for experimental use only, with a reference to
RFC8311
>>My interpretation is that for future deployment of AQMs (fq-codel, cake)
only ECT(0) should be used for classic ECN. This means that this part of the
problem >>goes away gradually.
Is this something that can be agreed upon ?

Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 5 maj 2021 15:47
> To: Ingemar Johansson S <[e-mail]>
> Cc: Steven Blake <[e-mail]>; Black, David
> <[e-mail]>; C. M. Heard <[e-mail]>; TSVWG
> <[e-mail]>
> Subject: Re: [tsvwg] Scope of the L4S Experiment (was: Guard DSCP)
> 
> > On 5 May, 2021, at 12:24 pm, Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]> wrote:
> >
> > As mentioned below RFC4774 is a BCP, I had to look up the meaning of
this.
> My understanding of  (https://tools.ietf.org/html/rfc1818) is that it
lists a set
> of guidance rules at the time of writing.
> 
> RFC-1818 has status HISTORIC.  The document you should probably be
> reading is RFC-2026, Section 5:
> 
> 	https://tools.ietf.org/html/rfc2026#page-15

[IJ] Good point, thanks

> 
> >    The BCP subseries of the RFC series is designed to be a way to
> >    standardize practices and the results of community deliberations.  A
> >    BCP document is subject to the same basic set of procedures as
> >    standards track documents and thus is a vehicle by which the IETF
> >    community can define and ratify the community's best current thinking
> >    on a statement of principle or on what is believed to be the best way
> >    to perform some operations or IETF process function.
> 
> My view is that BCPs have approximately the same force as Proposed
> Standard RFCs, but cover a different class of subject matter - policy
rather
> than technicalities.  It is possible to deviate from what a BCP states,
but there
> had better be a very good reason for doing so.  In this case, RFC-4774
details
> considerations for the standardisation process in the very specific field
of
> congestion control signalling, which is precisely what we are discussing
today.
> 
> I think you are also seriously misinterpreting what RFC-4774 states.  It
talks
> very specifically about "old routers" as the context for coexistence
between
> "alternate ECN" traffic (ie. L4S), RFC-3168 and loss-based traffic.  That
means
> fq_codel and Cake as they exist *today*, as well as any single-queue AQMs
> that may be out there, or which may yet be deployed conforming to RFC-
> 3168 - and, incidentally, the bog-standard dumb FIFO, for completeness'
> sake.  You cannot sidestep that context merely by proposing that fq_codel
> and Cake be changed; you must actually show that the change has already
> taken place.  As of right now, it has not.

[IJ] Point taken. But then again, all network gear have a limited lifetime
(mentioned in my email), either economic (increased Opex, energy cost/bit)
or plain physical (things break down, especially home gateways do).  

> 
> > Option 3:  The alternate ECN semantics are defined in such a way as
> >    to ensure the fair and peaceful coexistence of the alternate-ECN
> >    traffic with best-effort and other traffic, even in environments that
> >    include old routers that do not understand the alternate ECN
> >    semantics.
> 
> RFC-4774 Option 3 requires that the new, alternate ECN proposal is
> inherently compatible with existing traffic at existing routers.  That is
> categorically *not* true of L4S.  Option 3 therefore does not apply to
L4S.
> 

[IJ] That is subject to interpretation, just because what you say may
happen, does not mean that it will happen. In addition there is work on
fall-back solutions in TCP Prague. Sure these are not bullet proof and you
found a few cases where it fails. But the question is how serious these
issues are?. Sure we can continue and discuss this for a few years more and
even device a guard DSCP. But by the time that we are done, the majority of
these old routers that we discuss today have passed EOL and have been
replaced by devices that treat ECT(1) as experimental (or L4S) 


> > Option 2:  All alternate-ECN traffic deploys some mechanism for
> >    verifying that all routers on the path understand and agree to use
> >    the alternate ECN semantics for this traffic
> 
> 
> RFC-4774 Option 2 is a slightly more realistic target for L4S.  The
"Classic ECN
> detection heuristic" algorithm aimed in this direction, as does my "dual
DSCP"
> proposal for retrofitting to L4S.
> 
> > Option 1:  Alternate-ECN traffic is clearly understood as unsafe for
> >    deployment in the global Internet
> 
> If neither Option 2 nor Option 3's requirements are met, then Option 1 is
the
> only viable solution.  That is what requires the use of a containment
> mechanism to explicitly keep L4S within the participating network(s).
> 
>  - Jonathan Morton