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

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

Jonathan.

This part of the discussion was around new deployments of AQMs. See
https://mailarchive.ietf.org/arch/msg/tsvwg/Ge7cbzFFQyFzpHEMGGnG6AqnjnY/ .
This appears to get lost in the iterations. In other words, it does not deal
with already existing AQMs out there, that was a separate topic where
RFC4774 comes into the discussion.

Please see more inline [IJ3]

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 5 maj 2021 22:34
> 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 11:07 pm, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > RFC8311 updates RFC3168 and RFC3168 is updated by RFC8311 among
> > other... In addition, the IANA registry lists ECT(1) as for
> > experimental use.. RFC8311 states, "unless otherwise specified by an
> experimental RFC...".
> 
> As I have explained before, RFC-8311 does not *obsolete* RFC-3168 - that
is
> a different and more drastic step than updating it.  This means that
> middlebox implementors can continue to refer to RFC-3168 as the only
> necessary authority on what an ECN AQM needs to do.  RFC-3168 specifies
> that as far as a middlebox is concerned, ECT(0) and ECT(1) are synonymous.

[IJ3] But I don't see why it is necessary, sure it could be a possibility in
the long term, but for L4S it is not really necessary. It is sufficient with
the wordings in RFC8311.

> 
> A new RFC, satisfying the requirements in RFC-8311, could further update
> RFC-3168 by specifying alternate behaviour in response to ECT(1), or
> permitting middleboxes to change ECT(0) to ECT(1) (or vice versa) under
> certain conditions.  The "new AQMs" proposed as part of the L4S and SCE
> systems would rely on such allowances.  But implementors would still have
a
> choice as to whether to implement RFC-3168 or the new RFC, and there
> would be no requirement to change existing middleboxes that already
> conform to RFC-3168.  We should therefore expect RFC-3168 middleboxes to
> continue to be a feature of the Internet.

[IJ3] That RFC would then be L4S-ID (recall RFC8311 ""unless otherwise
specified by an experimental RFC..." , then the only sensible way forwards
is to move it L4S-ID to WGLC. That should give sufficient guidance for
implementors of new network gear as RFC3168 clearly states, updated by
RFC8311. 
And note that SCE is not subject to discussion. This is only about L4S .

> 
> Requiring all existing ECN AQMs, which at present rely on RFC-3168, to be
> changed to treat ECT(1) differently, would require obsoleting RFC-3168 so
> that it is no longer an active Internet specification.  There is a process
to do
> so, but I do not think that process would succeed if initiated.

[IJ3] As mentioned above, already existing AQMs were not part of this
particular discussion, that was a separate part where RFC4774 came into
play. 

> 
>  - Jonathan Morton