Draft: draft-ietf-quic-recovery

Commentary: I started this to but there 's not much to fix . This does not change normative text , it just makes the intro match the detailed text which follows . 
 I 'm not sure - if padding is included to discover PMTU or whatever , and the pipe clogs up , that is a problem even if the contribution is not ack eliciting . It is of course still important to not block acks . 
 I understood the text as saying that you can probably assume that all packets ( including non - ack - eliciting ones ) got lost when you do n't hear anything back for a while ... Also if you receive a packet that only ACKs non - ack - eliciting packets this would be weird but it probably means there is not persistent congestion because you know something went though . 
 This is good . The problem with non - ack - eliciting packets is that a sender can not infer anything about network conditions when it is n't expecting an ack . Meaning that the receiver could have received everything and simply not responded if none of those packets are ack - eliciting . 
 yes , you do n't know anything when you do n't received an ACK . However , you may still received an ACK for non - ACK - eliciting packet ( as that is not forbidden ) and then you do know something that you should not ignore . The text is unclear about that . Maybe adding another sentence is the right thing to do . 
 I 'm not sure I follow . If a sender receives an ack for a non - ack - eliciting packet , that only establishes its receipt . I do n't understand how what you are saying is a problem with this text . That said , I do think this text incorrectly depicts the actual mechanism below , so I 've written . 
 I think you 're saying the same thing . The text as currently written suggests that : Send an ack - eliciting packet Send 100 non - ack - eliciting packets Send another ack - eliciting packet Receive an ack for the 100 non - ack - eliciting packets If persistent congestion is the loss of all packets in that time frame , this is n't persistent congestion . If persistent congestion is the loss of all ack - eliciting packets in that time frame , this is . The change in the follow - up PRs brings it back to what I think was originally intended . 
 : But we do want loss of non - ack - eliciting packets to count towards persistent congestion ; they are n't special in terms of loss , they 're just special in terms of eliciting an ack . Which is why we only care about the " edge packets " being ack - eliciting . 
 On the mailing list   asked some questions about persistent congestion and why it was only applicable to in - flight packets . During the explanation , I realized that it should probably be ack - eliciting packets , not in - flight . UPDATE : It already is ack - eliciting in all but one spot . I wrote PR to fix that one spot . 
 To have the context , I quote your explanation . I think ack - eliciting makes more sense here than in - flight . At least , I understand that for the persistent congestion detection the first and the last packet need to be ack - eliciting . But why does this have to be true for packets sent between these two ack - eliciting packets ? Here is an example for the edge case . The loss of three out of 50 packets let the sender consider this a persistent congestion . In general , I do n't see a real issue here . But , I would like to understand why it is helpful to ignore the fact that non - ack - eliciting packets , sent between two lost ack - eliciting packets , have been acknowledged . 
 This absolutely should not be in flight packets . This may not cause a major issue as it stands but it is not technically correct . 
 The text is largely correct(ack - eliciting , not in - flight ) already , based on my reading . Unfortunately , the very first description is incorrect , which is potentially confusing , so see
Paragraph (version A):
When a sender establishes loss of all in-flight packets sent over a
long enough duration, the network is considered to be experiencing
persistent congestion.
Paragraph (version B):
When a sender establishes loss of all ack-eliciting packets sent over
a long enough duration, the network is considered to be experiencing
persistent congestion.