3 ms·

One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ? I've read it's 2 to 3 times more CPU intensive, aren't we impli

by ldng 8y ago

One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ? I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ... That is raising the barrier of entry for newcomers, is it not ? Isn't TCP already versioned ?

CaliforniaKarl 8y ago
> One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ? I think parts of it can still be hardware-accelerated. For example, OpenSSL et al will take advantage of available AES encryption CPU instructions, if it knows about them. So, if the TLS library supports such offloading, then the HTTP/3 library would get that benefit. > I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ... Happily, a number of those vendors are kernel developers, and contribute changes back upstream. So, if the bottleneck is in the kernel (for example, by a lack of UDP fast processing paths), then I expect those cloud providers would be working on contributions to make kernel UDP as performant as kernel TCP. The next thing that would be missing is support for UDP offloading in the NIC space. But TBH I don't know much about the current state of hardware offloading, so I can't speak to it. > Isn't TCP already versioned ? I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'. [0]: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml https://www.iana.org/assignments/protocol-numbers/protocol-n...
- ldng 8y ago
  Hum, right, parts of TLS could be offloaded. Now will the TLS protocol will continue to evolve ? And will QUIC follow ? And you could offload UDP, TLS but not QUIC itself. Unless you're BigBuck Company and offload to FPGAs competition can't afford. Could happen. It's a gap that might close, but right now, to me, it is a notable competitive advantage.
- takeda 8y ago
  > > Isn't TCP already versioned ? > I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'. Currently there is only a single TCP, it didn't need new version, because it has options mechanism to add additional information as needed. If it would need to be redesigned a new protocol would be created and a new protocol number would be allocated. Kind of like what happened with ICMP and ICMPv6.
tracker1 8y ago
I'm not sure there's a reason large parts of it couldn't be hardware accelerated.. for that matter why specific implementations couldn't happen on a network controller for that matter. Sure, initial implementations will be software only, so that it can be implemented on top of the OS, that doesn't negate the opportunity to move pieces down the stack.
wmf 8y ago
Some NICs already accelerate TLS so QUIC probably won't be any more difficult. Although QUIC NICs may not be available until 2-3 years after the RFC.

by ldng 8y ago

CaliforniaKarl 8y ago

> One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ? I think parts of it can still be hardware-accelerated. For example, OpenSSL et al will take advantage of available AES encryption CPU instructions, if it knows about them. So, if the TLS library supports such offloading, then the HTTP/3 library would get that benefit. > I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ... Happily, a number of those vendors are kernel developers, and contribute changes back upstream. So, if the bottleneck is in the kernel (for example, by a lack of UDP fast processing paths), then I expect those cloud providers would be working on contributions to make kernel UDP as performant as kernel TCP. The next thing that would be missing is support for UDP offloading in the NIC space. But TBH I don't know much about the current state of hardware offloading, so I can't speak to it. > Isn't TCP already versioned ? I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'. [0]: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml https://www.iana.org/assignments/protocol-numbers/protocol-n...

ldng 8y ago
Hum, right, parts of TLS could be offloaded. Now will the TLS protocol will continue to evolve ? And will QUIC follow ? And you could offload UDP, TLS but not QUIC itself. Unless you're BigBuck Company and offload to FPGAs competition can't afford. Could happen. It's a gap that might close, but right now, to me, it is a notable competitive advantage.
takeda 8y ago
> > Isn't TCP already versioned ? > I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'. Currently there is only a single TCP, it didn't need new version, because it has options mechanism to add additional information as needed. If it would need to be redesigned a new protocol would be created and a new protocol number would be allocated. Kind of like what happened with ICMP and ICMPv6.

tracker1 8y ago

I'm not sure there's a reason large parts of it couldn't be hardware accelerated.. for that matter why specific implementations couldn't happen on a network controller for that matter. Sure, initial implementations will be software only, so that it can be implemented on top of the OS, that doesn't negate the opportunity to move pieces down the stack.

wmf 8y ago

Some NICs already accelerate TLS so QUIC probably won't be any more difficult. Although QUIC NICs may not be available until 2-3 years after the RFC.