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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Some editorial suggestions

> @@ -801,33 +801,41 @@ limit is increased.
 
 ## Flow Credit Increments {#fc-credit}
 
-This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a

```suggestion
sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so means a sender will
```

> @@ -801,33 +801,41 @@ limit is increased.
 
 ## Flow Credit Increments {#fc-credit}
 
-This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to

```suggestion
be blocked for the rest of the connection if the peer chooses not to
```

> -This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA
-or MAX_DATA frame to implementations, but offers a few considerations.  These
-frames contribute to connection overhead.  Therefore frequently sending frames
-with small changes is undesirable.  At the same time, larger increments to
-limits are necessary to avoid blocking if updates are less frequent, requiring
-larger resource commitments at the receiver.  Thus there is a trade-off between
-resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these

```suggestion
send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
```

> +and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
+multiple times within a round trip or send it early enough to allow for recovery
+from potential loss.

```suggestion
from loss of the frame.
```

> -resource commitment and overhead when determining how large a limit is
-advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the

```suggestion
connection. To avoid blocking a sender,
```

> -advertised.
+Implementations decide when and how many bytes to advertise in MAX_STREAM_DATA
+and MAX_DATA frames. This section describes one requirement and offers a few
+considerations.
+
+A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before
+sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame

```suggestion
a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
```

> +sending a MAX_STREAM_DATA or MAX_DATA frame, since doing so will mean that a
+sender could be blocked for the rest of the connection if the peer chooses to
+not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. Even if the peer sent these
+frames, waiting for them means that a sender will be blocked for at least an
+entire round trip.
+
+A sender that runs out of flow control credit will be unable to send new data
+and is considered blocked, resulting in degraded performance for the
+connection. To avoid blocking a sender and to reasonably account for the
+possibility of loss, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame
+multiple times within a round trip or send it early enough to allow for recovery
+from potential loss.
+
+Control frames contribute to connection overhead. Therefore, frequently sending
+MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable.  At the
+same time, larger increments to limits are necessary to avoid blocking if

I'd switch this around, ie:
"At the same time, less frequent updates require larger increments to the limits to avoid blocking."

-- 
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-333436130