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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

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

> @@ -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
+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