61–70 of 116 posts
Earlier quoted context omitted.
Wouldn't pretty much all of that overhead compared to TCP vanish if QUIC was implemented in the kernel?
No, due to the lack of TSO/LRO. Its my understanding that QUIC is designed to encrypt packet medata so that middle boxes cannot re-segment traffic. This same feature prevents NICs from doing TSO.
As far as I’ve been able to determine, QUIC suffers from the same SNI data leak that existing TLS versions with TCP has. I understand that ESNI is being (or is already?) included in the TLS 1.3 spec, but it’s obviously optional at this point. Anyways, since QUIC is being touted everywhere as being very secure: > [QUIC] protects both the data and the transport protocol itself It seems like missing ESNI as a required f…
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...
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…
so the arista's are gonna be able to ecmp on it?
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.
> 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…
There isn't much opportunity for people to plug random stuff between your server and the middlebox (the main middlebox would disallow it, like anything else), but there is still plenty of crappy rules everywhere and nobody knows why they exist or what they are. And you can't even call your ex-coworker and ask for help, because it's an ex-employee of the middlebox company, not yours.
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.
QUIC actually requires that request packets must be larger than the responses, until a handshake has been performed, in order to prevent reflection attacks.
Earlier quoted context omitted.
> Thus, moving the protocol to userspace makes a lot of sense. Raw IP sockets are accessible from the same userspace facing APIs as e.g. UDP sockets and don't require climbing up the stack. Unfortunately operating systems started to consider custom protocol implementations security risks but rather than reverse that thinking we've just continued to abstract up past it. In reality I think "where it is implemented in c…
Raw sockets don't really allow for multiple applications to use the same custom protocol. If, for example, chrome and firefox were both running, which gets packets destined for the QUIC transport protocol? The kernel wouldn't know; without the UDP header it can't distinguish flows. Likewise NAT devices typically support UDP flows today due to their prevalence in games, but if you introduce a new transport protocol at…
Though I don't know what's wrong with UDP. 8 bytes of overhead for 1450 bytes IP payload is 0.5% bandwidth. Checksum overhead should be negligible.