Change:
order (out-of-order). 0 represents 'false' and 1 represents 'true'. <del> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger Sequence Number value has been sent. </del> <ins> 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. </ins> An endpoint MAY send ACK_FREQUENCY frames multiple times during a connection and with different values.

Discussion:
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
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 IMMEDIATEACK 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 Kazuho 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 .