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

[Jonathan Morton <[e-mail]>]

> 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

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

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

> 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