I guess NAS (network access storage) would really benefit from QUIC; one could treat each file transfer as a separate session, so that a lost packet will not cause all the sessions to stall. Did any of the NAS protocols adopt QUIC already? Are they working on it?
The majority of Facebook's traffic now uses QUIC and HTTP/3
101–110 of 149 posts
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#102I guess NAS (network access storage) would really benefit from QUIC; one could treat each file transfer as a separate session, so that a lost packet will not cause all the sessions to stall. Did any of the NAS protocols adopt QUIC already? Are they working on it?
There's been some interest among the Samba hackers, including some discussion with Microsoft. They seem quite excited about SMB-on-QUIC as an Internet-capable network filesystem protocol.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#103Am I reading the IETF status incorrectly or is HTTP/3 still i draft status? Why on earth are they implementing a protocol that is in draft status?
You are reading it correctly. This is a draft, and I presume Facebook's engineering team are confident that they have the resources (time/ money/ whatever) to stay reasonably up to date on any subsequent changes.
Generally the way this work goes, at first things change pretty violently, maybe it goes from let's have a 1 byte version number, ASN.1 OIDs for everything and some JSON, to actually it's always the five bytes 'QUICK' then a four byte version number, we're doing CORS instead of JSON, and no OIDs now it's all URNs, in like two weeks of git pulls and mailing list posts.
But after a while the drafts start to settle down. On some topics everybody is satisfied that there's a good argument for why we do this and not that, on others it's a coin toss and it's just easier not to change it than argue constantly. Do I like OIDs? Eh, they're better than URNs but I can live with either, so fine, have URNs if you insist.
QUIC has largely settled down. Google's systems for example will tell you they speak draft 29 of QUIC. Do they? Well, more or less. Maybe it's sort of draft 32 really. But drafts 29 and 32 are pretty similar, and draft 32 is going to Last Call now, if nobody raises any issues it's done.
Is it conceivable that somebody discovers a grave problem in QUIC and it has to be substantially revised? Yes. But it's not very likely. So it's easily possible that a draft 29 QUIC implementation like Google's (or Facebook's) will mostly interoperate with an actual QUIC standard next year after just some small tweaks to tell it this isn't a draft any more. Why wait?
HTTP/3 is a bit more than just do HTTP on QUIC, and it's slightly less finished than QUIC is, but it's also pretty stable and there's less that might change anyway.
Somebody has to try this stuff out, and at scale if we're to learn much more than "It might work" before it finishes that Last Call. Facebook, Google, Cloudflare, Mozilla, Netflix and so on are able to do that.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#104I am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken." Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.
Unfortunately, we may yet see networks that block or slow down QUIC, in a paradoxical attempt to improve performance. QUIC is designed to hide a lot from the network. But some network nodes use visibility into things like round-trip time, data-in-flight and packet loss for each flow, so they can adjust queuing parameters to optimise for each user. These measurements are easy to get from monitoring TCP, but not QUIC.…
This is a hefty bet. The gamble is that you're very good at this, and so you'll deliver better performance with HTTP/2 than the client could have got from HTTP/3, but even if you actually are right by a slim margin you're likely to suffer the same pushback from users as if you were wrong. The only scenarios where this is a smart bet are where competitors allow HTTP/3 and have noticeably worse performance.
If it's close, regardless of which way, you'll get beaten up for disabling HTTP/3, maybe that's unjust but that's how it is.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#105I am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken." Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.
TOR, at the moment, is based on TCP and since the whole architecture is based on the assumption of TCP, I don't see it changing anytime soon. QUIC means TOR is now "legacy" unless we just do the right thing and boycott QUIC.
Why does For have to be used to access HTTP services? The web is crap for privacy already.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#106Am I reading the IETF status incorrectly or is HTTP/3 still i draft status? Why on earth are they implementing a protocol that is in draft status?
Facebook is one of the biggest technology companies in the world and serves an unbelievable amount of traffic using the best technology available to them, and actively works to shape the technology standards they use. Facebook is squarely in the ideal HTTP/3 use case, why would they not experiment with the new standard that is supposed to help them if for no other reason than to validate that it delivers on its promise? (or not)
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#107Earlier quoted context omitted.
Essentially it is performance.getEntriesByType("navigation")[0].nextHopProtocol and background task to update UI, plus a link to chrome://net-export/ This one is not hard to audit but in current model should be done by each user.
If that's it, you could just save it as a bookmark: javascript:alert(performance.getEntriesByType("navigation")[0].nextHopProtocol)
That works in Firefox, too.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#108Earlier quoted context omitted.
Unfortunately, we may yet see networks that block or slow down QUIC, in a paradoxical attempt to improve performance. QUIC is designed to hide a lot from the network. But some network nodes use visibility into things like round-trip time, data-in-flight and packet loss for each flow, so they can adjust queuing parameters to optimise for each user. These measurements are easy to get from monitoring TCP, but not QUIC.…
This is a hefty bet. The gamble is that you're very good at this, and so you'll deliver better performance with HTTP/2 than the client could have got from HTTP/3, but even if you actually are right by a slim margin you're likely to suffer the same pushback from users as if you were wrong. The only scenarios where this is a smart bet are where competitors allow HTTP/3 and have noticeably worse performance. If it's clo…
What users are going to notice? Browsers and almost everything else is going to fallback to TCP and move on, because there are too many broken networks to bother.
Kind of like how most big sites clamp TCP MSS at 1440 instead of 1460; there's too many PPPoE or IPIP tunneled links with broken path mtu, and too many clients without working/enabler path mtu blackhole detection to bother making a fuss about it. Just move on and cry on the inside.
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#109Is QUIC implemented at the kernel level like TCP/UDP, or is it entirely userland? Is it encapsulated in UDP packets?
Most implementations[1] implement it in userland, but this is by no means a requirement. There is no implementation for the Linux kernel presently, but both msquic and F5's QUIC implementation can run in their respective kernels. QUIC is indeed built on top of UDP datagrams, much in the same way TCP is built (typically) on top of IP datagrams. [1] https://github.com/quicwg/base-drafts/wiki/Implementations
Could QUIC also have been built on top of IP datagrams instead of UDP datagrams? Or does our crufty Internet mean only UDP and TCP are viable Internet protocols?
Re: The majority of Facebook's traffic now uses QUIC and HTTP/3
#110Earlier quoted context omitted.
It's almost like Windows 95! I click something and then it just happens, immediately! Funny how people forgot that you actually can make (web)apps fast.
But being an SPA I'm sure it's a billion times more manageable for them to maintain instead of a javascript hack nightmare. So, yeah of course you can always make something lightning fast.. but can you manage it, or even develop it properly in the first place?
SPA is not synonymous with slowness, this meme needs to die already.