11 ms·

QUIC is not quick enough over fast internet

• lysace 2y ago
  > We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Haven't read the whole paper yet, but below 600 Mbit/s is implied as being "Slow Internet" in the intro.
  • Fire-Dragon-DoL 2y ago
    That is interesting though. 1gbit is becoming more common
    • schmidtleonard 2y ago
      It's wild that 1gbit LAN has been "standard" for so long that the internet caught up. Meanwhile, low-end computers ship with a dozen 10+Gbit class transceivers on USB, HDMI, Displayport, pretty much any external port except for ethernet, and twice that many on the PCIe backbone. But 10Gbit ethernet is still priced like it's made from unicorn blood.
      • nijave 2y ago
        2.5Gbps is becoming pretty common and fairly affordable, though My understanding is right around 10Gbps you start to hit limitations with the shielding/type of cable and power needed to transmit/send over Ethernet. When I was looking to upgrade at home, I had to get expensive PoE+ injectors and splitters to power the switch in the closet (where there's no outlet) and 10Gbps SFP+ transceivers are like $10 for fiber or $40 for Ethernet. The Ethernet transceivers hit like 40-50C
        • akira2501 2y ago
          Ironically.. 2.5 Gbps is created by taking a 10GBASE-T module and effectively underclocking it. I wonder if "automatic speed selection" is around the corner with modules that automatically connect at 100Mbps to 10Gbps based on available cable quality.
          • cyberax 2y ago
            My 10G modules automatically drop down to 2.5G or 1G if the cable is not good enough. There's also 5G, but I have never seen it work better than 2.5G.
            • akira2501 2y ago
              Oh man. I've been off the IT floor for too long. Time to change my rhetoric, ya'll have been around the corner for a while. Aging has it's upsides and downsides I guess.
            • chgs 2y ago
              I don’t think my 10g coppers will drop to 10m. 100m sure, but 10m rings a bell.
        • cyberax 2y ago
          40-50C? What is the brand? Mine were over 90C, resulting in thermal shutdowns. I had to add an improvised heat exchanger to lower it down to ~70C: https://pics.archie.alex.net/share/U0G1yiWzShqOGXulwe1AetDjRdfBOHilPBPNeRYQgcaWOtFOOXWrZ--Rht8WuKeLQkE https://pics.archie.alex.net/share/U0G1yiWzShqOGXulwe1AetDjR...
          • nijave 2y ago
            I think 10GTek. However there were only 2 of them in the uplink ports on a 24x1Gbps switch in a server cabinet with decent airflow. They might have been getting up to 60C but I don't think they were hitting as high as you were saying. I've since replaced with a 8x10Gbps Hasivo switch so I can't check anymore.
        • crote 2y ago
          The main issue is switches, really. 5Gbps USB NICs are available for $30 on Amazon, or $20 on AliExpress. 10Gbps NICS are $60, so not exactly crazy expensive either. But switches haven't really kept up. A simple unmanaged 5-port or 8-port 2.5GigE isn't too bad, but anything beyond that gets tricky. 5GigE switches don't seem to exist, and you're already paying $500 for a budget-brand 10GigE switch with basic VLAN support. You want PoE? Forget it. The irony is that at 10Gbps fiber suddenly becomes quite attractive. A brand-new SFP+ NIC can be found for $30, with DACs only $5 (per side) and transceivers $30 or so. You can get an actually-decent switch from Mikrotik for less than $300. Heck, you can even get brand-new dualport SFP28 NICs for $100, or as little as $25 on Ebay! Switch-wise you can get 16 ports of 25Gbps out of a $800 Mikrotik switch: not exactly cheap, but definitely within range for a very enthusiastic homelabber. The only issue is that wiring your home for fiber is stupidly expensive, and you can't exactly use it to power access points either.
          • maccard 2y ago
            > The only issue is that wiring your home for fiber is stupidly expensive What do you mean by that? My home isnt wired for ethernet. I can buy 30m of CAT6 cable for £7, or 30m of fibre for £17. For a home use, that's a decent amount of cable, and even spending £100 on cabling will likely run cables to even the biggest of houses.
            • hakfoo 2y ago
              Isn't the expensive part more the assembly aspect? For Cat 6 the plugs and keystone jacks add up to a few dollars per port, and the crimper is like $20. I understand building your own fibre cables-- if you don't want to thread them through walls without the heads pre-attached, for example-- involves more sophisticated glass-fusion tools that are fairly expensive. A rental service might help there, or a call-in service-- the 6 hours of drilling holes and pulling fibre can be done by yourself, and once it's all cut to rough length, bring out a guy who can fuse on 10 plugs in an hour for $150.
              • Dylan16807 2y ago
        • Dylan16807 2y ago
          > My understanding is right around 10Gbps you start to hit limitations with the shielding/type of cable and power needed to transmit/send over Ethernet. If you decide you only need 50 meters, that reduces both power and cable requirements by a lot. Did we decide to ignore the easy solution in favor of stagnation?
          • nijave 2y ago
            I'm not sure what you're saying. The cable length is largely fixed/determined by the building you're running cable in. I'd rather spend an extra $100 on cable than start ripping open walls/floors/ceilings to get a slightly more optimal run length. If it's new construction or you already have everything ripped open it's less of an issue.
            • Dylan16807 2y ago
              I'm not saying 10gig itself should have been range-limited. I'm saying if the reason it was expensive was cable limits and transmit power, both of those can be solved by cutting the range. And if cutting the range could have given us cheap fast connections 15 years ago we should have made it a variant. It could have become the default network port, and anyone that wanted full distance could have bought a card for it. Instead we waited and waited before making slower versions of 10gig, and those are still very slow to roll out. Also 2.5gig and 5gig seem especially consumer-oriented, so for those users a cheap but half range 10gig would be all upside. And 40gig can't reach 100m on any version of copper, so it's not like 100m is a sacred requirement.
      • jsheard 2y ago
        Those very fast consumer interconnects are distinguished from ethernet by very limited cable lengths though, none of them are going to push 10gbps over tens of meters nevermind a hundred. DisplayPort is up to 80gbps now but in that mode it can barely even cross 1.5m of heavily shielded copper before the signal dies. In a perfect world we would start using fiber in consumer products that need to move that much bandwidth, but I think the standards bodies don't trust consumers with bend radiuses and dust management so instead we keep inventing new ways to torture copper wires.
        • schmidtleonard 2y ago
          Sure you need fiber for long runs at ultra bandwidth, but short runs are common and fiber is not a good reason for DAC to be expensive. Not within an order of magnitude of where it is.
          • Dylan16807 2y ago
            These days, passive cables that support ultra bandwidth are down to like .5 meters. For anything that wants 10Gbps lanes or less, copper is fine. For ultra bandwidth, going fiber-only is a tempting idea.
        • crote 2y ago
          > In a perfect world we would start using fiber in consumer products that need to move that much bandwidth We are already doing this. USB-C is explicitly designed to allow for cables with active electronics, including conversion to & from fiber. You could just buy an optical USB-C cable off Amazon, if you wanted to.
          • Dylan16807 2y ago
            When you make the cable do the conversion, you go from two expensive transceivers to six expensive transceivers. And if the cable breaks you need to throw out four of them. It's a poor replacement for direct fiber use.
      • michaelt 2y ago
        Agree that a widespread faster ethernet is long overdue. But bear in mind, standards like USB4 only support very short cables. It's impressive that USB4 can offer 40 Gbps - but it can only do so on 1m cables. On the other hand, 10 gigabit ethernet claims to go 100m on CAT6A.
        • crote 2y ago
          USB4 does support longer distances, but those cables need active electronics to guarantee signal integrity. That's how you end up with Apple's $160 3-meter cable.
          • chgs 2y ago
            A 3m 100g dac is 1/3 the price
      • Aurornis 2y ago
        > Meanwhile, low-end computers ship with a dozen 10+Gbit class transceivers on USB, HDMI, Displayport, pretty much any external port except for ethernet, and twice that many on the PCIe backbone. But 10Gbit ethernet is still priced like it's made from unicorn blood. You really can’t think of any major difference between 10G Ethernet and all of those other standards that might be responsible for the price difference? Look at the supported lengths and cables. 10G Ethernet over copper can go an order of magnitude farther over relatively generic cables. Your USB-C or HDMI connections cannot go nearly as far and require significantly more tightly controlled cables and shielding. That’s the difference. It’s not easy to accomplish what they did with 10G Ethernet over copper. They used a long list of tricks to squeeze every possible dB of SNR out of those cables. You pay for it with extremely complex transceivers that require significant die area and a laundry list of complex algorithms.
        • schmidtleonard 2y ago
          There was a time when FFE, DFE, CTLE, and FEC could reasonably be considered an extremely complex bag of tricks by the standards of the competition. That time passed many years ago. They've been table stakes for a while in every other serial standard. Wifi is beating ethernet at the low end, ffs, and you can't tell me that air is a kinder channel. A low-end PC will ship with a dozen transceivers implementing all of these tricks sitting idle, while it'll be lucky to have a single 2.5Gbe port and you'll have to pay extra for the privilege. No matter, eventually USB4NET will work out of the box. The USB-IF is a clown show and they have tripped over their shoelaces every step of the way, but consumer Ethernet hasn't moved in 20 years so this horse race still has a clear favorite, lol.
        • reshlo 2y ago
          You explained why 10G Ethernet cables are expensive, but why should it be so expensive to put a 10G-capable port on the computer compared to the other ports?
          • kccqzy 2y ago
            Did you completely misunderstand OP? The 10G Ethernet cables are not expensive. In a pinch, even your Cat 5e cable is capable of 10G Ethernet albeit at a shorter distance than Cat 6 cable. Even then, it can be at least a dozen times longer than a similar USB or HDMI or DisplayPort cable.
      • Fire-Dragon-DoL 2y ago
        It passed it! Here there are offers up to 3gbit residential (Vancouver). I had 1.5 bit for a while. Downgraded to 1gbit because while I love fast internet, right now nobody in the home uses it enough to affect 1gbit speed
      • Dalewyn 2y ago
        There is an argument to be made that gigabit ethernet is "good enough" for Joe Average. Gigabit ethernet is ~100MB/s transfer speed over copper wire or ~30MB/s over wireless accounting for overhead and degradation. That is more than fast enough for most people. 10gbit is seemingly made from unicorn blood and 2.5gbit is seeing limited adoption because there simply isn't demand for them outside of enterprise who have lots of unicorn blood in their banks.
    • deleted 2y ago
      [deleted]
  • Dylan16807 2y ago
    Just as important is > we identify the root cause to be high receiver-side processing overhead, in particular, excessive data packets and QUIC's user-space ACKs It doesn't sound like there's a fundamental issue with the protocol.
  • nine_k 2y ago
    Gigabit connections are widely available in urban areas. The problem is not theoretical, but definitely is pretty recent / nascent.
    • Dylan16807 2y ago
      A gigabit connection is just one prerequisite. The server also has to be sending very big bursts of foreground/immediate data or you're very unlikely to notice anything.
  • Aurornis 2y ago
    Internet access is only going to become faster. Switching to a slower transport just as Gigabit internet is proliferating would be a mistake, obviously.
    • tomxor 2y ago
      In terms of maximum available throughput it will obviously become greater. What's less clear is if the median and worst throughput available throughout a nation or the world will continue to become substantially greater. It's simply not economical enough to lay fibre and put 5G masts everywhere (5G LTE bands covers less area due to being higher frequency, and so are also limited to being deployed in areas with a higher enough density to be economically justifiable).
      • deleted 2y ago
        [deleted]
      • nine_k 2y ago
        Fiber is the most economical solution, it's compact, cheap, not susceptible to electromagnetic interference from thunderstorms, not interesting for metal thieves, etc. Most importantly, it can be heavily over-provisioned for peanuts, so your cable is future-proof, and you will never have dig the same trenches again. Copper only makes sense if you already have it.
        • tomxor 2y ago
          Then why isn't it everywhere, it's been practical for over 40 years now.
          • nine_k 2y ago
            It is everywhere in new development. I remember Google buying tons of "dark fiber" capacity from telcos like 15 years ago; that fiber was likely laid for future needs 20-25 years ago. New apartment buildings in NYC just get fiber, with everything, including traditional "cable TV" with BNC connectors, powered by it. But telcos have colossal copper networks, and they want to milk the last dollars from it before it has to be replaced, with digging and all. Hence price segmenting, with slower "copper" plans and premium "fiber" plans, obviously no matter if the building has fiber already. Also, passive fiber interconnects have much higher losses than copper with RJ45s. This means you want to have no more than 2-3 connectors between pieces of active equipment, including from ISP to a building. This requires more careful planning, and this is why wiring past the apartment (or even office floor or a single-family house) level is usually copper Ethernet.
  • dathinab 2y ago
    They also mainly identified a throughput reduction due to latency issues caused by ineffective/too many syscalls in how browsers implement it. But such a latency issue isn't majorly increasing battery usage (compared to a CPU usage issue which would make CPUs boost). Nor is it an issue for server-to-server communication. It basically "only" slows down high bandwidth transmissions on end user devices with (for 2024 standards) very high speed connection (if you take effective speeds from device to server, not speeds you where advertised to have bough and at best can get when the server owner has a direct pairing agreement with you network provider and a server in your region.....). Doesn't mean the paper is worthless, browser should improve their impl. and it highlights it. But the title of the paper is basically 100% click bait.
    • ec109685 2y ago
      How is it clickbait? The title implies that QUIC isn't as fast as other protocols over fast internet connections.
      • dathinab 2y ago
        Because it's QUIC _implementations of browser_ not being as fast as the non quick impl of browsers on connections most people would not just call fast but very fast (in context of browser usage) while still being definitely 100% fast enough for all browser use case done today (sure it theoretically might reduce video bit rate, that is, if it isn't already capped to a anyway smaller rate, which AFIK it basically always is). So "Not Quick Enough" is plain out wrong, it is fast enough. The definition of "Fast Internet" misleading. And even "QUIC" is misleading as it normally refers to the protocol while the benchmarked protocol is HTTP/3 over QUIC and the issue seem to be mainly in the implementations.
  • nh2 2y ago
    In Switzerland you get 25 Gbit/s for $60/month. In 30 years it will be even faster. It would be silly to have to use older protocols to get line speed.
    • 77pt77 2y ago
      Now do the same in Germany...
  • wkat4242 2y ago
    For local purposes that's certainly true. It seems that quic trades a faster connection establishment for lower throughput. I personally prefer tcp anyway.
  • cj 2y ago
    In other words: Enable http/3 + quic between client browser <> edge and restrict edge <> origin connections to http/2 or http/1 Cloudflare (as an example) only supports QUIC between client <> edge and doesn’t support it for connections to origin. Makes sense if the edge <> origin connection is reusable, stable, and “fast”. https://developers.cloudflare.com/speed/optimization/protocol/http3/ https://developers.cloudflare.com/speed/optimization/protoco...
    • dilyevsky 2y ago
      Cloudflare tunnels work over quic so this is not entirely correct
  • paulddraper 2y ago
    > below 600 Mbit/s is implied as being "Slow Internet" in the intro Or rather, not "Fast Internet"
    • lysace 2y ago
      Yeah.
• exabrial 2y ago
  I wish QUIC had a non-TLS mode... if I'm developing locally I really just want to see whats going over the wire sometimes and this adds a lot of un-needed friction.
  • krater23 2y ago
    You can add the private key of your server in wireshark and it will automatically decrypt the packets.
    • jborean93 2y ago
      This only works tor RSA keys and I believe ciphers that do not have forward secrecy. Quic is TLS 1.3 and all the ciphers in that protocol do forward secrecy so cannot be decrypted in this way. You’ll have to use a tool that provides the TLS session info through the SSLKEYLOGFILE format.
      • giuscri 2y ago
        Like which one?
    • exabrial 2y ago
      I'm aware... sigh, I've used this method to decrypt traffic alraedy and this is a giant PITA.
  • guidedlight 2y ago
    QUIC reuses parts of the TLS specification (e.g. handshake, transport state, etc). So it can’t function without it.
• spott 2y ago
  Here “fast internet” is 500Mbps, and the reason is that quic seems to be cpu bound above that. I didn’t look closely enough to see what their test system was to see if this is basic consumer systems or is still a problem for high performance desktops.
• Tempest1981 2y ago
  From September: QUIC is not quick enough over fast internet (acm.org) https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484991 (327 comments)
  • lysace 2y ago
    My personal takeaway from that: Perhaps we shouldn't let Google design and more or less unilaterally dictate and enforce internet protocol usage via Chromium. Brave/Vivaldi/Opera/etc: You should make a conscious choice.
    • vlovich123 2y ago
      So because the Linux kernel isn’t as optimized for QUIC as it has been for TCP we shouldn’t design new protocols? Or it should be restricted to academics that had tried and failed for decades and would have had all the same problems even if they succeeded? And all of this only in a data center environment really and less about the general internet Quic was designed for? This is an interesting hot take.
      • lysace 2y ago
        I'm struggling to parse my comment in the way you seem to think it did. In what way did or would my comment restrict your ability to design new protocols? Please explain.
        • vlovich123 2y ago
          Because you imply in that comment that it should be someone other than Google developing new protocols while in another you say that the protocols are already too complex implying stasis is the preferred state. You’re also factually incorrect in a number of ways such as claiming that HTTP/2 was a Google project (it’s not and some of the poorly thought out ideas like push didn’t come from Google). The fact of the matter is that other attempts at “next gen” protocols had taken place. Google is the only one that won out. Part of it is because they were one of the few properties that controlled enough web traffic to try something. Another is that they explicitly learned from mistakes that the academics had been doing and taken market effects into account (ie not requiring SW updates of middleware boxes). I’d say all things considered Internet connectivity is better that QUIC got standardized. Papers like this simply point to current inefficiencies of today’s implementation - those can be fixed. These aren’t intractable design flaws of the protocol itself. But you seem to really hate Google as a starting point so that seems to color your opinion of anything they produce rather than engaging with the technical material in good faith.
