Re: [tcpm] Sender Fallback in draft-ietf-tcpm-accurate-ecn-14

Bob Briscoe <> Sun, 21 March 2021 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ECCB3A12B9 for <>; Sun, 21 Mar 2021 11:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.773
X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c_xQlbWe_ZCx for <>; Sun, 21 Mar 2021 11:32: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 81CD13A12B8 for <>; Sun, 21 Mar 2021 11:32: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=97o+31FEPMRC6ZLnmewqKQVXA+3KZvyAW0ctUxUJl+A=; b=vVego68kcAcodqKYEDxH81w2vY DwM/0ScZOJ36Tq0y4SBUu1URH4tJOPjfAauZE6XnaNWmi1RV6XKynhsVqj3dbx+Axt4bTEr++Yb17 nAwDo06NYAtk1STCtN/CC+VwdWd79+Kx8kJnBQOCvJz3Q/Iz+30On1limttCKCRUiMViLhuEG30gO cgKXPC8WUDUZTL3QtrjWuLEl6uk8gHtLnNh8pDTyEgPRd1qiE6oN1W2JVH2V3KQvZg/AdALrB1oeg +ZRTbWwf3/Fcm5pJx21K0b2sdNvpc9hT3jTIJC8mpPjn4OOup02uGDQ5kJCl1ETzwawubXqZrxQKL O2a2idmQ==;
Received: from ([]:43052 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lO2sY-0003Xp-G9; Sun, 21 Mar 2021 18:32:46 +0000
To: Gorry Fairhurst <>, Mirja Kuehlewind <>
Cc: tcpm IETF list <>
References: <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sun, 21 Mar 2021 18:32:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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] Sender Fallback in draft-ietf-tcpm-accurate-ecn-14
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: Sun, 21 Mar 2021 18:32:54 -0000

Mirja, Gorry,

Point taken about mission creep from ECN feedback to setting the IP-ECN 
field in packets as a data sender.

The question is, where would fall-back behaviour like this be defined?
It's not congestion response, so it would not be relevant in each CC 
It's about mangling detection and fall-back. So it really belongs in 
RFC3168, or an update to RFC3168.
AccECN is now intended to update RFC3168, but its scope is not meant to 
cover fall-back.

I guess this ought to be recorded somewhere as a necessary item for an 
RFC3168bis. I don't think the IETF has a process for such a ToDo list, 
or does it?

As far as the AccECN draft is concerned, shouldn't I just delete this 
para? Rather than include something in AccECN that is out of scope, and 
then weaken it to non-normative, which could be misinterpreted as being 
unimportant, rather than out of scope.


On 21/03/2021 02:41, Gorry Fairhurst wrote:
> On 16/03/2021 16:25, Mirja Kuehlewind wrote:
>> Hi Bob,
>> I do agree with Gorry that this is actually not about how to provide 
>> feedback but about how to use ECN and I think we were always aiming 
>> to separate the two.
>> Maybe we can change to not normative and say something like disabling 
>> after a small fixed number fo CE marked packets is the easiest way to 
>> address this problem but there might be other, smarter, more flexible 
>> approaches…?
>> Mirja
> Yes - that was what I noted.
> It would be possible to conjecture other ways to do this, although I 
> am not sure this is helpful. Perhaps the draft could instead say this 
> "this can be done by ..." and explain the method that is being used. 
> That leaves the possibility for a later spec to define a standard 
> sender method, or an alternative, but in the meantime it provides 
> guidance on what might be a useful practical approach.
> Gorry
>>> On 12. Mar 2021, at 13:23, Gorry Fairhurst <> 
>>> wrote:
>>> Thanks, see below:
>>> On 12/03/2021 12:14, Bob Briscoe wrote:
>>>> Gorry,
>>>> We added this 'cos we were told it is common practice in production 
>>>> ECN-capable stacks.
>>> That's fine, and can be usefully noted - but then I'll say again - 
>>> this is about how *ECN* is used, not specifically an accurate ECN 
>>> issue!
>>>> I think it would be hard (and inefficient) to check continuously, 
>>>> because changing to or from a long run of CE marks once in progress 
>>>> is perfectly valid behaviour for a good path.
>>> I agree that it would seem bad to check continuously, but maybe on a 
>>> path change detected (however that might be determined)?
>>>> Perhaps those who have implemented this could comment?
>>> That would be great,....
>>>> Bob
>>> Gorry
>>>> On 12/03/2021 11:58, Gorry Fairhurst wrote:
>>>>> I have questions on the sender fallback in use of ECT(?) - not 
>>>>> because I do not agree with the method, I think the approach is 
>>>>> good. However, the method here is something that impacts the 
>>>>> sender CC method, not the feedback method. Maybe this was 
>>>>> discussed before - if so remind me - my questions relate to this:
>>>>> /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,
>>>>>     but it MUST continue to feed back any ECN markings on arriving 
>>>>> packets./
>>>>> (i) I’m pretty sure this is safe to wait for /the remainder of the 
>>>>> connection/. Is this possibly unnecessarily restrictive - without 
>>>>> explaining why, in that some connections are long-lived and do 
>>>>> experience path changes?
>>>>> - At least I would like some text about path changes to path that 
>>>>> would support AccECN, and what happens.
>>>>> (ii) This isn’t really about AccECN at all, it’s about guidance on 
>>>>> the use of ECT(?) by a TCP sender's CC .
>>>>> I think this is intended here *only* is to apply to TCP senders, 
>>>>> and I think that needs to be made clear? - Although it might also 
>>>>> be valuable (non-normative?) advice for other transports that also 
>>>>> have a similar way of reporting CE?
>>>>> - To me is something that needs to be more explicit, and probably 
>>>>> in a separate sub-section or something?
>>>>> Gorry
>>>>> _______________________________________________
>>>>> tcpm mailing list
> _______________________________________________
> tcpm mailing list

Bob Briscoe