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

From: ianswett <[email-masked]>
Date: Wed, 16 Oct 2019 10:55:19 -0700

This makes idle timeout symmetric by stating that a peer will close the connection at or soon after the idle timeout expires, creating clear expectations of idle timeout behavior.

Fixes #2602 
Takes some of the improved text from #2745
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3099

-- Commit Summary --

  * Idle timeout indicates you will timeout then

-- File Changes --

    M draft-ietf-quic-transport.md (25)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3099.patch
https://github.com/quicwg/base-drafts/pull/3099.diff

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 16 Oct 2019 12:11:36 -0700

janaiyengar commented on this pull request.

> -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 can advertise a different idle timeout value. An idle timeout
+indicates the connection will be abandoned when the timer ends or soon
+afterwards.  If a peer advertises a smaller idle timeout value than the
+local endpoint, the local endpoint MAY choose to idle timeout after the
+shorter period advertised by the peer.  By announcing an idle timeout,
+an endpoint commits to initiating an immediate close ({{immediate-close}})
+if it abandons a connection prior to both its peers and its own idle timeout
+expiring.

I don't think I follow this sentence. What is the endpoint committing to? To closing the connection at min(local_timeout, remote_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 can advertise a different idle timeout value. An idle timeout
+indicates the connection will be abandoned when the timer ends or soon
+afterwards.  If a peer advertises a smaller idle timeout value than the
+local endpoint, the local endpoint MAY choose to idle timeout after the
+shorter period advertised by the peer.  By announcing an idle timeout,
+an endpoint commits to initiating an immediate close ({{immediate-close}})
+if it abandons a connection prior to both its peers and its own idle timeout
+expiring.
+
+An endpoint that sends packets near the end of the idle timeout period of a peer

```suggestion
An endpoint that sends packets near the end of its peer's idle timeout period
```

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

---

From: ianswett <[email-masked]>
Date: Wed, 16 Oct 2019 13:27:31 -0700

@ianswett pushed 1 commit.

dc5b220c7e9be644223a0a0b829320256c356ea2  Update draft-ietf-quic-transport.md

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

---

From: ianswett <[email-masked]>
Date: Wed, 16 Oct 2019 13:28:40 -0700

ianswett commented on this pull request.

It's committing to explicitly closing(and not silently closing) if it's before min(local_timeout, remote_timeout).  This was adapted from MT's PR.

-- 
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#discussion_r335692657

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Oct 2019 13:53:31 -0700

martinthomson requested changes on this pull request.

This doesn't read particularly well as written.  I've suggested something, but I'm not entirely sure that it works.

> @@ -2357,15 +2357,22 @@ containing frames other than ACK or PADDING (an ack-eliciting packet; see
 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

Each endpoint advertises a different idle timeout, but the effective value is determined by taking the minimum of the two advertised values.  By announcing an idle timeout, endpoints commit to initiating an immediate close ({{immediate-close}}) if it abandons a connection prior to the effective value.

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

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 17:33:11 -0700

2537a1a53d178d956f28c48994011ff51d8aac8e  Martin's suggestion and some reordering

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

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 17:34:39 -0700

61dcaadf58bef6e9029192689d204614f3f9b082  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3099/files/2537a1a53d178d956f28c48994011ff51d8aac8e..61dcaadf58bef6e9029192689d204614f3f9b082

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 17:36:56 -0700

6fd0ac8e5df10209624fb18ac4ea90a6d93c2b94  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3099/files/61dcaadf58bef6e9029192689d204614f3f9b082..6fd0ac8e5df10209624fb18ac4ea90a6d93c2b94

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 18:08:57 -0700

kazuho commented on this pull request.

I have suggestions for parts that did not read well to me, but otherwise LGTM.

-: The idle timeout is a value in milliseconds that is encoded as an integer; see
-  ({{idle-timeout}}).  If this parameter is absent or zero then the idle
-  timeout is disabled.
+: The max idle timeout is a value in milliseconds that is encoded as an integer;
+  see ({{idle-timeout}}).  If this parameter is absent or zero then the idle
+  timeout is disabled unless the peer specifies a max idle timeout.

Maybe rephrase to: "Idle timeout is disabled when this parameter is absent or zero on both sides"?

> @@ -4593,11 +4595,12 @@ endpoints send PING frames without coordination can produce an excessive number
 of packets and poor performance.
 
 A connection will time out if no packets are sent or received for a period
-longer than the time specified in the idle_timeout transport parameter (see
-{{termination}}).  However, state in middleboxes might time out earlier than
-that.  Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval,
-experience shows that sending packets every 15 to 30 seconds is necessary to
-prevent the majority of middleboxes from losing state for UDP flows.
+longer than the time specified in the max_idle_timeout transport parameter

s/specified in/negotiated by using/?

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

---

From: ianswett <[email-masked]>
Date: Tue, 29 Oct 2019 09:59:02 -0700

Thanks!

-- 
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#discussion_r340204526

---

From: ianswett <[email-masked]>
Date: Tue, 29 Oct 2019 09:59:58 -0700

Thanks, I went for negotiated using.

-- 
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#discussion_r340205193

---

From: Nick Banks <[email-masked]>
Date: Tue, 29 Oct 2019 10:08:31 -0700

nibanks approved this pull request.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 16:25:07 -0700

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

-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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Oct 2019 13:20:44 -0700

MikeBishop approved this pull request.

If you're going to explain why you restart when sending, you might need to explain why you _don't_ restart when sending subsequent packets.  Perhaps "when sending _one or more_ packets" might help point this explanation at bursts, rather than at individual packets?

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