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

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> +  max_ack_delay = 0
+  kPersistentCongestionThreshold = 2
+
+If an eck-eliciting packet is sent at time = 0, the following scenario would
+illustrate persistent congestion:
+
+  t=0 | Send Pkt #1 (App Data)
+  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

I had a hard time figuring out where this equation came from. Maybe it's more readable if you don't fill in the value for the `kPersistentCongestionThreshold`?

> +  rttvar = 0
+  max_ack_delay = 0
+  kPersistentCongestionThreshold = 2
+
+If an eck-eliciting packet is sent at time = 0, the following scenario would
+illustrate persistent congestion:
+
+  t=0 | Send Pkt #1 (App Data)
+  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

This doesn't match the description in the first paragraph, does it?
> 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.

With this algorithm, we would detect persistent congestion even if packet 2 and 4 were acked, right?

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