Re: [quicwg/base-drafts] ACK generation recommendation (#3304)

[mjoras <[e-mail]>]

At Facebook, ACK handling is the largest component of what I'd call "discretionary" CPU cost (i.e. not crypto, not syscall/userspace->kernel copying). I expect that will be true in general once people have optimized their implementations. We see fine results with the suggested basic Chrome heuristic, and haven't experimented with much beyond that but it's on our roadmap. I don't think we should keep the current ACK every other in the draft as it will largely end up being facetious. Deployments will use what ends up working better in practice and we know ACKing every other is measurably problematic (I can share numbers if people are interested).

That being said, I feel uncomfortable recommending the Chrome heuristic in the draft, as it reminds me of some of the early TCP RFC's which have recommendations and constants that did not age well and are largely ignored today. Can we punt something similar to @ianswett's initial idea of having this controlled via TP or new frame type?

-- 
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/3304#issuecomment-566815909