Re: [quicwg/base-drafts] Idle timeout indicates you will timeout (#3099)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

Thanks for doing this.

I wonder if we have any place where we can state the principle that drives this.  That is, "after the time indicated in max_idle_timeout, the endpoint will no longer send nor accept packets."

> -processed successfully.  The timer is also restarted when sending a packet
-containing frames other than ACK or PADDING (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.
-
-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

```suggestion
Each endpoint advertises a different max_idle_timeout, but the effective value
```

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

```suggestion
a max_idle_timeout, endpoints commit to initiating an immediate close
```

> -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
+received and processed successfully.  The timer is also restarted when sending
+a packet containing frames other than ACK or PADDING (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 its peer's idle timeout period

```suggestion
An endpoint that sends packets near the end of the idle timeout period
```

> @@ -2344,28 +2344,30 @@ source address.
 
 ## Idle Timeout {#idle-timeout}
 
-If the idle timeout is enabled, a connection is silently closed and the state is
-discarded when it remains idle for longer than both the advertised
+If the idle timeout is enabled by either peer, a connection is silently closed
+and the state is discarded when it remains idle for longer than the max
 idle timeout (see {{transport-parameter-definitions}}) and three times the

```suggestion
max_idle_timeout (see {{transport-parameter-definitions}}) and three times the
```

> @@ -2344,28 +2344,30 @@ source address.
 
 ## Idle Timeout {#idle-timeout}
 
-If the idle timeout is enabled, a connection is silently closed and the state is
-discarded when it remains idle for longer than both the advertised
+If the idle timeout is enabled by either peer, a connection is silently closed
+and the state is discarded when it remains idle for longer than the max

```suggestion
and the state is discarded when it remains idle for longer than the
```

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