Subject: Re: [quicwg/base-drafts] Change idle_timeout to max_idle_timeout (#3099)

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 16:02:53 -0800

martinthomson commented on this pull request.

> -
-The value for an idle timeout can be asymmetric.  The value advertised by an
-endpoint is only used to determine whether the connection is live at that
-endpoint.  An endpoint that sends packets near the end of the idle timeout
-period of a peer risks having those packets discarded if its peer enters the
-draining state before the packets arrive.  If a peer could timeout within a
-Probe Timeout (PTO; see Section 6.3 of {{QUIC-RECOVERY}}), it is advisable to
-test for liveness before sending any data that cannot be retried safely.  Note
-that it is likely that only applications or application protocols will
-know what information can be retried.
+Each endpoint advertises a different max_idle_timeout, but the effective value
+is determined by taking the minimum of the two advertised values. By announcing
+a max_idle_timeout, endpoints commit to initiating an immediate close
+({{immediate-close}}) if it abandons a connection prior to the effective value.
+
+An endpoint restarts any timer it maintains when a packet from its peer is

```suggestion
An endpoint restarts its idle timer when a packet from its peer is
```

> -test for liveness before sending any data that cannot be retried safely.  Note
-that it is likely that only applications or application protocols will
-know what information can be retried.
+If the idle timeout is enabled by either peer, a connection is silently closed
+and its state is discarded when it remains idle for longer than the minimum of
+the max_idle_timeouts (see {{transport-parameter-definitions}}) and three times
+the current Probe Timeout (PTO).
+
+Each endpoint advertises a max_idle_timeout, but the effective value
+at an endpoint is computed as the minimum of the two advertised values. By
+announcing a max_idle_timeout, an endpoint commits to initiating an immediate
+close ({{immediate-close}}) if it abandons the connection prior to the effective
+value.
+
+An endpoint restarts any timer it maintains when a packet from its peer is
+received and processed successfully.  The timer is also restarted when sending

```suggestion
received and processed successfully.  The idle timer is also restarted when sending
```

-- 
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/3099#pullrequestreview-330226161

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Dec 2019 16:06:19 -0800

janaiyengar commented on this pull request.

One more comment

+close ({{immediate-close}}) if it abandons the connection prior to the effective
+value.
+
+An endpoint restarts any timer it maintains when a packet from its peer is
+received and processed successfully.  The timer is also restarted when sending
+an ack-eliciting packet (see {{QUIC-RECOVERY}}), but only if no other
+ack-eliciting packets have been sent since last receiving a packet.  Restarting
+when sending packets ensures that connections do not prematurely time out when
+initiating new activity.
+
+An endpoint that sends packets near the end of the idle timeout period
+risks having those packets discarded if its peer enters the draining state
+before the packets arrive.  If a peer could time out within a Probe Timeout
+(PTO; see Section 6.2.2 of {{QUIC-RECOVERY}}), it is advisable to test for
+liveness before sending any data that cannot be retried safely.  Note that it

What does it mean to test for liveness? Can you make this more explicit?

-- 
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/3099#pullrequestreview-330227021

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 16:06:58 -0800

@martinthomson pushed 1 commit.

774bc68d220a32c23054baffcfebca2d8b1c6f76  Use idle timer more directly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3099/files/875de3f37a1455793d715d481f895cfb32e33aa8..774bc68d220a32c23054baffcfebca2d8b1c6f76

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 16:07:55 -0800

c55954007d7162b0ebbed350a421909847765b46  wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3099/files/774bc68d220a32c23054baffcfebca2d8b1c6f76..c55954007d7162b0ebbed350a421909847765b46