Everyone knows that Weird Al lampooned computers in a famous parody song (It’s All About the Pentiums). But if you want more hardcore (including more hardcore language, so if you are offended by rap music-style explicit lyrics, maybe don’t look this up), you probably want “Kill Dash 9” by Monzy. There’s a line in that song about “You thought the seven-layer model referred to a burrito.” In fact, it refers to how networking applications operate, and it is so ingrained that you don’t even hear about it much these days. But as [Codemia] points out, QUIC aims to disrupt the model, and for good reason.
Historically, your application (at layer 7) interacts with the network through other layers like the presentation layer and session layer. At layer 4, though, there is the transport layer where two names come into play: TCP and UDP. Generally, UDP is useful where you want to send data and you don’t expect the system to do much. Data might show up at its destination. Or not. Or it might show up multiple times. It might show up in the wrong order. TCP solves all that, but you have little control over how it does that.
When things are congested, there are different strategies TCP can use, but changing them can be difficult. That’s where QUIC comes in. It is like a user-space TCP layer built over a UDP transport. There are a lot of advantages to that, and if you want to know more, or even just want a good overview of network congestion control mitigations, check the post out.
If you want to know more about congestion control, catch a wave.
Before even looking at this, my immediate impression is that of a BMW taking the shoulder lane when the traffic gets too heavy for their liking.
Exposing connection state to layer-4 switch or load balancer or firewall is usually describable. Which isn’t possible when you implement semi-custom protocols on top of UDP.
But the problem with TCP always has been that it attempts to generalize a solution to a set of problems that are not general. Most of the time it works very well, but over the decades we’ve ran into one problem or another and have extended TCP in various ways to deal with it.
That said, you can run massive websites with very little CPU power over TCP. These production environments are very heavily tuned in order to do what they do. But it does demonstrate taht TCP does get it right in some cases (most cases I’d argue).
Yeah, this is just another wayland. Ignore decades of tooling and knowledge buildup and instead make network management a mess. If software messes up the tcp protocol, you fire up wireshark and you see what is wrong. When quic messes up you quickly goto tears.
I never thought of it this way before. Thanks for the observation from a decidedly old-school guy.
Yet another project developed by cokeheads at Google who code first and do the design later. It’s likely that it will end up dead, among many other project like Stadia, Glassholes or Web Accelerator.
What the heck are you talking about? HTTP/3 is already a standard and already uses QUIC for transport.
7 layers just reminds me of M.A. Padlipsky and “The Elements of Networking Style”.
Having 7 layers just to have 7 layers is silly.
all people seem to need delicious pizza
I always had the feeling that there were seven layers in the standard model just to have seven layers. Real-life networks don’t really map to all the layers. Pretty sure that’s why you don’t hear much about it these days.
While the 7-layer model is useful as a model, we need to remember that modern networking (ie TCP/IP and related) don’t really follow that 7-layer model very well:
1) It never had an “internet” layer.
2) you can sort-of fit layers 1-4 (physical through transport) into the model, but the “layers” above transport get very fuzzy, merged, and competitive. (rather similar to the way most filesystems these days don’t go much beyond “byte stream.”)
3) naively implementing each layer separately is a sure path to poor performance.