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

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.

I am not sure if we want to adopt this PR (in current form).

> @@ -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.

As @martinthomson points out, this is a deviation from the definition of max_ack_delay in the transport draft, that says that the value defaults to 25ms and is updated when receiving the transport parameters from the peer.

We could have different definitions, but IMO it is unnecessary in this case, based on our agreement that persistent congestion is a connection-wide event and that it can be applied during the handshake.

-- 
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-466406959