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

Bob Briscoe <> Sat, 08 April 2017 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 963F41205D3; Sat, 8 Apr 2017 02:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EpdIQHbS_5jD; Sat, 8 Apr 2017 02:05:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 850B61293EB; Sat, 8 Apr 2017 02:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q+PzN+hJydlZjAUcnVEdzLwappJmJC28KwGpjZcn0zM=; b=U7yvb249YOgfrNxMRwQY1mIBXQ CEUV97kX+48FMHjRtNt/+fcFo3iNoDqBYUjtEIwgiv7ure9YQfESB1nmjK/mvuLXa3jEXzWd4izGA BaGfMB98gQ0WG73TrEglADRQWX74esC3GISbvRiT+AgRnbE4tgGVnSBVISv+ARz0SFH8VkuAtXzj4 SWySVh+zyyx9mVLvu8XLw43pFxwjbXcT+3pn5/OENYTqkICnlM8ckrBVR74OMFQHQ23nG+WVAFjk+ x1fXWcE4QiGjis3yHiD9d8Xi62yTvGMpGMt68YOk3RMnUZgPN6Q422ND04chJ46zHrYvnB6DGFsp6 NZndrPEg==;
Received: from ([]:52786 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <>) id 1cwmJX-0004NA-K2; Sat, 08 Apr 2017 10:05:47 +0100
To: "Black, David" <>
References: <> <> <>
Cc: TCP Prague List <>, tsvwg IETF list <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sat, 8 Apr 2017 10:05:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Apr 2017 09:05:55 -0000


Thx for confirming we are OK to go ahead with this.

What's the status of the ecn-l4s-id adoption call?
If it's about to be formally adopted, I could add in this text at the 
same time as changing the filename to draft-ietf...


On 08/04/17 01:34, Black, David wrote:
> 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 (
> -----------------------------------
> 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 [] On Behalf Of Bob
>> Briscoe
>> Sent: Wednesday, March 29, 2017 3:26 AM
>> To: Dave Dolson <>
>> Cc: TCP Prague List <>rg>; tsvwg IETF list <>
>> 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
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe                     
>> _______________________________________________
>> tcpPrague mailing list
> _______________________________________________
> tcpPrague mailing list

Bob Briscoe