Subject: [quicwg/base-drafts] Prevent Idle Timeout while Blocked (#3266)

From: Nick Banks <[email-masked]>
Date: Tue, 19 Nov 2019 07:26:33 -0800

Fixes #2744 

To prevent a connection from going idle while it has application data to send, this PR recommends periodically sending the blocked frame as a keep alive.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Prevent Idle Timeout while Blocked

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Nov 2019 16:20:38 -0800

Hmm, this is a design change.

-- 
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/3266#issuecomment-555777043

---

From: ianswett <[email-masked]>
Date: Tue, 19 Nov 2019 17:39:47 -0800

ianswett commented on this pull request.

> @@ -785,13 +785,12 @@ flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
 and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
-control limits.  These frames are expected to be sent infrequently in common
-cases, but they are considered useful for debugging and monitoring purposes.
-
-A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames
-for the same data limit, unless the original frame is determined to be lost.
-Another STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
-limit is increased.
+control limits.  If a sender is blocked for long enough it is possible for the
+connection to idle timeout, even though the data is actively queued to be sent.
+To prevent this idle timeout from occurring, the sender SHOULD continue to
+periodically send the STREAM_DATA_BLOCKED or DATA_BLOCKED frame.  One method is
+to immediately resend the frame on acknowledgment of the previous one if the

I tend to think this might be overly aggressive?  If 10 streams are blocked, there's no reason to send 10 frames an RTT, is there?

-- 
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/3266#pullrequestreview-319463967

---

From: Nick Banks <[email-masked]>
Date: Tue, 19 Nov 2019 18:10:04 -0800

nibanks commented on this pull request.

I'm not trying to make any requirements on how many frames and how often you must send them. The only SHOULD here is to periodically (less than idle timeout) send some blocked frames. I'd leave it up to implementations to decide exactly what to do here. How should the text change (if at all) to make that more clear?

-- 
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/3266#discussion_r348261429

---

From: ianswett <[email-masked]>
Date: Tue, 19 Nov 2019 18:21:09 -0800

How about "One method is to resend a DATA_BLOCKED or STREAM_DATA_BLOCKED frame when there are no ack-eliciting packets in flight."

-- 
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/3266#discussion_r348263761

---

From: Nick Banks <[email-masked]>
Date: Tue, 19 Nov 2019 18:43:52 -0800

@nibanks pushed 1 commit.

49cea64e4bc427763900b739cc85528880767913  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/3266/files/9969af3c4f1a2696a94b3f8e3c504476bd4804f6..49cea64e4bc427763900b739cc85528880767913

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 20 Nov 2019 00:28:04 -0800

janaiyengar commented on this pull request.

+to resend a DATA_BLOCKED or STREAM_DATA_BLOCKED frame when there are no
+ack-eliciting packets in flight.

I would add some text to the idle timeout section as well (section 10.2). Something like "An endpoint should be careful to avoid an idle timeout if it is idle because of flow control; see Section XX".

Suggested rephrase: "If a sender is blocked for a period longer than the idle timeout ({{name-idle-timeout}}), the connection might get closed even when data is available for transmission. To keep the connection from closing, a sender SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when there are no ack-eliciting packets in flight."

-- 
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/3266#pullrequestreview-319659546

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Nov 2019 08:28:42 -0800

4170f4073ffa7bbeae39acf5ef512e37cb63898b  Jana's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3266/files/49cea64e4bc427763900b739cc85528880767913..4170f4073ffa7bbeae39acf5ef512e37cb63898b

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 20 Nov 2019 17:15:51 -0800

Sorry, jut a bit more rewording, but looks good otherwise.

> @@ -785,13 +785,11 @@ flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
 and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
-control limits.  These frames are expected to be sent infrequently in common
-cases, but they are considered useful for debugging and monitoring purposes.
-
-A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames
-for the same data limit, unless the original frame is determined to be lost.
-Another STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
-limit is increased.
+control limits.  If a sender is blocked for a period longer than the idle
+timeout ({{idle-timeout}}), the connection might get closed even when data is
+available for transmission.  To keep the connection from closing, a sender

```suggestion
available for transmission.  To keep the connection from closing, a sender that is flow control limited
```

> @@ -785,13 +785,11 @@ flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
 and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
-control limits.  These frames are expected to be sent infrequently in common
-cases, but they are considered useful for debugging and monitoring purposes.
-
-A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames
-for the same data limit, unless the original frame is determined to be lost.
-Another STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
-limit is increased.
+control limits.  If a sender is blocked for a period longer than the idle
+timeout ({{idle-timeout}}), the connection might get closed even when data is
+available for transmission.  To keep the connection from closing, a sender
+SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when there

```suggestion
SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it
```

> @@ -785,13 +785,11 @@ flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
 and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
-control limits.  These frames are expected to be sent infrequently in common
-cases, but they are considered useful for debugging and monitoring purposes.
-
-A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames
-for the same data limit, unless the original frame is determined to be lost.
-Another STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
-limit is increased.
+control limits.  If a sender is blocked for a period longer than the idle
+timeout ({{idle-timeout}}), the connection might get closed even when data is
+available for transmission.  To keep the connection from closing, a sender
+SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when there
+are no ack-eliciting packets in flight.

```suggestion
has no ack-eliciting packets in flight.
```

-- 
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/3266#pullrequestreview-320585820

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Nov 2019 18:23:35 -0800

f3e1f901ebe2d1f20bce40b350ea4a7af2c18726  Jana's suggestions (2)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3266/files/4170f4073ffa7bbeae39acf5ef512e37cb63898b..f3e1f901ebe2d1f20bce40b350ea4a7af2c18726

---

From: ianswett <[email-masked]>
Date: Wed, 20 Nov 2019 22:01:21 -0800

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/3266#pullrequestreview-320655155

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 Nov 2019 22:35:02 -0800

martinthomson approved this pull request.

> @@ -2353,7 +2351,8 @@ processed successfully.  The 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.
+activity.  An endpoint should be careful to avoid an idle timeout if it is idle

You use "should", which is a little sketchy.

> 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 {{data-flow-control}}).

