Re: [quicwg/base-drafts] Don't recommend 3 RTTs of credit (and other editorial) (#3301)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

A few more suggestions, but this looks close.

> @@ -801,33 +801,37 @@ limit is increased.
 
 ## Flow Credit Increments {#fc-credit}

How about "Managing Flow Control"?

> -If a sender runs out of flow control credit, it will be unable to send new data
-and is considered blocked.  It is generally considered best to not let the
-sender become blocked.  To avoid blocking a sender, and to reasonably account
-for the possibility of loss, a receiver should send a MAX_DATA or
-MAX_STREAM_DATA frame at least two round trips before it expects the sender to
-get blocked.
-
-A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
-sending MAX_STREAM_DATA or MAX_DATA, since doing so will mean that a sender will
-be blocked for at least an entire round trip, and potentially for longer if the
-peer chooses to not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames.
+implementations.  As an optimization, an endpoint could send frames related to
+flow control only when there are other frames to send or when a peer is blocked,
+ensuring that flow control does not cause extra packets to be sent.
+
+A sender that is blocked could choose to not send STREAM_DATA_BLOCKED or

```suggestion
A blocked sender is not required to send STREAM_DATA_BLOCKED or
```

> -MAX_STREAM_DATA frame at least two round trips before it expects the sender to
-get blocked.
-
-A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
-sending MAX_STREAM_DATA or MAX_DATA, since doing so will mean that a sender will
-be blocked for at least an entire round trip, and potentially for longer if the
-peer chooses to not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames.
+implementations.  As an optimization, an endpoint could send frames related to
+flow control only when there are other frames to send or when a peer is blocked,
+ensuring that flow control does not cause extra packets to be sent.
+
+A sender that is blocked could choose to not send STREAM_DATA_BLOCKED or
+DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a
+STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or
+MAX_DATA frame; doing so could result in the sender being blocked for the rest
+of the connection. Even if the sender sent these frames, waiting for them will

```suggestion
of the connection. Even if the sender sends these frames, waiting for them will
```

> -A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
-sending MAX_STREAM_DATA or MAX_DATA, since doing so will mean that a sender will
-be blocked for at least an entire round trip, and potentially for longer if the
-peer chooses to not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames.
+implementations.  As an optimization, an endpoint could send frames related to
+flow control only when there are other frames to send or when a peer is blocked,
+ensuring that flow control does not cause extra packets to be sent.
+
+A sender that is blocked could choose to not send STREAM_DATA_BLOCKED or
+DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a
+STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or
+MAX_DATA frame; doing so could result in the sender being blocked for the rest
+of the connection. Even if the sender sent these frames, waiting for them will
+result in the sender being blocked for at least an entire round trip.
+
+When a sender receives credit after being blocked, it can send a large amount of

```suggestion
When a sender receives credit after being blocked, it may be able to send a large amount of
```

-- 
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/3301#pullrequestreview-334967789