Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Love QUIC and HTTP/3

fastly.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: Why We Love QUIC and HTTP/3

#51

Post by mcguire »

teacpde wrote: post #44
drewg123 wrote: post #28

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…

Awesome analysis. This is first time that I read about the downsides of QUIC, curious that whether implementing it in userspace was a conscious trade off knowing the performance downside or Google/IETF wasn’t aware of the problem at all?

Implementing new transport protocols in kernelspace has significant downsides for adoption. In fact, it has been a long time since anyone tried it.

Re: Why We Love QUIC and HTTP/3

#52

Post by Avamander »

daurnimator wrote: post #16
cdmckay wrote: post #8

Earlier quoted context omitted.

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

I think TCP fast open is a bad example for this. None of the common socket libraries that I know (never mind http libraries) have gained support for TCP fast open yet.

It's a bad example because it's badly adopted?

Re: Why We Love QUIC and HTTP/3

#53

Post by galadran »

drewg123 wrote: post #28

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…

tl;dr - QUIC doesn't have kernel or hardware support (yet).

These aren't intrinsic problems with QUIC, they're common to all new protocols.

Re: Why We Love QUIC and HTTP/3

#54

Post by collinf »

> These interposing network elements, called middleboxes, often unwittingly disallow changes to TCP headers and behavior, even if the server and the client are both willing.

There is nothing worse than finding out that someone not even at the company anymore decided years before to deploy some crap like this. Drives me absolutely crazy to impose stuff like this where silos in companies means transitioning involves on the order of 4-5 different "components" need to change.

Re: Why We Love QUIC and HTTP/3

#55

Post by geuszb »

drewg123 wrote: post #28

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…

Thanks for sharing the insight... This being HN, it doesn't necessarily read to me like a disadvantage for QUIC the protocol as much as an opportunity for someone to come up with a way to do hardware-assisted QUIC in the networking interface...

Re: Why We Love QUIC and HTTP/3

#56

Post by daurnimator »

Avamander wrote: post #52
daurnimator wrote: post #16

Earlier quoted context omitted.

I think TCP fast open is a bad example for this. None of the common socket libraries that I know (never mind http libraries) have gained support for TCP fast open yet.

It's a bad example because it's badly adopted?

It's a bad example of middle-boxes causing ossification, as the adoption has been more limited by library/framework support than middle-boxes blocking it.

Re: Why We Love QUIC and HTTP/3

#57

Post by Matthias247 »

irq-1 wrote: post #48
drewg123 wrote: post #28

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…

Two questions: can't large files continue to be served on HTTP2? and won't https://www.dpdk.org/ allow user-space network stacks to do segmentation, etc...? (Maybe it's too immature?)

Regarding the first question:

Even HTTP/2 involves some of the issues the parent mentions. HTTP/2 is not really helpful for large files, and might likely perform worse than HTTP/1.1 due to the additional insertion and parsing of control flow headers. HTTP/2 helps small files most, by avoiding the overhead of connection establishment for those.

Re: Why We Love QUIC and HTTP/3

#58

Post by Matthias247 »

drewg123 wrote: post #28

QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…

I think in general I agree. However the overhead numbers are exaggerated, and we should be fair with that. E.g. it was already mentioned that multiple UDP packets can be transmitted via a single syscall, and reasonable implementations can make use of it. I haven't read the Quic spec (yet), so I don't know how much data can be aggregated without waiting for ACKs or interleaving other data - but if it's anything comparable to HTTP/2 then it should be configurable and support >= 64kB chunks.

I also don't think a QUIC server would read the whole file into user-space at once - that's just a giant memory waste. Rather it would be streamed and chunks would get encrypted. That process requires of course an extra copy (likely even two for the unencrypted and encrypted version), but that's the same for all user-space file serving and encryption options and nothing new due to QUIC. For KTLS it would need to get investigated whether the kernel solution doesn't also perform a copy somewhere (I honestly don't know).

Re: Why We Love QUIC and HTTP/3

#59

Post by blackflame7000 »

josteink wrote: post #27
blackflame7000 wrote: post #7

Earlier quoted context omitted.

It runs over UDP so they did go back to the protocol layer when designing a solution. Thats the whole point is to fix the tcp halt and retransmit delay when a packet gets lost.

So it will be firewalled by most corporate firewalls then? Hardly sounds useful.

Why would it get firewalled? DNS runs over UDP on port 53

Re: Why We Love QUIC and HTTP/3

#60

Post by scurvy »

QUIC will also usher in a new era of volumetric DDoS attacks. No longer can content providers use upstream ACLs to block udp garbage and fragments. The only option will be to use Fastly, AWS, or Cloudflare to ride out attacks.

QUIC is the tool to bring about the next phase of Internet centralization by the mega players.

Post reply on HN