Draft: draft-ietf-quic-ack-frequency

Commentary: Are IMMEDIATEACK frames ack - eliciting ? This does n't seem to be explicitly stated anywhere . I would expect IMMEDIATEACK to be ack - eliciting , but I see a statement that an IMMEDIATEACK frame " can be used with a PING frame [ ... ] if a sender wants an immediate RTT measurement or if a sender wants to establish receiver liveness as quickly as possible . " Why would a PING frame be necessary if IMMEDIATEACK itself is ack - eliciting ? 
 I did add to PR a sentence that IMMEDIATEACK frames are by definition ack - eliciting . However , I think your question makes actually an interesting point about what the difference between PING and IMMEDIATEACK is .  says about PING frames : So I guess this means that PING frames are ack - eliciting but you may not get an ack immediately based on the implemented ACK strategy at the receiver . I guess that 's not a problem because when the one end sends and the other receives the PING ( even if no ACK frame is sent ) the idle timer gets reset . I tried to clarify this in PR . Does that help ? 
 PR does n't really clarify the situation for me . If IMMEDIATEACK is ack - eliciting , why would one send it in the same packet as a PING frame ? To put it another way : What is the difference between a packet containing an IMMEDIATEACK frame and nothing else , and a packet containing an IMMEDIATE_ACK and PING frame and nothing else ? Both are ack - eliciting , and both should trigger an immediate ACK . To my understanding , PING frames exist solely as a way to make a packet ack - eliciting . If a packet contains other ack - eliciting frames , adding a PING frame has no effect . 
 The difference ( which I tried to clarify ) is that a PING frame might not trigger an immediate ACK . It will trigger an ACK eventually but depending on the ACK strategy used , it might wait for the delayed ACK timer to expire before it sends the ACK . 
 I 'm sorry , I think you misunderstood my question . Three possible packets : frame alone . and IMMEDIATEACK frames . frame alone . I understand the difference between ( 1 ) and ( 2 ) . A packet containing a PING frame is ack - eliciting , but the ack may be delayed up to maxackdelay . A packet containing an IMMEDIATEACK frame will be acknowledged immediately . I do not understand the difference between ( 2 ) and ( 3 ) . Both are ack - eliciting packets that result in an immediate ACK rather than one potentially delayed by maxackdelay . If there is no difference between them , then why would one send ( 2 ) rather than the shorter and equivalent ( 3 ) ? If there is a difference , what is it ? 
 maybe calling the frame PINGIMMEDIATE would more closely indicate the intent of the frame . This is because we seem to mixing actions and subject . If a PING elicites an ACK at sometime ( variable due to delay ) , a PINGIMMEDIATE is more likely to elicit an ACK sooner . 
 Thanks for clarification . Got it now . I guess I was implicitly assuming that you can never send an ACK_IMMEDIATE frame alone ( option 3 ) but I also guess the draft does n't say that anywhere explicitly . On the other hand , why not . So one way or the other , we have to clarify this ! I will discuss tomorrow with the other authors and we will propose a solution ! Thanks ! 
 I do n't see any reason to prevent sending the frame alone . We might consider making this frame like ACK , where a packet that contains only this frame is not ack - eliciting . Then it would be logical that you 'd need to send it with PING or some other ack - elicitng frame . But to be honest , that sounds overly complicated and I do n't think it 's needs . Either way , some room for clarification in the text . 
 PINGIMMEDIATE or IMMEDIATEPING seems clearer to me , since this is a variant of the PING frame rather than a variant of the ACK frame . 
 I would prefer sticking to the name IMMEDIATEACK . The reasoning is that ACK is more than just a pong . ACK carries the list of all the packets that have been received , rather than signalling that just a ping has arrived . It might be true that IMMEDIATEACK can be used as a ping , but that is not the intent of adding the frame , IIUC . 
 IMMEDIATEACK is not an ack , however . It is a request for an ack , which is the same as PING . Note that a PING frame is not a request for a pong . QUIC does not have " pong"s . A PING frame is an ack - eliciting frame , and like any other ack - eliciting frame requires the recipient to reply with an ACK frame within maxack_delay . It has no semantics beyond being ack - eliciting . 
 Yeah , the role of the frame is " elicit immediate ack . " Admittedly , by calling the frame IMMEDIATEACK , we are omitting " elicit " . If we want to be perfect , we can call the frame ELICITIMMEIDATEACK . OTOH , calling the frame " IMMEDIATEPING " implies that PING frames in QUIC elicits an ack and nothing more than that . While that is true with QUIC , my concern is if that implication is intuitive . IIRC the reason we PING frames in QUIC v1 ( instead of just suggesting stacks use an old DATA frame or whatever ) is that having a frame with a name representing a mechanism ( i.e. , ping - pong ) is more intuitive . If we are to follow that precedent , calling the new frame IMMEDIATE_PING is IMO not a very good idea , because it requires the understanding of the underlying mechanism to see how the frame is to be used ( elicit immediate ack ) . 
 I think the right name would be something like IMMEDIATEACKREQUEST or if we want to go shorter may IMMEDIATEACKREQ . 
 That signals the intent more clearly and avoids the frame being confused with an actual ACK 
 The draft does not specify retransmission behavior for the two new frame types . Based upon the frame descriptions , I think it would be reasonable that the ACKFREQUENCY frame should be retransmitted but not the the IMMEDIATEACK . For the latter , the timeout or the ACK that triggers the retransmission would render it useless . If this behavior is correct , can we specify it in the draft ? 
 I think it might make sense to say something along the lines of " the information that might be carried in frames is sent again in new frames as needed . " ( ) , as well as possibly adding a link to that section . I 'm not sure if we need to say anything more , because the ( re)transmission strategy depends on each QUIC stack . To give an example , if a QUIC stack is designed to send an ACKFREQUENCY frame every couple of RTTs , there is not need to track the ACK for ACKFRQUENCY frame , because it would transmit a new signal regardless of if the previous one is lost . 
 That makes sense for the ACKFREQUENCY frame . For the IMMEDIATEACK frame , I am not sure there is any use for retransmitting it . 
 For ACKFREQUENCY we already have this text : ACKFREQUENCY frames are ack - eliciting . However , their loss does not require retransmission if an ACKFREQUENCY frame with a larger Sequence Number value has been sent . However , I created a PR ( ) with the following clarification of this text : NOT just be retransmitted . Instead , a new ACKFREQUENCY frame with a larger Sequence Number value and potential updated information SHOULD be sent if loss was detected and if a new ACKFREQUENCY was not already sent in the mean time until the loss was detected . And this new text for IMMEDIATEACK : on the receipt of an ACK frames , there is no need to request another ack . If a packet containing IMMEDIATEACK and data is detected as lost due to an time - out , the sender MAY send the retransmitted data again together with an IMMEDIATE_ACK frame . Does that make sense ? 
 Yeah , I think that clarifies it . Thank you . 
 not merged yet as discussion is still about using SHOULD or not . 
 I believe  is correct , and we tried not to use normative language around retransmission in RFC9000 , so it seems like we should stick with that convention . 
 We now removed normative language and tried to keep it short . If more explanation is needed , maybe we can open a separate issue . Please review the ( merged ) PR .
ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame
is lost, is encouraged to send an ACK_FREQUENCY frame, unless an
ACK_FREQUENCY frame with a larger Sequence Number value has already
been sent.  However, it is not forbidden to retransmit the lost frame
(see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore
duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence
Number.
By definition IMMEDIATE_ACK frames are ack-eliciting.  An endpoint
SHOULD send a packet containing an ACK frame immediately upon
receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending an
ACK frame despite receiving an IMMEDIATE_ACK frame.  For example, an
endpoint might do this if a large number of received packets contain
an IMMEDIATE_ACK or if the endpoint is under heavy load.
IMMEDIATE_ACK frames do not need to be retransmitted.