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

# 13.2.1.  Sending ACK Frames
#
# Every packet SHOULD be acknowledged at least once, and ack-eliciting
# packets MUST be acknowledged at least once within the maximum delay
# an endpoint communicated using the max_ack_delay transport parameter;
# see Section 18.2.  max_ack_delay declares an explicit contract: an
# endpoint promises to never intentionally delay acknowledgments of an
# ack-eliciting packet by more than the indicated value.  If it does,
# any excess accrues to the RTT estimate and could result in spurious
# or delayed retransmissions from the peer.  A sender uses the
# receiver's max_ack_delay value in determining timeouts for timer-
# based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].
# 
# An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
# packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
# within its advertised max_ack_delay, with the following exception.
# Prior to handshake confirmation, an endpoint might not have packet
# protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets
# when they are received.  It might therefore buffer them and
# acknowledge them when the requisite keys become available.
# 
# Since packets containing only ACK frames are not congestion
# controlled, an endpoint MUST NOT send more than one such packet in
# response to receiving an ack-eliciting packet.
# 
# An endpoint MUST NOT send a non-ack-eliciting packet in response to a
# non-ack-eliciting packet, even if there are packet gaps that precede
# the received packet.  This avoids an infinite feedback loop of
# acknowledgments, which could prevent the connection from ever
# becoming idle.  Non-ack-eliciting packets are eventually acknowledged
# when the endpoint sends an ACK frame in response to other events.
# 
# An endpoint that is only sending ACK frames will not receive
# acknowledgments from its peer unless those acknowledgments are
# included in packets with ack-eliciting frames.  An endpoint SHOULD
# send an ACK frame with other frames when there are new ack-eliciting
# packets to acknowledge.  When only non-ack-eliciting packets need to
# be acknowledged, an endpoint MAY choose not to send an ACK frame with
# outgoing frames until an ack-eliciting packet has been received.
# 
# An endpoint that is only sending non-ack-eliciting packets might
# choose to occasionally add an ack-eliciting frame to those packets to
# ensure that it receives an acknowledgment; see Section 13.2.4.  In
# that case, an endpoint MUST NOT send an ack-eliciting frame in all
# packets that would otherwise be non-ack-eliciting, to avoid an
# infinite feedback loop of acknowledgments.
# 
# In order to assist loss detection at the sender, an endpoint SHOULD
# generate and send an ACK frame without delay when it receives an ack-
# eliciting packet either:
# 
# *  when the received packet has a packet number less than another
#    ack-eliciting packet that has been received, or
# 
# *  when the packet has a packet number larger than the highest-
#    numbered ack-eliciting packet that has been received and there are
#    missing packets between that packet and this packet.
# 
# Similarly, packets marked with the ECN Congestion Experienced (CE)
# codepoint in the IP header SHOULD be acknowledged immediately, to
# reduce the peer's response time to congestion events.
# 
# The algorithms in [QUIC-RECOVERY] are expected to be resilient to
# receivers that do not follow the guidance offered above.  However, an
# implementation should only deviate from these requirements after
# careful consideration of the performance implications of a change,
# for connections made by the endpoint and for other users of the
# network.

[[spec]]
level = "MUST"
quote = '''
Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum delay
an endpoint communicated using the max_ack_delay transport parameter;
see Section 18.2.
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
within its advertised max_ack_delay, with the following exception.
'''

[[spec]]
level = "MUST"
quote = '''
Since packets containing only ACK frames are not congestion
controlled, an endpoint MUST NOT send more than one such packet in
response to receiving an ack-eliciting packet.
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST NOT send a non-ack-eliciting packet in response to a
non-ack-eliciting packet, even if there are packet gaps that precede
the received packet.
'''

[[spec]]
level = "SHOULD"
quote = '''
An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.
'''

[[spec]]
level = "MAY"
quote = '''
When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY choose not to send an ACK frame with
outgoing frames until an ack-eliciting packet has been received.
'''

[[spec]]
level = "MUST"
quote = '''
In
that case, an endpoint MUST NOT send an ack-eliciting frame in all
packets that would otherwise be non-ack-eliciting, to avoid an
infinite feedback loop of acknowledgments.
'''

[[spec]]
level = "SHOULD"
quote = '''
In order to assist loss detection at the sender, an endpoint SHOULD
generate and send an ACK frame without delay when it receives an ack-
eliciting packet either:
'''

[[spec]]
level = "SHOULD"
quote = '''
Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events.
'''