Change:
CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment; see sending-acknowledgements. <del> A packet that does not increase the largest received packet number for its packet number space (packet-numbers) by exactly one.  A packet can arrive out of order if it is delayed, if earlier packets are lost or delayed, or if the sender intentionally skips a packet number. </del> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.

Discussion:
I believe this was the existing intent, so marking this editorial.
What are the downsides of not doing this and generally having logic that triggers an immediate ACK if any out-of-order packet is received?
Also, how would you recommend implementing this logic, assuming you already have the general logic? Keep a flag and only trigger the immediate ACK if that is ?
The code that sends ACK frames would track the largest received ack-eliciting packet to determine if packets are out of order, not the largest received packet. This is similar to PTO, which is armed from the largest ack-eliciting packet, not the largest packet.
The text is already very clear that if you receive an ACK-only packet out of order, you MUST NOT send an ACK. The goal of this PR is to clarify that ACK-only packets don't count when deciding when ack-eliciting packets are out-of-order.
Followup on my , I think what we need to do is to clarify that the scope of out-of-order packets is limited to ack-eliciting packets. We can say that a out-order packet is defined as "a newly received ack-eliciting packet carrying a packet number that is either smaller than those of any previously-received ack-eliciting packets, or is more than one greater than any of those packets."
How do you tell if the absent packets are ack-eliciting? I mean, most scenarios we use this definition are for the receiver, which can't know whether a missing packet is ack-eliciting.
NAME I've left my two cents regarding that concern on the .
NAME if I'm understanding correctly, the concern is that an implementation that sends ACK-only packets immediately but paces others will routinely have ACK-only packets skipping ahead of ACK-eliciting packets. If you react to all reordering, you'll send a lot of unneeded immediate ACKs when interacting with such an implementation.
Yeah, that makes sense. Thanks.
NAME has it right. It doesn't cause a correctness issue, but it could result in a large number of unnecessary ACK-only packets being sent.
I ended up largely taking NAME suggestion from URL, and no longer relying on out-of-order, but didn't remove the definition entirely. I can if people prefer.
Thanks NAME removed.
The existing text mostly covers this, but I don't think it's always as clear as it could be.

If one is doing various offloads(pacing/crypto/etc) and those cause the sender to decide to send a batch of packets at once, with release times that are over a few milliseconds, the sender should not have to wait until all those packets are released to send an ACK. A simple example at the receiver is an ACK arrives with PN 10, then PN 9 arrives. I do not believe PN 9 should not be considered 'out-of-order' and trigger an immediate ACK. Recovery is designed with this case in mind, but when re-reading this text, I thought it was unclear. The simple way to think about this is "ACK-only packets don't affect acknowledgement behavior", which matches with TCP and most of our existing text. I think this will end up being editorial and I believe the only clarification necessary is but I'd appreciate other peoples thoughts on whether this is something worth thinking about and whether there are any other changes necessary.
I share the view that this has been the intent, and that it is editorial. Loss recovery is an interaction between sender sending data vs. receiver sending acks. We might have two endpoints doing loss recovery at the same time, when both sides are sending data. But that should not affect how loss recovery works.
In URL, NAME asks: I think we need to think about two possibilities: an ack-eliciting packet overtaking ack-only packet, and an ack-only packet overtaking an ack-eliciting packet. If the former happens, the receiver can do nothing but send an immediate ack, because it cannot tell if the yet-missing packet is ack-only. But in the opposite case, the receiver can tell that it was an ack-only packet, because it has already received that packet. IIUC, NAME point is that we'd frequently see the latter when pacing is used, and therefore that we should address the issue. IMO, this issue is an artifact of us using one packet number space for loss recovery in both directions. The problem cannot be cleanly solved unless we use different packet number spaces for ack-eliciting packets and ack-only packets. That said, I do think that it is a good idea to minimize the impact of the problem, and that the proposed clarification works fine in that respect.
That's a reasonable analysis of this situation. That is also consistent with what our stack implements.

That is, we only ever send an immediate acknowledgement when we receive ack-eliciting packets. I can't see how you would do otherwise, frankly. However, I think that attempting to define "out-of-order" is the problem. I just searched the transport document for this and we don't use the definition. Therefore, I suggest that we say what we mean when it comes to describing how to immediately acknolwedge packets. That is, Or something like that. The out-of-order definition can go.
Good thought on getting rid of 'out-of-order', that should help.
I was about to say we could simplify the second bullet, but that would miss the case of: N-3: last received ack-eliciting packet N-2: lost N-1: ACK-only packet N: Newly received We want to send an immediate ACK on receipt of N, but not N-1. Nor do we want one on the late receipt of N-2.
border-Borderline design, let's run the process for visibility
Thanks for writing this down.NAME Thank you for all your work.