• superkuh 2y ago
  Since QUIC was designed for Fast Internet as used by the megacorporations like Google and Microsoft how it performs at these scales does matter even if it doesn't for a human person's end. Without it's designed for use case all it does is slightly help mobile platforms that don't want to hold open a TCP connection (for energy use reasons) and bring in fragile "CA TLS"-only in an environment where cert lifetimes are trending down to single months (Apple etc latest proposal).
  • dathinab 2y ago
    not really it's (mainly) designed by companies like Google to connect to all their end users Such a internet connection becoming so low latency that the latency of receiver side processing becomes dominant is in practice not the most relevant. Sure theoretically you can hit it with e.g. 5G but in practice even with 5G many real world situations won't. Most importantly a slow down of such isn't necessary bad for Google and co. as it only add limited amounts on strain on their services, infrastructure, internet and is still fast enough for most users to not care for most Google and co. use cases. Similar being slow due to receiver delays isn't necessary bad enough to cause user noticeable battery issues, on of the main reasons seem to many user<->kernel boundary crossings which are slow due to cache missues/ejections etc. but also don't boost your CPU clock (which is one of the main ways to drain your battery, besides the screen) Also like the article mentions the main issue is sub optimal network stack usage in browsers (including Chrome) not necessary a fundamental issue in the protocol. Which brings us to inter service communication for Google and co. which doesn't use any of the tested network stacks but very highly optimized stacks. I mean it really would be surprising if such network stacks where slow as there had been exhaustive perf. testing during the design of QUIC.
