Change:
Are IMMEDIATEACK frames ack-eliciting? This doesn'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. RFC9000 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 doesn'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: PING frame alone. PING and IMMEDIATEACK frames. IMMEDIATEACK 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 maxack_delay. 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 doesn'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 don'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 don'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 added 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

Discussion:
IMMEDIATE_ACK frame helps mitigate this problem. An IMMEDIATE_ACK frame can be useful in other situations as well. <del> 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 </del> <ins> For example, if a sender wants an immediate RTT measurement or if a </ins> sender wants to establish receiver liveness as quickly as possible. <ins> 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. </ins> An endpoint SHOULD send a packet containing an ACK frame immediately upon receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending