Subject: [quicwg/base-drafts] Persistent Congestion Requires Probes to be Sent (#2356)

From: Nick Banks <[email-masked]>
Date: Tue, 22 Jan 2019 08:18:39 -0800

Currently, persistent congestion is only determine when the required number of probes have been sent. But probes aren't sent if the app layer continues to send data. This likely means the persistent congestion determination should be time based instead of probe count based.

-- 
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/issues/2356

---

From: ianswett <[email-masked]>
Date: Tue, 22 Jan 2019 09:25:37 -0800

I agree this wasn't the intent of the text.

I'm not sure this is an important problem to solve in practice, but I'm happy to review if a PR if you want to write one up?

-- 
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/issues/2356#issuecomment-456486798

---

From: Nick Banks <[email-masked]>
Date: Tue, 22 Jan 2019 12:32:17 -0800

Fundamentally, I think we should separate persistent congestion determination from how many (if any) probes were actually sent. Persistent congestion is just an amount of time (since the oldest outstanding, retransmittable packet) we should wait before declaring "something really bad is going on" for this connection, and back off.

In good (non-edge) cases, the current logic works well and is fairly simple to implement. It just breaks down in the cases where any other traffic is getting periodically sent. I would propose just making a separate timer/timeout for persistent congestion. It would follow similar rules for RTO for TCP:

1. When a new packet is sent, if the PC (persistent congestion) timer isn't running, start it.
2. When you receive an ACK that acknowledged new data, restart the timer.

The next question is just how long to run the timer. Assuming we want to keep the current values (sum of 3 PTOs), I think it'd be something like:

 `(smoothed_rtt + 4 * rttvar + max_ack_delay) * ((2 ^ 3) - 1)`

If this sounds reasonable, I can attempt to put together a PR.

-- 
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/issues/2356#issuecomment-456552366