Re: [tcpPrague] Treatment of ECT(1) pre L4S

This message is written as the author of the ECN Experimentation draft, not as a WG chair.

This topic was discussed in Chicago with a request to me as author of the ECN experimentation draft to check that both options below are permitted.  These options are for network nodes that do not implement L4S dual queues but for which there is a desire to do something reasonable with ECT(1) in light of L4S usage.  The crucial ECN experimentation draft text is in Section 4.2 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation#section-4.2):

-----------------------------------
4.2.  ECT Differences

   Section 5 of RFC 3168 specifies that:

      Routers treat the ECT(0) and ECT(1) codepoints as equivalent.

   In support of ECT Differences experimentation, this memo updates RFC
   3168 to allow routers to treat the ECT(0) and ECT(1) codepoints
   differently, provided that the changes from RFC 3168 are documented
   in an Experimental RFC.  The specific change to RFC 3168 is to insert
   the words "unless otherwise specified by an Experimental RFC" at the
   end of the above sentence.
-----------------------------------

The ecn-l4s-id is intended to become an Experimental RFC, and hence would benefit from the added "unless otherwise specified by an Experimental RFC" text.  That added text imposes no limits on the scope of "otherwise specified" - we are relying on the combined good sense of the draft authors, WG members, the IETF community and the IESG to ensure that nothing horrendous in this area makes it into an Experimental RFC ;-).

I see no problem with an Experimental RFC for L4S specifying not only experimental changes to network nodes that fully participate in the experiment (dual queues) but also specifying experimental changes for network nodes that only partially participate - the options below are for network nodes that only partially participate.

Thanks, --David

> -----Original Message-----
> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob
> Briscoe
> Sent: Wednesday, March 29, 2017 3:26 AM
> To: Dave Dolson <ddolson@sandvine.com>
> Cc: TCP Prague List <tcpPrague@ietf.org>; tsvwg IETF list <tsvwg@ietf.org>
> Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S
> 
> Dave,
> 
> I've cc'd this to tsvwg.
> We will put text in the ecn-l4s-id draft unless there is not consensus
> from others about this yet.
> 
> I agree with Koen now.
> 
> To be clear, I believe that a classic AQM supporting only RFC3168
> (Classic) ECN:
> * should never alter the ECT(1) field
> * should be configurable between the following two behaviours:
>    - [default] treat ECT(1) as if it does not support ECN, so drop where
> it would have marked CE
>    - treat ECT(1) as if it is ECT(0)
> 
> I am less keen than Koen on adding the latter option - I prefer clear
> simple advice to avoid confusion.
> So IMO, if you don't want another config knob, it would be OK to just
> support the default.
> 
> Ideally, once the DualQ specs are approved, the AQM should also be
> upgraded to support Dual Qs and the squared relationship between them.
> 
> Sorry it's taken so long to confirm this.
> 
> Cheers
> 
> 
> 
> Bob
> 
> On 22/07/16 12:01, Dave Dolson wrote:
> > If an operator were to deploy ECN today, pre L4S, what should be the
> treatment of ECT(1)?
> >
> > I believe, from a discussion with Koen, that the safest approach is for a pre-
> L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1)
> were treated the same as ECT(0) then new experimental TCP-Prague flows
> would out-compete any ECT(0) traffic.
> >
> > Is this agreed? If so, should it be recommended somewhere?
> >
> > Note that I got mixed answers on this from other IETF folks, so I think it is
> worth sorting out.
> >
> >
> > -Dave
> >
> >
> >
> > _______________________________________________
> > tcpPrague mailing list
> > tcpPrague@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpprague
> 
> --
> __________________________________________________________
> ______
> Bob Briscoe                               http://bobbriscoe.net/
> 
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague