Hacker News Reader

Comment by virattara | Hacker News Reader

The problem with making changes to TCP or using SCTP is that it would take a lot of time for the implementations to be rolled worldwide, one of the main reasons why is that so is that these protocols are implemented in kernel space any change would take years before its widely adopted over the network. TCP fast open is an example of this. For this reason, QUIC's functions are implemented in the user space over UDP(no changes made to UDP). But this has also created problems for QUIC as it turns out that QUIC has significantly higher CPU usage compared to TCP.

All of this well explained in this doc: https://http3-explained.haxx.se/

View on HN

Yes, the biggest thing about Quic deployment is that UDP other than most well known ports is being firewalled almost universally on low end ISPs.

In the end, a QUIC probe, and a subsequent TCP fallback would be worse than well done TCP, and no better than MPTCP/TFO/SCTP/DCCP (all of which were supported by mainline OSes for a long time)

I believe macOS/iOS is the only major OS with MPTCP right now. Some others have patches available or are in the process of landing their own implementations but that'll likely take a bit and still doesn't include Windows. SCTP is supported by most kernels but usually can't get out of your local network before something either explicitly blocks it or can't understand it and so drops it. DCCP won't even work on your network, unless your network is only Linux machines. TFO is blocked by enough junk middleboxes that, on average, it's less efficient than just not trying to use it.

Your only real choices are TCP without any extensions created in the past 20 years or UDP. Some firewalls will block UDP but at least it'll survive the open internet so that's a problem you can get IT to fix.

I'm not sure how that really is a problem. I am writing this from a box that has IPv6 and most of the latest TCP stuff including BBR, ECN and TFO. It took a while until we got to that point, but here we are. In the past we were able to wait too, why not now?

I think the time taken by end-users/customers using your app will be of more concern here since they will take significantly more time to upgrade their devices to a new transport protocol or fixes in existing ones. QUIC will enable us to restrict such updates to the developer level.

That doesn't really explain what changed, where the urgency is coming from. Also note that some TCP improvements are sender-side only, so you only need to upgrade your server, not all client devices.

The urgency is coming from mobile networks and high reliance on low latency for user engagement.

Also even if we assume that 50% of all internet users have access the most modern protocols as soon as reasonable we still care about how quickly the next half will upgrade.

And in a sense I agree with this vision of the internet. On one hand the internet could be a super optimized distributed communication network with a lot of embedded functionality (I really like the concept of content-centric-networks/name-centric-networks) on the other hand the internet could be a dumb many-ended pipe (the IP protocol)

In terms of how I use the internet in practice I always prefer the dumb pipe model.

The upgrade problem is something that google created with android devices being stuck on old kernels, now they're trying to paper over that mess by moving things to userspace. That may solve this particular problem but it creates a new maintenance nightmare with hundreds of different applications bringing their own congestion control and different transport implementation on top of dozens of differnet TLS libraries. It seems like a little more patience and ensuring that devices remain upgradable could give us most of the advancements without the downsides.

That is a possible source of error, still there is the issue of network devices that implement ossified versions of internet standards. For example when they tried to use different kinds of compression in unencrypted HTTP it came out that a lot of middleboxes would simply "fix" the content-encoding header to be either gzip or deflate, regardless of that making it illegible.

Reply on news.ycombinator.com