[tcpm] Re: Last Call: <draft-ietf-tcpm-accurate-ecn-31.txt> (More Accurate Explicit Congestion Notification (ECN) Feedback in TCP) to Proposed Standard

[Gorry Fairhurst <[e-mail]>]

Hello Stuart,

Top posting here - this document is in the RFC Auth-48 state.  I believe the final form does address the issues raised by the review, and will be shortly issued as an RFC. From my own sides, I do also see this an important piece of work, and one that is the result of a lot of contributions! I look forward to seeing this published.

I will leave it to the editors , if they wish to add more to answer specific questions…

Best wishes,
Gorry

> 
> On 18 Apr 2026, at 00:45, Stuart Cheshire <cheshire=[e-mail]> wrote:
> 
> On Jan 27, 2025, at 11:59, The IESG <[e-mail]> wrote:
> 
>> The IESG has received a request from the TCP Maintenance and Minor Extensions
>> WG (tcpm) to consider the following document: - 'More Accurate Explicit
>> Congestion Notification (ECN) Feedback in TCP'
>> <draft-ietf-tcpm-accurate-ecn-31.txt> as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2025-02-10. Exceptionally, comments may
>> be sent to [e-mail] instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
> 
> Just writing to check in on this.
> 
> It has been over a year since the Last Call on this document, and it has been in AUTH48 for a while.
> 
> I’m particularly interested in the following issue, which I previously mentioned in passing in my review on 6th February 2025:
> 
>> Testing for Zeroing of the ACE Field
>> 
>>  The possibility of re-ordering means that there is a small chance
>>  that the ACE field on the first packet to arrive is genuinely zero
>>  (without middlebox interference).  This would cause a host to
>>  unnecessarily disable ECN for a half connection.  Therefore, in
>>  environments where there is no evidence of the ACE field being
>>  zeroed, implementations can skip this test.
>> 
>> I have reservations about this test. The idea that this heuristic might suffer from false positives and falsely disable Accurate ECN for no good reason worries me. A user is expecting the low-latency benefits of L4S and Accurate ECN, and then though no fault of their own sometimes does not get these benefits. I also have mixed feelings about the trade-off that is implicit here: If there are defective middleboxes on the path, would we like to see these middleboxes fixed, or do we want to enable them to remain broken in perpetuity (to the detriment of all the people unfortunate enough to have their traffic traverse those defective middleboxes)?
>> 
>> Knowing what we know now in 2025, is this zero-ACE-field check still necessary? I would hate to have a heuristic designed to work around failures of the past end up becoming a liability that causes a new set of unpredictable failures indefinitely into the future.
> 
> Subsequently this mild reservation proved to be justified, when Koen De Schepper discovered it was causing real operational problems. I believe this code has been removed from Linux now, and I gave the attached presentation at IETF 124 in Montréal, November 2025. I believe we agreed that this text had proven unwise and should be removed before publication.
> 
> Where do we stand on this? Was the change made in the RFC to match the reality of what Linux (and other platforms) actually do? Is the RFC ready to publish?
> 
> TCP Accurate ECN is awesome work, and I hate to see it languish.
> 
> Stuart Cheshire
> 

> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]