Change:
This duration is computed as follows: <del> For example, assume: If an ack-eliciting packet is sent at time t = 0, the following scenario would illustrate persistent congestion: The first three packets are determined to be lost when the acknowledgement of packet 4 is received at t = 8.  The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the threshold was reached and because none of the packets between the oldest and the newest packets are acknowledged, the network is considered to have experienced persistent congestion. </del> <ins> Unlike the PTO computation in pto, persistent congestion includes the max_ack_delay irrespective of the packet number spaces in which losses are established. The following example illustrates how persistent congestion can be established.  Assume: Consider the following sequence of events: Packets 2 through 8 are declared lost when the acknowledgement for packet 9 is received at t = 12.2. The congestion period is calculated as the time between the oldest and newest lost packets: 8 - 1 = 7.  The duration for establishing persistent congestion is: 2 * 3 = 6.  Because the threshold was reached and because none of the packets between the oldest and the newest lost packets were acknowledged, the network is considered to have experienced persistent congestion. While this example shows the occurrence of PTOs, they are not required for persistent congestion to be established. </ins> When persistent congestion is established, the sender's congestion window MUST be reduced to the minimum congestion window

Discussion:
Makes the period computation a bit clearer. Also addresses NAME comment in .
Looks like there is some confusion on Slack about the case where disjoint sets of packets are lost. Do we need two examples rather than one?
NAME This confusion now has its own issue: .
I'm going to merge this. Happy to fix any more editorial issues separately.
A sender sends a tail of 10 packets, packet number 1 to 10. It now receives an acknowledgement for packets 5 and 10, which establishes the loss of all other packets. It's not clear how to perform the check for persistent congestion now. Several options come to mind: check if the period between 6 and 9 is longer than 3PTO check if either the period between packet 1 and 4 or the period between packet 6 and 9 is longer than 3PTO The ACK doesn't establish loss of all tail packets, so there's no persistent congestion. In an offline discussion, both NAME and NAME expressed preferences for different options here. I'm not sure what the right thing to do is here, but at least the draft should be clearer on what exactly establishes persistent congestion and what doesn't.
Consider the case where the sender receives an acknowledgement for packets from 5 to 10, and the period between 1 and 4 was longer than 3*PTO. IIUC, this is clearly a persistent congestion. The original example is strictly worse than that, and I think it would make sense to declare persistent congestion in the case too. In other words, I think that 3 is incorrect. That said, I do not have a strong opinion regarding if we should specifically recommend either of 1 or 2, considering that the logic (or the time threshold) being used to detect persistent congestion is merely a recommendation.
FWIW, we had some discussion regarding the design rationale behind persistent congestion in , and it seemed to me that it was mostly about the amount of time the sender cannot make any progress.
seems also related
I think we should keep it simple, which IMO is do nothing. Or if we want to add a recommendation, we can say that you start with the largest lost packet and try to detect Persistent congestion until either you have found 1 occurrence or reached the end of list.
This is fixed in , and is an editorial fix.

The example shown counts multiples of the PTO, so the maxackdelay and rttvar values chosen aren't really relevant. The first is only ever 0 during the handshake and the second is never zero unless you have faster than light packet transmission. Counting number of times the base PTO lapses is clearer, and avoids having to use unrealistic values for these two values.
Thanks Jana, this is a nice improvement.