Draft: draft-ietf-quic-ack-frequency

Commentary: by adding a one byte IMMEDIATE_ACK frame . 
 editorial nit : my preference would be for frame diagrams to use the notation in QUIC transport . I see that ACK_FREQUENCY is defined using ASCII art , so perhaps you want to consider a separate follow up PR to switch styles after this lands . 
 Thanks Lucas , I filed to update them . 
 They currently use ascii art . Will write this up once is merged . 
 sgtm , thanks ! 
 When sending a PTO packet , a sender wants to induce an immediate ACK . The only trick I know to induce such an ACK is intentionally skip the packet number . However , the problem of that approach is that it relies on the receiver not ignoring reorders . When an ACKFREQUENCY frame previously sent had set the bit , then it become impossible for a sender to induce an immediate ACK when sending a PTO packet . At the moment , the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet , but that seems like a bit of unnecessary overhead to me . Should we have a dedicated frame for inducing immediate ACKs instead ? 
 That 's an option . Another option is to revisit the max_reordering idea discussed in . If the  reordering was 5 , then you could skip 5 PNs . I do feel like it 'd be nice to allow specifying an int for  reordering , since that matches up with adaptive packet threshold loss detection , but as I expressed in , I think getting the details right are deceptively difficult , so I 'm torn . 
 This does seem like a real problem . I like the idea of a single " ELICIT_ACK " type frame . With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick . An explicit frame is also easier to implement for the sender than the packet number skipping . 
 There 's quite a bit of discussion on this on the tcpm mailing list at the moment , ie : I 'm increasingly thinking it 's worth using an unused protected bit in the header for this . It 'd end up competing with the 2 - bit packet loss measurements , but given those are experimental and may never be widely deployed , I think it might be worth it . For example , I believe this could allow an implementation to not include maxackdelay in PTO if it set the " ACK - pull"(or whatever it 's called ) bit on the final packet . That already seems possible if more than the threshold number of ack - eliciting packets are outstanding . 
 I 've thought more about this , and I think most of the time a 1 - byte frame would be acceptable , but it definitely adds some implementation complexity , so I 'd be curious which design others prefer ? If we can decide , then I 'll be happy to write a PR(or can ) . Besides PTO , a use case would be making the last packet before becoming app - limited elicit an immediate ACK . This could allow skipping maxackdelay for all PTOs(see ) , though always doing it could be a bit much in some cases . For example , browsers commonly send a series of requests , but to the transport it seems app - limited between them , because it does n't know the browser has another request to send . It might be useful for ' chirping ' as well , but I 've never tried that , so it 's mostly speculation . 
 We do n't currently have any intention of deploying them either , and I think that 's unlikely to change . I have n't seen a lot of good evidence that they are terribly helpful , and content providers do n't seem to have a good incentive for implementing it . For us at least , the difference in complexity for a frame versus a bit in the header is negligible . A frame is actually be slightly easier to implement and losing a byte here and there is n't so bad . 
 I strongly prefer using the header bit . Although it will be a bit more work to implement , the fact that I wo n't end up with a 1 - byte STREAM frame that I have to split off at the end of the packet will be worth the effort . 
 I 'm increasingly thinking it 's worth using an unused protected bit in the header for this . It 'd end up competing with the 2 - bit packet loss measurements , but given those are experimental and may never be widely deployed , I think it might be worth it . Is testimony of network operators not taken as evidence ? I remember a line of people , from different companies -- BT , ATT , and so on , at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting . 
 I do not see anyone propose a 1 - byte STREAM frame . I believe what is meant is a new frame type . If anything , using a new frame type to elicit an ACK is easier than using a header bit , as it involves fewer parts of the code to change . 
 Nobody is proposing a 1 - byte STREAM frame ( you ca n't just make up stream data anyway ) . The problem is that a new frame would consume bytes ( or probably one byte ) in the packet payload . Given that you set this signal on a PTO , and PTOs are often retransmissions of packets , this would require you to repackage ( and , most likely , cut off a single byte from a STREAM frame ) . Using a header bit would solve that problem . 
 and I discussed this and there are number of ways to fix this , but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft , we feel it 's important it be fixed in some way . One more option is new STREAM frame codepoints that elicit an immediate ACK . 
 I 'm ready to write a PR , but I 'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK , PONG , etc ) . I lean towards a new frame , since there are enough code - points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK . 
 +1 . While I would not be opposed to repurposing the existing PING frame , I do not see the necessity of doing that . Let 's simply consume one code point of the remaining 33 . 
 Thanks , now for bikeshedding time . Some possible names : ACKME ACKPULL ( from TCP ) FAST_ACK PONG 
 Putting on my bikeshedding hat : I do n't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame . The " pull " TCP terminology is fine ( e.g. PULLACK ) but we could also be more explicit with something like SOLICIT_ACK . 
 SCTP has something similar and calls it SACK - IMMEDIATELY ( RFC 7053 ) . 
 Thanks , I 'd be happy with ACKIMMEDIATELY or IMMEDIATEACK 
 For those two options I 'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant . 
 IMMEDIATEACK sounds good to me . Alternatively , I 'd be also fine with something like ACKNOW . 
 IMMEDIATE_ACK it is , PR coming .
The IMMEDIATE_ACK Frame is a frame which causes the peer to send a
packet containing an ACK frame immediately, similar to the receipt of
Initial and Handshake packets during the QUIC handshake.
Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the
ACK if the vast majority of received packets contain an IMMEDIATE_ACK
or the receiver is under heavy load.  Senders MAY include multiple
IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is
identical to a single IMMEDIATE_ACK frame.