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.
Wayland doesn’t ignore decades of tooling and knowledge buildup. It learns from it and realizes a lot of it was a bad idea. The same people are working on wayland as previously spent 30 years working on Xorg because they realized there were large, glaring flows in the Z model that were impossible to fix.
Just to pick a couple examples off the top of my head: ever wonder why it’s impossible on X to engage the screensaver while a context menu is open? Or why you can’t change screen brightness or volume levels in a lockscreen?
There have been detailed talks given by core Xorg developers on all the ways C is unfixably broken and why wayland is needed going back more than a decade. Here’s one given back in 2013 by one of the three people on earth who understand how the X input stack works: https://youtu.be/RIctzAQOe44?t=1115 I’ll skip to the part about “network transparency” specifically. :P
X model*
X is unfixably broken *
real alphabet soup today
So basically you cherry-picked one sample. But you do not understand what it was talking about. Yes, they do not work. But it is called ‘extension’ for a good reason. There is not guarantee, that SHM or DRI are present on an X server. And you must not assume it. Same goes for wayland and it’s protocols, only now it is another circus with protocol support. Oops.
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.
Exactly, their browser already uses it and they don’t know it :)
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.
Another SPDY. Can’t wait to read about it not being supported by anything anymore.
classic story. stuff moves into the kernel for speed. stuff moves into userspace libs for control. next there’ll be a QUIC implementation in the kernel for speed, then some other new thing will pop up in userspace. maybe even a replacement for IP in userspace on top of raw sockets. it might help fix the issue with defining a connection in terms of two IPs and two sockets results in the connection breaking when a mobile device changes IP address.
No need to wait : https://lwn.net/Articles/1029851/
It would be slower than raw UDP but also slower than TCP? At least that’s what I’m getting since it works on the layer above TCP/UDP