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

Bob Briscoe <> Fri, 22 July 2016 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3512012D52D for <>; Fri, 22 Jul 2016 05:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AXz47wT2aAHk for <>; Fri, 22 Jul 2016 05:52:53 -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 6444A12D1A1 for <>; Fri, 22 Jul 2016 05:52:53 -0700 (PDT)
Received: from ([]:43160) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1bQZwh-0003jU-Ec for; Fri, 22 Jul 2016 13:52:51 +0100
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 22 Jul 2016 13:52:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.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.17
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: Fri, 22 Jul 2016 12:52:56 -0000


Assuming you're using an existing RED implementation...

Advice #1: If you can, make ECT(1) separately configurable from ECT(0), 
even if you set them both to the same config for now.
Advice #2: Don't drop ECT(1) if you are marking ECT(0). That would just 
introduce yet another odd behaviour.
                   As long as you've satisfied advice #1, you can change 
this decision in future if it proves better.
Advice #3: Once we have some L4S hosts, it might be possible to at least 
config ECT(1) to use the instantaneous queue size, rather than a 
smoothed queue size (ie RED's EWMA const = 2^0  = 1).

If you're actually implementing the AQM now, my advice would be 
different. I assume you are just talking about configuring an existing 

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.
OK. But we'll need to do some experiments first.

> -Dave
> _______________________________________________
> tcpPrague mailing list

Bob Briscoe