Draft: draft-ietf-quic-ack-frequency

Commentary: I think we should n'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  : 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 do n'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 do n't have ignore - ecn set to true ) and will cause unfairness . 
 I had this  conference presentation and paper in mind by   of MIT : It 's research , but it 's a sensible algorithm in certain environments like cell networks . 
 Thank you for providing the link . I watched the video of the talk and it does n't seem like he is using ECN along with Accelerate and Brake . One can simply disable ECN if they do n't wish to use that method in the data packets . Disabling of ECN can also happen in the middle of the connection . I do n't think we need to say ,  wants to use ECN but he does n't want to get immediate ACKs when CE marks are received at the receiver - that sounds contradictory to me . 
 your comment seems like a good choice to me . ACK immediately whenever there is transition . 
 Most endpoints ignore ECN today , so I do n'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 does n't want its packets to be dropped at the bottleneck and also , it does n'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 is n'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   , 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 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    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 do n't drop packets and instead rely entirely on ECN . This seems like a recipe for unfairness , so I ca n'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 do n'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  : " For ECN , you do n'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 ( 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 ( ) , and we do n't believe we need to depart from existing text for CE - marked packets , since those are true congestion events , and we do n'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 . the hundredth CE in a row , you 'll probably start to realize that each CE is not a ' congestion event ' . need to make sure that this does n'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  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  ( when  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  , 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  ) 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 alternative is meant to be " as  ( 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 did n'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 '    bytes . Specifically : 0 is rfc9000 behavior . Conveniently , this means clients sending   values of 0 or 1 will see no change in behavior . 1 is   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 .
As discussed in implementation however, there are undesirable
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
account to maximize congestion controller and loss recovery
performance.
As discussed in implementation however, there can be undesirable
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
account to maximize congestion controller and loss recovery
performance.
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.