Draft: draft-ietf-quic-ack-frequency

Commentary: tell me if this is sufficient , or if you wanted more references to RFC9000 . 
 Thanks , I 'm open to other suggestions if you have them , but nothing else stuck out at me . I 'm reluctant to repeat the full definition of out of order in this document , given it 's well defined in RFC9000 . 
 When reviewing the draft I got caught on this part : As specified in Section 13.2.1 of [ QUIC - TRANSPORT ] , endpoints are expected to send an acknowledgement immediately on receiving a reordered ack - eliciting packet . This extension modifies this behavior . There is an issue here in how this draft uses " reordering " . Section 13.2.1 of RFC 9000 does say that ACKs should be sent immediately if : " 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 , orwhen 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 . " Although the first bullet clearly is reordering , the second could be caused by three different mechanisms : Reordering of packets , loss of packets , or sender intentional gap ( as discussed in ) Thus , I think this section needs to be clear if actually means both of the above bullets for when to send ACK or only one of them ? 
 Thanks Magnus , the intent was to follow the RFC9000 definition , so I 'll write a PR to clarify that was the intent . 
 A couple of minor edits , but lgtmOk , I think this is truly the bare minimal to resolve my issue . There exist a clearer chain back towards Section 13.2.1 in RFC9000 and I guess that is sufficient .
QUIC-TRANSPORT currently specifies a simple delayed acknowledgement
mechanism that a receiver can use: send an acknowledgement for every
other packet, and for every packet when reordering is observed.  This
simple mechanism does not allow a sender to signal its constraints.
This extension provides a mechanism to solve this problem.
QUIC-TRANSPORT currently specifies a simple delayed acknowledgement
mechanism that a receiver can use: send an acknowledgement for every
other packet, and for every packet that is received out of order
(Section 13.2.1 of QUIC-TRANSPORT).  This simple mechanism does not
allow a sender to signal its constraints.  This extension provides a
mechanism to solve this problem.
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 observes reordering
(reordering).  0 represents 'false' and 1 represents 'true'.
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 CE-marked packets
(reordering).  0 represents 'false' and 1 represents 'true'.
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 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 CE-marked packets
(out-of-order).  0 represents 'false' and 1 represents 'true'.
reordering, congestion, and batch describe exceptions to this
strategy.
out-of-order, congestion, and batch describe exceptions to this
strategy.