Re: [quicwg/base-drafts] Remove 1 RTT delayed ack requirement (#3055)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.



> @@ -3009,11 +3009,16 @@ guidance offered below seeks to strike this balance.
 An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
 This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.
 
-A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT
-estimate or the value it indicates in the `max_ack_delay` transport parameter.
-This ensures an acknowledgment is sent at least once per RTT when packets
-needing acknowledgement are received.  The sender can use the receiver's
-`max_ack_delay` value in determining timeouts for timer-based retransmission.
+An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting
+packets.  An endpoint commits to a maximum delay using the max_ack_delay
+transport parameter; see {{transport-parameter-definitions}}.  max_ack_delay
+declares an explicit contract: an endpoint promises to never delay
+acknowledgments of an ack-eliciting packet by more than the indicated value. If
+it does, any excess accrues to the RTT estimate and could result in delayed
+retransmissions from the peer.  For Initial and Handshake packets, a
+max_ack_delay of 0 is used.  The sender uses the receiver's `max_ack_delay`
+value in determining timeouts for timer-based retransmission, as detailed
+in section 5.2.1 of {{QUIC-RECOVERY}}.

```suggestion
in Section 5.2.1 of {{QUIC-RECOVERY}}.
```

-- 
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/3055#pullrequestreview-292744200