Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.txt

"Scheffenegger, Richard" <> Sat, 05 February 2022 12:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA71D3A18D2; Sat, 5 Feb 2022 04:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eZVCKIPoX2l; Sat, 5 Feb 2022 04:02:09 -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 35DB53A18CA; Sat, 5 Feb 2022 04:02:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1644062481; bh=tldLGdS2h58KMciA3AH6zsnITrvuhsWNtLm4zl0MgMs=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=E2RJfgn7lR3bfHE7/BW/lHnsV5unSLUd/fmkfN5GN49DAtpGqCns58QKNrDFNhTWO LQcb3Sy6AVKx53olNoGp0w3pUnbYhUiJb6R33qJSfQcAyb3Rlw3YmCku/ol6cTVM59 hI4dZ6Y9SSGSx+S597DVXwjBv/owu8A/FbdUQ66Y=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1N4hzZ-1mFNHL3DaJ-011kXa; Sat, 05 Feb 2022 13:01:20 +0100
Message-ID: <>
Date: Sat, 05 Feb 2022 13:01:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
To: Vidhi Goel <>, Bob Briscoe <>
Cc: Richard Scheffenegger <>, " Extensions" <>, Mirja Kuehlewind <>
References: <> <> <> <> <>
From: "Scheffenegger, Richard" <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:XFrxiI5ZqWFkAo7fMY94iRM/yffkHzLWkCsFCXSdoY/0kedvBLv /e6afGdBbegJLC9QMHTWvc/0dSBgMI49d5ZkCaoUoMRcPRIIxjsqvWg58dmUSbDujTt+evp SzYyDuaN9IIafZM9UnfJor9HO33jyx1lSAPqxPTCAKRElYHa5HorNmQsvRjwL1rQzD1CkkB OTdqMDWSInpJiPmmEOvPA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:aVP2p13wsnY=:IfawQZGkf76uJWabyAcgqb x3cd7LCD0lmN7B2Wl2WeC3mmTqRkU3DhWULZpu8/Aa3zcZBTNBR3nsKqWKlQgt6eYHnS8OYB+ mVAhvdPLnvLwoxv+SbiZVLVaVfFSUib7qxf2CMHSX57JOkkgb7gLiZzhC768JMF9Zpof5y/Uo E0ak4oPUiZpojTWVLCoT6PHl2Pp09y6xEC6LVcr80s1a/mbMq/KbIkFf5t1daMDi+cH8cyAMs 9P7Jil/O5suvqrbjwq8C2Utfv9MphcZEc85Dl/htyFGmr8Dypvx0I2FWQV4KLEZzrc9YErlvD C1EFQVDf0CfZvy+kOzm0kuFnieaeyLbp9JthATyQbcOV+bPo+dvNHDNYqdNaliVN/7isSqu1E SOUzlI7E9xskqiWII5eMrRx9v4N5pj2W8D2cALalOCwiU/3GXAbH7Ab2ysc0agR/pRB1cIbu4 0WdI8cVqHBDgcQppYfkJ2+JxbUZIjMAVdUxlQuaOt0VLU7NcHrUFzz/BYMafZ2AWFtHWtead+ Dhl7UpOY/7pkIeJGdF4UjkCuH/RSTKUCdQWFAP4c9lYlI5PjfNoGl0k4No+thkCcZF8DlIdC/ jjY3Wz2hY3NLKH8P1IcFopi2z7Fa5CokWp3SnxMojLG1nQ9O3qAwnOjWX86sLuEDNmr51Qxji dMMbbNxTy/J7ff/7u6Ck6Zx5BvBfGloslbKI+SUIcWTTWAK/6tNuaB3sHma8LFSSt8+LhYaW1 gCxC0pNPRt6HQOxZyi1oD6wqgz4pNxHdPUOPJjek7B9RVl25AoE44YaHqEPEFYHBBW1qnWuRe LzUv8FaaKop3pJmF5vqeWYSRAMfgXAly9Wmq3dd+yVcQVPRwGV1VguBdySSPPJOFKfyi1/djI Y/Tq0raK2rqmeiUBZb3H8VacquRJi07dhsm6pLgjk/DdN+EMlg+E9hM/0p9SmQLTDSsCULyDy 2iTy0PSTUHaH1HrnB0oBxCp++4Lk2pbWYDd3F4yso5Qbthv0SaTDt5q8tmf6n2Ztr//9yLSZN RLXa/1xViQ0CWtWyvwk8aPIBlZFfB2mTS120W0+48r5Kv5hOWrqHAhxahHxFJTkRCFk7v7gOn 5HfHMbrOARzvYA=
Archived-At: <>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.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: Sat, 05 Feb 2022 12:02:14 -0000


