Draft: draft-ietf-quic-ack-frequency

Commentary: Per suggestion in , this PR changes the immediate ACK behavior to only send an immediate ACK when transitioning from non - marked to CE marked . Also treats receipt of non Ack - Eliciting packets as    if they are CE marked . 
 I 'm wondering if this should be max(2 , Ack - Eliciting Threshold)/2 instead ? As it is , except for the immediate ack on unmarked to CE marked , this algorithm basically does n't change acknowledgement behavior at all . 
 I think this is about done and I 'd like to merge it prior to shipping the next version of the draft . Can anyone provide a final review ? 
 and I discussed this . Forcing ACKing of ACKs seems problematic ( thanks and we would like to steer clear of that for this time being . So we are removing any text about ACKing non - ack - eliciting packets , since that seems like a footgun . If there 's a specific reason to include it , let 's do that in a new Issue and PR . 
 Thanks for the suggestion Let 's keep this relatively simple for now . 
 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 .
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic [1].
Source code and issues list for this draft can be found at
https://github.com/quicwg/ack-frequency [2].
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.  Source
code and issues list for this draft can be found at
<https://github.com/quicwg/ack-frequency>.
Working Group information can be found at <https://github.com/
quicwg>.