Skip to content

Comment on Employing QUIC Protocol to Optimize Uber’s App Performance

Comments

Isn't TLP[0] supposed to fix the largest cause (tail losses) of this issue? It should result in retransmits far sooner than the 30 seconds they mention.

Recently developed algorithms, such as BBR, model the network more accurately and optimize for latency. QUIC lets us enable BBR and update the algorithm as it evolves.

Again this is available for TCP in recent linux kernels[1]. And it's sender-side, so it should be unaffacted by ancient android devices.

Are they using ancient linux kernels on their load balancers? Or are the sysctl knobs for these features turned off in some distros?

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [1] https://kernelnewbies.org/Linux_4.9#BBR_TCP_congestion_contr...

BBR in kernel works for TCP because it's used for TCP congestion control. QUIC is built on top of UDP and there is no congestion control used for UDP, you implement it in your application/protocol built on top of UDP. From what I remember QUIC implementation supports BBR and Cubic as congestion control mechanisms.

Correct. QUIC also implements TLP. Main advantage is deployability since this is a user-space solution.

If you need it on the client side, it's basically never going to happen on Android. Between manufacturers that never update and Google doesn't seem to care (they never enabled path MTU probing, even though it's been in all the kernels they shipped, and Apple uses it aggressively to great success in terrible networks)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.