Subject: [quicwg/base-drafts] Use the 'no outstanding' rule to defer idle timeout (#1652)

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Aug 2018 17:54:14 -0700

Closes #1648.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Use the 'no outstanding' rule to defer idle timeout

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Tue, 14 Aug 2018 13:34:37 -0700

ianswett commented on this pull request.

Nice improvement, some text suggestions.

> @@ -2499,9 +2499,11 @@ A connection that remains idle for longer than the advertised idle timeout (see
 draining state when the idle timeout expires.
 
 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 the last
-received packet.  The latter condition ensures that initiating new activity
-postpones a timeout.
+starts from the last packet received.  In order to ensure that initiating new
+activity postpones an idle timeout, an endpoint restarts this timer when sending
+a packet if there are no other packets outstanding.  This condition only applies
+to packets that contain other than ACK or PADDING frames; those packets could

"that contain other" is awkward, how about "that contain frames other"

> @@ -2499,9 +2499,11 @@ A connection that remains idle for longer than the advertised idle timeout (see
 draining state when the idle timeout expires.
 
 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 the last
-received packet.  The latter condition ensures that initiating new activity
-postpones a timeout.
+starts from the last packet received.  In order to ensure that initiating new
+activity postpones an idle timeout, an endpoint restarts this timer when sending
+a packet if there are no other packets outstanding.  This condition only applies
+to packets that contain other than ACK or PADDING frames; those packets could
+remain outstanding longer and prevent the timeout from being extended.

How about a separate sentence "Packets that contain only ACK or PADDING frames may never be acknowledged, so they do not extend the timeout."

> @@ -2499,9 +2499,11 @@ A connection that remains idle for longer than the advertised idle timeout (see
 draining state when the idle timeout expires.
 
 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 the last
-received packet.  The latter condition ensures that initiating new activity
-postpones a timeout.
+starts from the last packet received.  In order to ensure that initiating new
+activity postpones an idle timeout, an endpoint restarts this timer when sending
+a packet if there are no other packets outstanding.  This condition only applies

How about "In order to ensure that initiating new activity postpones an idle timeout, an endpoint restarts this timer when sending a packet containing frames besides ACK or PADDING and no other packets are outstanding."

-- 
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/1652#pullrequestreview-146237522

---

From: ianswett <[email-masked]>
Date: Tue, 14 Aug 2018 13:35:31 -0700

This comment is obsolete if you make the above change or something similar.

-- 
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/1652#discussion_r210094526

---

From: ianswett <[email-masked]>
Date: Tue, 14 Aug 2018 13:37:14 -0700

On a high level, there's some remaining vagueness about what outstanding means.  Particularly now that PADDING frames count towards bytes in flight, but do not elicit an ACK.

-- 
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/1652#issuecomment-413007596

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Aug 2018 17:11:33 -0700

@martinthomson pushed 1 commit.

3526d34  Fixup idle timeout with no use of 'outstanding'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1652/files/3c5ae7b5bd50fde5338c68996cd75b4546b132c0..3526d342c88159880c79f33919c8b663d36fb5ae

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Aug 2018 17:57:28 -0700

Merged #1652 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/1652#event-1789124204

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Aug 2018 20:09:38 -0700

Surely an ACK only packet does not prevent idle timeout from refreshing? It merely does not controbute to progress?

-- 
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/1652#issuecomment-413081078

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Aug 2018 07:56:27 +0000 (UTC)

Receiving an ACK-only packet will reset the timer.  Sending one might.  If there are no other outstanding packets, then an ACK is sent after receiving a packet and after waiting for any ACK delay.  That will refresh the timer.  However, you won't send another ACK-only packet until a packet is declared lost, which only happens when new packets arrive.

-- 
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/1652#issuecomment-413122721

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 Aug 2018 02:35:26 -0700

I'm just find the word "prevent" confusing here:

"Packets that contain only ACK or
 PADDING frames are not acknowledged until an endpoint has other frames to send,
 so they could prevent the timeout from being refreshed."

-- 
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/1652#issuecomment-413145620

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Aug 2018 15:04:18 -0700

An ACK- and PADDING-only packet would not get acknowledged and so remain unacknowledged indefinitely.  If the rule is "don't refresh if you have unacknowledged packets", then those packets would prevent the timeout from being restarted when a new packet is sent.

-- 
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/1652#issuecomment-413353058

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 Aug 2018 15:31:01 -0700

I see - but why don't you exclude those packets. Simplicity? 

-- 
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/1652#issuecomment-413359493