[HN Gopher] QUIC Is Not Quick Enough over Fast Internet
___________________________________________________________________
QUIC Is Not Quick Enough over Fast Internet
Author : carlos-menezes
Score : 70 points
Date : 2024-10-19 21:04 UTC (1 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| lysace wrote:
| > 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 wrote:
| That is interesting though. 1gbit is becoming more common
| schmidtleonard wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/U0G1yiWzShqOGXul
| we1AetDjR...
| jsheard wrote:
| 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 torturing
| copper for all it's worth.
| michaelt wrote:
| 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.
| Dylan16807 wrote:
| 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.
| Aurornis wrote:
| 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 wrote:
| 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).
| rvnx wrote:
| Copper cable costs around $3 to $6 per meter, while fiber
| optic cable typically costs between $1 to $5 per meter
| jiggawatts wrote:
| Here in Australia there's talk of upgrading the National
| Broadband Network to 2.5 Gbps to match modern consumer
| Ethernet and WiFi speeds.
|
| I grew up with 2400 baud modems as _the super fast upgrade_ ,
| so talk of multiple gigabits for consumers is blowing my mind
| a bit.
| TechDebtDevin wrote:
| Is Australia's ISP infrastructure nationalized?
| ratorx wrote:
| It depends on whether it's meaningfully slower. QUIC is
| pretty optimized for standard web traffic, and more
| specifically for high-latency networks. Most websites also
| don't send enough data for throughput to be a significant
| issue.
|
| I'm not sure whether it's possible, but could you
| theoretically offload large file downloads to HTTP/2 to get
| best of both worlds?
| dathinab wrote:
| 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.
| exabrial wrote:
| 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 wrote:
| You can add the private key of your server in wireshark and it
| will automatically decrypt the packets.
| guidedlight wrote:
| QUIC reuses parts of the TLS specification (e.g. handshake,
| transport state, etc).
|
| So it can't function without it.
| spott wrote:
| 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 wrote:
| From September:
|
| QUIC is not quick enough over fast internet (acm.org)
|
| https://news.ycombinator.com/item?id=41484991 (327 comments)
| lysace wrote:
| 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 wrote:
| 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 wrote:
| 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.
| GuB-42 wrote:
| Maybe, but QUIC is not bad as a protocol. The problem here is
| that OSes are not as well optimized for QUIC as they are for
| TCP. Just give it time, the paper even has suggestions.
|
| QUIC has some debatable properties, like mandatory
| encryption, or the use of UDP instead of being a protocol
| under IP like TCP, but there are good reasons for it, related
| to ossification.
|
| Yes, Google pushed for it, but I think it deserves its
| approval as a standard. It is not perfect but it is
| practical, they don't want another IPv6 situation.
| ratorx wrote:
| Having read through that thread, most of the (top) comments
| are somewhat related to the lacking performance of the
| UDP/QUIC stack and thoughts on the meaningfulness of the
| speeds in the test. There is a single comment suggesting
| HTTP/2 was rushed (because server push was later deprecated).
|
| QUIC is also acknowledged as being quite different from the
| Google version, and incorporating input from many different
| people.
|
| Could you expand more on why this seems like evidence that
| Google unilaterally dictating bad standards? None of the
| changes in protocol seem objectively wrong (except possibly
| Server Push).
|
| Disclaimer: Work at Google on networking, but unrelated to
| QUIC and other protocol level stuff.
| lysace wrote:
| > Could you expand more on why this seems like evidence
| that Google unilaterally dictating bad standards?
|
| I guess I'm just generally disgusted in the way Google is
| poisoning the web in the worst way possible: By pushing
| ever more complex standards. Imagine the complexity of the
| web stack in 2050 if we continue to let Google run things.
| It's Microsoft's embrance-extend-and-extinguish scheme
| taken to the next level.
| superkuh wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jvanderbot wrote:
| 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 wrote:
| 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 wrote:
| 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.
| p1necone wrote:
| 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 wrote:
| 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 wrote:
| 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-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?
| austin-cheney wrote:
| QUIC is faster than prior versions of HTTP, but its still HTTP.
| It will never be fast enough because its still HTTP:
|
| * 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.
|
| Instead just use WebSockets. You can execute HTTP over
| WebSockets. The advantage there is multiple protocols supported
| over a single port with all the performance benefits of
| WebSockets that are not achievable to HTTP. Some of those
| benefits include:
|
| * fire and forget, no round trips
|
| * no headers, instead messages make use of binary frame headers
| that are only 2-14 bytes in length
|
| * The sockets are intended to be persistent, instead of requiring
| things like keep-alive headers
|
| * WebSockets are full duplex
| quotemstr wrote:
| > * 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.
| akira2501 wrote:
| 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.
| Aurornis wrote:
| > QUIC is faster than prior versions of HTTP, but its still
| HTTP. It will never be fast enough because its still HTTP: > *
| String headers > * round trips > * many sockets, there is
| additional overhead to socket creation, especially over TLS
|
| QUIC is a transport. HTTP can run on top of QUIC, but the way
| you're equating QUIC and HTTP doesn't make sense.
|
| String headers and socket opening have nothing to do with the
| performance issues being discussed.
|
| String headers aren't even a performance issue at all. The
| amount of processing done for when the most excessive use of
| string headers is completely trivial relative to all of the
| other processing that goes into sending 1,000,000,000 bits per
| second (Gigabit) over the internet, which is the order of
| magnitude target being discussed.
|
| I don't think you understand what QUIC is or even the prior art
| in HTTP/2 that precedes these discussions of QUIC and HTTP/3.
| 10000truths wrote:
| TL;DR: Nothing that's inherent to QUIC itself, it's just that
| current QUIC implementations are CPU-bound because hardware
| offload support for it 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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-19 23:00 UTC)