Safety issue during incipient persistent congestion episode

[pravb]

"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."

QUIC declares persistent congestion only upon receipt of an ACK for a packet sent after entering loss recovery. This means that the cwnd will remain large and usable even if there is prolonged network silence with packets outstanding. If the state of the transport was application limited, this can cause a large burst on the network.

In TCP, an RTO causes immediate drop of the cwnd to min_cwnd.

Ideally QUIC should drop the cwnd in the same timescale as TCP would. Typically minrto for the Internet is 200 msec or 300 msec (and larger if the RTT is larger).

[ianswett]

I do not want to change the existing algorithm, because the app-limited case is the case when the sender is strictly less aggressive than the congestion controller limits, so I believe it's less likely to cause issues for the network.

I can write text pointing out this difference.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action. Editorial issue to explain the difference to TCP and its safety.

[martinthomson]

@LPardue, this was in the latest batch of consensus calls, but you didn't mark it has having consensus. Can you review please?

[LPardue]

You are correct, I missed this one somehow sorry so moving to has consensus