Original text:
7.6. <del> When a sender establishes loss of all in-flight packets sent over a long enough duration, the network is considered to be experiencing </del>  persistent congestion. 7.6.1.

Reviewer comments:
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 don'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 cannot infer anything about network conditions when it isn't expecting an ack. Meaning that the receiver could have received everything and simply not responded if none of those packets are ack-eliciting.
NAME yes, you don't know anything when you don'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.
NAME I'm not sure I follow. If a sender receives an ack for a non-ack-eliciting packet, that only establishes its receipt. I don'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 .
NAME 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 isn'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.
NAME : But we do want loss of non-ack-eliciting packets to count towards persistent congestion; they aren'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 Timo Völker 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 don'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

Revised text:
7.6.  <ins> When a sender establishes loss of all ack-eliciting packets sent over a long enough duration, the network is considered to be experiencing </ins> persistent congestion. 7.6.1.