Draft: draft-ietf-quic-transport

Commentary: I believe this was the existing intent , so marking this editorial . 
 What are the downsides of not doing this and generally having logic that triggers an immediate ACK if any out - of - order packet is received ? 
 Also , how would you recommend implementing this logic , assuming you already have the general logic ? Keep a flag and only trigger the immediate ACK if that is ? 
 The code that sends ACK frames would track the largest received ack - eliciting packet to determine if packets are out of order , not the largest received packet . This is similar to PTO , which is armed from the largest ack - eliciting packet , not the largest packet . 
 The text is already very clear that if you receive an ACK - only packet out of order , you MUST NOT send an ACK . The goal of this PR is to clarify that ACK - only packets do n't count when deciding when ack - eliciting packets are out - of - order . 
 Followup on my , I think what we need to do is to clarify that the scope of out - of - order packets is limited to ack - eliciting packets . We can say that a out - order packet is defined as " a newly received ack - eliciting packet carrying a packet number that is either smaller than those of any previously - received ack - eliciting packets , or is more than one greater than any of those packets . " 
 How do you tell if the absent packets are ack - eliciting ? I mean , most scenarios we use this definition are for the receiver , which ca n't know whether a missing packet is ack - eliciting . 
 I 've left my two cents regarding that concern on the . 
 if I 'm understanding correctly , the concern is that an implementation that sends ACK - only packets immediately but paces others will routinely have ACK - only packets skipping ahead of ACK - eliciting packets . If you react to all reordering , you 'll send a lot of unneeded immediate ACKs when interacting with such an implementation . 
 Yeah , that makes sense . Thanks . 
 has it right . It does n't cause a correctness issue , but it could result in a large number of unnecessary ACK - only packets being sent . 
 I ended up largely taking suggestion from , and no longer relying on out - of - order , but did n't remove the definition entirely . I can if people prefer . 
 Thanks removed . 
 The existing text mostly covers this , but I do n't think it 's always as clear as it could be . If one is doing various offloads(pacing / crypto / etc ) and those cause the sender to decide to send a batch of packets at once , with release times that are over a few milliseconds , the sender should not have to wait until all those packets are released to send an ACK . A simple example at the receiver is an ACK arrives with PN 10 , then PN 9 arrives . I do not believe PN 9 should not be considered ' out - of - order ' and trigger an immediate ACK . Recovery is designed with this case in mind , but when re - reading this text , I thought it was unclear . The simple way to think about this is " ACK - only packets do n't affect acknowledgement behavior " , which matches with TCP and most of our existing text . I think this will end up being editorial and I believe the only clarification necessary is but I 'd appreciate other peoples thoughts on whether this is something worth thinking about and whether there are any other changes necessary . 
 I share the view that this has been the intent , and that it is editorial . Loss recovery is an interaction between sender sending data vs. receiver sending acks . We might have two endpoints doing loss recovery at the same time , when both sides are sending data . But that should not affect how loss recovery works . 
 In , asks : I think we need to think about two possibilities : an ack - eliciting packet overtaking ack - only packet , and an ack - only packet overtaking an ack - eliciting packet . If the former happens , the receiver can do nothing but send an immediate ack , because it can not tell if the yet - missing packet is ack - only . But in the opposite case , the receiver can tell that it was an ack - only packet , because it has already received that packet . IIUC , point is that we 'd frequently see the latter when pacing is used , and therefore that we should address the issue . IMO , this issue is an artifact of us using one packet number space for loss recovery in both directions . The problem can not be cleanly solved unless we use different packet number spaces for ack - eliciting packets and ack - only packets . That said , I do think that it is a good idea to minimize the impact of the problem , and that the proposed clarification works fine in that respect . 
 That 's a reasonable analysis of this situation . That is also consistent with what our stack implements . That is , we only ever send an immediate acknowledgement when we receive ack - eliciting packets . I ca n't see how you would do otherwise , frankly . However , I think that attempting to define " out - of - order " is the problem . I just searched the transport document for this and we do n't use the definition . Therefore , I suggest that we say what we mean when it comes to describing how to immediately acknolwedge packets . That is , Or something like that . The out - of - order definition can go . 
 Good thought on getting rid of ' out - of - order ' , that should help . 
 I was about to say we could simplify the second bullet , but that would miss the case of : N-3 : last received ack - eliciting packet  : lost  : ACK - only packet N : Newly received We want to send an immediate ACK on receipt of N , but not N-1 . Nor do we want one on the late receipt of N-2 . 
 border - Borderline design , let 's run the process for visibility 
 Thanks for writing this down . Thank you for all your work .
Paragraph (version B):
when 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.