On "the OSI deprogrammer"

[fanf]

https://dotat.at/@/2024-03-26-iso-osi-usw.html

Back in December, George Michaelson posted an item on the APNIC blog titled "That OSI model refuses to die", in reaction to Robert Graham's "OSI Deprogrammer" published in September. I had discussed the OSI Deprogrammer on Lobsters, and George's blog post prompted me to write an email. He and I agreed that I should put it on my blog, but I did not get a round tuit until now...

The main reason that OSI remains relevant is Cisco certifications require network engineers to learn it. This makes OSI part of the common technical vocab and basically unavoidable, even though (as Rob Graham correctly argues) it's deeply unsuitable.

It would be a lot better if the OSI reference model were treated as a model of OSI in particular, not a model of networking in general. OSI ought to be taught as an example alongside similar reference models of protocol stacks that are actually in use.

One of OSI's big problems is how it enshrines layering as the architectural pattern, but there are other patterns that are at least as important:

• The hourglass narrow waist pattern, where a protocol stack provides a simple abstraction and only really cares about how things work on one side of the waist.

  For instance, IP is a narrow waist and the Internet protocol stack only really cares about the layers above it. And Ethernet's addressing and framing are another narrow waist, where IEEE 802 only really cares about the layers below.

• Recursive layering of entire protocol stacks. This occurs when tunnelling, e.g. MPLS or IPSEC. It works in concert with narrow waists that allow protocol stacks to be plugged together.

  Tunneling starkly highlights what nonsense OSI's fixed layers are, leading to things like network engineers talking about "layer 2.5" when talking about tunneling protocols that present Ethernet's narrow waist at their endpoints.

Speaking of Ethernet, it's very poorly served by the OSI model. Ethernet actually has three layers:

• PHY (cables, MAU, SFP)
• MAC (AUI, MII)
• LLC (LLDP, LACP)

Then there's WiFi which looks like Ethernet from IP's point of view, but is even more complicated. And almost everything non-ethernet has gone away or been adapted to look more like ethernet...

Whereas OSI has too few lower layers, it has too many upper layers: its session and presentation layers don't correspond to anything in the Internet stack. I think Rob Graham said that they came from IBM SNA, and were related to terminal-related things like simplex or block-mode, and character set translation. The closest the ARPANET / Internet protocols get is Telnet's feature negotiation; a lot of the problem solved by the presentation layer is defined away by the ASCII-only network virtual terminal. Graham also said that when people assign Internet functions to layers 5 and 6, they do so based on the names not based on how the OSI describes what they do.

One of the things that struck me when reading Mike Padlipsky's Elements of Networking Style is the amount of argumentation that was directed at terminal handling back then. I guess in that light it's not entirely surprising that OSI would dedicate two entire layers to the problem.

Padlipsky also drew the ARPANET layering as a fan instead of a skyscraper, with intermediate layers shared by some but not all higher-level protocols, e.g. the NVT used by Telnet, FTP, SMTP. I expect if he were drawing the diagram later there might be layers for 822 headers, MIME, SASL -- though they are more like design patterns than layers since they get used rather differently by SMTP, NNTP, HTTP. The notion of pick-and-mix protocol modules seems more useful than fixed layering.

Anyway, if I could magically fix the terminology, I would prefer network engineers to talk about specific protocols (e.g. ethernet, MPLS) instead of bogusly labelling them as layers (e.g. 2, 2.5). If they happen to be working with a more diverse environment than usual (hello DOCSIS) then it would be better to talk about sub-IP protocol stacks. But that's awkwardly sesquipedalian so I can't see it catching on.

Comments

[graydon2]

Disclaimer: not a Networking Person.

I wonder how the "narrow waist pattern" differs from the general (very widely practiced) notion of information hiding / abstraction in computing more generally. I think most fields of computing tend to treat it as the key to controlling complexity, enabling modular decomposition and verification, and interoperability / interchangeability. Is there something different about the way it works in networking?

In general I agree with Graham's "OSI Deprogrammer" doc (as much of it as I've read so far) that teaching a simple "network-on-network" model (or "protocol that both carries payload for those above and is payload for those below") is better practice, and sorta relates to what I was asking above: it feels to me the core of his point is just to teach the general concept of an abstraction -- with things it assumes and things it provides given those assumptions are satisfied -- and that's a good enough concept on its own without dressing it up in references to OSI or unified 7-layer-burritos with separate globally-preordained functions. Seems right to me! I mean, we wouldn't teach general computer-system or program design with a predetermined numbered set of abstractions (unless we adopted 12-factor applications, ha!)

Re: terminals, I think a lot about ARPANet getting started because Bob Taylor had to have 3 different terminals in his office to talk to 3 different remote computing sites. Of course the lower level protocols also had to be made to agree, but so did the terminals!

[fanf]

I think the narrow waist pattern adds a couple of things to the general notions of abstraction and information hiding:

• It’s narrow in the sense of being fairly minimal, as discussed in Saltzer, Reed, Clarke’s “end-to-end arguments in system design” - but this also fits Outsterhout’s guideline that APIs should be narrow and deep.

• It’s narrow in the sense of being a single protocol, in contrast to the many protocols in the layers immediately below and above. OSI did not have this property, e.g. it had both connection-oriented and connectionless protocols in its network layer.

For a curriculum to be about networking, it needs to be a lot more specific than teaching the general concept of abstraction. Like, which abstractions are successful in networks and which are not? What are the common patterns students should understand so that when they encounter a new networking protocol, they can more easily grasp how it works and how it fits in with other parts of the stack?

The cause of this discussion is that there isn’t a good vocabulary for talking about networking protocol stacks in abstract terms. Or at least the IETF and IEEE don’t have one that could displace OSI. I sort of hope that it might be possible to adapt much of the existing vocabulary into a pattern language without the baggage of an obsolete and maladaptive architectural framework.

Anyway, thanks for the interesting comment :-) Makes me glad I finally posted this, even 3 months after I wrote it!