Fast Recovery Implementation.

[Kazedaa]

I noticed that the NewReno implementation currently lacks a fast recovery mechanism. I also found that this has been mentioned in Issue #1823.

Is anyone actively working on this issue?

I’m interested in contributing by implementing the fast recovery mechanism. Before proceeding, I’d like to check if there are any guidelines or existing plans I should be aware of.

Looking forward to your input. Thanks!

[huitema]

At the time when New Reno was specified, there was generally a single specification for both loss recovery and congestion control. This has evolved. The QUIC specification (RFC 9002) cleanly separates the two functions. Loss recovery in Picoquic is implemented independently of the congestion control algorithm, and basically follows RFC 9002, which itself is based on RFC 8985 (RACK). The "The NewReno Modification to TCP's Fast Recovery Algorithm" specification in RFC 6582 is largely obsolete, and there is no plan to implement it in QUIC.

When we discuss "recovery" for congestion control algorithm, we are not usually speaking about packet loss recovery, but about a specific interaction between congestion control and packet loss detection. The congestion control algorithm will at some point decide that it at seen too many packet losses, or too many ECN marks, or too much increase in delays -- different algorithms can use different combination of those. At that point, the CC algorithm will decide to change the transmission control: reduce the congestion window, reduce the pacing rate, or both. This will reduce the congestion, but only after a delay. When the decision is made, there are still a lot of packets in flight, and the path is likely to remain congested until all these packets have exited the network. We will know that when all packets in flight at the time of the congestion detection are acknowledged -- or, to be a bit more conservative, when the first packet sent after the congestion detection has been acknowledged. The "recovery period" is the time between these two events.

I said that all algorithms ought to implement it. The New Reno implementation kinda does it, with one caveat. It manages two variables, "nr_state->recovery_sequence", i.e., the last packet sent before the congestion event, and "nr_state->recovery_start", the time of the congestion event. It will only react to losses of packets sent after nr_state->recovery_sequence, and only handle spurious loss detection event for one RTT after "nr_state->recovery_start". There is a tiny bug: to match the spirit of the specification, New Reno should not increase the window if packets sent before the congestion event are acked -- but the implementation does!

[Kazedaa]

Thank you for the detailed explanation! I appreciate the clarification on how Picoquic handles loss recovery separately from congestion control and the insights into the NewReno implementation. That makes sense, and I now understand why implementing fast recovery as described in RFC 6582 isn't necessary here.

Thanks again for your time and for pointing out the relevant details. I'll consider other ways to contribute instead. Closing this discussion now.