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

Mirja Kuehlewind <> Tue, 16 March 2021 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CC7A3A1327 for <>; Tue, 16 Mar 2021 09:26:04 -0700 (PDT)
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 RincPWP9T1JF for <>; Tue, 16 Mar 2021 09:26:02 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A4333A1324 for <>; Tue, 16 Mar 2021 09:26:02 -0700 (PDT)
Received: from ([2003:de:e71f:e600:35c6:11d2:11d0:ba64]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lMCW0-0005yq-4t; Tue, 16 Mar 2021 17:25:52 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Tue, 16 Mar 2021 17:25:48 +0100
Cc: Bob Briscoe <>, tcpm IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3608.
X-HE-SMSGID: 1lMCW0-0005yq-4t
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: Tue, 16 Mar 2021 16:26:05 -0000

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…?


> 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