Merge pull request #4000 from quicwg/ianswett-out-of-order-ack

Out of order relative to other ack-eliciting packets

draft-ietf-quic-transport.md

@@ -222,13 +222,6 @@ Ack-eliciting Packet:
   CONNECTION_CLOSE. These cause a recipient to send an acknowledgment; see
   {{sending-acknowledgements}}.
 
-Out-of-order packet:
-
-: 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.
-
 Endpoint:
 
 : An entity that can participate in a QUIC connection by generating, receiving,
@@ -3571,12 +3564,15 @@ which could prevent the connection from ever becoming idle.  Non-ack-eliciting
 packets are eventually acknowledged when the endpoint sends an ACK frame in
 response to other events.
 
-In order to assist loss detection at the sender, an endpoint SHOULD send an ACK
-frame immediately on receiving an ack-eliciting packet that is out of order. The
-endpoint SHOULD NOT continue sending ACK frames immediately unless more
-ack-eliciting packets are received out of order.  If every subsequent
-ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent
-immediately for every received ack-eliciting packet.
+In order to assist loss detection at the sender, an endpoint SHOULD generate
+and send an ACK frame without delay when it receives an ack-eliciting packet
+either:
+
+* when the received packet has a packet number less than another ack-eliciting
+  packet that has been received, or
+* when the packet has a packet number larger than the highest-numbered
+  ack-eliciting packet that has been received and there are missing packets
+  between that packet and this packet.
 
 Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in
 the IP header SHOULD be acknowledged immediately, to reduce the peer's response