• skybrian 2y ago
  Looking at Figure 5, Chrome tops out at ~500 Mbps due to CPU usage. I don't think many people care about these speeds? Perhaps not using all available bandwidth for a few speedy clients is an okay compromise for most websites? This inadvertent throttling might improve others' experiences. But then again, being CPU-throttled isn't great for battery life, so perhaps there's a better way.
  • jeroenhd 2y ago
    These caps are a massive pain when downloading large games or OS upgrades for me as the end user. 500mbps is still fast but for a new protocol looking to replace older protocols, it's a big downside. I don't really benefit much from http/3 or QUIC (I don't live in a remote area or host a cloud server) so I've already considered disabling either. A bandwidth cap this low makes a bigger impact than the tiny latency improvements.
• jvanderbot 2y ago
  Well latency/bandwidth tradeoffs make sense. After bufferbloat mitigations my throughout halved on my router. But for gaming while everyone is streaming, it makes sense to settle with half a gigabit.
• kachapopopow 2y ago
  This sounds really really wrong. I've achieved 900mbps speeds on quic+http3 and just quic... Seems like a bad TLS implementation? Early implementation that's not efficient? The CPU usage seemed pretty avg at around 5% on gen 2 epyc cores.
  • kachapopopow 2y ago
    This is actually very well known: current QUIC implementation in browsers is *not stable* and is built of either rustls or in another similar hacky way.
    • AlienRobot 2y ago
      Why am I beta testing unstable software?
      • FridgeSeal 2y ago
        Because Google puts whatever they want in their browser for you to beta test and you’ll be pleased about it, peasant /s.
      • stouset 2y ago
        You’re the one choosing to use it.
        • AlienRobot 2y ago
          Okay, which browser doesn't come with it enabled by default? Chrome, Vivaldi, and Firefox do. Am I supposed to use Edge?
    • vasilvv 2y ago
      I'm not sure where rustls comes from -- Chrome uses BoringSSL, and last time I checked, Mozilla implementation used NSS.
• p1necone 2y ago
  I thought QUIC was optimized for latency - loading lots of little things at once on webpages and video games (which send lots of tiny little packets - low overall throughput but highly latency senstive) and such. I'm not surprised that it falls short when overall throughput is the only thing being measured. I wonder if this can be optimized at the protocol level by detecting usage patterns that look like large file transfers or very high bandwidth video streaming and swapping over to something less cpu intensive. Or is this just a case of less hardware/OS level optimization of QUIC vs TCP because it's new?
  • zamalek 2y ago
    It seems that syscalls might be the culprit (ACKs occur completely inside the kernel for TCP, where anything UDP acks from userspace). I wonder if BGP could be extended for protocol development.
• jrpelkonen 2y ago
  Curl creator/maintainer Daniel Stenberg blogged about HTTP/3 in curl a few months ago: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-2024/ https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20... One of the things he highlighted was the higher CPU utilization of HTTP/3, to the point where CPU can limit throughput. I wonder how much of this is due to the immaturity of the implementations, and how much this is inherit due to way QUIC was designed?
  • cj 2y ago
    I’ve always been under the impression that QUIC was designed for connections that aren’t guaranteed to be stable or fast. Like mobile networks. I never got the impression that it was intended to make all connections faster. If viewed from that perspective, the tradeoffs make sense. Although I’m no expert and encourage someone with more knowledge to correct me.
    • dan-robertson 2y ago
      I think that’s a pretty good impression. Lots of features for those cases: - better behaviour under packet loss (you don’t need to read byte n before you can see byte n+1 like in tcp) - better behaviour under client ip changes (which happen when switching between cellular data and wifi) - moving various tricks for getting good latency and throughput in the real world into user space (things like pacing, bbr) and not leaving enough unencrypted information in packets for middleware boxes to get too funky
    • therealmarv 2y ago
      It makes everything faster, it's an evolvement of HTTP/2 in many ways. I recommend watching https://www.youtube.com/watch?v=cdb7M37o9sU https://www.youtube.com/watch?v=cdb7M37o9sU
    • fulafel 2y ago
      That's how the internet works, there's no guaranteed delivery and TCP bandwidth estimation is based on when packets start to be dropped when you send too many.
  • 2y ago
• austin-cheney 2y ago
  EDITED. I preference WebSockets over anything analogous to HTTP. Commented edited because I mentioned performance conditions. Software developers tend to make unfounded assumptions/rebuttals of performance conditions they have not tested.
  • quotemstr 2y ago
    > * String headers > * round trips > * many sockets, there is additional overhead to socket creation, especially over TLS > * UDP. Yes, in theory UDP is faster than TCP but only when you completely abandon integrity. Have you ever read up on the technical details of QUIC? Every single of one of your bullets reflects a misunderstanding of QUIC's design.
    • Aurornis 2y ago
      Honestly the entire comment is a head scratcher, from comparing QUIC to HTTP (different layers of the stack) or suggesting that string headers are a performance bottleneck. Websockets are useful in some cases where you need to upgrade an HTTP connection to something more. Some people learn about websockets and then try to apply them to everything, everywhere. This seems to be one of those cases.
  • akira2501 2y ago
    I'd use them more, but WebSockets are just unfortunately a little too hard to implement efficiently in a serverless environment, I wish there was a protocol that spoke to that environment's tradeoffs more effectively. The current crop aside from WebSockets all seem to be born from taking a butcher knife to HTTP and hacking out everything that gets in the way of time to first byte. I don't think that's likely to produce anything worthwhile.
    • austin-cheney 2y ago
      That is a fair point. I wrote my own implementation of WebSockets in JavaScript and learned much in doing so, but it took tremendous trial and effort to get right. Nonetheless, the result was well worth the effort. I have a means to communicate to the browser and between servers that is real time with freedom to extend and modify it at my choosing. It is unbelievably more responsive than reliance upon HTTP in any of its forms. Imagine being able to execute hundreds of end-to-end test automation scenarios in the browser in 10 seconds. I can do that, but I couldn't with HTTP.
• 10000truths 2y ago
  TL;DR: Nothing that's inherent to QUIC itself, it's just that current QUIC implementations are CPU-bound because hardware GRO support has not yet matured in commodity NICs. But throughput was never the compelling aspect of QUIC in the first place. It was always the reduced latency. A 1-RTT handshake including key/cert exchange is nothing to scoff at, and the 2-RTT request/response cycle that HTTP/3-over-QUIC offers means that I can load a blog page from a rinky-dink server on the other side of the world in < 500 ms. Look ma, no CDN!
  • o11c 2y ago
    There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection. TLS only can add Confidentiality and Integrity, it can do nothing about the missing Availability.
    • suprjami 2y ago
      What does that have to do with anything here? This post is about QUIC performance, not TCP packet injection.
      • o11c 2y ago
        "Accept worse performance in order to fix security problems" is a standard tradeoff.
        • suprjami 2y ago
          QUIC was invented to provide better performance for multiplexed HTTP/3 streams and the bufferbloat people love that it avoids middlebox protocol interference. QUIC has never been about "worse performance" to avoid TCP packet injection. Anybody who cares about TCP packet injection is using crypto (IPSec/Wireguard). If performant crypto is needed there are appliances which do it at wirespeed.
    • ChocolateGod 2y ago
• throwaway984393 2y ago
  [dead]
• kibwen 2y ago
  How does it compare to HTTP/1 on similar benchmarks?
• cletus 2y ago
  At Google, I worked on a pure JS Speedtest. At the time, Ookla was still Flash-based so wouldn't work on Chromebooks. That was a problem for installers to verify an installation. I learned a lot about how TCP (I realize QUIC is UDP) responds to various factors. I look at this article and consider the result pretty much as expected. Why? Because it pushes the flow control out of the kernel (and possibly network adapters) into userspace. TCP has flow-control and sequencing. QUICK makes you manage that yourself (sort of). Now there can be good reasons to do that. TCP congestion control is famously out-of-date with modern connection speeds, leading to newer algorithms like BRR [1] but it comes at a cost. But here's my biggest takeaway from all that and it's something so rarely accounted for in network testing, testing Web applications and so on: latency. Anyone who lives in Asia or Australia should relate to this. 100ms RTT latency can be devastating. It can take something that is completely responsive to utterly unusable. It slows down the bandwidth a connection can support (because of the windows) and make it less responsive to errors and congestion control efforts (both up and down). I would strongly urge anyone testing a network or Web application to run tests where they randomly add 100ms to the latency [2]. My point in bringing this up is that the overhead of QUIC may not practically matter because your effective bandwidth over a single TCP connection (or QUICK stream) may be MUCH lower than your actual raw bandwidth. Put another way, 45% extra data may still be a win because managing your own congestion control might give you higher effective speed over between two parties. [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9 https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c... [2]: https://bencane.com/simulating-network-latency-for-testing-in-linux-environments-29daad98efcc https://bencane.com/simulating-network-latency-for-testing-i...
  • ec109685 2y ago
    For reasonably long downloads (so it has a chance to calibrate), why don't congestion algorithms increase the number of inflight packets to a high enough number that bandwidth is fully utilized even over high latency connections? It seems like it should never be the case that two parallel downloads will preform better than a single one to the same host.
    • Veserv 2y ago
• andsoitis 2y ago
  Designing for resource-constrained systems typically comes with making tradeoffs. Once the resource constraint is eliminared, you're no longer getting the benefit of that tradeoff but are paying the costs.
• ec109685 2y ago
  Meanwhile fast.com (and presumably netflix cdn) is using http 1.1 still.
  • dan-robertson 2y ago
    Why do you need multiplexing when you are only downloading one (video) stream? Are there any features of http/2 that would benefit the Netflix use case?
    • jeltz 2y ago
      QUIC handles packet loss better. But I do not think there is any benefit from HTTP2.
      • dan-robertson 2y ago
        Yeah I was thinking the same thing – in some video contexts with some video codecs you may care more about latency and may be able to get a video codec that can cope with packet loss instead of requiring retransmission – except it seemed it wouldn’t apply too much to Netflix where the latency requirement is lower and so retransmission ought to be fine. Maybe one advantage of HTTP/3 would be handling ip changes but I’m not sure this matters much because you can already resume downloads fine in HTTP/1.1 if the server supports range requests (which it very likely does for video)
      • yencabulator 2y ago
        Most significantly, QUIC handles packet loss in a way that is fair to all the contained streams; no head-of-line blocking. But the parent asks > Why do you need multiplexing when you are only downloading one (video) stream? So that largely doesn't apply.
• Thaxll 2y ago
  QUIC is pretty much what serious online games have been doing in the last 20 years.
• teleforce 2y ago
  Previous post on HN (326 comments - 40 days ago): QUIC is not quick enough over fast internet: https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484991
• AlienRobot 2y ago
  Anecdote: I was having trouble accessing wordpress.org. When I started using Wordpress, I could access the documentation just fine, but then suddenly I couldn't access the website anymore. I dual boot Linux, so it wasn't Windows fault. I could ping them just fine. I tried three different browsers with the same issue. It's just that when I accessed the website, it would get stuck and not load at all, and sometimes pages would just stop loading mid-way. Today I found the solution. Disable "Experimental QUIC Protocol" in Chrome settings. This makes me kind of worried because I've had issues accessing wordpress.org for months. There was no indication that this was caused by QUIC. I just managed to realize it because there was QUIC-related error in devtools that appeared only sometimes. I wonder what other websites are rendered inaccessible by this protocol and users have no idea what is causing it.
• tjoff 2y ago
  Industry will do absolutely anything, except making lightweight sites. We had instant internet in the late 90s, if you were lucky enough to have a fast connection. The pages were small and there were barely any javascript. You can still find such fast loading lightweight pages today and the experience is almost surreal. It feels like the page has completely loaded before you even released the mousebutton. If only the user experience were better it might have been tolerable but we didn't get that either.
  • OtomotO 2y ago
    I am currently de-javascripting a React app of some project I am working on. It's a blast. It's faster and way more resilient. No more state desync between frontend and backend. I admit there is a minimum of javascript (currently a few hundred lines) for convenience. I'll add a bit more to add the illusion this is still a SPA. I'll kill about 40k lines of React that way and about 20k lines of Kotlin. I'll have to rewrite about 30k lines of backend code though. Still, I love it.
    • NetOpWibby 2y ago
      Nature is healing. Love to see it.
    • pushupentry1219 2y ago
      Honestly I used to be on the strict noscript JavaScript hate train. But if your site works fast. Loads fast. With _a little_ JS that actually improves the functionality+usability in? I think that's completely fine. Minimal JS for the win.
      • OtomotO 2y ago
        Absolutely. I want the basic functionality to work without JS. But we have a working application and users are not hating it and used to it. We rely on modals heavily. And for that I added (custom) JS. It's way simpler than alternatives and some things we do are not even possible without JS/WASM (via JS apis to manipulate the DOM) today. I am pragmatic. But as you mentioned it, personally I also use NoScript a lot and if a site refuses to load without JS it's a hard sell to me if I don't know it already.
• LittleOtter 2y ago
  This paper has been shown one month ago:https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484991. Now it's back to headlines of HN.Seems like people all interested in this topic.
• jpambrun 2y ago
  This paper seems to be neglecting to the effect of latency and packet loss. From my understanding, the biggest issue with TCP is the window sizing that gets cut every time a packet gets lost or arrives out of order, thus killing throughput. The latency makes that more likely to happen and makes the effect last longer. This paper needs multiple latency simulations, some packet loss and latency jitter to have any value.
  • dgacmu 2y ago
    This is a bit of a misunderstanding. A single out of order packet will not cause a reduction; tcp uses three duplicate acks as a loss signal. So the packet must have been reordered to arrive after 3 later packets. Latency does not increase the chances of out of order packet arrival. Out of order packet arrival is usually caused by multipath or the equivalent inside a router if packets are handled by different stream processors (or the equivalent). Most routers and networks are designed to keep packets within a flow together to avoid exactly this problem. However, it is fair to say that traversing more links and routers probably increases the chance of out of order packet delivery, so there's a correlation in some way with latency, but it's not really about the latency itself - you can get the same thing in a data center network.
• lbriner 2y ago
  Funny though, we all implicitly buy into "QUIC is the new http/2" or whatever because fast = good without really understanding the details. It's like buying the new 5G cell phone because it is X times faster than 4G even though 1) My 4G phone never actually ran at the full 4G speed and 2) The problem with any connection is almost never due to the line speed of my internet connection but a misbehaving DNS server/target website/connection Mux at my broadband provider. "But it's 5G" Same thing cracks me up when people advertise "fibre broadband" for internet by showing people watching the TV like the wind is blowing in their hair, because that's how it works (not!). I used to stream on my 8Mb connection so 300Mb might be good for some things but I doubt I would notice much difference.