Original text:
number of acknowledgments allows connection throughput to scale much further. <del> As discussed in implementation however, there are undesirable </del>  consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  A sender's constraints on the acknowledgement frequency need to be taken into receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack- <del> eliciting packets the recipient of this frame can receive before sending an immediate acknowledgment.  A value of 0 will result in an immediate acknowledgement whenever an ack-eliciting packet received.  If an endpoint receives an ACK-eliciting threshold value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable value instead. </del>  A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay" invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. <del> An 8-bit field representing a boolean truth value.  This field is </del>  set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering <del> (reordering).  The value of this field MUST be 0x00 (representing "false") or 0x01 (representing "true").  Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del>  ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger 7.2. <del> As specified in Section 13.2.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. </del>  7.3. acknowledgments will cause undesirable bursts of data into the network.  10. TBD.

Reviewer comments:
I think we shouldn't make this change until we understand the use case for this field. IMO, it is harmful to the networks. Happy to discuss this over slack or at
When thinking about , it occurred to me that there may be use cases for not changing the acknowledgement behavior in the face of ECN. The most obvious example is an ECN scheme where the bit means faster/slower, and so at equilibrium, every other packet should be marked. This type of marking would trigger the most pathological ACK behavior of either the current draft(ie: RFC9000) or .
This seems like a good way to manage acknowledgment behaviour when different ECN schemes are in use. It's not necessarily a complete solution, but it should help avoid the worst sorts of reactions.
How to send an ACK on CE marking can be a receiver side logic, one ACK when CE marking changes. I agree if every other packet is marked, then that triggers every other ACK, but I don't understand why this would happen in steady state. Would be good to know a use-case for this. Are there networks that are marking CE incorrectly - for that we should disable ECN as described in RFC 9000. This has similar implications as where the delayed CE marks will result in delayed response to congestion at the sender and hence the network queuing will continue to increase possibly causing more CE marks on other responsive flows (that don't have ignore-ecn set to true) and will cause unfairness.
I had this Netdev conference presentation and paper in mind by Hari Balakrishnan of MIT: URL It's research, but it's a sensible algorithm in certain environments like cell networks.
Thank you NAME for providing the link. I watched the video of the talk and it doesn't seem like he is using ECN along with Accelerate and Brake. One can simply disable ECN if they don't wish to use that method in the data packets. Disabling of ECN can also happen in the middle of the connection. I don't think we need to say, Sender wants to use ECN but he doesn't want to get immediate ACKs when CE marks are received at the receiver - that sounds contradictory to me.
NAME your comment URL seems like a good choice to me. ACK immediately whenever there is transition.
Most endpoints ignore ECN today, so I don't see how this is more harmful than the status quo? Some endpoints negotiate ECN and then ignore it as well. With Hari's scheme, the Ignore CE option is exactly what you'd want, because a transition from non-CE to CE happens so frequently.
How the stacks ignore today would make the other side disable ECN even if it was negotiated successfully. Meaning, the sender will start sending Non-ECT in its packets and the routers will drop instead of marking CE. But if the sender continues to send packets with ECT(0) or ECT(1) after sending ignore-ECN = true, that means this sender is greedy as it doesn't want its packets to be dropped at the bottleneck and also, it doesn't want to respond the congestion marks right away. For senders using classic ECN, this is OK only when the ACKs eventually come within 1RTT ballpark as classic congestion controllers reduce cwnd once per RTT. But, for L4S scalable congestion control, this isn't good enough as the ACK with CE feedback should come immediately (with respect to time). Multiple packets with CE marks can be bundled into one ACK - which is the ACK on transition from CE to non-CE method.
There are many scenarios to use ECN, and today the most valuable one is the datacenter, not the public internet. In a datacenter, this may be an optimal ACK-ing scheme. In terms of classic vs L4S, it seems like both have delays which would be fairly tolerable (ie: 1 RTT and 1/8 or 1/4 RTT depending upon one's loss threshold), but larger delays could reduce their responsiveness to congestion. This is similar to Ignore Order, since both are signals which may indicate congestion, so the same guidance could apply to both to ensure sufficiently fast feedback in the case of possible loss or ECN marking.
Yes, they are the same with regards to delayed response to congestion and we are discussing that at URL One subtle difference between the two is that in case of ECN, the packets are never dropped which could cause slightly more unfairness to other flows. Similar to , we can add a limit to Max Ack Delay when ignore-ecn is used.
Even middleboxes which mark ECN also drop packets, they just mark earlier than they drop. I'm not aware of devices which when ECN is negotiated, actually don't drop packets and instead rely entirely on ECN. This seems like a recipe for unfairness, so I can't imagine someone doing this If you have evidence this really exists in the wild, that'd be interesting, but I think it's a fundamentally unfair design choice.
Classic ECN RFC 3168 says, First, ECN-Capable routers will only mark packets (as opposed to dropping them) when the packet marking rate is reasonably low. During periods where the average queue size exceeds an upper threshold, and therefore the potential packet marking rate would be high, our recommendation is that routers drop packets rather then set the CE codepoint in packet headers. For low to medium congestion, the middle box will mark CE without dropping and only after high congestion which could imply non-compliance from sender, it will revert to dropping packets. So, there is some degree of unfairness when congestion starts to build up. The use of ECN in public Internet is to avoid queue buildup and we would be going against that if we use ECN (to avoid packet drops) but don't respond in timely manner. If the only use case of this is data centers (of which I have very limited knowledge), then should we mention that in the draft? Something like, ?
My view is that implementations largely do not conform to 3168, so even though the text says that, I'd only believe it if someone could show me evidence that is what happens in the wild. Also, I think we should permanently deprecate 3168 and take back the bit, but that's a different conversation.
From Mirja: "For ECN, you don't need to send an immediate ACK for each CE. Immediate ACKs are most important when the codepoint switches to CE, but then, if multiple CEs in a row are received, you can bundle the ACK information. See also URL (Note that we are still working on that section for AccECN but I think any changes are only relevant for specifics of TCP)"
From editors' discussion: This text is the same as that in RFC9000 (URL), and we don't believe we need to depart from existing text for CE-marked packets, since those are true congestion events, and we don't need to optimize for collapsing acks during congestion.
Insisting on feeding back an ACK whenever there's a CE will come back to haunt you. After the hundredth CE in a row, you'll probably start to realize that each CE is not a 'congestion event'. You need to make sure that this doesn't force the receiver to ACK every CE-marked ACK, which could lead to interminable ACK ping-pong. Admittedly, the sender should be slowing down, so perhaps it's not so bad to ram the reverse path full of ACKs under 100% congestion in the forward path. But it's not necessary - you could potentially squash other traffic sharing the reverse path. Particularly not nice in the first RTT before the sender starts responding. Instead, a requirement like under the that Mirja pointed to, where you ACK every 'n' CE marks in a row will be sufficient. And if the peers support ACK frequency control, you might want to say 'n' is the greater of a) whatever 'standard' value is set by the IETF and b) the current ACK frequency requested by the sender. Finally, note that the AccECN section linked above was massively changed between -14 (when Mirja pointed to it) and -15 (now). Nearly all of the changes would be relevant to QUIC too (except the stuff about DupACKs, I think). So it's worth reading it all again carefully.
Thanks for the specific suggestion Bob, that's extremely helpful. I think there are four ways forward: 1) Stick with the current text and deal with the performance hit when using non-classic ECN. 2) Always do something along the lines AccECN is suggesting when ACKFREQUENCY is negotiated, ie: Ack immediately when max(2, Ack-Eliciting Threshold) packets with CE marks are received. 3) Change the ignoreorder 'bool' to be an enum with 4 values that are a mix of Classic(RFC9000) and accurate ECN response to CE marks. 4) Do something completely from RFC9000 or AccECN. I'm not sure what would inform this, but maybe there are aspects of QUIC which means the ACK response should be different from TCP Accurate ECN. I favor 2 and wrote to document that. My personal opinion is that classic ECN is not able to perform as well as newer marking schemes and should be deprecated, so perpetuating it is actively harmful.
The design is not (only) for 'non-classic ECN', it's for handling any severe reverse channel congestion. For the avoidance of doubt, if NAME alternative is meant to be "as Bob (AccECN) suggested", a number of possibly important details are missing: a) Immediately ACK the first transition from a non-CE packet to a CE data packet; and b) ACK every max(2, Ack-Eliciting Threshold) contiguous CE marked packets after that. The choice of 'packet' (twice) or 'data packet' (once) in the above is deliberate I agree that ECN feedback in RFC3168 should be deprecated (which is why I didn't object when it was proposed that AccECN should move from experimental to stds track update to 3168).
The PR includes the 'Immediately ACK the first transition from non-CE to CE. PTAL and see if the text looks correct.
After further thinking, I'm wondering if we should have multiple modes that are indicated by bits in the 'Ignore Order' bytes. Specifically: 0 is rfc9000 behavior. Conveniently, this means clients sending Ignore Order values of 0 or 1 will see no change in behavior. 1 is Ignore CE when choosing how frequently to acknowledge packets. This would likely be the best option for ECN algorithms where close to 50% of packets are marked. 2 is accurate ECN, which is the current PR.
Following up on my last comment, I created a separate issue () and PR () for the question about whether we want an Ignore ECN bool.