-- 
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/3266#pullrequestreview-322062888

---

From: Nick Banks <[email-masked]>
Date: Mon, 25 Nov 2019 06:57:36 -0800

You can thank @janaiyengar for the sentence. :) Either way, I do prefer Jana's text over "might need to send", though both seem like they are just trying to skate around using normative language.

-- 
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/3266#discussion_r350232033

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2019 15:54:33 -0800

martinthomson commented on this pull request.

Not so much.  We can't require anything here as there isn't any interoperability hazard we're avoiding.  The goal is to make the consequence of certain choices clear.

-- 
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/3266#discussion_r350482488

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 25 Nov 2019 16:29:06 -0800

kazuho commented on this pull request.

LGTM, though I think we need to add similar text for STREAMS_BLOCKED too.

-- 
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/3266#pullrequestreview-322664132

---

From: Nick Banks <[email-masked]>
Date: Mon, 25 Nov 2019 16:34:22 -0800

@kazuho I'd argue this whole section should have similar text for STREAMS_BLOCKED, not just the text this PR is adding.

-- 
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/3266#issuecomment-558404917

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 25 Nov 2019 17:54:49 -0800

@nibanks Corresponding text already exists in section 4.5.
>  An endpoint that is unable to open a new stream due to the peer's limits SHOULD send a STREAMS_BLOCKED frame ({{frame-streams-blocked}}).  This signal is considered useful for debugging.

My point is that we might want to update this too, as the sender should behave the same way when it is blocked by data flow control vs. when blocked by stream-level concurrency.

+because of flow control (see {{data-flow-control}}).

Maybe change the reference to {{flow-control}}? Otherwise, blocked by stream concurrency would be out-of-scope.

Or, we might say "data flow control ({{data-flow-control}}) or stream concurrency ({{controlling-concurrency}})."

-- 
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/3266#pullrequestreview-322687047