Re: [quicwg/base-drafts] Proposed fix for #3987 (#4071)

[Jana Iyengar <[e-mail]>]

@janaiyengar requested changes on this pull request.

I don't think this is quite right. max ack delay is useful in idle and closing/draining timeouts. I've suggested text changes, PTAL. 

> +The PTO includes the peer's maximum expected acknowledgement delay. This is not
+strictly necessary for the purposes of path validation, but defining
+validation_timeout as a function of the PTO is convenient, since implementations
+need to maintain a PTO value anyway.

```suggestion
Note:

: Using the PTO value here implicitly includes the peer's maximum expected
acknowledgement delay in the validation timeout period; see Section 6.2.1
of {{QUIC-RECOVERY}}. This is not necessary for the purposes of path validation,
since the peer is expected to respond to a PATH_CHALLENGE without delay;
see {{path-response}}. However, defining the timeout period as a function of PTO
is convenient, since implementations will maintain a PTO value anyway.
```

> +As defined in {{QUIC-RECOVERY}}, the PTO includes the peer's maximum expected
+acknowledgement delay. This is not strictly necessary for the purposes of the
+idle timeout, but defining it in this way is convenient, since implementations
+need to maintain a PTO value anyway.

```suggestion

Note:

: Using the PTO value here implicitly includes the peer's maximum expected
acknowledgement delay in the idle timeout period; see Section 6.2.1
of {{QUIC-RECOVERY}}. This ensures that the endpoint accounts for this
known peer delay before declaring the connection as idle and closing it.
```

> +(PTO) interval as defined in {{QUIC-RECOVERY}}. Note that the PTO includes the
+peer's maximum expected acknowledgement delay. While not strictly necessary for
+this purpose, it is convenient, since implementations need to maintain a PTO
+value anyway.

```suggestion
(PTO) interval as defined in {{QUIC-RECOVERY}}.

Note:

: Using the PTO value here implicitly includes the peer's maximum expected
acknowledgement delay in the closing and draining periods; see Section 6.2.1
of {{QUIC-RECOVERY}}. This ensures that the endpoint takes this peer delay
into account when waiting to discard subsequent packets sent by the peer.
```

> +As defined in {{QUIC-RECOVERY}}, the PTO includes the peer's maximum expected
+acknowledgement delay. This is not strictly necessary for the purposes of the
+idle timeout, but defining it in this way is convenient, since implementations
+need to maintain a PTO value anyway.

This one is deliberate -- we want to account for max ack delay.

-- 
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/4071#pullrequestreview-482947265