target = "https://www.rfc-editor.org/rfc/rfc9000#section-4.2"

# 4.2.  Increasing Flow Control Limits
#
# Implementations decide when and how much credit to advertise in
# MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
# considerations.
# 
# To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or
# MAX_DATA frame multiple times within a round trip or send it early
# enough to allow time for loss of the frame and subsequent recovery.
# 
# Control frames contribute to connection overhead.  Therefore,
# frequently sending MAX_STREAM_DATA and MAX_DATA frames with small
# changes is undesirable.  On the other hand, if updates are less
# frequent, larger increments to limits are necessary to avoid blocking
# a sender, requiring larger resource commitments at the receiver.
# There is a trade-off between resource commitment and overhead when
# determining how large a limit is advertised.
# 
# A receiver can use an autotuning mechanism to tune the frequency and
# amount of advertised additional credit based on a round-trip time
# estimate and the rate at which the receiving application consumes
# data, similar to common TCP implementations.  As an optimization, an
# endpoint could send frames related to flow control only when there
# are other frames to send, ensuring that flow control does not cause
# extra packets to be sent.
# 
# A blocked sender is not required to 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 sends 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 might be able
# to send a large amount of data in response, resulting in short-term
# congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of
# how a sender can avoid this congestion.

[[spec]]
level = "MAY"
quote = '''
To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early
enough to allow time for loss of the frame and subsequent recovery.
'''

[[spec]]
level = "MUST"
quote = '''
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.
'''