Re: [tsvwg] ECN as a classifier

Bob Briscoe <> Wed, 01 January 2020 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F071612006E; Tue, 31 Dec 2019 16:49:17 -0800 (PST)
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_HELO_NONE=0.001, 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 hPFGNmvojrQo; Tue, 31 Dec 2019 16:49:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C038120019; Tue, 31 Dec 2019 16:49:15 -0800 (PST)
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:References:Cc: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=jPD+Ds3JxliQmh6xMNfPFWr7JPp1d+CLzCIOifRHmNQ=; b=gj2hFML9mRvBPKDG3mt/1KD+6I +lY1N5H5R2UXhTN9T17ks8ziqRg0CGGfaj9Sdj+FX4f4bJZmlnWDXkyuFvEfHElmc3ly8cD4uBoLD eysMVKnQtYDix/DExHl+ICtKoKETaMkrqmXyOxj/mi8DUSY6AX5aVPdkPNZpw8SYH3AG/g5j75eVu LDqoMnmha7vGLPGh8qUp1K0PiKNbvkOnLKSiGTjdSy7l62TPlgESgNsPp/coH5spCmyVOLzegD0+g JdYvWxNrTP0Cn3ymzDZ1IPjx0XXLhrgxkfMj8bgcBZyCeV6aGinJMxTCax37UmlZEwkWs++2+Ss8V OPk/8Nrw==;
Received: from [] (port=39360 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1imSCH-0002In-8V; Wed, 01 Jan 2020 00:49:13 +0000
To: Jonathan Morton <>
Cc: Roland Bless <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Wed, 1 Jan 2020 00:49:12 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
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: [tsvwg] ECN as a classifier
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jan 2020 00:49:18 -0000


On 31/12/2019 17:42, Jonathan Morton wrote:
>> On 31 Dec, 2019, at 6:55 pm, Bob Briscoe <> wrote:
>> However, the original RFC3168 ECN architecture (that is incompatible with SCE) remains and will remain more widely supported in the Internet, probably for decades. Indeed, even today, the RFCs to make that change to all encapsulations (not just IP-in-IP tunnels) are not past the WG stage yet.
>> Tunnels and encapsulations are everywhere. Jonathan M says it doesn't matter if the SCE signal gets black-holed in tunnels and encapsulations.
> It's not that it doesn't matter at all - erasing the SCE signal would degrade the behaviour to RFC-3168 standard.  But that's an acceptable fallback position which allows for incremental deployment, even before all the tunnels are upgraded to the new standard.
> Thus the existing RFC-3168 compliant architecture is *not* incompatible with SCE as you claim.  So please don't claim that, when it isn't true.
You can say SCE is backward compatible with 3168 tunnels. But it is 
disingenuous to say it the other way round - that 3168 tunnels are 
compatible with SCE. Because many/most people will understand this to 
mean that 3168 tunnels are compatible with what SCE aims to achieve.

(An analogy would be to claim that a bare FIFO queue is compatible with 
ECN, which it isn't. Yes, ECN is backward compatible with FIFO queues, 
but not the other way round.)

When you say the 3168 architecture is compatible with SCE, you have 
quietly defined what SCE aims to achieve as "either SCE or 3168 
performance". This allows you to make a statement that only reveals the 
good part of a truth that is mostly bad. I have noticed you play with 
words like this a lot, presumably because you think that you might fool 
some casual observers.

To state the whole truth you ought to say, if a 3168-architecture tunnel 
contains the SCE bottleneck, until the tunnel is updated to support the 
SCE architecture SCE will always fall back to 3168 performance.

This adds up to 4 independent upgrades being needed before SCE can 
provide any benefit: sender, receiver, bottleneck AQM and potentially 
tunnel as well. Worse, tunnel processing is typically implemented in 
hardware. But you always describe SCE as a minor change.

Happy New Year

>   - Jonathan Morton

Bob Briscoe