41–50 of 50 posts
Earlier quoted context omitted.
TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.
Having debugged stuff for someone crazy who wanted less than 50ms global latency for a private search engine I can tell you the TLS negotiation adds significant time the first time you initialize the connection
Earlier quoted context omitted.
TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.
Having debugged stuff for someone crazy who wanted less than 50ms global latency for a private search engine I can tell you the TLS negotiation adds significant time the first time you initialize the connection
Earlier quoted context omitted.
> However, you can also advertise H3 support via Alt-Svc, so presumably you could do the same with TurboTLS. Alt-Svc is an http header, by the time you get http you already have TLS setup. In a Alt-Svc workflow you generally advertise h2 in TLS ALPN, then use Alt-Svc to advertise h3 capability in the headers of the first response, and then the client establishes a h3 connection and closes the h2 connection when it is…
Yes, that's correct. Basically the only good way to have a "first contact" fast track setup like this is by priming in DNS. My point is that the situation is th same for TurboTLS and QUIC/H3 in this respect.
fewer
less modifies singular nouns, fewer modifies plural nouns. Check here for more
https://www.latimes.com/socal/daily-pilot/opinion/tn-dpt-me-...
Earlier quoted context omitted.
Kernels and hardware have been optimized for TCP. QUIC will catch up eventually.
AFAIK, kTLS and hardware TLS offload don't solve the latency problem anyways. Those only handle the AEAD and record encapsulation/decapsulation in the critical path, where maximizing throughput is the concern. Control messages are not handled, so session establishment with client hello, cipher exchange, key exchange etc. is still done entirely in userspace, and the handshaking process is where the latency issues aris…
Earlier quoted context omitted.
I’m not sure what’s the relation with RSA but you’re right that it’s simple. And that’s what noise has been doing for years. There isn’t much else to look at here, unless you specifically need tls you should be using noise
TLS 1.3 and QUIC both support 0-RTT modes as well (as noted in the original paper). Note that anything that runs over TCP of course first has to absorb the TCP round-trip (modulo TFO) whatever crypto it uses. That's why QUIC uses UDP, and the motivation for the use of UDP in TurboTLS.
Earlier quoted context omitted.
Having debugged stuff for someone crazy who wanted less than 50ms global latency for a private search engine I can tell you the TLS negotiation adds significant time the first time you initialize the connection
50ms is impossible. Lowerbound is 68. One-way.
Earlier quoted context omitted.
Having debugged stuff for someone crazy who wanted less than 50ms global latency for a private search engine I can tell you the TLS negotiation adds significant time the first time you initialize the connection
I've designed my own private CDN and unless you have edges near each geo, you're not getting that kind of latency. And even after TLS negotiation you have no idea what the MSS on a link along the way will be causing fragmentation and retransmits. I've made do with some shenanigans with Noise and pre shared certs and have tried to make payload sizes as small as possible.
Earlier quoted context omitted.
I've designed my own private CDN and unless you have edges near each geo, you're not getting that kind of latency. And even after TLS negotiation you have no idea what the MSS on a link along the way will be causing fragmentation and retransmits. I've made do with some shenanigans with Noise and pre shared certs and have tried to make payload sizes as small as possible.
Yes this was using a presence in every GCP and Cloudflare and AWS edge location simultainiously all hooked together with latency based routing
Earlier quoted context omitted.
AFAIK, kTLS and hardware TLS offload don't solve the latency problem anyways. Those only handle the AEAD and record encapsulation/decapsulation in the critical path, where maximizing throughput is the concern. Control messages are not handled, so session establishment with client hello, cipher exchange, key exchange etc. is still done entirely in userspace, and the handshaking process is where the latency issues aris…
Oh yeah, QUIC is an improvement in terms of latency and even throughput over TCP/TLS. The claim that "QUIC is horribly inefficient" centers around CPU utilization and the cost of delivering each byte. That's where hardware offload shines but it doesn't exist for QUIC yet.
The same server that will do 375Gb/s at close to 50% idle will maybe deliver 70-90Gb/s of QUIC with the CPU maxed.
TLS+TCP delivers that performance with a lot of optimizations that just don't exist for QUIC:
- inline TLS offload (Mellanox CX6DX)
- async sendfile -- note, the above 2 mean that the kernel never even maps data from a file being sent to a client into memory, much less copies it to/from userspace like with QUIC. This cuts memory bandwidth to roughly 1/4 of what it would be with a traditional read/encrypt/write to socket server.
- TCP segmentation offload
- TCP & IP checksum offload
- TCP large receive offload
Some of these optimizations are slowly becoming available, but until all are present, QUIC will cost 2x - 4x as much to serve as TCP for a CDN workload.