Revised text:
number of acknowledgments allows connection throughput to scale much further.  <ins> As discussed in implementation however, there can be undesirable </ins> consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  A sender's constraints on the acknowledgement frequency need to be taken into receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack-  <ins> eliciting packets the recipient of this frame can receive without sending an immediate acknowledgment.  An immediate acknowledgement is sent when more than this number of ack-eliciting packets have been received, so value of 0 results in an immediate acknowledgement.  If an endpoint receives an ACK-Eliciting Threshold value that is larger than the maximum value the endpoint can represent, the endpoint MUST use the largest representable value instead. </ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay" invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION.  <ins> This field has no meaning in this version of ACK_FREQUENCY.  The value of this field MUST be 0x00.  Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. A 1-bit field representing a boolean truth value.  This field is </ins> set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering  <ins> (reordering).  0 represents 'false' and 1 represents 'true'. A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE-marked packets (reordering).  0 represents 'false' and 1 represents 'true'. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger 7.2.  <ins> An endpoint SHOULD send an immediate acknowledgement when a packet marked with the ECN Congestion Experienced (CE) codepoint in the IP header is received and the previously received packet was not marked CE. Doing this maintains the peer's response time to congestion events, while also reducing the ACK rate compared to Section 13.2.1 of QUIC- TRANSPORT during extreme congestion or when peers are using DCTCP RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168. </ins> 7.3. acknowledgments will cause undesirable bursts of data into the network. <ins> 9.4. To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends or it can simply send an IMMEDIATE_ACK frame, which is a non-probing frame. An endpoint's congestion controller and RTT estimator are reset upon confirmation of migration (Section 9.4 of QUIC-TRANSPORT), which can impact the number of acknowledgements received after migration.  An endpoint that has sent an ACK_FREQUENCY frame earlier in the connection SHOULD update and send a new ACK_FREQUENCY frame immediately upon confirmation of connection migration. 9.5. A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </ins> 10. TBD.