Re: [quicwg/base-drafts] Rework section on persistent congestion (#3961)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

This is much clearer, thanks.

> -sent over a long enough period of time, the network is considered to be
-experiencing persistent congestion.  Commonly, this can be established by
-consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting
-packet is sent, an explicit duration must be used to account for those cases
-where PTOs do not occur or are substantially delayed. The rationale for this
-threshold is to enable a sender to use initial PTOs for aggressive probing, as
-TCP does with Tail Loss Probe (TLP; see {{RACK}}), before establishing
-persistent congestion, as TCP does with a Retransmission Timeout (RTO; see
-{{?RFC5681}}). The RECOMMENDED value for kPersistentCongestionThreshold is 3,
-which is approximately equivalent to two TLPs before an RTO in TCP.
-
-This duration is computed as follows:
+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.
+
+### Duration {#duration}

```suggestion
### Duration {#pc-duration}
```

>  max_ack_delay irrespective of the packet number spaces in which losses are
 established.
 
+This duration is intended to allow a sender to use initial PTOs for aggressive

What is an "initial PTO"?  I think that you want to rephrase this.

Is the intent not to give the sender an opportunity to send multiple times before declaring PC?  And that we want to allow for more than one probe packet to be sent so that transient loss does not cause PC unnecessarily.

> +This design uses an explicit duration instead of consecutive PTO events since
+the PTO timer is restarted every time an ack-eliciting packet is sent. An
+application that trickles data restarts the PTO timer repeatedly, preventing the
+PTO timer from expiring for a potentially long period of time. A consequence of
+this design is that persistent congestion can be established without the
+occurrence of any PTOs.
+
+### Declaring Persistent Congestion
+
+A sender declares persistent congestion on receiving an acknowledgement, if the
+following conditions are true:
+
+* there are at least two ack-eliciting packets that are declared lost;
+
+* the duration between the send times of these two packets exceeds the
+  persistent congestion duration ({{duration}}); and

```suggestion
  persistent congestion duration ({{pc-duration}}); and
```

> +* the duration between the send times of these two packets exceeds the
+  persistent congestion duration ({{duration}}); and
+
+* all packets sent between those times are declared lost.
+
+Since network congestion is not affected by packet number spaces, persistent
+congestion SHOULD be established across packet number spaces. A sender that does
+not have state for all packet number spaces or an implementation that cannot
+compare send times across packet number spaces MAY use state for just the packet
+number space that was acknowledged.
+
+When persistent congestion is declared, the sender's congestion window MUST be
+reduced to the minimum congestion window (kMinimumWindow).  This response of
+collapsing the congestion window on persistent congestion is functionally
+similar to a sender's response on a Retransmission Timeout (RTO) in TCP
+({{RFC5681}}) after Tail Loss Probes (TLP; see {{RACK}}).

The repetition of the RTO and TLP citations seems a little duplicative here.

```suggestion
({{RFC5681}}) after Tail Loss Probes ({{RACK}}).
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3961#pullrequestreview-456280522