3 ms·
Despite middleboxes TCP and TLS are still evolving. It is slow and painful compared to green field designs like QUIC, but it still happens. Latency-based conge
by the8472 7y ago
Despite middleboxes TCP and TLS are still evolving. It is slow and painful compared to green field designs like QUIC, but it still happens.
Latency-based congestion controllers such as CTCP and BBR have gained adoption to better utilize long, fat pipes while keeping bufferbloat down. TFO was introduced to cut down the connection setup latency by 1 RTT if the endopints have seen each other before before. There is some noise about upstreaming MPTCP to linux which would then eventually make its way to android where it would be a big deal for seamless wifi/mobile transitioning.
TLS' evolution is self-evident from new versions including dramatically changed handshakes rolling out.
- tialaramex 7y agoSure, but that has the relationship wrong. TLS development can't realistically import work from QUIC because the relevant work already is TLS. The relationship between TLS and QUIC in such a system is mutual, like a clownfish and an anemone - each needs the other, QUIC is not just replacing TCP here, it's also dependant on TLS (in a way TCP obviously is no) because it offers TLS guarantees (e.g. forward secrecy) in QUIC itself, as well as guarantees TCP has like delivery order preservation. QUIC needs a cryptographic setup mechanism. 99% of TLS is the cryptographic setup mechanism, and then 1% is "Now that we've agreed everything, here is how to send application data", QUIC doesn't need that 1% but it takes all the rest of TLS 1.3 straight out of the box. A QUIC implementation can hypothetically end up negotiating TLS 1.4 (some future compatible TLS 1.3 upgrade) and that'll work out fine, the keys get generated and then just as with TLS 1.3 they are used to encrypt QUIC's native packets not a TLS application data layer.