I once implemented a part of RFC1006, a way to use ISO protocols on the internet. It contains gems like:
In migrating from the use of TCP/IP to the ISO protocols
Whoever wrote that RFC seemed to think of the internet as some temporary stopgap measure until responsible adults found the time to implement a real network protocol.
My main takeway was: Thank god the internet won, OSI was some badly specified eldritch horror. RFC1006 was the only spec that seemed more or less readable by a human being.
Because IPv4 was a temporary, stopgap solution. That's why it has 32bit addressing, when by late 1980s the need for larger address space for Internet was already well understood (that's partly why OSI does 20bytes for address).
The spec is wordy, but CLNS and TP4 differ little from IP and TCP, except for TP4 not having legacy of being a dumb emulated serial port, so it has message framing. Most of verbiage comes from the part that OSI took pains to handle a lot of problems upfront instead of saying "eh, it's temporary, let's go shopping", and writing standards with strict requirements tended to have certain verbiage allowing one to specify in minutiae what was missing from implementation, with no Postel around to promote lax handling.
N.B. a pretty serious (and implemented on Cisco and Sun) proposal to fix the already-known addressing problem of IPv4 was TUBA - which is essentially TCP running on top of CLNS.
Agree, the OSI model was what smart people who thought deeply about the issue decided we should do. Unfortunatly the timing was bad and the coherent model emerged just a bit to late. Maybe if the major networking infrastructures had been in Europe a switch could have been a possibility.
Americans are very pragmatic: make the stuff work and get on with your life, if problems arise in the future we will fix them. American standards are usually but a formalisation of already accepted practises (and this goes well beyond network stuff), this is why they are so effective and so poorly thought out. I guess it's still better than "ideals" that nobody follows.
And of course this is an oversimplification of some sensitivity difference between vast parts of the world, we individuals are but samples on the agregate sociological context that drives this sort of things.
It has nothing to do with Americans vs Europeans. Plenty of Americans spent excessive time navel gazing on optimal TCP/IP replacements (tons of research on Internet protocols comes out of American universities).
First to market wins if it works and solves the problem. That’s all there is too it. Nobody is going to wait around for something that might work that is theoretically better if you have an option that works and solves your problem.
IPv6 is a pragmatic replacement and it hasn’t even meaningfully killed IPv4 despite being widely available for nearly 20 years.
> It has nothing to do with Americans vs Europeans. Plenty of Americans spent excessive time navel gazing on optimal TCP/IP replacements (tons of research on Internet protocols comes out of American universities).
Yes, that was what my last point was about.
> First to market wins if it works and solves the problem. That’s all there is too it. Nobody is going to wait around for something that might work that is theoretically better if you have an option that works and solves your problem.
This way of framing the problem is weird to me. Markets are not handed to us by the Gods, we put them in place because some of us think they are a good way to solve problems. And in any case, consensus on green fields like networking at the time have very little to do with markets, at least in the economical sense (you could argue for a market of ideas but I don't think that's what you had in mind). But to give a famous counter example, most of the world have changed their perfectly fine system of units when a clearly better one emerged.
> IPv6 is a pragmatic replacement and it hasn’t even meaningfully killed IPv4 despite being widely available for nearly 20 years.
Not nearly as pragmatic as NAT.
Te be clear, I'm not saying that the pragmatic way is bad, in fact it's probably the best in most situations. I'm just pointing out that there might be psycho-social reasons for the non adoption of the OSI model by the network community. I could be wrong of course and I'm happy to read opposing thoughts on the matter.
EDIT: I re-read my first comment and I can see that I have been to dry in my writting and how it can be understood as "those damn Yankees are idiots!". I apologize for that, I'm trying to improve my nuances but still have a long way to go.
> This way of framing the problem is weird to me. Markets are not handed to us by the Gods, we put them in place because some of us think they are a good way to solve problems.
Markets exist no matter what. I’m speaking of markets in the economical sense, not a concrete “exchanging things for money”. Look up the phrase “market of ideas” to get a better feel for what I’m talking about.
> Not nearly as pragmatic as NAT.
You are proving my point. A solution that works good enough has immense momentum because the people that care to change are dwarfed by the people who don’t want to bother. IPv6 has a pretty solid sales pitch for ISPs (CGNAT is painful to scale, manage, etc), but they don’t have any say. It’s server admins that need to drop V4 to bring any forced change... and they can’t do that without losing visitors.
> I'm just pointing out that there might be psycho-social reasons for the non adoption of the OSI model by the network community. I could be wrong of course and I'm happy to read opposing thoughts on the matter.
It didn’t offer any clear upside worth the complexity. The shared l4/l3 with TCP/IP means people can easily use the OSI model between two hosts if they want. If the OSI model was actually better for writing software, it would be widespread already.
FWIW regarding your edit, I read your comment as faint and ironic praise. Specifically I had to laugh at, “ this is why they are so effective and so poorly thought out. I guess it's still better than "ideals" that nobody follows.”
A big source of problems with IPv6 replacing v4 is related to the same issues that plagued running the same applications on OSI protocols.
Being tightly coupled with temporary port of a temporary experimental API that happened because DoD wanted what was effectively "Emergency Capability IPv4 for Unix".
Once the broken design caused by BSD Sockets shows in one's program, it got progressively harder to fix it, especially given how ideologic the fight over APIs got. And then you had a growing installed base and vendors that lobbied against change because it cut into their profit margins, so requirement for OSI support was moved away and away.
"Good enough now" won over "won't stop working two years from now", so we built bandage over bandage over bandage.
I think it is often important for a standards group to be descriptive rather than merely prescriptive.
Prescriptivism nearly killed the W3C as they were sat around writing specs for xquery or whatever and meanwhile browsers we’re trying to add features while having backwards compatibility with themselves and trying to have compatibility with other browsers. Instead, the W3C should have been trying to codify the sort-of standards of eg quirks mode to persuade browsers to be more compatible with each other.
> he OSI model was what smart people who thought deeply about the issue decided we should do.
And yet, they came up with 2 layers of stuff that only a limited number of applications actually use (session, presentation), 2 protocols instead of one at layers 2 and 3, a much more complex layer 4 protocol. The application side of network programming would likely be much more difficult if we had used an OSI network instead of TCP/IP.
And yet, when I look at "everything over HTTP" (with occassional divergence to gRPC), it seems like most of it is crudely building missing layers of session and presentation.
Instead of reusing simple common blocks, we have tons of badly written textual parsers mired in historical details of early ASCII teletypes because the ARPA idea of protocol analyser was apparently "connect a teletype".
Many things are done over HTTP not for any particular reason of HTTP features, but because HTTP is the most accepted protocol across secured networks, and the fact that you'll easily find a package for HTTP support in almost any language you care for. HTTP is also the ultimate in portable GUI, so often you'll have an HTTP server for your product anyway, so using any other protocol besides it will add more problems.
If you try to use a new protocol over TCP, you'll quickly find all sorts of corportate networks that will drop your traffic; you'll quickly find that people are reluctant to open several ports to allow both your Web GUI and your backend protocol to talk to each other.
So at a very basic level, people aren't piggybacking over HTTP itself, they are piggy-backing onto "Most Used GUI protocol". It's true that they sometimes adopt some of HTTP's features, especially in terms of caching or common error formats, but much more often they ignore it completely (with WebSockets) or partially (binary data in POST requests with custom error messages).
Just as HATEOAS and Content-Type negotiation are extremely rarely used in application protocols, I don't think a Presentation layer would have ever caught on realistically speaking.
One road not taken could have been to define a rich document format in ASN.1 and write an application to display it, maybe call it something like "a browser".
The only ISO protocol that seems better designed than its IETF counterpart is IS-IS. Which is why it is still widely used. The spec is still hopelessly unreadable though.
This was supposed to be in the article but, I'll be honest, I wrote it over a vacation and stopped and started several times and some things got lost in the shuffle. I find IS-IS particularly interesting because, to summarize somewhat aggressively, TCP/IP first went into use basically without any working gateway protocols. So in early IP networks it was very common to use a full chunk of the OSI layer (IS-IS and CLNP) just to use IS-IS with IP prefixes shoehorned in, as the "IP" gateway protocol. OSPF is basically exactly this but formalized and running IS-IS over IP so you don't need the lower OSI layers. I'm sure there are still some IP networks out there today using the OSI stack for promulgating IP routes, it seems to still be well supported by all the vendors.
The OSI standards were thousands of dollars, I believe; a classic Big Standards move.
I think the writing was on the wall, right there. You're in college, what do you think the computer science folks are implementing and trying to improve, and teaching? Certainly not anything that cost real money, or that involved a towering bureaucracy, or language that no one could comprehend.
I remember the Arpanet flip-over from NCP to TCP, and that was a big deal. The TCP community had early experience implementing and getting stuff running at scale (for the time), with real users and expectations that things would more or less stay working.
"I hear they're moving to 42 layers, because it's a sacred number in Bali."
The transition date for TCP was Jan 1, 1983 (see RFC 801 and various other documents by Crocker, et al). I don't recall any shutdowns, though my Arpanet access at the time was limited to a dial-up TIP and some PDP-10s at MIT, and I might not have noticed. There wasn't any kind of summer holiday shutdown at the university I was at, nor at NBS (where I was interning).
The grad-level computer networking course I was taking in early '82 mentioned ISO (we used Tannenbaum, recently published, as a base text). The professor pretty much threw his hands up at all the ISO layers. "This is not how you implement networking in real life."
There's a lot to like in IPV6, as well as some things to hate. Transitions remain difficult, but seem unavoidable (sooo much software smuggles IP addresses in 32-bit ints, and changing millions of lines of code and updating database schemas to match is not very much fun).
"I have said before that I believe that teaching modern students the OSI model as an approach to networking is a fundamental mistake that makes the concepts less clear rather than more."
Oh my Jesus, this, so much this.
This was a great, well written article. Even as a network engineer, I learned some things. Never hurts to study the fundamentals.
That was a long post, saying something that I feel didn’t need as many words, but it is correct.
I learned the OSI model, and it was presented as “And THE LORD sayeth ‘LET THERE BE SEVEN LAYERS.’ And it was good...” and so forth. It was presented as “This is the way we do things.”
And I have never actually seen a true implementation of OSI “in the wild.” It was confusing.
It was useful, in helping me to look at communications in an organized fashion (I’ve written a fair bit of that kind of stuff), but in the same way that reading historical fiction teaches me about the Victorian Era.
I also learned X.400 as an exchange protocol. Folks these days, should give thanks at dinnertime that Professor Van Helsing drove a stake through that nightmare.
I normally don't mention the names of companies with which I worked in social media posts, but Dialcom has been dead a long time. I don't think it matters.
They also used PRIMOS. I worked in FORTRAN (4), PL/1, and C.
> However, X.25 had significant limitations, and was married to the telephone network in uncomfortable ways (both in that it relied on leased lines and in that X.25 was in many ways designed as a direct analog to the telephone network).
This is a bit harsh.
I downloaded Minix updates, and indeed my first Linux kernel disk images, over an X.25 network.
X.25 was one of the first packet-switching protocols - predating IPv4 by a few years - and therefore is very much NOT an analog to telephone (circuit-switched, predominantly, historically and at the time) networks. (Okay, there were VC's, let's not muddy the waters.)
I recall in the early/mid 1990's a colleague hunting down a weird X.25 network utilisation pattern, where a customer was establishing and tearing down connections at a rapid rate of knots. Details are fuzzy, it was a long time ago, but IIRC the customer had worked out how to embed payload in the connection establishment header, but at the far end was refusing that connection (while ingesting the payload). Billing was done based on connection establishment and subsequent transfer. Great (loophole) success, etc.
TFA touches on SNA (IBM's System Network Architecture) but doesn't seem to attribute as much blame to it as I believe we should. SNA was, coincidentally, a 7-layer model. The obvious distinction, to modern minds anyway, is the hierarchical vs peer relationship between entities on a network. (An interesting question to ask graduates is to define a network -- this historical view disparity is objectively fascinating in the contemporary context where peer addressability is an assumed function of same.)
> The X.509 certificate format and concepts are directly used today by TLS and other cryptographic implementations, including its string representations (length-prefixed) which were a decent choice at the time but now quite strange considering the complete victory of null-terminated representations.
Er, what? What network protocols even use nul-terminated strings?
Even if this is referring to programming languages’ native string types, nul termination only won in C, while just about every other language uses some kind of explicit length encoding.
Indeed, and between buffer overruns and "accidental quadratics", null terminated strings gaining widespread adoption in core system APIs are probably the biggest and most expensive mistake of computing industry.
For a useful introduction to network layers, Radia Perlman explains the actual layers and how to think about them pragmatically: https://youtu.be/qXz_RxBFQ20?t=496
The part about CSMA reminded me that as an educational model, a lot of what can go right, or wrong with an 802.11(abgn/ac/ax) network is at what we would call layer 2. If you've ever seen an environment that's a CSMA hell of -70 noise floor in 2.4 GHz and devices stomping on each other, or a poorly configured "mesh" network, that's all layer 2. Thinking about things like, how are your design constraints different when dealing with a half duplex/TDD air medium, vs something like a traditional FDD point to point microwave radio?
But then as a mental model in order to understand that, it's important to think about the layer 1 of what the wifi radios are doing: Questions such as, why is this Comcast 802.11ac home router running in an 80 MHz channel, stepping on this other device that's also trying to run in the same 80 MHz channel? Why did somebody install a unifi AP with a torus shaped RF pattern vertically on a wall, instead of horizontally on a ceiling as it was intended?
"ceiling mount" in the name always on ceiling, "wall mount" on wall, "directional" in the direction you want, if not specified horizontal on a table (ceiling mount acceptable). If there is going to be a dead zone in the omni pattern it's generally the "back" (where most other stuff is like ports and power). On ceiling mount the back will be able to go straight up into a ceiling, if the back is just one of the smaller sides then it's definitely meant to sit on a table.
what model do you have? If it's an all-in-one router like a HAP AC, it should be horizontal, best coverage would be if it were flat on a wood shelf or similar.
Aren't Mikrotik part numbers just the most amazing things? For something like that, the antennas are omnis, the RF pattern coming off each one is an oval. Mostly vertical and maybe with the ones at the sides a bit at an angle is a good choice.
Visualize if you were to take a pencil and skewer it lengthwise through an oval shaped fruit, the fattest part of the fruit would be the highest gain part of the antenna's RF pattern.
Agreed. To take it further, the OS APIs suck for protocol selection too. And router technologies. And basically everything.
E.g. in theory your router should work with level 3 and below. This includes the firewall. However, try to implement a new Level 4 protocol and all of a sudden your packets won't route.
This was the whole point of this separation - that while UDP and TCP are useful in general cases, there are much better and novel ways to frame packets for e.g. cust infrastructure with different properties and different requirements.
But it simply doesn't work.
This stuff has driven me nuts for decades. OSI has rarely been helpful aside from just general communication of ideas. It shouldn't be used as any authoritative reference, ESPECIALLY not in classrooms.
> E.g. in theory your router should work with level 3 and below.
If you look at the configuration on a typical small but powerful router (I'll use a Juniper MX204 for an example), of course it's doing things at both layers 2 and 3. It's a useful model to define what is going on with various ethernet switch fabrics, before you try to understand how it's set up at layer 3. At layer 2 you could have a 100GbE interface that carries a vlan trunk going to a 1RU 48-port switch physically adjacent to the mx204, to create local subinterfaces on the router to 10Gbps PNI peers, to downstream colocation/datacenter customers, etc.
That's all traditional "layer 2" ethernet stuff. Then your logical subinterfaces themselves are configured as BGP peers, which is of course layer 3.
Understanding the model of your theoretical MX204 you've got:
layer 1: AC or DC power, cabling, fans, physical mounting, serial console cables
also layer 1, but has an impact on how you can configure stuff at layer 2: Does this port have a short reach 100GbE CWDM4 interace in it? Or a longer reach coherent? Maybe this 10GbE port has a 1490/1550 bidi single strand in it?
layer 2: Ethernet configuration in all its myriad ways. And also things like P and PE MPLS configuration to carry a layer 2 circuit between places over your layer 3 network. Configuration for ISIS would also go in layer 2.
layer 3: bgp, ospf, all the typical "router" stuff.
I believe the parent isn’t complaining that routers do things at layers 1-3, but that they also do things at layer 4 (namely, block anything that isn’t TCP or UDP).
Isn't this just a naming issue, though? I remember initially being confused by "switches" doing layer 3 stuff and "routers" doing layer 4 stuff, but over the years I've just learned to revise the definitions in my head; now I consider "router" to be a box that works on most layers (up to all of them with a sufficiently smart router), and "switch" to be just a cheaper router with more Ethernet ports.
Layers seem OK for dividing protocols, but networks tend to be managed across all layers, so it's understandable all that functionality gets put in a single device - possibly internally structured one. I'm not a network engineer, but what I understand from the admin panel of my Mikrotik router is that the mental model here is a bunch of virtual devices, each working on one of the layers, packaged into one physical box.
In terms of equipment capabilities we most certainly have switches that have sets of layer 3 capabilities, even a ten year old cisco 3750x can do basic OSPF, BGP, EIGRP etc. Often referred to as an enhanced or layer 3 switch.
But you for sure wouldn't call it a router because it has nowhere near the routing table RAM, routing ability, or full set of routing configuration parameters as you would want to use on a dedicated purpose router.
For your mikrotik, if you open it up or if you look at someone's teardown of one, what you'll see is a set of gigabit ethernet switch chips (perhaps 1 ASIC per every 4 ports) under heatsinks, that have purely layer 2 feature sets only. And then one CPU that runs the mikrotik routerOS which does layer 3 things. The mikrotik will have different levels of performance in packets per second capability for traffic flows that stay at purely layer 2, and another level of capability in Mbps and pps at layer 3. The OS on the mikrotik knows how to tell the switch chips how to do things at layer 2 (define this vlan, define this trunk, group certain ports into the same fabric, do 802.1x stuff, etc).
Aside from extra hardware, routers generally have a firewall built-in and can perform NAT translations and otherwise act as a gateway. They do DHCP in most cases, too. Of course when you start to look at enterprise setups things get a little more complicated.
Since routers act as gateways, they have their own IP address too.
Switches are not gateways. They join two physical segments and mask them as a single logical segment. They do routing only in the most basic of senses - moving packets between the physical lines.
My work involves writing software for big routers and switches used by ISPs, data centers, campuses, etc. and I can guarantee you that a router will 100% switch/route your exotic packets with an unknown L4 protocol number. It literally does not care about anything past the IP header.
There are a few things I can think of that may have led to your experience, one of them is NAT. Well, NAT just sucks. It is the reason why I want IPv4 to die. Just getting rid of NAT will be worth the pain of switching to IPv6.
> E.g. in theory your router should work with level 3 and below. This includes the firewall. However, try to implement a new Level 4 protocol and all of a sudden your packets won't route.
If you’re talking about something that is just routing and not doing a higher layer operation like NAT then routers don’t care about layer 4. The huge routers running the Internet backbones absolutely don’t care about layer 4 protocols and support arbitrary L4 protocols.
What you’re thinking of is normally sold as a “home router”, which is actually a NAT device that is only a router in the most basic sense (has directly connected interface routes and a default route). NAT is the thing that breaks the transparency because it has to modify and track layer 4 protocol fields in order to disambiguate all of the traffic coming into the single IP address you get at home.
I make a lot of use of "Layer 3 switches" and I try to always say that with scarequotes, along with "smart firewall" and "router". For a lot of reasons, some good and more bad, network vendors have mostly abandoned the tidy separation of concerns often taught in classes. I still say "SCTP is the future" in the voice of a professor who repeated this endlessly, and the failed adoption of SCTP is a big symptom of the practical difficulties actually posed by the layer model.
Far more common today is to handle unusual "L4" protocols by tunneling them, which leads to another increasingly common situation that teaching via the OSI model does not prepare students for: "L2" protocols tunneled back through an "L3" protocol. Or in telco networks usually, through a different "L2" protocol (MPLS, ATM, pick your poison). These are all things that the layered network model empowers us to do, but the "OSI-first" teaching approach, at least as I have seen it, mentions scarcely or not at all.
Not sure what you mean, this separation does exist in routers we have today. A router that forwards packets based on only the destination IP address wouldn't care about your fancy new L4 protocol at all. Most ISP routers would be capable of this.
It would not be possible with most SOHO routers because they use NAT which mostly only compatible with TCP and UDP (though a more advanced SOHO router is capable of doing 1:1 for other L4 protocols).
I actually found the OSI Reference Model to be incredibly helpful both as a student and later in my work life as an operations engineer. I was able to successfully break problems down in a methodical layer-by-layer approach to troubleshooting and find the root causes and solve extremely esoteric and difficult problems that other people, including very smart talented engineers, were completely stumped by. This wasn't because I was smarter or knew some secret, but because breaking problems down into smaller pieces and identifying and learning tooling to examine those problems in isolated pieces makes it easier to find the actual cause.
While it is very true that the OSI Reference Model doesn't map to real life systems exactly, it's still a relatively accurate view with a little bit of hedging as to what layers something might fit into. Additionally many of the protocols that were built for OSI networks have been adapted and implemented on top of TCP/IP networks and are extremely valuable in some circumstances at global scale, because the telecoms people designing these systems /thought about/ global scale from the get-go, where-as it was mostly an afterthought for later computer systems researchers. X.500 in particular is a fantastic protocol, that while convoluted and esoteric, enables some very complex replication topologies while providing strong guarantees that are simply not possible in lighter weight protocols. When thinking deeply about identity management and authentication, X.500 is not a bad thing to fully understand, even if you end up implementing a lighter weight protocol, because while "over-engineered" it's well thought out.
That said, ASN.1 notation is a hellacious curse and should have been burned and buried in the pit it came from before it ever saw the light of day. Unfortunately, it's a key component of nearly all the X. series standards built on top of OSI.
The best critique of the OSI layer model was the classic "To Hell with the OSI 7 Layer Model" post. It has disappeared from the current internet, with the exception of essay sites that stole it and now want money to reproduce, but the Wayback Machine remembers:
I'm sorry, I've progressively improved the site behavior on mobile but the ASCII art is the one thing I haven't been able to figure out without compromising my "values" :)
I could probably do something with CSS to swap it for a version that isn't sensitive to reflowing. I'll put it on the todo list.
(Some extra stuff is needed to hide the scrollbar. Apparently there's no way to make it appear only when needed, duh. Oh and the last line should probably have wrap enabled to show the links.)
The real problem was the core concept of isolating knowledge, i.e. Layer 2 doesn't know anything about layer 3. That's a flawed concept. The trivial, yet essential protocol ARP break the OSI model, for example. And then there's firewalls...
I think I've said this before on computer.rip, maybe not, but I've joked that "ICMP is original sin" as it's kind of the start of a whole set of consistency-breaking aspects of the IP stack - ARP is another one. I still think layers are a useful concept but yes, it's clear that believing in them too much will get you in trouble. In practice developers have seldom hesitated to violate the layer boundary if it's convenient.
And that's why, almost 40 years later we have another HN front page post [1] right now saying the NMP package netmask, used by more thank 250K apps to handle all the esoteric standard conventions for notation in IPv4, this microservice got a few edge cases wrong and so everyone needs to update !
The quote, "All models are wrong, but some are useful" comes to mind. The OSI model is useful but far from perfect. But you'd be doing students a disservice if you don't teach them about it at a minimum because the OSI model is part of the networking vernacular.
I think there are good arguments to be made that the OSI model has too many layers to be useful. My favorite description of the IP networking model is that IP is the "narrow waist" of internet protocols. Lower levels can vary and upper levels can vary, but IP remains constant (which is why IPv6 is such a nightmare whereas all the other protocols below and above IP have changed significantly with less effort).
The main utility the OSI model has served me is being able to recite it for job interviews.
More honestly, though, I think the OSI model can be used very constructively in teaching by contrasting it with IP. IP is simpler and also less feature-rich; you can learn a lot about IP by noticing which aspects of the OSI model were "left out" from IP (putting it that way muddles the timeline but probably also isn't that inaccurate) and how it varies from what was designed at one point as a "complete" protocol set. But this is all a part of my larger philosophy of a "historical approach" to teaching networking. It's not too uncommon for instructors to do this by discussing X.25 and/or ALOHA early on and then comparing/contrasting IP, but for whatever reason it is typical to introduce the OSI model alongside IP without the historical context of what the OSI model is and isn't useful for today.
I find OSI layers 1-3 to be fairly descriptive of how things usually work today. Layers 4-7 are worthless as real systems are not necessarily structured that way.
The OSI model was created by telecom people, not computer people. This is important because the two groups have radically different views of what networks are for and how they work, to the extent that they spent a lot of the 80s and 90s talking past each other.
In the telecom world at that time the fundamental unit was the "circuit", meaning a two-way voice telephone call. The upper frequency limit of a voice circuit is 4kHz, so the Nyquist criterion said that digitising a voice circuit required 8,000 samples per second. The required signal to noise ratio fit nicely into 8 bits, so a digital circuit was 64,000 bits per second each way, with strong real-time jitter and latency guarantees (because, voice).
If you weren't using the link for a while you still had to pay for it by the second because you were getting the guaranteed 64,000 bits per second all the time; that bandwidth was reserved for your use and nobody else could mop up the spare. Meanwhile the correctness of the received data was best-effort because the odd corrupt bit isn't an issue in a voice circuit. If you wanted more bandwidth then you could pay for multiple circuits to the same destination.
In telecoms all the intelligence goes into the exchanges; the phone is merely a dumb end-point. If you want services like call forwarding you type numbers into the phone, but all the application software lives at the exchange.
If you talked to telecom engineers about the future, they would talk about video calls. They would be just like phone calls but with higher bandwidth.
Meanwhile the computer people needed the exact opposite to what a voice circuit provides. If you send a file another computer you need it to arrive bit-for-bit accurate, but you don't much care about bandwidth and latency. While a physical pipe has a certain capacity, you don't need or want to reserve bandwidth on it, you just want the data to move as fast as physically possible.
So telecom people wanted to provide a smart network connecting dumb end-points, with guaranteed bandwidth and latency with best-effort correctness, while computer people wanted to connect smart end-points to a dumb network that provided guaranteed correctness but only best-effort bandwidth and latency.
Things got worse when the Web started being used by people at home. Now most of the data was flowing in one direction, but circuits were fundamentally about equal bi-directional communication. So now half of that expensive bandwidth was being wasted.
The "adults in the room" attitude of the telcos didn't help; they had over a century of experience running international telecom networks and thought they knew how to do it. Therefore they weren't interested in the opinions of those hairy computer guys.
For more on this, read "Mother Earth, Mother Board" by Neal Stephenson.
I often mention that the general philosophy of telephone engineers is "hilariously complicated." But of course that's a bit unfair, there are good reasons telecoms people did things the way they did. It's important to understanding modern computer networks, I think, to observe that reliability and proactive traffic engineering were top priorities for the telecom industry but to a large extent an afterthought in the computing industry. Traffic engineering especially, management of overloaded links and etc, is often an "emergent property" of computer networks, while it was very much by intention in the telephone network where link reservation and etc. are common practices.
As computer users, every day we live with the pros and cons of this difference in philosophy. Our network links are much faster but much less reliable than they would be had, e.g. the ISDN vision which I've mentioned before on computer.rip gained more traction. For a long time applications like video conferencing and newsgathering stuck to ISDN rather than the internet because of the "cons" in the tradeoff. You imagine a world where, say, an online video stopping to buffer is as rare as a kernel panic, but you've also got to check if your internet subscription covers a reservation of that size.
Come judgment day I think there is guilt on both sides, telecom people broadly did not foresee the huge capabilities of "opportunistic" (e.g. contentious) network utilization, but computer people broadly did not foresee the demands of real-time media over computer networks. Despite AT&T's dedicated but haphazard efforts through US vs. AT&T, the telephone industry did not gain serious traction in the nascent world of computers, and then computers took over telecom, and so we all just sort of live in the world of contentious networking now and it's hard to imagine it a different way.
Does anyone have book recommendations for like a complete covering of how we get the lower layers working for networking? I believe I understand stuff in isolation but every time I read a full thing I get a lot into “wait but why am I not worrying about packet ordering issues when doing random socket stuff with Python” style existential dilemmas
Thinking of something that might be equivalent to “NAND to Tetris” for networks. I want to know how the wires work fully!
The data on the wires really varies too much to cover like a nand2tetris where you can walk through one way to do it from the ground up and call it good. Generally if there is a way to transmit data it's possible and probably your socket could go over it or some combination. Even taking a narrow scope such as "copper cables carrying ethernet" leads to various collision algorithms, encodings, wire counts, and optional components like PoE to consider and that's not counting "copper cables with something else that can transport encapsulation ethernet data efficiently".
Generally though you really don't care about how the data gets on the wire (I mean it's definitely interesting but it doesn't help you any more at a practical than thinking about what happens at the ethernet frame layer).
Also when it comes down to it not only is the physical encoding wildly different most each step of the way but it's not even ethernet. I.e. the only thing that matters are the guarantees of the socket interface, not the guarantees of what it rides over. The socket may ride over some transport which guarantees in order delivery and no congestion or it may ride over some transport which guarantees nothing, not even in order delivery. What matters is what the socket guarantees, e.g. is it a TCP socket provided by the OS where the OS guarantees it'll reassemble, handle loss, handle out of order, etc for you or is it something like a UDP socket which leaves most of these up to you (or a raw socket where the OS really isn't doing much of anything for you).
That being said if you want to pick a single example just to walk through it bottom to top one time pick 1G RJ45 copper between two PCs which have a TCP session going. There isn't really a need for a book, just the Wikipedia articles on gigabit Ethernet, IPv4, and TCP. It's just that this isn't always the stack so it doesn't really matter what Ethernet/IPv4 happen to give you - all that matters is what the TCP socket says it's going to guarantee.
I don't have good recommendations for a book, but I can recommend spending a few weeks implementing it. libpacp is probably the easiest way to send and receive raw ethernet frames, and you only need to implement ARP, IP, and TCP to have something not unlike telnet.
ARP and IP are fairly easy to implement, and TCP is as well as long as it doesn't need to be fast (e.g., live with a fixed and smallish window size, discard out-of-order packets, don't bother with selective ACK, etc).
> Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle.
So true. Worse, it's useful to use an expression like "down below layer 3" knowing it's a rough metaphor; yet that credence gives credibility to what turned out to be a muddle headed idea.
yes! It's so helpful to make colleagues understand that encryption is not the job of the application, and that authentication is not encryption, is also delegated to a lower layer protocol.
I am truly curious what critics of the OSI model propose as catalyst for such conversations.
I disagree about it not being a useful model for teaching stuff. In particular as a facilities based ISP, you have to care about what the OSI layer 1 is, because ultimately an ISP is built out of real world physical things.
The article seems to skip over concerns about layer 1. But if you have no understanding of how things are engineered at layer 1, or of the possible failure modes, all sorts of bad things can happen. Or you'll end up buying the wrong thing, or getting bamboozled by equipment vendors once they realize you're not paying attention to the layer 1.
People not understanding layer 1 are how things happen like an ISP sending out somebody to try to install a 10GbE 1310nm/LX circuit to a piece of equipment that was shipped with a multimode SFP+ in it.
Engineering of large complex backbone systems encompasses the overlap between layers 1 and 2. For instance all of the optical engineering that goes into a inter-city DWDM system is "layer 1" - but those same DWDM chassis have 10/100GbE short reach layer 2 transport circuits hanging off of them, to connect to your own ISP's or customers' ISPs' network equipment. Then the controller card in your DWDM system is likely running some form of embedded Linux and has a 100BaseTX/1000BaseT interface in it with an IP address in a management network, it can have an snmpd on it that exposes a set of OIDs to poll by network monitoring gear, it runs an sshd on it it, etc. So you've got layer 3 and layer 4/5 stuff going on in that same 10RU DWDM box which needs to be taken into account in your network design. Maybe you have a system somewhere which periodically retrieves a text dump of the entire configuration of the DWDM box, whatever its equivalent of a 'show run' is, and stores it in git? That's all layers 4-7.
In the modern all-ethernet world, tons of possible configuration parameters for exactly how the 10 or 100GbE handoffs are set up on each side. And various configuration parameters. Ever encountered somebody who mistakenly ordered a 10GbE WANPHY circuit when it should have been LANPHY, or vice versa? That's an example of why an understanding of the underlying layers of what you're working on is important.
Only once you have a good solid grasp of layers 1 and 2 can you begin to properly architect your network at layer 3.
One thing that I do try to repeat as often as possible, if helping to train NOC and junior neteng people, is that things get very blurry between how software is set up at layers 4-7. The same piece of software that might be doing things at what the OSI model would call layer 4 may also have a end user GUI/presentation/operator interface that would be defined as layer 7. I do not think that mentally imagining rigid definitions between layers 4-7 is very useful these days.
I personally think that as a method of understanding network architecture, the first level of layers 1-3, and 4, are much more useful than the blurry "4-7" model.
Every time someone says the 7 layer OSI model is actually good for teaching they go on to describe teaching the TCP model instead where you have:
1) Link (physical)
2) Internet (IPv4 or IPv6 these days)
3) Transport (UDP or TCP or whatever)
4) Application (stuff handled by the application logic)
Which is precisely what people mean when they say the OSI model is bad to teach. It's not that using a layered abstract model is bad for teaching it's that the 7 layer OSI model is bad for teaching.
I think it's a bad idea to teach people "layer 2" is the Internet, (tcp/ip, ipv4, ipv6, udp, icmp, etc).
People doing stuff with networks need to be aware that the physical (layer 1) is its own distinct thing from layer 2: the link layer network (such as Ethernet fabrics, ethernet as wifi, SDH/SONET transport systems, whatever sort of network accomplishes the purpose of putting multiple devices on a fabric where they can talk to each others' NICs).
Nothing says you have to run IP over an ethernet switch and a group of things that can arp each other - you could very well run something as weird as novell netware or your own custom software stack. The link layer is exactly that, a link layer, it's most often used with IP but not as an absolute. Understanding that the link layer exists underneath and does things independently of the IP network is important.
In an opposite example, you can build an IP network out of two devices that are adjacent to each other over a SDH/SONET network, and there's no Ethernet anywhere. Something as simple as two routers with OC192 interfaces sitting next to each other on a test bench with a fiber patch cable between them, as a BGP adjacency.
The interesting part here is that the consumer's layer 1 is actually a virtualized layer 4-5 on the ISP's side (and maybe even 6 if you include FBI watching your packets).
It blew my mind when I realized that the difference between malware and "military grade" malware is just that they target exactly those token ring'ed devices, where they try to craft network packets where they know that the implementation is gonna fail in the parsing process.
Once you realize that and the underlying containers that come with it, you can efficiently redteam anything. Cisco deep packet inspecting switches? VLANs? VPNs? No problemo, they got an outdated linux on there, too. And they usually don't have the RAM to compensate for buggy implementations either.
You're missing the point. Yes, understanding the different layers involved in a network is important. But the OSI model is the wrong way to explain those layers, because it's a different network/software architecture from the one which was implemented in the Internet. The "blurriness" you're referring to in layers 4-7 is literally because those layers are describing software which was never written.
Oh, absolutely agree on that, trying to actually make the OSI model as it was intended a real thing in real life would be an utter exercise in futility. I was thinking purely of how the OSI model concepts can be mapped to things we have built and use now on LANs and WANs, as an educational/mental model concept.
I do think the upper layers are reasonable as long as you condense them down into transport and application layers. Transport has historically been either UDP or TCP, but I think a better definition is a layer which provides "meta" level guarantees. Under that definition TLS is also a transport technology (providing encryption) and even HTTP could be part of the transport layer since it can provide automatic caching and the ability to be used from the browser (kind of a tautology, but significant since the browser has become so important).
I don't really object to the first 4 layers of the OSI model as applied to the current network stack - it's a pretty useful model of the separation-of-concerns between, say, Cat5, ethernet, IP, TCP.
The biggest thing I would point out here, which I only mentioned briefly in the article, is the division of layer 2 into the MAC and the LLC "sublayers". This is received wisdom today that is frequently repeated in textbooks and courses, but this whole concept of "sublayers" was invented (and then formalized into standards!) to resolve the OSI model's poor correspondence to many non-OSI technologies like Ethernet II and 802.11*. Not only does the OSI model have "too many" layers, it also has "too few". So this is a major way in which the OSI model is not some "idealized" or "genericized" model like people often claim, but rather an alternative model that is sometimes similar, sometimes different from TCP/IP.
It reminds me of the taxonomy of living things. The 8 levels (Domain, Kingdom, Phylum, ...) are useful at the top, but break down fairly quickly as we've learned how complicated life really is.
The last plant I looked up (Wisteria) doesn't really have a useful phylum or class classification, and has 7 non-mappable "clade" groups of which it is a member. They still teach the 8 levels though.
That article starts with a mistake, historically OSI was created after TCP/IP so it's more OSI that is based on tcp/ip by extending it to a generic network architecture
This was a very busy period in the history of computer networking, and many things happened at the same time, which can make it hard to make any statements about "x is based on y." The OSI model is most definitely not based on TCP/IP or vice versa. While TCP/IP was generally an earlier effort there were revisions being made to TCP/IP at the same time that the OSI model was being designed, and TCP/IP did not become the clear leader in computer networking until after the completion of the OSI work (arguably not until as late as the mid-'90s depending on how you feel about the issue of "WANs" vs "LANs" which often took different paths in the '80s). For most purposes they were parallel efforts, and the designers of the two were each aware of the other but mostly working off of different prior art.
This further makes the point that many of the differences between TCP/IP and the OSI model were very intentional choices, as the OSI designers were well aware of IP and viewed it as unsuitable while the adopters of IP were judging the OSI model to be impractical.
The article doesn't say that OSI was created before TCP/IP. It says that X.25 was created before TCP/IP, and that OSI is an abstraction of that particular design (and thus doesn't map neatly to the IP stack).
My main takeway was: Thank god the internet won, OSI was some badly specified eldritch horror. RFC1006 was the only spec that seemed more or less readable by a human being.