Draft: draft-ietf-quic-ack-frequency

Commentary: Removes the normative SHOULD from : " a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack - eliciting packets in flight " . It may be back in some form , see issue 
 I am sure this PR could be improved upon , but I 'm happy enough with it to land it and make future improvements . What are others thoughts ? 
 I 'm OK to merge the PR , and then to open issues around that - my key issue is that I do n't think a single ACK per RTT is the correct advice for loaded paths ( or lossy paths ) . In the measurements I have seen , several ( e.g. 4 ) per RTT are beneficial to be avoid the effects of path variation and loss on the return path . 
 In the congestion control PR I suggested the following sentence : The congestion control section is probably not the right place for this normative requirement but I think it 's a correct requirement ( with the intention that it is a SHOULD and not MUST and you maybe decide differently e.g. in a DC environment ) . 
 I 'm unsure if I want to say this or not , but thanks for filing an issue . If we do say this , we should have a note that the Request    value may be limited by the minackdelay transport param . 
 Which PR does this have ? ? 
 yes currently it 's part of 
 I removed the normative requirement from PR as part of accepting your suggestion . I 'm inclined to not add a new normative requirement elsewhere , since it 's not clear to me exactly what that should be . 
 I 'll note that we still have : " To limit these consequences of reduced acknowledgement frequency , a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack - eliciting packets in flight . " I personally feel this is sufficient . 
 Yes , that the same requirement . Especially as the next sentence also says : " A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round - trip time ( RTT ) , or it can set the Ack - Eliciting Threshold and     values to be no more than a congestion window and an estimated RTT , respectively . " So I guess this is cover in the right place already now and we can close the issue . Thanks ! 
 Currently there is the following text in PR : as communicated via the ' minackdelay ' transport parameter , preventing the receiver from sending an acknowledgment every RTT in time . In these cases , ' Reordering Threshold ' can be harmful , because it delays fast loss detection . It is not clear how much this case ( which usually only occurs in data centres and not over the Internet ) should be discussed and what the right guidance would be . 
 I 'd argue we do n't need to discuss it further , and instead just call it out as an issue as PR does . 
 Addressed by 
 Current text says : " Similarly , if these controllers rely on the timing of peer acknowledgments ( an " ACK clock " ) , delaying acknowledgments will cause undesirable bursts of data into the network . " PR was closed , but I think this is still open ? - The current text seems cryptic to me . Do the bursts really impact the congestion control design ? - I can see ACK frequency changes could cause undesirable bursts of data , and those bursts could , in turn , induce congestion - can we explain that . Especially since RFC9000 also seems to say these bursts could be mitigated by pacing , and also they could be controlled in some other way to be less than a maximum burst size ( e.g.  burst ) . I 'd still argue that QUIC has a behaviour which expects bursts of upto 10 packets , and that this argues that pacing at least right now to mitigate bursts larger than the size of IW . Such burst mitigations are not without their own tradeoffs . The ACK_Frequency frame can postpone reporting loss , are there other impacts ? 
 Delaying ACKs could cause bursts , but it 's certainly not guaranteed due to pacing , etc . I 'll update the text to correct and clarify this .
