Add psuedocode for ACK sending logic in recovery

[ianswett]

Once #1428 is resolved, I believe I can construct fairly simple pseudocode for the ack sending algorithm and I believe this is worthwhile.

[mikkelfj]

Would it be possible to have both a Reno style and a rate based style algorithm - or at least a refence?

[ianswett]

There are no IETF standard rate based algorithms I'm aware of, but my real objection would be that the recovery doc could become very long. I think the example of Reno is simple to understand and covers the important differences between TCP and QUIC that may effect congestion control implementations?

[martinthomson]

Like the rest of this document, Reno-like is a baseline, and we have consensus on doing that. The spectrum of possibilities are not limited by what we specify here, but we do have to specify something that is known to be good for the Internet. If nothing else, describing more than one algorithm would be a schedule risk.

[huitema]

Maybe that's just me, but when I am implementing QUIC I treat the recovery spec as mostly informational, something you follow if you don't know better. I do expect that researchers will keep coming up with better congestion control schemes, and that we will keep improving the retransmission mechanisms, or the ACK sending mechanism.

Of course, things work better if the receiver is aware of the congestion control algorithm used by the sender. For example, if the sender is using basic RENO and relies on ACK clocking, receivers should send frequent ACKs to try reduce the risk of packet bunching. On the other hand, if the sender is using some form of rate control or pacing, then the receiver should send ACK as infrequently as practical, in order to minimize the cost of ACK processing. And if the sender relies on delay-based congestion control algorithms, the receivers should try send several ACK per RTT, to provide good estimate of RTT evolution.

So if we are bound to create new transport options, maybe we should let senders signal which congestion controller they are using. If the receiver understands the algorithm they can optimize. If not, they can fall back to some safe default.

[ianswett]

I'm going to close this, because the intent is to move the ACK sending logic into the transport doc, and the transport doc doesn't have pseudocode.