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

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

Hi

 

My comment, admittedly with too little experience in IETF nomenclature and lingo so it is not too unlikely that I am off here.

I read both RFC4774 and 

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.

 

Then we have already deployed devices, and here opinions differ around everything from upgradeability to expected life time of these devices. And here RFC4774 and in particular option 3 can be applicable.

 

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.  But quote:“The resulting document is viewed as having the technical approval of the IETF, but it is not, and  cannot become an official Internet Standard”. My understanding is then that a BCP gives more slack than a proposed standard. 

 

Can option 3 in RFC4774 be side stepped ?, if RFC4774 is read as being an official Internet standard, then the answer is definitely no. But RFC4774 is a BCP. 

The question is then, is it safe enough to side step option 3 ?. Opinions differ here. My opinion is that there I (still) little evidence of deployed and enabled RFC3168 AQMs and it is furthermore a limited set of few corner cases where L4S traffic can potentially starve out classic ECN traffic.

Also, internet gear (routers, switches, home gateways) have an economical or physical lifetime of just a few years. So my impression is that a large share of the deployed gear has been upgraded or even replaced by the time that we have standardized a guard DCSP. And then we have allocated a lot of time for very little gain and in the process delayed L4S standardization even more.

 

/Ingemar

  

 

From: tsvwg <[e-mail]> On Behalf Of Steven Blake
Sent: den 4 maj 2021 19:06
To: Black, David <[e-mail]>; C. M. Heard <[e-mail]>
Cc: TSVWG <[e-mail]>
Subject: Re: [tsvwg] Scope of the L4S Experiment (was: Guard DSCP)

 

On Tue, 2021-05-04 at 16:35 +0000, Black, David wrote:

Mike,

 

> I had certainly understood the intended scope to be sets of cooperating/participating networks rather than the Internet as a whole.

> How could it possibly be otherwise, with a change in the semantics of CE that is incompatible with existing standards, without at the same time obsoleting those standards?

 

Short answer (as I understand it) – L4S was originally intended to be compatible.  For details of what compatible means in this context, see Section 4.3 of RFC 4774 (Option 3:  Friendly Coexistence with Competing Traffic, https://datatracker.ietf.org/doc/html/rfc4774#section-4.3).

 

> The evidence presented here strongly suggests to me that L4S is not benign to existing standards. If it is to be used experimentally, it must be contained.

> If it is to be used internet-wide, then existing incompatible uses should be obsoleted.

 

You're not the only person who has expressed the view that L4S is not able to proceed under RFC 4774 Option 3.

 

Everyone - when responding to this message, please keep in mind that RFC 4774 is a BCP (Best Current Practice) document, namely BCP 124.

 

Thanks, --David

 

From: C. M. Heard <[e-mail] <mailto:[e-mail]> > 
Sent: Tuesday, May 4, 2021 12:40 AM
To: Black, David
Cc: TSVWG
Subject: Scope of the L4S Experiment (was: Guard DSCP)

 

[EXTERNAL EMAIL] 

On Tue, Apr 27, 2021 at 3:57 PM Black, David wrote:

the appropriate L4S experiment scope may be sets of cooperating/participating networks rather than the (originally envisioned) Internet as a whole.

 

I had certainly understood the intended scope to be sets of cooperating/participating networks rather than the Internet as a whole. How could it possibly be otherwise, with a change in the semantics of CE that is incompatible with existing standards, without at the same time obsoleting those standards?

 

When Differentiated Services was introduced by RFC 2474, the existing TOS standard was obsoleted, based on good evidence that it was unused (there was only one implementation of TOS routing, IIRC, and negligible deployment). It didn't get introduced as an experiment.

 

When the original experimental incarnation of ECN was specified by RFC 2481, it could be introduced as an internet-wide experiment because prior standardized uses of the field had been obsoleted on good evidence of non-use, and there was good evidence that harm would not be caused to deployed systems.

 

The evidence presented here strongly suggests to me that L4S is not benign to existing standards. If it is to be used experimentally, it must be contained. If it is to be used internet-wide, then existing incompatible uses should be obsoleted.

 

One or the other, please. Don't deploy L4S internet-wide and call it experimental.

 

Mike Heard

 

 

To reiterate what I wrote on March 26: if there is really so little RFC 3168 ECN deployed in the Internet that it can be safely ignored for an Internet-wide ECN experiment with incompatible signaling and congestion response, then the only responsible thing to do is to go through the process of moving RFC 3168 to historic.

 

 

Regards,

 

// Steve