WGLC review of draft-ietf-quic-ack-frequency-07

[Martin Duke <[e-mail]>]

(No hats) IMO this is ready, but I have some minor comments.

(3) "Receiving a min_ack_delay transport parameter indicates that the peer
might send ACK_FREQUENCY frames in the future. Until an ACK_FREQUENCY frame
is received, receiving this transport parameter does not cause the endpoint
to change its acknowledgement behavior."

This doesn't seem consistent with earlier statements in the document.
Specifically, min_ack_delay is meant to indicate the ability to *receive*
ACK_FREQUENCY. Indeed, the previous paragraph states that it is perfectly
legal for an endpoint to not send this TP and send ACK_FREQUENCY, provided
that the peer sent the TP.

Granted, it would be weird for the endpoint to not send the TP if it is
also going to send ACK_FREQUENCY frames, which maybe is what you mean? But
IMO this paragraph just confuses things.

(4) "Receipt of an invalid value MUST be treated as a connection error of
type TRANSPORT_PARAMETER_ERROR"

Is this really a TRANSPORT_PARAMETER_ERROR if it's caused by a frame that
violates the limits in the peer's parameter? I think it's more of a
PROTOCOL_ERROR, or better yet, a newly minted error code.

(3) and (5). What are the requirements to coordinate use of IMMEDIATE_ACK
frames? The transport parameter specifically only addresses ACK_FREQUENCY.
I would imagine that the TP also advertises the willingness to receive
IMMEDIATE_ACK?

(6.2) "Unreported Missing:
Packets with packet numbers between the Largest Unacked and Largest
Reported that have not yet been received"

Please specify that this is inclusive. In the first example, when packet 10
arrives, Largest Reported is exactly 7, and there is an ack because 7 is
missing.

(7) There is an outdated reference to "ignore order". This should be
"reordering threshold = 0". Indeed, the statement

"When Ignore Order is enabled and loss causes the peer to not receive
enough packets to trigger an immediate acknowledgement, the receiver will
wait 'max_ack_delay', increasing the chances of a premature PTO. Therefore,
if Ignore Order is enabled, the PTO MUST be larger than the peer's
'max_ack_delay'."

seems outdated. Instead, the sender can only ignore max_ack_delay if the
number of packets in flight >= ack_eliciting_threshold +
reordering_threshold if reordering_threshold > 0. In effect
reordering_threshold = 0 is a special value that actually indicates
infinity.

Martin