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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 873A0120198; Thu, 25 Jul 2019 11:41:50 -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 CaETscFNL2qp; Thu, 25 Jul 2019 11:41:48 -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 713DD120191; Thu, 25 Jul 2019 11:41:48 -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=6OP/Lntt11VO0jUQMa4Dwmix2HzSFnl/gYdtA8cCj9U=; b=RfFlRAKpLRkts9ZSrvzYj9VeKv gA/A1/UHvq6oVUh6+BdUelaKO1tdJCvWvll6tQWO34a3ASwKIMQVq2agjkZBe4H3YG7FUof2r55Q4 7jbkBeV1W8QWWOPXCA7Kkp6VnKDtl+Jb+qkomZQgbhSeZoHD7PvefZDr8CdgZ1aP2MLT3HMVHfdT2 NRtUi2/wCiaVwMtPOTpD1nfoCi9bpjkqRjqKDJivhe1izOexhYxlvdzrKOMnAPw+4OkCVYBQNijQ2 CKA59xm9BZ5HWMHt+vhX9SuxoHkFj3loV+GGeGL8x660YhRFY3PEAp2+kr76JljSLRyjeQIF5l5y5 O3BwDybw==;
Received: from ([]:48218) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1hqigU-0006oU-EV; Thu, 25 Jul 2019 19:41:46 +0100
To: Jonathan Morton <>, "Scharf, Michael" <>
Cc: "Rodney W. Grimes" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <a85d38ba-98ac-e43e-7610-658f4d03e0> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 25 Jul 2019 14:41:44 -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:41:51 -0000


On 22/07/2019 10:48, Jonathan Morton wrote:
>> On 21 Jul, 2019, at 9:01 pm, Scharf, Michael <> wrote:
>> Please be aware that there is also draft-ietf-tcpm-generalized-ecn-04, which in the current version has a dependency on draft-ietf-tcpm-accurate-ecn for certain cases.
>> Just to state the obvious: These documents are work in progress in TCPM and TCPM always welcomes feedback.
> I just skimmed through it to remind myself of certain details.  Most of it only applies once AccECN has completed negotiation, so the same arguments apply.
Actually in 2 out of 7 cases, not "most". See table 1 in the spec, which 
is intended for people who skim.
> I do however note that SYN is described as the most important packet to protect with ECN, and this is of course sent before AccECN negotiation has completed.  Further, if the SYN-ACK then indicates that AccECN is *not* supported by the remote end - which would be the case for both an SCE endpoint and any conventional one - a conservative IW of 1 segment SHOULD be conservatively selected, with no modification for the increasingly common IW10 case (the default for current versions of Linux).  This incurs a flow completion time delay of approximately 3 RTTs, which could be perceptible to end users.
The draft explains: the reduction to IW1 is in the client to server 
direction. It cites measurement studies that show it's unusual to get >1 
initial packet in that direction anyway. And the reduction to 1 is only 
a SHOULD. An implementation could choose 2 for instance.

When new to the IETF, it's even more important to read the draft before 
sending critique (cos you won't have heard all the previous discussion). 
Otherwise it burns busy people's time on the list unnecessarily.

> A less extreme response may be justified here, given that the strongest signal that may have been missed by the lack of ECN feedback is a CE mark, for which the most conservative TCP response is to halve the cwnd.  So for an IW4 sender, the IW should be reduced to 2, and for an IW10 sender, the IW should be reduced to 5.  This would reduce the flow completion penalty to 1 RTT when encountering a non-AccECN endpoint.
Again, pls read the rationale for fall-back to IW1 in the draft. 
(There's a whole rationale section after the normative text section, 
with linked referenced from each section of it).

Briefly, if you get a CE, it implies the queue was up to it's marking 
threshold 1 RTT ago, presumably with traffic from another flow(s). So 
adding more than 1 packet is likely to be pointless and 
counterproductive for them and you.

But this is only a SHOULD, cos experiments might prove IW1 is 
unnecessary (if anyone is motivated to bother because they have an app 
that starts with >1 request data packet).


>   - Jonathan Morton

Bob Briscoe