(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
