Hacker News Reader

Comment by tyingq | Hacker News Reader

Because QIC is UDP based, Chrome first runs a race with TCP just in case you're sitting behind some device that blocks UDP.

I wonder how much bandwidth this will waste globally.

View on HN

Most global bandwidth is from video streaming, so most of the data isn't in the first couple packets.

So the number would probably be surprisingly large but also a very small fraction of overall traffic.

I wonder if Happy Eyeballs means that there are 4 races in total for systems under dual-stack...

Or, a more interesting measure: how much more full will all our NAT connection-state tables be because of this?

> I wonder how much bandwidth this will waste globally.

One or two packets? A handful of bytes per initial connection. The Connection ID mechanism and QPACK are likely to save a lot more data than is lost on initial TCP races.

I could have worded it better. I understand it's small in any single area.

Just interesting to contemplate the total effect when you have a userbase like Chrome's.

Or how many "visitor" statistics will it flaw ?

Isn't that like any device behind NAT?

Yes. NAT, firewalls with admins that don't know what QUIC is, various corporate MITM boxes, etc.

Most NAT still allows UDP hole-punching (STUN/TURN/ICE) unless specifically blocked (which a depressing number still do).

No. Most NATs handle UDP sessions trivially as long as one end of the connection is not behind a NAT itself. Tricks like UDP hole punching are necessary only between two endpoints that are both behind NATs.

And assuming the protocol can cope with changing source ports. I’ve seem some udp protocols that only work if the source port is not translated.

Reply on news.ycombinator.com