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

From: Bob Briscoe <[email-masked]>
Date: Wed, 29 Mar 2017 08:26:00 +0100

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/