For asymmetric link technologies, such as DOCSIS, LTE, and
satellite, connection throughput in the forward path can become
constrained when the reverse path is filled by acknowledgment
packets RFC3449.  When traversing such links, reducing the number
of acknowledgments can achieve higher connection throughput, lower
the impact on other flows or optimise the overall use of
transmission resources Cus22.
The rate of acknowledgment packets can impact link efficiency,
including transmission opportunities or battery life, as well as
transmission opportunities available to other flows sharing the
same link.
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint that is sending this value
is able to delay an acknowledgement.  This limit could be based on
the receiver's clock or timer granularity. 'min_ack_delay' is used
by the peer to avoid requesting too small a value in the Request
Max Ack Delay field of the ACK_FREQUENCY frame.
Endpoints MUST NOT remember the value of the min_ack_delay transport
parameter they received for use in a subsequent connection.
Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets,
as per Section 7.4.1 of QUIC-TRANSPORT.
A variable-length integer representing the sequence number
assigned to the ACK_FREQUENCY frame by the sender to allow
receivers to ignore obsolete frames.
A variable-length integer representing the maximum number of ack-
eliciting packets the recipient of this frame receives before
sending an acknowledgment.  A receiving endpoint SHOULD send at
least one ACK frame when more than this number of ack-eliciting
packets have been received.  A value of 0 results in a receiver
immediately acknowledging every ack-eliciting packet.  By default,
an endpoint sends an ACK frame for every other ack-eliciting
packet, as specified in Section 13.2.2 of QUIC-TRANSPORT, which
corresponds to a value of 1.
A 1-bit field representing a boolean truth value.  This field is
set to "true" by an endpoint that does not wish to receive an
immediate acknowledgement when the peer receives a packet out of
order (out-of-order). 0 represents 'false' and 1 represents
'true'.
A variable-length integer representing the value to which the
endpoint requests the peer update its "max_ack_delay"
(Section 18.2 of QUIC-TRANSPORT).  The value of this field is in
microseconds, unlike the 'max_ack_delay' transport parameter,
which is in milliseconds.  Sending a value smaller than the
"min_ack_delay" advertised by the peer is invalid.  Receipt of an
invalid value MUST be treated as a connection error of type
PROTOCOL_VIOLATION.  On receiving a valid value in this field, the
endpoint MUST update its "max_ack_delay" to the value provided by
the peer.
A variable-length integer that indicates how many out of order
packets can arrive before eliciting an immediate ACK.  If no
ACK_FREQUENCY frames have been received, the endpoint immediately
acknowledges any subsequent packets that are received out of
order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the
default value is 1.  A value of 0 indicates out-of-order packets
do not elicit an immediate ACKs.
ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame
is lost, is encouraged to send an ACK_FREQUENCY frame, unless an
ACK_FREQUENCY frame with a larger Sequence Number value has already
been sent.  However, it is not forbidden to retransmit the lost frame
(see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore
duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence
Number.
An endpoint can send multiple ACK_FREQUENCY frames with different
values within a connection.  A sending endpoint MUST send
monotonically increasing values in the Sequence Number field, since
this field allows ACK_FREQUENCY frames to be processed out of order.
A receiving endpoint MUST ignore a received ACK_FREQUENCY frame if
the Sequence Number value in the frame is not greater than the
largest processed thus far.
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than or equal to the recorded
"Ack-Eliciting Threshold".
An IMMEDIATE_ACK frame can be useful in other situations as well.
For example, if a sender wants an immediate RTT measurement or if a
sender wants to establish receiver liveness as quickly as possible.
PING frames (Section 19.2 of QUIC-TRANSPORT) are ack-eliciting but if
a PING frame is sent without an IMMEDIATE_ACK frame, the receiver
might not immediately send an ACK based on its local ACK strategy.
By definition IMMEDIATE_ACK frames are ack-eliciting.  An endpoint
SHOULD send a packet containing an ACK frame immediately upon
receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending an
ACK frame despite receiving an IMMEDIATE_ACK frame.  For example, an
endpoint might do this if a large number of received packets contain
an IMMEDIATE_ACK or if the endpoint is under heavy load.
IMMEDIATE_ACK frames do not need to be retransmitted.
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than the "Ack-Eliciting
Threshold".
An endpoint is expected to bundle acknowledgements when possible.
Every time an acknowledgement is sent, bundled or otherwise, all
counters and timers related to delaying of acknowledgments are reset.
If the most recent ACK_FREQUENCY frame received from the peer has an
"Ignore Order" value of "true" (0x01), the endpoint does not make
this exception.  That is, the endpoint MUST NOT send an immediate
acknowledgement in response to packets received out of order, and
instead continues to use the peer's "Ack-Eliciting Threshold" and
"max_ack_delay" thresholds for sending acknowledgements.
An endpoint SHOULD send an immediate acknowledgement when a packet
marked with the ECN Congestion Experienced (CE) RFC3168 codepoint in
the IP header is received and the previously received packet was not
marked CE.
Doing this maintains the peer's response time to congestion events,
while also reducing the ACK rate compared to Section 13.2.1 of QUIC-
TRANSPORT during extreme congestion or when peers are using DCTCP
RFC8257 or other congestion controllers (e.g.  I-D.ietf-tsvwg-aqm-
dualq-coupled) that mark more frequently than classic ECN RFC3168.
To avoid sending multiple acknowledgements in rapid succession, an
endpoint MAY process all packets in a batch before determining
whether a threshold has been met and an acknowledgement is to be sent
in response.
To avoid sending multiple acknowledgements in rapid succession, an
endpoint can process all packets in a batch before determining
whether to send an ACK frame in response, as stated in Section 13.2.2
of QUIC-TRANSPORT.
A sender needs to be responsive to notifications of congestion, such
as a packet loss or an ECN CE marking.  To enable a sender to respond
to potential network congestion in a timely fashion, usually at least
one acknowledgement per round trip is needed if there are
unacknowledged ack-eliciting packets in flight.  A sender can
accomplish this by setting the Ack-Eliciting Threshold to a value no
larger than the current congestion window or the Request Max Ack
Delay value to no more than the estimated round trip.  Note that the
congestion window particularly but also the RTT are dynamic and
therefore might require frequent updates if the selected value are
close to these limits.  Alternatively, a sender can accomplish this
by sending an IMMEDIATE_ACK frame once per round trip, though if the
packet containing an IMMEDIATE_ACK is lost, detection of that loss
will be delayed by the reordering threshold or requested max ack
delay.
Note that it is possible that the RTT is smaller than the receiver's
timer granularity, as communicated via the 'min_ack_delay' transport
parameter, preventing the receiver from sending an acknowledgment
every RTT in time.  In these cases, Reordering Threshold values other
than 1 can be harmful, because it delays fast loss detection.
A congestion controller that is congestion window limited relies upon
receiving acknowledgements to send additional data into the network.
An increase in acknowledgement delay increases the delay in sending
data, which can reduce the achieved throughput.  Congestion window
growth can also depend upon receiving acknowledgements.  This can be
particularly significant in slow start (Section 7.3.1 of QUIC-
RECOVERY), when delaying acknowledgements can delay the increase in
congestion window and can create larger packet bursts.
If the sender is application-limited, acknowledgements can be delayed
unnecessarily when entering idle periods.  Therefore, if no further
data is buffered to be sent, a sender can send an IMMEDIATE_ACK frame
with the last data packet before an idle period to avoid waiting for
the ack delay.
A sender might use timers to detect loss of PMTU probe packets
(Section 14 of QUIC-TRANSPORT).  A sender SHOULD bundle an
IMMEDIATE_ACK frame with any PTMU probes to avoid triggering such
timers.
An improperly configured or malicious data sender could cause a data
receiver to acknowledge more frequently than its available resources
permits.  However, there are two limits that make such an attack
largely inconsequential.  First, the acknowledgement rate is bounded
by the rate at which data is received.  Second, ACK_FREQUENCY and
IMMEDIATE_ACK frames can only request an increase in the
acknowledgment rate, but cannot force it.
In general, with this extension, a sender cannot force a receiver to
acknowledge more frequently than the receiver considers safe based on
its resource constraints.
This document defines a new transport parameter to advertise support
of the extension described in this document and two new frame types
to registered by IANQ in the respective "QUIC Protocol" registries
under https://www.iana.org/assignments/quic/quic.xhtml [1].
The following entry in transport-parameters should be added to the
"QUIC Transport Parameters" registry under the "QUIC Protocol"
heading.
The following frame types should be added to the "QUIC Frame Types"
registry under the "QUIC Protocol" heading.