Draft: draft-ietf-quic-transport

Commentary: This explains what needs to be kept and why . Specifically , you need to keep ranges unless you have other means of ensuring that you do n't accept packets from those ranges again . You also need to keep the largest acknowledged so that you can get a packet number from subsequent packets . This also recommends that ACK frames include the largest acknowledged always . That is primarily to ensure that ECN works properly , and even there , you only disable ECN if you get some weird reordering , so it 's probably not a big deal if you do n't follow this recommendation . The issue is marked design , but the resolution here is basically a restatement of other text . I think we can run this through the design process , but it is n't really worth flagging this in a change log in my opinion . 
 you should probably look at this . I have marked the associated issue anyway , but I 'd appreciate another review . 
 In , notes that this " MUST " : My understanding is that this prevents the largest acknowledged packet from going backwards . We use the monotonic increase of the Largest Acknowledged field in two ways : In ECN validation , this is used to filter out ACK frames that might have arrived out of order , which might have lower counts legitimately . In key updates , where the value of the largest acknowledged is used to drive the change to new keys and to prevent use of old keys after an update . In my view , having ECN validation fail is quite unfortunate , but likely workable . On the other hand , uncertainty about largest acknowledged could introduce instability in the key update process . If an endpoint 's conception of what the value is changes , I doubt that we 'll see extra key updates ( I think that the AEAD would protect us from that ) , but we might leave open the possibility of interleaving of packets from two different key phases . I would suggest that we retain this " MUST " . 
 For out of order ACK frames , you can use the packet number the ACK arrives in . I realize that we have tried to allow frames to be retransmitted , but I think retransmitting ACK frames without modifying the ACK delay / etc is so harmful we should probably prohibit that one frame from being retransmitted , since it creates a bunch of edge cases . Or we could let ECN validation could fail , but that 'd be a bit sad . I 'm confused about what the issue with key updates is ? The largest acked you 've ever seen does n't change , just the largest acked from the last ACK frame . When determining the size of the packet number , we say : " The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent . " I 'd rather not make this a MUST unless we have a good reason . There are valid use cases that become more complex with this constraint . 
 I really want to understand the use cases that you think that this might break . Because key updates very much depend on tracking largest acknowledged . The key updates case has a fairly simple example . Say you receive packet 10 in key phase 1 . Then 11 in key phase 2 . That 's valid . But if you ACK those and then only remember up to packet 8 , packet 9 can use key phase 2 and you wo n't know that it is invalid . 
 I 'd like to suggest tracking largest acknowledged from forcing all ACK frames to contain the largest acknowledged and have that value never decrease . Given you need to track largest acknowledged locally(ie : not only in the in - flight ACK frame ) , I do n't think there are any problems there . I have two cases in mind where the largest acked could validly decrease : 1 ) A receiver that tracks a limited number of ACK blocks and the oldest block happens to be the one containing largest acked . 2 ) If an application was reordering tolerant(ie : from ) then two different senders on a single ' connection ' may be sending packets with disparate packet numbers , causing what appears to be very large scale reordering . In this case , it 'd be valuable to discard the older ACK ranges even if they contained the largest acked . Maybe the first is an edge case we do n't care about in a use case we are n't optimizing for and the latter is solvable with careful issuing of packet number ranges . Even so , I 'm not sure what the motivation is for this change ? I guess the ECN case could be , but using largest acked as a proxy for retransmitted ACKs is a very bad design in my opinion . 
 I do n't think we really need to cater for retransmitted ACK frames in any way . What I 'm concerned about is reordering . Yes , using the increase of largest acknowledged as a proxy for strict ordering is a little weird , but the assumption is that frame handling is distinct from packet handling and packet numbers are not available when frames are handled . ( I think that 's the principle we agreed on ; that 's why it 's OK to use packet numbers in key updates , for example , something that I can confirm is borne out by implementation experience . ) The case you describe here has the appearance of exactly that type of reordering if the two senders also generate their own ACK frames ( though this seems very strange ) . But I think that the consequences of that sort of design are not our responsibility to deal with . 
 I do n't recall on us agreeing that packet numbers were n't available when frames are handled , can you clarify why that property is important ? 
 I agree with on the principle of not requiring the enclosing packet 's packet number during frame handling , and we use sequence numbers within frames to help with reordering . This was at least true in an earlier version of NCID frames , and we had discussed this principle then . This is also why the ACK_FREQUENCY frame in includes a sequence number . That said , I do n't understand the issue with key updates here . Largest acked so far is a connection - level state variable that can be used for key updates . I suspect that I 'm not understanding the example scenario . can you elaborate on your key update example ? Is your example motivated by a receiver that does not remember the largest acked or one that does not wish to ack anything but the packet that was just received ? 
 I was under the impression that the argument was that largest acknowledged was not being tracked , but  made it clear that the concern was about not signaling it . That removes key updates as a concern . If remains unclear , then I ca n't really do better . 
 my example was motivated by either case , but primarily not wanting to ACK anything besides what was just received . 
 Perhaps it 's a naive model , but I had envisioned an implementation remembering a chain of ranges of packet numbers it had received or not . The implementation would save space by forgetting the earliest packet numbers when the chain got too long , and would construct an ACK frame out of the latest set of these ranges it had room for . In that mental model , at least , there 's not really room for the idea that you might drop the largest - acked frame number from your memory because it 's too old -- it 's always at the most - recent end of your chain , even if you currently happen to be receiving packets that fill in the middle for some implementation - specific reason . ( Implementation - specific to the peer , which you obviously ca n't know about or code for ! ) 
 That matches my model for this . It is also likely the case that the next packet you receive is  , so there is no real advantage to forgetting the largest acknowledged . Not sending largest acknowledged is slightly different though . I can understand how an implementation might choose to send only ranges that have recently changed . My contention is that this is not a good choice and we should recommend against that . 
 to produce some text here that separates retention policy ( MUST ) from signaling policy ( SHOULD ) .
Paragraph (version A):
When discarding unacknowledged ACK Ranges, a receiver MUST retain the
largest received packet number.  A receiver SHOULD retain ACK Ranges
containing newly received packets or higher-numbered packets.
Paragraph (version B):
A receiver MUST retain an ACK Range unless it can ensure that it will
not subsequently accept packets with numbers in that range.
Maintaining a minimum packet number that increases as ranges are
discarded is one way to achieve this with minimal state.
Paragraph (version B):
Receivers can discard all ACK Ranges, but they MUST retain the
largest packet number that has been successfully processed as that is
used to recover packet numbers from subsequent packets; see packet-
encoding.
Paragraph (version B):
A receiver SHOULD include an ACK Range containing the largest
received packet number in every ACK frame.  The Largest Acknowledged
field is used in ECN validation at a sender and including a lower
value than what was included in a previous ACK frame could cause ECN
to be unnecessarily disabled; see ecn-validation.