Thanks for reading the draft very closely!

Well, in the non-ECT SYN case, where the SYNACK indicates an ECT (ect0,
ect1, ce) is the obvious - and fully semantically correct - use case of
that possible use.

For the set of three codepoints (ECT0, ECT1, CE) the only other possible
valid detection scenario would be if a SYN+CE is sent (deliberately,
althought one can argue that a sender should not originate CE-marked
packets), but a SYNACK without CE is returned (full or partial
bleaching). At least under the current RFC3168 definition of IP ECN

allowed transitions:
nonECT -> nonECT

ECT0 -> ECT0
ECT0 -> ECT1
ECT0 -> CE

ECT1 -> ECT1
ECT1 -> ECT0 (possibly)
ECT1 -> CE

CE -> CE

Thinking about this aspect more, I am now unsure, if the higher level
functions, such as detection of IP ECN codepoint mangling, or validating
across multiple RTTs, should be in this document - or not rather be in a
separate draft, in order to facilitate independent implementation and
improvement of mechanisms in that space.

However, the above table of allowed IP ECN transistions may be updated
independently of AccECN - and performing extensive checks as part of a
signal protocol ossifies this IMHO.

As a middle ground, perhaps having these descriptions in a non-normative
section, clearly stating these to be examples of what an impemented
could choose to do?


