Subject: Re: [quicwg/base-drafts] Define idle timeout more precisely (#1614)

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 17:39:23 -0700

ianswett commented on this pull request.

>  {{transport-parameter-definitions}}) is closed.  A connection enters the
 draining state when the idle timeout expires.
 
-The time at which an idle timeout takes effect won't be perfectly synchronized
-on both endpoints.  An endpoint that sends packets near the end of an idle
-period could have those packets discarded if its peer enters the draining state
-before the packet is received.
+Endpoints use the value they advertise when determining an idle timeout.  The
+idle timeout starts from the last packet received, or the first packet sent
+after sending that packet.  The latter condition ensures that initiating new
+activity postpones a timeout.
+
+The value for an idle timeout can be asymmetric.  The value advertised by a peer
+is only used to determine whether the connection is live at a peer.  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 be in within an RTO (see Section 4.3.3 of

How about "If a peer could idle timeout within an RTO(), it is advisable..."

-- 
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/1614#pullrequestreview-142611289

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 17:44:35 -0700

@martinthomson pushed 1 commit.

e590859  Reword at Ian's suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1614/files/e7e7fa65e00c7386ca873b8d9b07f5302dd4aaf4..e590859a453da676fc713cc707e5aa1484d9a602

---

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 17:45:28 -0700

ianswett 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/1614#pullrequestreview-142612114

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 01 Aug 2018 21:21:52 -0700

siyengar approved this pull request.

Otherwise this looks great. Thanks for putting up the pr to clarify things.

You talk about the asymmetric nature of idle timeout later, but maybe useful to say this before.

“Each endpoint advertises their own idle timeout to the peer”.

Maybe less confusing to say a value “advertised by an endpoint ... is live at an endpoint”

-- 
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/1614#pullrequestreview-142639404

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 21:25:20 -0700

9fde275  Subodh's editorial tweaks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1614/files/e590859a453da676fc713cc707e5aa1484d9a602..9fde275b3798385dd55e494ff75c8331c6af31f3

---

From: MikkelFJ <[email-masked]>
Date: Wed, 01 Aug 2018 23:37:18 -0700

mikkelfj commented on this pull request.

> -Endpoints use the value they advertise when determining an idle timeout.  The
-idle timeout starts from the last packet received, or the first packet sent
-after sending that packet.  The latter condition ensures that initiating new
-activity postpones a timeout.
-
-The value for an idle timeout can be asymmetric.  The value advertised by a peer
-is only used to determine whether the connection is live at a peer.  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 an RTO (see Section 4.3.3 of
-{{QUIC-RECOVERY}}), it is advisable to test for liveness before sending any data
-that cannot be retried safely.
+Each endpoint advertises their own idle timeout to their peer. The idle timeout
+starts from the last packet received, or the first packet sent after sending
+that packet.  The latter condition ensures that initiating new activity
+postpones a timeout.

This is not very clear without more context:
What is "that" packet? Do you mean "The idle timeout is reset whenever a packet is received or sent."?
 Where is the timeout advertised, TP presumably? 

-- 
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/1614#pullrequestreview-142659696

---

From: MikkelFJ <[email-masked]>
Date: Wed, 01 Aug 2018 23:38:17 -0700

OK there is a reference to TP in earlier paragraph.

-- 
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/1614#discussion_r207114877

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 23:40:44 -0700

3c7133b  It's the last received, not last sent

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1614/files/9fde275b3798385dd55e494ff75c8331c6af31f3..3c7133bae364ce3963b71a4070cdb5f3c3d618e5

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 23:41:46 -0700

martinthomson commented on this pull request.

@mikkelfj, you picked up on a serious error here.  It's the first packet sent after the last received packet.  Fresh eyes FTW.

-- 
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/1614#discussion_r207115535

---

From: ianswett <[email-masked]>
Date: Thu, 02 Aug 2018 09:06:31 -0700

Still LGTM.

-- 
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/1614#pullrequestreview-142865315

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Aug 2018 22:30:45 +0000 (UTC)

Merged #1614 into master.

-- 
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/1614#event-1768802088