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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

Getting close, a few more suggestions

>  
 ~~~
 (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
     kPersistentCongestionThreshold
 ~~~
 
-Unlike the PTO computation in {{pto}}, persistent congestion includes the
-max_ack_delay irrespective of the packet number spaces in which losses are
-established.
+Unlike the PTO computation in {{pto}}, this duration includes the max_ack_delay
+irrespective of the packet number spaces in which losses are established.
+
+This duration allows a sender to send enough packets, including some in response

```suggestion
This duration allows a sender to send as many packets, including some in response
```

> -Unlike the PTO computation in {{pto}}, persistent congestion includes the
-max_ack_delay irrespective of the packet number spaces in which losses are
-established.
+Unlike the PTO computation in {{pto}}, this duration includes the max_ack_delay
+irrespective of the packet number spaces in which losses are established.
+
+This duration allows a sender to send enough packets, including some in response
+to PTO expiration, as TCP does with Tail Loss Probe ({{RACK}}), before
+establishing persistent congestion, as TCP does with a Retransmission Timeout
+({{?RFC5681}}).
+
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.
+
+This design does not use consecutive PTO events to establish persistent
+congestion, since a PTO expiration is controlled by application patterns in

```suggestion
congestion, since a PTO expiration is influenced by application patterns in
```

> -Unlike the PTO computation in {{pto}}, persistent congestion includes the
-max_ack_delay irrespective of the packet number spaces in which losses are
-established.
+Unlike the PTO computation in {{pto}}, this duration includes the max_ack_delay
+irrespective of the packet number spaces in which losses are established.
+
+This duration allows a sender to send enough packets, including some in response
+to PTO expiration, as TCP does with Tail Loss Probe ({{RACK}}), before
+establishing persistent congestion, as TCP does with a Retransmission Timeout
+({{?RFC5681}}).
+
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.
+
+This design does not use consecutive PTO events to establish persistent
+congestion, since a PTO expiration is controlled by application patterns in

Or maybe something else.  Controlled seems odd to me.

> +data with silence periods between them restarts the PTO timer every time it
+sends, potentially preventing the PTO timer from expiring for a long period of
+time, even when no acknowledgments are being received. The use of a duration
+enables a sender to establish persistent congestion without depending on the
+occurrence of PTOs.
+
+### Establishing Persistent Congestion
+
+A sender establishes persistent congestion on receiving an acknowledgement, if
+the following conditions are true:
+
+* there are at least two ack-eliciting packets that are declared lost;
+
+* a prior RTT sample existed at the time these packets were sent;
+
+* the duration between the send times of these packets exceeds the


```suggestion
* the duration between the send times of the first and last lost packets exceeds the
```

> +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 ({{RACK}}).

This sentence repeats lines 844 to 847, so I'd be inclined to remove it.

```suggestion
reduced to the minimum congestion window (kMinimumWindow).
```

-- 
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-458719452