An Unreliable Datagram Extension to QUIC | Hacker News Reader

An Unreliable Datagram Extension to QUIC

quicwg.org

39 pointsborn-jre16 comments

All this time I thought datagrams were part of standard QUIC. I guess Rust's `quinn` has been implementing an earlier draft of this extension?

https://docs.rs/quinn/latest/quinn/struct.Connection.html#me...

Yes. It’s the extension

I really hope they standardize the fallback to HTTP2 (and HTTP1 too). Almost any real world internet facing application will need one and it'd be a shame if they all had to reinvent the wheel when it could be done at a lower level once for everyone.

as system admins of the world further clamp down on UDP at their firewalls, not sure about the adoption rate of QUIC and its some 13 odd variants, and whether QUIC/UDP would take off.

Daniel Stenberg, the author of cURL, was highlighting graceful fallback as the greatest challenge to QUIC/HTTP3 adoption. If the only complaint from users is "video starts 3 second late", UDP will likely stay blocked.

Reminds me of the Python 2 -> Python 3 upgrade. py3 was similar enough that you could make libraries to essentially support both. Users didn't really notice much difference, but maintaining lower-level libraries was often a pain. Those compatibility libraries were great, but in retrospect I think a clean break would have been better for everyone.

Fallback will happen far earlier (<1s). You don’t want to stare at a blank website for 3 seconds.

Kinda like Happy Eyeballs, right? https://en.wikipedia.org/wiki/Happy_Eyeballs

Happy eyeballs is indeed used in common implementations of http/3

I've wondered about this myself. I'm in the early stages of designing a tunneling protocol, and I'd love to use QUIC to solve head-of-line blocking, but I'm concerned about UDP blocking.

According to this (excellent) article, the UC Berkeley WiFi blocks all outgoing UDP except DNS:

https://tailscale.com/blog/how-nat-traversal-works/

specifically, that's the UC Berkeley _guest_ wifi called out there.

Since UDP is also used by every major videogame and many real time streaming platforms (e.g., Zoom), it's unlikely to be blocked en masse on standard consumer networks.

Your comment is correct. There will be always some networks that do not behave the spec compliant manner or have limited connectivity. However they are most likely unfixable on application level and unless the network admins themselves do something then some applications won’t work.

While it’s true that UDP was often blocked by default infrastructure is now opened up in order to support HTTP/3 as operators notice its importance.

However that will also often mean Http/3 and Quic will often only work on UDP port 443 - even though theoretically any port could be used for it (the number is delivered via the Alt-Svc announcement)

There are also sites that previously allowed UDP which started blocking UDP port 443 specifically to block QUIC and force fallback to HTTP/2 or lower.

Reasons include some forms of traffic fairness management on mobile networks (to ensure throughout and low latency, it's much easier with TCP), and some corporate network security products to monitor traffic destinations at the domain level.

wont be easy unless they also deploy mitigation for UDP-based DDoS.

Even though it puts me on the side of agreeing with Google and even wanting them to use their monopoly power, I think when Chrome starts pushing for HTTP/3 and the benefits become clear, middleboxes will be pressured to allow it.

Reply on news.ycombinator.com