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

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.



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

Ah, I forgot that I had thought about this and decided to leave it as it is :-) We do not require a sender to send a BLOCKED frame, and we therefore need to require receivers to not wait for this frame since it may never arrive. That's a deadlock (of a strange sort).


-- 
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#discussion_r359162790