target = "https://www.rfc-editor.org/rfc/rfc9002#section-7.7"

# 7.7.  Pacing
#
# A sender SHOULD pace sending of all in-flight packets based on input
# from the congestion controller.
# 
# Sending multiple packets into the network without any delay between
# them creates a packet burst that might cause short-term congestion
# and losses.  Senders MUST either use pacing or limit such bursts.
# Senders SHOULD limit bursts to the initial congestion window; see
# Section 7.2.  A sender with knowledge that the network path to the
# receiver can absorb larger bursts MAY use a higher limit.
# 
# An implementation should take care to architect its congestion
# controller to work well with a pacer.  For instance, a pacer might
# wrap the congestion controller and control the availability of the
# congestion window, or a pacer might pace out packets handed to it by
# the congestion controller.
# 
# Timely delivery of ACK frames is important for efficient loss
# recovery.  To avoid delaying their delivery to the peer, packets
# containing only ACK frames SHOULD therefore not be paced.
# 
# Endpoints can implement pacing as they choose.  A perfectly paced
# sender spreads packets exactly evenly over time.  For a window-based
# congestion controller, such as the one in this document, that rate
# can be computed by averaging the congestion window over the RTT.
# Expressed as a rate in units of bytes per time, where
# congestion_window is in bytes:
# 
# rate = N * congestion_window / smoothed_rtt
# 
# Or expressed as an inter-packet interval in units of time:
# 
# interval = ( smoothed_rtt * packet_size / congestion_window ) / N
# 
# Using a value for "N" that is small, but at least 1 (for example,
# 1.25) ensures that variations in RTT do not result in
# underutilization of the congestion window.
# 
# Practical considerations, such as packetization, scheduling delays,
# and computational efficiency, can cause a sender to deviate from this
# rate over time periods that are much shorter than an RTT.
# 
# One possible implementation strategy for pacing uses a leaky bucket
# algorithm, where the capacity of the "bucket" is limited to the
# maximum burst size and the rate the "bucket" fills is determined by
# the above function.

[[spec]]
level = "SHOULD"
quote = '''
A sender SHOULD pace sending of all in-flight packets based on input
from the congestion controller.
'''

[[spec]]
level = "MUST"
quote = '''
Senders MUST either use pacing or limit such bursts.
'''

[[spec]]
level = "SHOULD"
quote = '''
Senders SHOULD limit bursts to the initial congestion window; see
Section 7.2.
'''

[[spec]]
level = "MAY"
quote = '''
A sender with knowledge that the network path to the
receiver can absorb larger bursts MAY use a higher limit.
'''

[[spec]]
level = "SHOULD"
quote = '''
To avoid delaying their delivery to the peer, packets
containing only ACK frames SHOULD therefore not be paced.
'''