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

[Subodh Iyengar <[e-mail]>]

siyengar approved this pull request.

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

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

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

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

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