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

Bob Briscoe <> Fri, 12 March 2021 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D34D03A19CA for <>; Fri, 12 Mar 2021 04:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 5clIjStgmIWE for <>; Fri, 12 Mar 2021 04:14:26 -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 185993A19C5 for <>; Fri, 12 Mar 2021 04:14:25 -0800 (PST)
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=xq3+ur277ghYKgbCYftI7xrPhkGW4nswCdlvyC5dId0=; b=QXfkf/pBkxNseUyOtFp/GhqnT0 ZSXET9xZjB3cX5t7PevDE3SR880KTHFPi4LOsO8GRsITaegDuDukL742xJei3FWW4QUKU1i03d93H 0dXZRJPBNdAfnEXmoAp+RGuTUbZ3IrwhWDRpHq2u3qwsqkigdNc1cmVXOBsvpKNxMbFVyyjuVJjrf s0crJpzt50HrfrK3JkjZQOxj3CKJ0COwef0HYibjGPSAJYE+vrH31RBQoww2NST13hqURWyaot6nK JB0Kuh+uhgzykevAe/MhZHaOxFrygNzHxMcZgIXxIXCxplBZzmKXWkegW9isPUDjl1UeqzOurb2Y5 35baiwJA==;
Received: from ([]:53050 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lKggS-0004XI-C9; Fri, 12 Mar 2021 12:14:24 +0000
To: Gorry Fairhurst <>, tcpm IETF list <>
Cc: Mirja Kuehlewind <>
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 12 Mar 2021 12:14:23 +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: Fri, 12 Mar 2021 12:14:28 -0000


We added this 'cos we were told it is common practice in production 
ECN-capable stacks.

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.

Perhaps those who have implemented this could comment?


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

Bob Briscoe