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

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.

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