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

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.



> +  t=1 | Send Pkt #2 (PTO 1)
+  t=3 | Send Pkt #3 (PTO 2)
+  t=7 | Send Pkt #4 (PTO 3)
+  t=8 | Recv ACK of Pkt #4
+
+The first three packets are determined to be lost when the ACK 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 * ((2 ^ 2) - 1)) = 3.  Because the threshold was
+reached, the network is considered to have experienced persistent congestion.
+
+When persistent congestion is established, 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}}.

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

> @@ -1282,15 +1309,28 @@ Invoked by loss detection from DetectLostPackets when new packets
 are detected lost.
 
 ~~~
+   InPersistentCongestion(congestion_period):
+     pto = smoothed_rtt + 4 * rttvar + max_ack_delay
+     return
+       congestion_period >
+         pto * (2 ^ kPersistentCongestionThreshold - 1)

editorial nit: this looks a bit confusing because 'return' is on a line by itself. How about:

return congestion_period >
                    pto * (2 ^ kPersistentCongestionThreshold - 1)

>  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}}.
+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.  This duration is the
+equivalent of kPersistentCongestionThreshold consecutive PTOS, smoothed_rtt +
+4 * rttvar + max_ack_delay * ((2 ^ kPersistentCongestionThreshold) - 1).

Agreed that it seems odd to backoff on max_ack_delay. @ianswett : Let's do that separately.

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