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
An IMMEDIATE_ACK frame can be useful in other situations as well.
For example, it can be used with a PING frame (Section 19.2 of QUIC-
TRANSPORT) if a sender wants an immediate RTT measurement or if a
sender wants to establish receiver liveness as quickly as possible.
An IMMEDIATE_ACK frame can be useful in other situations as well.
For example, if a sender wants an immediate RTT measurement or if a
sender wants to establish receiver liveness as quickly as possible.
PING frames (Section 19.2 of QUIC-TRANSPORT) are ack-eliciting but if
a PING frame is sent without an IMMEDIATE_ACK frame, the receiver
might not immediately send an ACK based on its local ACK strategy.