Re: [quicwg/base-drafts] Fixing max_ack_delay (#3938)

[Jana Iyengar <[e-mail]>]

@janaiyengar requested changes on this pull request.

Agreed that we can't take the proposed text. I've suggested some text.

(apologies about not getting to this sooner, I was trying to prioritize the design issues assuming that I'd have gotten to the editorial ones sooner than now.)

> @@ -1094,7 +1094,9 @@ max_ack_delay:
 : The maximum amount of time by which the receiver intends to delay
   acknowledgments for packets in the Application Data packet number space. The
   actual ack_delay in a received ACK frame may be larger due to late timers,
-  reordering, or lost ACK frames.
+  reordering, or lost ACK frames. max_ack_delay is initialized to 0 and
+  updated when transport parameters are exchanged. If a peer does not
+  specify max_ack_delay, it is set to 25ms.

I'd suggest some text like this, to avoid repeating the details here.
```
The maximum amount of time by which the receiver intends to delay acknowledgments
for packets in the Application Data packet number space, as defined by the eponymous
transport parameter (Section 18.2 of {{QUIC-TRANSPORT}}). Note that the actual
ack_delay in a received ACK frame may be larger due to late timers, reordering, or lost
ACK frames.
```

-- 
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/3938#pullrequestreview-469772612