Persistent Congestion Requires Probes to be Sent

[nibanks]

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.

[ianswett]

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?

[nibanks]

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.