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

[Jonathan Morton <[e-mail]>]

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

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