Am 05.02.2022 um 02:14 schrieb Vidhi Goel:
> I like your response for all the points. I can review the diff for the
> proposed changes, if you’d like before committing them to the draft.
> Sorry, I want to add a new comment for this text,
> If a TCP client has set the SYN to Not-ECT, but
>     receives feedback that the IP-ECN field on the SYN arrived with a
>     different codepoint, it can detect such middlebox interference and
>     send Not-ECT for the rest of the connection.
> This statement holds good for Not-ECT but doesn’t if lets say the SYN
> was ECT0 or ECT1 as those could be marked CE and still be valid. Should
> we add a statement for ECT marked SYN as well?
> Thanks,
> Vidhi
>> On Feb 4, 2022, at 5:44 AM, Bob Briscoe <
>> <>> wrote:
>> Vidhi,
>> I've increased the table of contents to tocdepth = "4" which might
>> help find the relevant sections better, because a lot of the meat in
>> this draft is under sections 3.2.2 (ACE) and 3.2.3 (Option).
>> I've responded below, but I'd prefer it if you would say these things
>> on the list, so we have a better justification for changing the draft.
>> Reviewing a draft that has just be re-posted shouldn't imply anything
>> about whether Apple is implementing the draft or not.
>> (BTW, regarding the proposed change to the initial value of r.e1b, I
>> was going to send that  to the list once co-authors agreed to it. But
>> it would be nice if some of the edits were not self-generated.)
>> See [BB] inline for responses (which I'll repeat if you send to the list).
>> On 04/02/2022 07:37, Vidhi Goel wrote:
>>> Hello Bob and authors,
>>> I have read the draft a few times and will send my extensive review
>>> at a later point. But right now, I want to ask some critical things
>>> that an implementation could benefit from.
>>> The draft says,
>>> /If a TCP client has set the SYN to Not-ECT, but/
>>> /   receives feedback that the IP-ECN field on the SYN arrived with a/
>>> /   different codepoint, it can detect such middlebox interference and/
>>> /   send Not-ECT for the rest of the connection/
>>> 1. On the forward path from client to server, the client will revert
>>> to Not-ECT when it sees for example, that it sent a Non-ECT SYN but
>>> received ACE encoding other than 0 1 0. What does the client do in
>>> the last ACK of the 3WHS -
>>>  a. does it stay in AccECN mode and still send AccECN encoding based
>>> on the IP code point of SYN-ACK (Table 4)? This would mean that
>>> client won’t participate in ECN on the sender half of the connection
>>> and only provide AccECN feedback to the server as a receiver.
>>>  b.  does it disable AccECN mode and set ACE= 0 0 0 so that a server
>>> in AccECN mode can disable ECN based on Table4?
>>> While writing this, I realized that the intention is probably a.
>>> Could you confirm? Also, when the sender sets Not-ECT in its data
>>> packets, it should also disable acting upon any ACE feedback as we
>>> could still receive false ACE feedback from the server if the
>>> network, lets say, changed 00 (not ECT) to 01(ECT1). If you agree, we
>>> should add some text around this. Based on the current text, the
>>> sender will always respond to the ACE feedback even if it sends Not-ECT.
>>> TBH, this is a complicated scenario, where sender said to the network
>>> - I don’t trust you so I can’t use ECN. Feel free to drop my packets.
>>> And the network mangles the IP to ECT1 and then set CE (when
>>> congested) which would be feedback’ed from the receiver. Now, the
>>> packet wasn’t dropped which it should have been. So, is it better to
>>> just ignore this feedback because sender doesn’t trust the network or
>>> just act on it and reduce cwnd in order to reduce congestion in the
>>> network somewhere.
>> [BB] Your points are all good ones.
>> I'll address this last complex scenario first, because it has
>> implications for the earlier questions. First I'll define some
>> terminology:
>> Simple mangling scenario:
>>   * some network function, e.g. broken Diffserv ToS-byte remarking,
>>     illegally remarks a Not-ECT  SYN to CE.
>> Your complex mangling scenario, repeated here:
>>   * some network function, e.g. broken Diffserv ToS-byte remarking,
>>     illegally remarks a Not-ECT SYN to ECT0 or ECT1,
>>   * then congestion at a subsequent bottleneck is marking some packets CE
>> Then potentially the client could tailor its behaviour after sending a
>> Not-ECT SYN, If the SYN/ACK feedback is
>>  1. ECT: disable sending ECT, but continue responding to ECN feedback
>>  2. CE, disable sending ECT, and disable response to ECN feedback
>> However, this is uncertain, because CE feedback on the SYN/ACK could
>> indicate either the simple or the complex mangling scenario.
>> A simpler alternative would be to always continue responding to ECN
>> feedback. Rationale:
>>   * Whether case #1 or #2, assume that mangling of the SYN might have
>>     been Not-ECT to ECT, even if the feedback off the SYN is CE.
>>   * Then as the connection progresses, if /all/ feedback is CE,
>>     there's already a recommendation to fall-back to disabling
>>     congestion response.
>> If we do this, I think we ought to say "SHOULD continue to respond to
>> ECN feedback", not "MUST".
>> And we'll need to put this all to the WG.
>> 1.a) Now back to the beginning of your point. The text you quote is
>> from §2.5 which is in the non-normative "Overview and Rationale"
>> section (§2).
>> You really need the normative text from:
>>           <>Testing
>>           for Mangling of the IP/ECN Field
>>           <>
>> where it says (end of 1st para):
>>     " ...for the remainder of the connection the client MUST NOT send
>>     ECN-capable packets, but it MUST continue to feed back any ECN
>>     markings on arriving packets."
>> So, you're right, the answer is (a).
>> It can't be (b), because, once in AccECN mode, 000 on the ACE field
>> just becomes a counter value, and no longer negotiates the feedback mode.
>> 1.b) As per the above, let's conservatively assume complex mangling.
>> So, at the end of the first para quoted above I suggest we add:
>>     " ...for the remainder of the connection the client MUST NOT send
>>     ECN-capable packets *but**it**SHOULD continue to respond to ECN
>>     feedback even though **it **is no longer sending ECN-capable
>>     packets (see reasoning below)**. T**he client**MUST remain in the
>>     same feedback mode and***it MUST continue to feed back any ECN
>>     markings on arriving packets."
>> I'll do the same for next para about the server.
>> I'll work out some text for the reasoning, but I won't give it here.
>> There are two other cases where it disables sending ECT, which don't
>> say whether it continues to respond to congestion:
>>   * "Testing for Mangling" section, penultimate para,  where it's
>>     receiving solid CE:
>>     "Once a Data Sender has entered AccECN mode it SHOULD check
>>     whether all feedback received for the first three or four rounds
>>     indicated that every packet it sent was CE-marked. If so, for the
>>     remainder of the connection, the Data Sender SHOULD NOT send
>>     ECN-capable packets*and it SHOULD NOT respond to ECN feedback*,
>>     but *it MUST remain in the same feedback mode and *it MUST
>>     continue to feed back any ECN markings on arriving packets*(in its
>>     role as Data Receiver)*."
>>   * Next section "Zeroing of the ACE Field", 2nd para:
>>     "If the value of this ACE field is zero (0b000), the Data Sender
>>     disables sending ECN-capable packets for the remainder of the
>>     half-connection by setting the IP/ECN field in all subsequent
>>     packets to Not-ECT, *but**it**SHOULD continue to respond to ECN
>>     feedback even though **it **is no longer sending ECN-capable
>>     packets.* *It MUST also remain in the same feedback mode and it
>>     MUST continue to feed back any ECN markings on arriving packets
>>     (in its role as Data Receiver).*"
>> I'll also add reasoning (in the zeroing section, it already says that
>> ACE=0b000 is not an unambiguous indication of mangling).
>> And this prompts me to edit the bullet in an earlier section about the
>> obligation of a sender to respond to congestion feedback:
>>         3.1.5.
>>         <>Implications
>>         of AccECN Mode
>>         <>
>>     "It is still obliged to respond appropriately to AccECN feedback
>>     that indicates there were ECN marks on *ECN-capable *packets it
>>     had previously sent."
>> And I'll add a bullet:
>>     "*If the sender chooses not to send ECN-capable packets (e.g.
>>     because path traversal of the ECN field is suspect), it can ignore
>>     any **ECN **feedback about those packets if it is certain that it
>>     cannot be valid (see Section 3.2.2, which gives normative
>>     requirements for certain specific cases).*"
>> I've said 'can' rather than 'MUST' because it's hard to cover all
>> cases, e.g. single packets without ECT when it's not clear whether the
>> feedback covered another packet that was ECT.
>> How does all this sound?
>>> 2. On the reverse path from server to client, if a server sends a
>>> Not-ECT SYN-ACK and receives ACE handshake encoding on last ACK other
>>> than 0 1 0, there is no text like above that says server should send
>>> Not-ECT for the rest of the connection (or at least I didn’t find
>>> it). I think the server should also do same as client as the two
>>> paths could be different. One could make it more complicated by
>>> saying, if both client and server decide to not use ECN on their
>>> corresponding sender half, then ECN should be disabled but let’s talk
>>> about that later.
>> [BB] It's in the second para of:
>>           <>Testing
>>           for Mangling of the IP/ECN Field
>>           <>
>>> 3. In general, not setting the ECT (ECT0 or ECT1) code point on an
>>> outgoing packet is different from supporting AccECN right as in the
>>> host can still provide AccECN feedback on the receive path.
>> [BB] Yup.
>> Do you think any further explanation is needed in the above sections?
>> Bob
>>> ….
>>> To be continued if more questions come to my mind.
>>> Thanks,
>>> Vidhi
>>>> On Feb 3, 2022, at 7:24 AM, Bob Briscoe <> wrote:
>>>> tcpm folks,
>>>> This rev to accurate-ecn is the first of two. The second will
>>>> hopefully follow on its heels in the next couple of days.
>>>> Diffs between this first rev (-16) and -15:
>>>> 1.  switches round two fairly large sections, so I've deferred other
>>>> changes to a second rev so the diffs won't be masked by the switch
>>>> round of sections.
>>>> Suggested by Ilpo to match the order in which the tests in these
>>>> sections will be executed:
>>>> * Test for mangling the IP-ECN field (now,
>>>> * Then test for zeroing the ACE field (now
>>>> 2. Ilpo suggested some clarifications in " Consistency
>>>> between AccECN Feedback Fields", which is about the receiver of
>>>> feedback ensuring consistency between the mandatory 3-bit ACE field
>>>> and the optional 24-bit counters. In brief (paraphrasing) it
>>>> previously only said "MUST consider both fields", when it is now
>>>> clearer that it actually meant "MUST reconcile both fields", so that
>>>> there is always a consistent baseline for subsequent ACKs.
>>>> 3. A minor point is added in an appendix about the details that the
>>>> pseudocode doesn't cover.
>>>> Bob
>>>> PS. #2 & #3 were added to the XML ages ago (Jul '21), so you will
>>>> have seen them in the HTML. However, prob due to my clumsiness, the
>>>> posted TXT didn't include them whereas the posted XML did (ironic
>>>> for a section about consistency). In turn, inconsistency was only
>>>> possible because I am having to manually post the TXT for this
>>>> draft, due to an unresolved issue with v3 RFC XML tables.
>>>> On 03/02/2022 14:43, wrote:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the TCP Maintenance and Minor
>>>>> Extensions WG of the IETF.
>>>>>         Title           : More Accurate ECN Feedback in TCP
>>>>>         Authors         : Bob Briscoe
>>>>>                           Mirja Kühlewind
>>>>>                           Richard Scheffenegger
>>>>> Filename        : draft-ietf-tcpm-accurate-ecn-16.txt
>>>>> Pages           : 60
>>>>> Date            : 2022-02-03
>>>>> Abstract:
>>>>>    Explicit Congestion Notification (ECN) is a mechanism where network
>>>>>    nodes can mark IP packets instead of dropping them to indicate
>>>>>    incipient congestion to the end-points.  Receivers with an ECN-
>>>>>    capable transport protocol feed back this information to the sender.
>>>>>    ECN was originally specified for TCP in such a way that only one
>>>>>    feedback signal can be transmitted per Round-Trip Time (RTT).
>>>>>  Recent
>>>>>    new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
>>>>>    (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
>>>>>    accurate ECN feedback information whenever more than one marking is
>>>>>    received in one RTT.  This document specifies a scheme to provide
>>>>>    more than one feedback signal per RTT in the TCP header.  Given TCP
>>>>>    header space is scarce, it allocates a reserved header bit
>>>>> previously
>>>>>    assigned to the ECN-Nonce.  It also overloads the two existing ECN
>>>>>    flags in the TCP header.  The resulting extra space is exploited to
>>>>>    feed back the IP-ECN field received during the 3-way handshake as
>>>>>    well.  Supplementary feedback information can optionally be provided
>>>>>    in a new TCP option, which is never used on the TCP SYN.  The
>>>>>    document also specifies the treatment of this updated TCP wire
>>>>>    protocol by middleboxes.
>>>>> The IETF datatracker status page for this draft is:
>>>>> There is also an htmlized version available at:
>>>>> A diff from the previous version is available at:
>>>>> Internet-Drafts are also available by rsync at
>>>>> <>::internet-drafts
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>> --
>>>> ________________________________________________________________
>>>> Bob Briscoe
>>>> _______________________________________________
>>>> tcpm mailing list
>> --
>> ________________________________________________________________
>> Bob Briscoe
> _______________________________________________
> tcpm mailing list