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

[Gorry Fairhurst <[e-mail]>]

On 05/05/2021 19:44, Black, David wrote:
> As a WG chair, without commenting on the rest of this discussion, I agree with this portion of Jonathan's summary of the role of BCPs at IETF:
>
> 	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 the past, I have seen the IESG apply more rigorous review to drafts intended for Best Current Practice status than to drafts intended for Proposed Standard status, but that can vary from year to year.
>
> Thanks, --David

+1 on the status of BCPs.The key question I have is whether this BCP is 
relevent to this proposed use.

* The reclassification of RFC8311 in 2018 - as a PS - has enabled new 
experimental use of the ECT(1) codepoint by an RFC. This was not an 
option open to the IETF when RFC 4774 was published. RFC8311explicitly 
provides ABE (published as an EXP RFC in 2018) and L4S as an example.

* I would expectevidence/rationale in the L4S draft to explain why RFC 
4774 (a BCP) is not relevant. This might clarify whether L4S is an 
update to RFC 3168 (defining both transport and network aspects), or an 
instance of RFC 4774 (which I read as targeting multi-level ECN marking 
and use in an edge-to-edge context – e.g. as  realised in PCN, RFC 5696).

Gorry

>
> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: Wednesday, May 5, 2021 9:47 AM
> To: Ingemar Johansson S
> Cc: Steven Blake; Black, David; C. M. Heard; TSVWG
> Subject: Re: [tsvwg] Scope of the L4S Experiment (was: Guard DSCP)
>
>
> [EXTERNAL EMAIL]
>
>> 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc1818__;!!LpKI!1k2aHtuNmS8NqaE6aw6FbJXpRSyyQBXX9-m0yAnCxJRUpaTLhJVSFb9QUO9eEdep$ [tools[.]ietf[.]org]) 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc2026*page-15__;Iw!!LpKI!1k2aHtuNmS8NqaE6aw6FbJXpRSyyQBXX9-m0yAnCxJRUpaTLhJVSFb9QUFSPRMK6$ [tools[.]ietf[.]org]
>
>>     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