Subject: [quicwg/base-drafts] Idle timeout editorial fixes (#3444)

From: ianswett <[email-masked]>
Date: Sun, 09 Feb 2020 11:31:34 -0800

>From @janaiyengar and @MikeBishop comments on #3099 

Fixes #3184
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Idle timeout editorial fixes

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3444.patch
https://github.com/quicwg/base-drafts/pull/3444.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/3444

---

From: Martin Thomson <[email-masked]>
Date: Sun, 09 Feb 2020 14:56:13 -0800

martinthomson requested changes on this pull request.

I think that the shift in the explanation misses the important point for a lesser one.

> @@ -2420,20 +2420,21 @@ close ({{immediate-close}}) if it abandons the connection prior to the effective
 value.
 
 An endpoint restarts its idle timer when a packet from its peer is received
-and processed successfully.  The idle 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 might need to send packets to avoid an
-idle timeout if it is unable to send application data due to being blocked on
-flow control limits; see {{flow-control}}.
+and processed successfully.  The idle timer is also restarted when sending the
+first ack-eliciting packet (see {{QUIC-RECOVERY}}) after receiving a packet.
+Only restarting when sending after receipt of a packet ensures the idle timeout
+is not excessively lengthened past the time the peer's timeout has expired.

This sentence doesn't really capture what the original text was attempting to explain.  That is, the original text intended to explain that a reset on receipt is insufficient because local attempts to restart communication might still result in the idle timeout period lapsing.  This says something different.

-- 
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/3444#pullrequestreview-355640812

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Feb 2020 11:29:46 -0800

MikeBishop commented on this pull request.

 value.

I think the change is in response to [my comment](https://github.com/quicwg/base-drafts/pull/3099/files/e4dd819fb3939e82c668b52076f7d89d500b8e3f#r340837260), that you also need to clarify why it's not sufficient to reset it on every packet you send.  Basically, we've chosen a more complicated condition than "on receive" or "on send," and we should justify why the simpler conditions don't work.

-- 
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/3444#discussion_r378465590

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 09:58:05 -0800

@ianswett pushed 1 commit.

7f0e36ce84a70e4e22b4ab1454d05884052b68b0  Add back old sentence

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3444/files/f247379b14f50465adc7c992a7db5853430686c8..7f0e36ce84a70e4e22b4ab1454d05884052b68b0

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 09:58:56 -0800

ianswett commented on this pull request.

 value.

Thanks, I added back the original sentence, since as you point out, something was lost.  PTAL.

-- 
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/3444#discussion_r379846025

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Feb 2020 15:42:13 -0800

martinthomson 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/3444#pullrequestreview-359439595

---

From: MikkelFJ <[email-masked]>
Date: Sat, 22 Feb 2020 03:13:57 -0800

mikkelfj commented on this pull request.

> @@ -2420,20 +2420,22 @@ close ({{immediate-close}}) if it abandons the connection prior to the effective
 value.
 
 An endpoint restarts its idle timer when a packet from its peer is received
-and processed successfully.  The idle 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 might need to send packets to avoid an
-idle timeout if it is unable to send application data due to being blocked on
+and processed successfully.  The idle timer is also restarted when sending the
+first ack-eliciting packet (see {{QUIC-RECOVERY}}) after receiving a packet.
+Restarting when sending packets ensures that connections do not prematurely time
+out when initiating new activity.  Only restarting when sending after receipt of
+a packet ensures the idle timeout is not excessively lengthened past the time
+the peer's timeout has expired.  An endpoint might need to send packets to avoid
+an idle timeout if it is unable to send application data due to being blocked on
 flow control limits; see {{flow-control}}.

Perhaps clarify that it is the application that decides when to keep a connection alive.

-- 
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/3444#pullrequestreview-363023786

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Feb 2020 15:33:05 -0800

martinthomson commented on this pull request.

 value.

That's only true to the extent that the application controls what activity is generated.  An application needs to communicate its intent.

-- 
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/3444#discussion_r382949761

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Feb 2020 15:33:13 -0800

Merged #3444 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/3444#event-3063046948