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

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

Hi Jonathan
Please see below, marked [IJ2]

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 5 maj 2021 17:50
> 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 6:05 pm, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > 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 ?
> 
> No, because there are two aspects to use of ECT(1) at play.  You have
found
> only one of them.
> 
> RFC-3168 states that ECT(0) and ECT(1) shall be treated identically by
> middleboxes.  It is of course possible for a later specification to update
that,
> but unless and until RFC-3168 is obsoleted, middleboxes that treat ECT(1)
> identically to ECT(0) will continue to exist and be newly deployed on the
> Internet.  This aspect of RFC-3168 was included *specifically* to provide
a
> consistent baseline behaviour upon which experimental uses of ECT(1) could
> rely, so it seems unlikely to be discarded without serious justification.
> 
> One such experimental use was ECN Nonce.  This emitted an unpredictable
> pattern of ECT(0) and ECT(1) from the sender as a way to verify whether
> correct RFC-3168 semantics existed on the network path and in the
receiver.
> It was never deployed, but it would have relied on that aspect of
RFC-3168.
> 
> Another such use is by SCE, which also relies on existing ECN-aware
> middleboxes implementing this aspect of RFC-3168.
> 
> If L4S cannot operate safely in an environment where existing middleboxes
> correctly implement well-established RFCs, then L4S has a problem, not the
> RFC in question.

[IJ2] This does not make sense at all.
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...". Well that
RFC is https://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-l4s-id/ which
has been waiting for WGLC for some time now. 
Besides this, ECN Nonce is historic and SCE is not of interest in this
context, as we discuss L4S and not SCE

> 
> >> 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).
> 
> Right now, that process is *increasing* the number of RFC-3168 compliant
> middleboxes on the Internet, not reducing them.  The reverse will only
> *begin* to occur if you can convince the IETF to obsolete RFC-3168.  I do
not
> see any chance of that happening.
> 
>  - Jonathan Morton