Re: [quicwg/base-drafts] Add psuedocode for ACK sending logic in recovery (#1716)

[Christian Huitema <[e-mail]>]

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

-- 
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/1716#issuecomment-417877754