Re: [quicwg/base-drafts] When the sender is using standard Reno congestion control, ack every ~2 packets (#1428)

[Christian Huitema <[e-mail]>]

Ian, you probably have vastly more data that I do. When we are concerned with Reno and Cubic, is that a theoretical concern based on simulation, or a practical issue visible in your telemetry? I say that because ACK compression and ACK suppression does happen a lot to TCP "in the wild". Cable modems do it, for example. If I was shipping a TCP implementation on a major platform, I would do something about it, so I suppose that most of the big releases have.

In any case, you have to go back to the reason why implementations want fewer ACKs -- first to reduce CPU load caused by packet-sent interrupts, and second to ease potential bottlenecks on the reverse path. So there no point being dogmatic. If ACKs are spaced "enough", be it in packets or in milliseconds, you win already; going further will only improve your CPU cost a little, but it might risk a lot.

I suspect that is how gQUIC came to adopt a 10 packet cap. Or maybe a 10 ms cap as well.


-- 
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/1428#issuecomment-420511395