5 ms·
An Unreliable Datagram Extension to QUIC
- ReactiveJelly 5y agoAll 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#method.send_datagram https://docs.rs/quinn/latest/quinn/struct.Connection.html#me...
- Matthias247 5y agoYes. It’s the extension
- fowl2 5y agoI 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.
- egberts1 5y agoas 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.
- anticristi 5y agoDaniel 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.
- anderspitman 5y agoReminds 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.
- Matthias247 5y agoFallback will happen far earlier (<1s). You don’t want to stare at a blank website for 3 seconds.
- ReactiveJelly 5y agoKinda like Happy Eyeballs, right? https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs
- Matthias247 5y agoHappy eyeballs is indeed used in common implementations of http/3
- anderspitman 5y agoI'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/ https://tailscale.com/blog/how-nat-traversal-works/
- felixgallo 5y agospecifically, 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.
- miohtama 5y agoYour 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.
- Matthias247 5y agoWhile 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)
- egberts1 5y agowont be easy unless they also deploy mitigation for UDP-based DDoS.
- jlokier 5y agoThere 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.
- ReactiveJelly 5y agoEven 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.