Re: [quicwg/base-drafts] Reword Immediate ACK Recommendation (#2424)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I think that this is better, though I'd like to confirm design intent.

> @@ -134,6 +134,11 @@ Crypto Packets:
 
 : Packets containing CRYPTO data sent in Initial or Handshake
   packets.
+  
+Out-of-order Packets:
+
+: Packets that do not increase the largest received packet number for its
+cryptographic context by exactly one.

Do you want to add: "Packets can arrive out of order as a result of packets ahead of them being lost or delayed."  I think that's accurate.

> @@ -244,11 +249,9 @@ ack-eliciting packet. QUIC recovery algorithms do not assume the peer sends
 an ACK immediately when receiving a second ack-eliciting packet.
 
 In order to accelerate loss recovery and reduce timeouts, the receiver SHOULD
-send an immediate ACK when it receives a new packet which is not one greater
-than the largest received packet number. A receiver MAY send immediate ACKs
-for the next few ack-eliciting packets that are received, but SHOULD NOT
-send an immediate ACK for more than 1/8 RTT after receiving an out-of-order
-packet.
+send immediate ACKs for an interval after it receives an out-of-order packet.
+This interval SHOULD NOT exceed 1/8 RTT unless more out-of-order packets arrive
+during the interval.

So the idea is that every out-of-order packet triggers a 1/8 RTT interval of immediate acknowledgments?

I thought that the idea was to disable the sending of immediate acknowledgments if out-of-order packets started becoming routine.  That is, if you have a highly unreliable path, then immediate acknowledgments aren't helping repair errors, they are just noise.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2424#pullrequestreview-200374387