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

Bob Briscoe <> Wed, 29 March 2017 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C46A12968F; Wed, 29 Mar 2017 00:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 bbtCcDDboyU5; Wed, 29 Mar 2017 00:26:05 -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 7957D128B4E; Wed, 29 Mar 2017 00:26:05 -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:Cc:From: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=mbaxm6qX/RWhN04q2VeBjZCwkq0hGPdfc+ukib4DEE8=; b=NsiuoZ69YOOhfwBPQYk3gUzhJf HT/H8TgbaUpZx7hJNZFSqks4mBDhbMZG3juJMZW/jqrm2zYzkdoB2sWmbsVwBpCWWOmgHs/uw9lxR ZIzsuknfCOIA/Nn8ikEcidQU0MnwDfbq/BSJo08w2ElKOhT2s5jzqVYwW71B8YW5co/Zxe1ftCD2h RldJTNRkDykl6sIXtH6u2R/mP+Q1g1l7EaI5aIQ/7mzBxAgKpok8JvK9rTCa2xB2FEqg8qwto3tuW SQNOESvCAgRjiVmuvsmdlRn7OZcCYdQUSNbt5xXzo0x0YtZyHXW/eW8yZ3uiV+33W4ucflMhF+EHa bAtrdrpg==;
Received: from [] (port=55824 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <>) id 1ct7zX-0003Q6-8t; Wed, 29 Mar 2017 08:26:03 +0100
To: Dave Dolson <>
References: <>
From: Bob Briscoe <>
Cc: TCP Prague List <>, tsvwg IETF list <>
Message-ID: <>
Date: Wed, 29 Mar 2017 08:26:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; 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: Wed, 29 Mar 2017 07:26:08 -0000


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.



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