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

Gorry Fairhurst <> Mon, 04 November 2019 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51AE212008D; Mon, 4 Nov 2019 01:41:36 -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 S8o7YCa63kol; Mon, 4 Nov 2019 01:41:34 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id D1BCA12002E; Mon, 4 Nov 2019 01:41:33 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 0FB251B000A3; Mon, 4 Nov 2019 09:41:25 +0000 (GMT)
Message-ID: <>
Date: Mon, 04 Nov 2019 09:41:25 +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: Sebastian Moeller <>
CC: Jonathan Morton <>, "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 09:41:36 -0000

On 04/11/2019, 09:11, Sebastian Moeller wrote:
>> On Nov 4, 2019, at 09:19, Gorry Fairhurst<>  wrote:
>> 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.
>> Gorry
> Question: Since the ABE RFC is marked experimental while RFC3168 is a proposed standard, why should tcpsce fall-back to RFC8511 instead of RFC3168?
Because, that is why the WG publishes EXP RFCs.

My own understanding, is that to publish a PS update to TCP, it is good 
to have deployment experience.
To get there, you need to alreday have completed detailed experiments in 
labs, etc, and show safety
there and then have a proposal that has been accepted by the WG and 
developed into an RFC
- The EXP RFC. Next comes the deployment, and decision about what to do 
next - many TCP RFC's remain EXP.

In this case, the purpose of the RFC8511 experiment is to "collect experience with the deployment of ABE
and confirm acceptable safety in deployed networks that use this update to TCP congestion control"
and then to "propose it as a Standards-Track document in the future".  (Section 6).

> I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent experiments (and introduce undesired fate-sharing).
That can indeed be an issue, if a new proposal comes along that depends 
on one of the existing experiments. That needs careful thought.
> Sebastian