Draft: draft-ietf-quic-transport

Commentary: It 's no longer normative and it 's in a single section . I only moved text so far , and not as far as suggested . I can go farther here or in a follow - up PR . 
 I would like to merge this .  ? 
 Can we merge this soon . I 'm worried about it developing conflicts . 
 Yep , lost the chance to fix the PR . We are - of course - still open for editorial improvements in the form of new pull requests though . 
 them " exemplary " but 13.2.4 has MUST in it . 
 For reference , this refers to and in the editor 's copy . I 'm in favour of striking the exemplary note and saying that while the recovery draft is advisory , this document depends on implementations following something like what is recommended . 
 The specific MUSTs are n't really about the ACK algorithm per se , but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code . If an implementation is unable to do duplicate detection for a packet number range , it MUST fail toward rejecting all packets , not toward accepting potential duplicates . An implementation must track the greatest packet number ever received , for use in recovering future packet numbers . In fact , the first requirement is discussed in 12.3 and could probably be dropped here . The second is n't actually called out ( MUST ) in 17.1 , but could easily be moved there . 
 I think I 'm inclined towards reorganizing the text and putting all the ' exemplary ' parts into one section(ie : " Limiting ACK Ranges " ) and moving the normative text either into " Managing ACK Ranges " or elsewhere in the draft . 
 I thought I could clean this up fairly quickly , but I think a fair number of paragraphs need to move , including some of suggestions . I 'm happy to try to improve this in a few days if no one else has beaten me to it . 
 Anyone want to help out and take this on ? 
 Sorry about dropping this one . I 'm fine with it , and happy to make editorials one later . Thanks  . When you lay it out like this , it seems so obvious . I checked that we do n't have citations for { { ack - tracking } } , so this works nicely . If you care about the " MAY " , then we can fix that in another PR .
Paragraph (version A):
ack-tracking and ack-limiting describe an exemplary approach for
determining what packets to acknowledge in each ACK frame.  Though
the goal of these algorithms is to generate an acknowledgment for
every packet that is processed, it is still possible for
acknowledgments to be lost.  A sender cannot expect to receive an
acknowledgment for every packet that the receiver processes.
Paragraph (version A):
A receiver limits the number of ACK Ranges (ack-ranges) it remembers
and sends in ACK frames, both to limit the size of ACK frames and to
avoid resource exhaustion.  After receiving acknowledgments for an
ACK frame, the receiver SHOULD stop tracking those acknowledged ACK
Ranges.
Paragraph (version B):
A receiver limits the number of ACK Ranges (ack-ranges) it remembers
and sends in ACK frames, both to limit the size of ACK frames and to
avoid resource exhaustion.  After receiving acknowledgments for an
ACK frame, the receiver SHOULD stop tracking those acknowledged ACK
Ranges.  Senders can expect acknowledgements for most packets, but
QUIC does not guarantee receipt of an acknowledgment for every packet
that the receiver processes.
Paragraph (version B):
ack-tracking describes an exemplary approach for determining what
packets to acknowledge in each ACK frame.  Though the goal of this
algorithm is to generate an acknowledgment for every packet that is
processed, it is still possible for acknowledgments to be lost.