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

Bob Briscoe <> Thu, 25 July 2019 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1198120198; Thu, 25 Jul 2019 11:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 piX12O2hRbhY; Thu, 25 Jul 2019 11:20:07 -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 16E23120183; Thu, 25 Jul 2019 11:20:07 -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: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=byacMvIpwO1ixGGAaMSpuxBvsY8AvT9obkpqT5raZHI=; b=xrwvQ2asO2Tkgr7rvHNnQ309s1 hPyoANTRyW3W3RJ67bTHbtJU+WpbN3XZ004TdjGub+5kPW5oIbGD2KGHaQOI8EvRq39aowu3BKD3x EYUmndqDsmDyaokWtjiSZTtfniaKZ4hsVJ8QpaiwLFtn39j0Obl1hxIq2M614fNJ8U4vGMQ53lc/9 xcoKWjHlfSSvM5ntPX3doDMzfl5k6rmrIRpzkVk4z0t5zQDvUJH0ajYy96pUlz49kxWZ2z6s1+4RG pxbLQA3WkXzIN2J6R6+qH6O7+krrDYKJHx76gnZlXY07OEcgTIAo2H6+6gnxs33Z3+v+8xeARlBd1 SEadWHxg==;
Received: from ([]:47536) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1hqiLU-0003aS-DC; Thu, 25 Jul 2019 19:20:04 +0100
Cc: "Black, David" <>, "" <>, "" <>
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 25 Jul 2019 14:20:02 -0400
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: [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: Thu, 25 Jul 2019 18:20:11 -0000


On 12/07/2019 15:39, Rodney W. Grimes wrote:
>> Rod,
>> This draft appears to be focused on obtaining a TCP header bit for SCE.
> Yes, that is correct.
>> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn ( and consider how that functionality might (or might not) be usable with SCE.
> I specifically did not do what Accurate Ecn attempts as that requires
> a TCP option negotiation at connection establishment to negotiate the
> overloading of other TCP header bits.  SCE only needs 1 new bit, and
> does not alter the behavior of any current bits.
Just to correct this slightly - in AccECN, there is no explicit TCP 
option negotiation. Negotiating use of the 3 header bits also implicitly 
states that the endpoints might have implemented the TCP option. 
However, it's not mandatory to send the option (it is recommended), and 
it's not mandatory to even implement the logic to read in the option 
(that is highly recommended). Reason: the protocol has to be able to 
work even if the option is stripped on the path.

> This proposal (TCPSCE) does not in any way effect the current use of
> any of the other bits, and use of the NS bit should be fully backwards
> compatible and ignored by pre SCE implementations and does not require
> a TCP option negotiation.
> I have to get additional data but have been lead to understand that
> adding a tcp option and doing that negotiation is going to cause a
> great deal of pain in the ability to deploy accurate ecn as it is
> currently designed due to middle box inspection and handling.
There's already been concern about burning TCP header codepoints, which 
might use up space that prevents something in future. The idea of AccECN 
is to enable generic more accurate feedback. It was based on a 
protracted requirements-gathering exercise [RFC7560], and lots of 
compromising along the way.

The idea was to have a generic wire protocol with a dumb receiver, so 
that the same feedback protocol could support multiple needs for 
feedback by different TCP congestion control algorithms.

So a fairly inefficient re-use of the 'NS' TCP header flag for one 
particular experiment is very unlikely to fly, particularly when the 
experiment it supports doesn't satisfy all the requirements in 7560.

For instance, I think the reason the tcpsce draft discusses multiple 
ways of doing the feedback is that, in the presence of pure ACK loss 
(which is often due to deliberate ACK thinning), none of the three 
solutions preserve reliable delivery of the ACK signal.

In the case of Single ACK (4.1), the additional ACK load would be 

In the case of immediate ACKing of an IP-SCE (not delaying the ACK - 
S.4.2), it introduces bias (i.e. a higher proportion of ESCE ACKs to 
non-ESCE), so it becomes hard/impossible for the sender to reverse 
engineer what congestion feedback level was intended.

In the case of dithering (4.3), the congestion signal frequently becomes 
deferred (and there may not be a next packet for some time).

The requirements [RFC7560] recognise that this is a multi-dimensional 
compromise so any solution had to explain the rationale for its 
particular choices.

However, I don't think this solution is anywhere near as efficient in 
its use of the limited bit-space as many of the other rejected AccECN 
proposals have been, let alone the currently chosen one.


> Regards,
> Rod
>> Thanks, --David
>>> -----Original Message-----
>>> From: tsvwg <> On Behalf Of Rodney W. Grimes
>>> Sent: Monday, July 8, 2019 8:07 PM
>>> To:;
>>> Subject: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-
>>> 00.txt
>>> I have posted a new version with updated proper tcpm working group
>>> name of draft-grimes-tcpm-tcpsce-00
>>> (formerly draft-grimes-tcpmwg-tcpsce-00.txt)
>>> This is first cut at how SCE works in TCP
>>> Cross posting this to both tsvwg and tcpm due to overlap
>>>> A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt
>>>> has been successfully submitted by Rodney W. Grimes and posted to the
>>>> IETF repository.
>>>> Name:		draft-grimes-tcpm-tcpsce
>>>> Revision:	00
>>>> Title:		Some Congestion Experienced in TCP
>>>> Document date:	2019-07-08
>>>> Group:		Individual Submission
>>>> Pages:		5
>>>> URL:  
>>> 00.txt
>>>> Status:
>>>> Htmlized:
>>>> Htmlized:
>>> tcpsce
>>>> Abstract:
>>>>     This memo classifies a TCP code point ESCE ("Echo Some Congestion
>>>>     Experienced") for use in feedback of IP code point SCE ("Some
>>>>     Congestion Experienced").
>>> --
>>> Rod Grimes                                       

Bob Briscoe