Employing QUIC Protocol to Optimize Uber’s App Performance

Re:Employing QUIC Protocol to Optimize Uber’s App Performance by api on Monday May 20, 2019 @05:58PM (#19965706)

The other awesome thing about QUIC is that it encrypts almost everything including header information, making middlebox traffic shaping worthless and demoting middleboxes in general.

[ Parent | on HN ]

Re:Employing QUIC Protocol to Optimize Uber’s App Performance by drewg123 on Tuesday May 21, 2019 @08:17AM (#19969428)

It also makes hardware offloads like TSO and LRO impossible, and increases cost-per-byte served by a factor of 4 or more. So if you have infinite CPU to throw at QUIC and/or low bandwidth or connection targets, its great. If you are concerned at all about server-side efficiency, its terrible.

FWIW, I work on the Netflix CDN, and specialize in server-side efficiency; we have had 100G flash CDN nodes for years serving at 90G+ in production. None of that would be possible with QUIC as it stands. I suspect our max B/W on these machines would drop from ~95Gb/s to 20Gb/s or less if we were to switch to QUIC.

[ Parent | on HN ]

Re:Employing QUIC Protocol to Optimize Uber’s App Performance by api on Tuesday May 21, 2019 @10:23AM (#19970399)

I hear you and those are valid points.

Don't blame QUIC. Blame ISPs and middlebox makers for abusing their (literal network-wise) position and breaking the end-to-end principle. History has shown that we just have to encrypt everything and quite literally cut out the middleman/box.

[ Parent | on HN ]

Re:Employing QUIC Protocol to Optimize Uber’s App Performance by scott00 on Tuesday May 21, 2019 @09:30AM (#19969938)

Does the protocol actually make it impossible, or is it just not implemented by current OS/hardware?

[ Parent | on HN ]

Re:Employing QUIC Protocol to Optimize Uber’s App Performance by vlovich123 on Thursday May 23, 2019 @03:10PM (#19994927)

Definitely just that the HW hasn't caught up.

https://www.netdevconf.org/0x13/session.html?talk-quic-offlo...

[ Parent | on HN ]