5 ms·

> solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades QUIC explicitly addresses "network middlebox ossification" of TCP, by en

> solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades QUIC explicitly addresses "network middlebox ossification" of TCP, by encrypting almost everything about the protocol. This type of ossification is where the network blocks or corrupts any deviations that it doesn't recognise but thinks it does. TCP "OS ossification" is a different kind. By itself, this could have been overcome by streaming TCP-in-UDP and amending it from there. Even that is only because of OS APIs. If OSes allowed applications to bind to a TCP port and process the raw packets, applications that want to could implement TCP themselves. If that kind of dual-binding seems strange, I think it's actually more or less what we'll end up with with QUIC in the end: The OS providing QUIC sockets (socket(AF_INET,SOCK_QUIC,...)) to applications that don't care to implement the QUIC stack themselves, while allowing other applications to bind to UDP in the usual way and implement their own application-level QUIC. I think current QUIC solves application vs. OS ossification issues in the short term, allowing things to evolve beyond TCP, but it's a temporary benefit. In time I think we will see QUIC ossify when it's implemented in many applications that don't get updated. Most browsers are updated often. But I'm seeing more obscure applications starting to include QUIC and depend on it (without any TCP fallback even) - leading eventually to hundreds of "hand-written quality" QUIC implementations, all destined to get out of date. Various languages are implementing their own QUIC libraries, and these aren't all going to be maintained the same way. Shipped applications ossify too. That's why I think it'll end up in the OS kernels eventually.

jsnell 6y ago
You're right that the two forms of ossification are distinct, but I'm quite certain that both were driving factors here. Rolling out new TCP options is a decade-long process, and if anything goes wrong with the initial design, once it is shipping you're basically never fixing it. Applications are much easier to update than operating systems, auto-update for the vast majority of users, and for the <1% who don't update the app can always fall back to TCP. (E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.) The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.

jsnell 6y ago

You're right that the two forms of ossification are distinct, but I'm quite certain that both were driving factors here. Rolling out new TCP options is a decade-long process, and if anything goes wrong with the initial design, once it is shipping you're basically never fixing it. Applications are much easier to update than operating systems, auto-update for the vast majority of users, and for the <1% who don't update the app can always fall back to TCP. (E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.) The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.