Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

Gorry Fairhurst <> Mon, 04 November 2019 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D373B1208E6; Mon, 4 Nov 2019 00:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id un9dMO5rQV2U; Mon, 4 Nov 2019 00:19:58 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id 93A69120894; Mon, 4 Nov 2019 00:19:58 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 535B31B00064; Mon, 4 Nov 2019 08:19:51 +0000 (GMT)
Message-ID: <>
Date: Mon, 04 Nov 2019 08:19:50 +0000
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jonathan Morton <>
CC: "Rodney W. Grimes" <>, "" <>, "Rodney W. Grimes" <>, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 08:20:01 -0000

On 03/11/2019, 13:08, Jonathan Morton wrote:
>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<>  wrote:
>>> With respect to draft-ietf-tcpm-accurate-ecn and
>>> draft-grimes-tcpm-tcpsce compatibility:
>>>    When accurate ecn (AccECN) fails to negotiate an AccECN capable session
>>>    it falls back to RFC3168 conformance, leaving a state that is fully
>>>    compatible with SCE, hence they are compatible.
>> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN?
> RFC-8511 doesn't change the signalling on the wire relative to RFC-3168.  That was the sense intended here.
>   - Jonathan Morton
RFC3168 describes both endpoint behaviour and network functions. To me, 
this sentence is about
how you receive indications of incipent congestion, the sender can 
change from using only CE to using CE plus
the accurate information -or fall back to using just CE - ultimately it 
falls back to just detecting congestion (loss,delay).
So yes, the CE signal could be regarded as input to SCE.

The endpoint behaviour, I think, should fall back to RFC8511.