Re: [quicwg/base-drafts] Persistent Congestion Time Threshold (#2365)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

I think the pseudocode is good, but I have some suggestions on the text.

> @@ -1003,15 +1003,21 @@ packets might cause the sender's bytes in flight to exceed the congestion window
 until an acknowledgement is received that establishes loss or delivery of
 packets.
 
-When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and 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}}.
-
+## Persistent Congestion
+
+The network is considered to be experiencing persistent congestion when the

The old text was more correct than this text in the sense that it's important that not only does time pass, but all the packets are lost within that period of time.

How about:
"When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is considered to be experiencing persistent 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}}.
-
+## Persistent Congestion
+
+The network is considered to be experiencing persistent congestion when the
+sender goes a period of time without receiving any ACK frames for its in-flight,
+ack-eliciting packets.  Generally, this can be calculated as a number of
+consecutive PTOs (pto_count is more than  kPersistentCongestionThreshold, see
+{{cc-consts-of-interest}}), but since the PTO timer is reset when a new
+ack-eliciting packet is sent, an explicit timeout must be used to account for
+those cases where PTOs do not occur.
+
+When persistent congestion is encountered the sender's congestion window MUST be

```suggestion
When persistent congestion is established, the sender's congestion window MUST be
```

> @@ -1003,15 +1003,21 @@ packets might cause the sender's bytes in flight to exceed the congestion window
 until an acknowledgement is received that establishes loss or delivery of
 packets.
 
-When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and 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}}.
-
+## Persistent Congestion
+
+The network is considered to be experiencing persistent congestion when the
+sender goes a period of time without receiving any ACK frames for its in-flight,
+ack-eliciting packets.  Generally, this can be calculated as a number of

Suggestion: replace "Generally, this can be calculated as a number of consecutive PTOs (),..." with
"Commonly, this can be established by consecutive PTOs,..."

-- 
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/2365#pullrequestreview-197306266