RFC 873

RFC 873: The Illusion of Vendor Support 🦋

Author: M. A. Padlipsky, The MITRE Corporation, Bedford, Massachusetts Date: 12-Aug-83, 11:44 AMW Companion pieces: M82-47, M82-48, M82-50, and M82-51

---

Abstract ✨

Okay bestie, the big claim here is that the idea of waiting around for "vendor supplied" intercomputer networking protocols built on the International Standards Organization's Reference Model for Open System Interconnection is, um, not it. The paper argues this is especially true compared to protocols built on the ARPANET Reference Model (ARM), and it's shown to be fallacious. 💅

This paper is a companion piece to M82-47, M82-48, M82-50, and M82-51. 🌸

---

Introduction

Okay so even a couple of members of the DoD Protocol Standards Technical Panel are on board with the vibe, and so are some members of the DoD Protocol Standards Steering Group, plus (apparently) somebody at the GAO 👀. Everyone wants to "go with vendor-supported intercomputer networking protocols instead of using our own." The author's take on what that means should be clear from the title, honestly. 🙈

But here's the thing: the desire is totally well-meant! It's about saving the Government money, which is lowkey iconic. So what evidence is there that would make it so stigmatized? That's the tea we're spilling. ☕

---

Scope

First, we have to figure out what "vendor-supported protocols" even means. 🧐 It can't be just X.25, because that only gets you through the network layer. That's true whether you're looking at the International Standards Organization's widely-publicized Reference Model for Open System Interconnection (ISORM) or the unfortunately rather tacit reference model (ARM) that the ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed to. It's giving incomplete. 💀

It also can't be just X.25 plus X.28/X.29 (even with X.75 tossed in to handle "internetting" and X.121 for addressing). Why? 🌈

1. They don't serve as a protocol suite for resource sharing (also known as OSI). They only allow for remote access [1].
2. They come from the Consultative Committee on International Telegraphy and Telephony, and they include one or two other protocols, in reality. They don't even make up the full protocol suite being worked on by the U. S. National Bureau of Standards, let alone the somewhat different suite ISO is evolving. 😭

So it has to be a suite from NBS or ISO. For what we're doing here, we don't need to tell them apart, because their Reference Models are close enough to be shorthanded as the ISORM. ✨

---

Timeliness

Okay, so once we accept that we're talking about an ISORM-related protocol suite as what the vendors are expected to support, one big consequence comes up that can kind of dominate everything else I'm about to say. 🚨 The DoD procurement process has really long lead times. And the ISORM suite is by no means complete right now. 🐢

Without getting into its merits or demerits, only X.25 (as levels 1-3, and with some ambiguity about what level X.75 belongs at) is firmly in the ISORM suite (which it'll be convenient to call "ISORMS"). Even that's kind of shaky. A British observer at a recent PSTP meeting told the author, "We in the U.K. don't believe X.25 is officially part of the ISORM." Honestly, same. 🇬🇧

There are proposals that have been floating around for a while at Level 4. There are others that are less far along through the international (or even national, remembering NBS) standardization process, covering Level(s) 5-7. Here's the catch:

1. These are by and large "paper protocols," meaning they haven't been tested with actual use. 📄
2. Even ISO and NBS's warmest supporters admit the standardization process "takes years."

So if the DoD wants to avoid buying what might turn out to be a series of pigs in a series of pokes, it can't wait for the ISORMS. 🐷

On the other hand, the DoD is letting intercomputer networking contracts right now. And right now, there actually is a suite of protocols designed to the ARPANET Reference Model. It's called ARMS, with no pun intended 🙃. Implementations of the ARMS already exist for a number of operating systems the DoD already uses.

Now, it's not being argued that the ARMS protocols come "for free" in upcoming acquisitions. Contractors fuss about the style of the available specifications, and system maintainers fear incursions of non-vendor supplied code into operating systems, and so on. But it's unarguable that the ARMS can be procured significantly more rapidly than the ISORMS. ⚡

It's also unarguable that people who talk about their unwillingness to see the DoD "develop new protocols rather than employ international standards" haven't done their homework. We're not talking about new protocols in the ARMS. We're talking about protocols that have been in real use for years. 📚

---

Quality of Support

Okay, but the timeliness argument can come back with a counterargument: that the ISORMS is "worth waiting for." So we're not done yet! 😤 Let's look further at what "vendor support" actually means. Clearly, the people making this argument expect that vendors' implementations of protocols will conform to the Standards for those protocols. But given the nature of these specifications, what can we infer about the quality of support we can expect from vendors? 🤔

Two problem areas are immediately obvious: ambiguities and options. Let's take ambiguities first. Here are some of the questions knowledgeable observers have raised about the present state of the ISORMS:

1. Can an X.25 comm subnet offer alternate routing? The answer depends on whether "DCE's" are expected to follow X.25 between themselves. It gets even messier because some ISORM advocates don't include the Data Communication Elements in their depictions of the Model. That leads to the metaphorical question "Are there parking garages between the highrises?" 🏢 If you can conform to X.25 and not offer alternate routing (which certainly appears consistent with the spec, and might even be construed as required by it), then the DoD's inherent interest in "survivability" can't be served by you. 😬
2. Can an X.75 internet offer alternate gatewaying? The answer is almost surely no, unless the X.75 spec is re-written. If not, again the DoD's interest isn't served.
3. Does "Expedited Data" have semantics with regard to the L4-L5/L7 interface? (Not as I read the spec, btw.) If not, the ISORMS lacks the ability to convey an "Out-of-Band-Signal" to an Application protocol. This leads to the metaphorical question, "What good is an SST if there's nobody on duty at the Customs Shed?" 🛃
4. Do all layers have to be traversed on each transmission? There are rumors of a new ISORM "null-layer" concept. It's not in the last version the author looked at, though, and apparently the answer is yes for now. If so, the DoD's inherent interest in efficiency/timeliness can't be served. This leads to the metaphorical question, "Are there elevators inside the highrises, or just staircases?" 🪜
5. Can an implementation be in conformance with the ISORM and still flout the prescription that "N-entities must communicate with each other by means of N-1 entities"? (Not as I read the spec.) If not, implementations must be inefficient, because the prescription is an inappropriate legislation of implementation detail that can only lead to inefficient implementations. 🙄
6. Is each layer one protocol or many? The point quoted in 5 would seem to imply the latter, but many ISORM advocates claim it's the former, except for L1 and L7. If each layer is a "monolith," the DoD's interest isn't served. There are lots of situations where the applications of interest need different L1-3 and L4 protocols in particular, and almost surely different L5 and L6 protocols. (Areas of concern: Packetized Speech, Packet Radio, etc.) 📡

*This and other metaphorical questions are dealt with at greater length in reference [2].

The upshot of these ambiguities (and we haven't exhausted the subject) is that different vendors could easily offer ISORMS in good faith that don't interoperate "off-the-shelf." Sure, they could almost certainly be fixed, but not cheaply. 💸 It's also interesting that a recent ANSI X3T5 meeting decided to vote against accepting the ISORM as a standard (while endorsing it as valuable descriptively). The committee realized the very point we're making here: that requiring contractual compliance with a Reference Model can only be desirable if the Reference Model is articulated with utter, and probably humanly unattainable, precision. 🤯

The area of options is also a source of concern about future interoperability of ISORMS implementations from different vendors. There's no need to go into detail, because the broad concern borders on the obvious. What happens when Vendor A's implementations rely on the presence of an optional feature that Vendor B's implementations don't choose to supply? Somebody ends up paying, and it's unlikely to be either Vendor. 🫠

On the other side of the coin, the ARMS designers were all colleagues who met together frequently to resolve ambiguities and refine optionality in common. Not that the ARMS protocols are held to be flawless, but they're much further along than the ISORMS. 🌟

So to wrap up this section: there are grounds to suspect that the quality of vendor support will be low unless the price of vendor support is high. 💅

---

Nature of the Design Process

The advantage of having colleagues design protocols, which we touched on above, leads to another area that makes you wonder how valuable vendor-supported protocols really are. 🤨 Let's look at how international standards actually get made:

The first problem is about who actually shows up to the international standardization process 👀 I've totally nagged two of my NBS friends about fixing the rules for who gets to join standards committees 🙄 and every time they shrug like "they're voluntary standards orgs, babe, we take what we're given" 🤷‍♀️ Honestly, how much that should matter is kinda up in the air, ngl. The argument "How can you expect those institutions which have votes to send their best technical people to a standards committee? Those are precisely the people they want to keep at home, working away" is super tempting, but it doesn't actually guarantee that standards committees only attract less-competent technicians 🤔 There are even a few Old Network Boys from the ARPANET involved with the ISORM, and at least one at NBS ✨ Still, once you realize that the rule saying only active implementers of TCP could be on the design team even blocked the present author from attending (one of the oldest Old Network Boys, and the coiner of the phrase, at that) 💅 it's pretty clear that the ARMS has an almost automatic technical-quality advantage over the ISORMS, without even needing to bring up the politicization of the international standards arena, which most people already acknowledge 🫶

So what about NBS's independent effort? They have access to the experienced designers who evolved the ARMS, right? 🥺 One would think so, but in practice NBS's read on the political necessities of their situation led one of their representatives at a PSTP (the Department of Defense Protocol Standards Technical Panel) meeting to respond to a reminder about their proposed Transport Protocol. That reminder was that one of its features was a recapitulation of an early ARPANET Horror Story, and it would consume inordinate amounts of CPU time on participating Hosts. The response? Only "the NBS Transport Protocol has to be acceptable as ECMA [the European Computer Manufacturer's Association] Class 4." 😭 And even though NBS went to one of the traditional ARPANET-related firms for most of their protocol proposals, curiously enough, in all the Features Analyses the author has seen, the features attributed to protocols in the ARMS are almost as likely to be misstated as not 💀

The conclusion we should draw from all this is not that there's something wrong with the air in Gaithersburg 🌸 It's that there's something bracing in the air that gets exhaled by technical people whose different "home systems'" idiosyncracies naturally lead to intellectual cross-fertilization on one hand, and a tacit agreement that "doing it right" takes precedence over "doing it expediently" on the other 🧚 (If that sounds too corny, just know the author attended a large number of ARPANET protocol design meetings even though he wasn't eligible for TCP: in order to clarify our Host-parochial biases, we screamed at each other a lot, but we got the job done 📣💖)

One other aspect of the international standardization process has noteworthy, unfortunate implications for the resulting designs 😬 However one might feel on a technical level about the presence of at least seven layers (some seem to be undergoing mitosis and growing "sublayers"), it leads to a real problem at the organizational-psychological level. For each layer gets its own committee, each committee is vulnerable to Parkinson's Law, and each layer is in danger of becoming an expansionist fiefdom .... If your protocol designers are, on the other hand, mainly working system programmers when they're at home (as they tend to be in the ARPANET), they are far less inclined to make their layers their careers 🎀 And if experience is weighted heavily (as it usually was in the ARPANET), the same designers tend to be involved with all or most of the protocols in your suite. This not only militates against empire building, it also minimizes misunderstandings over the interfaces between protocols 👑

"Space-Time" Considerations ⏳

At the risk of beating a downed horse 🐴 there's one other problem area with the belief that "Vendor supplied protocols will be worth waiting for," and it really must be touched on. Let's examine the likely motives of the Vendors with respect to "space-time" considerations. The system programmer designers of the ARMS were highly motivated to keep protocol implementations small and efficient, in order to conserve the very resources they were trying to make sharable: the Hosts' CPU cycles and memory locations. Are Vendors similarly motivated? 🤨

For some, the reminder that "IBM isn't in business to sell computers, it's in business to sell computer time" (and you can replace the company name with just about any one you want) should suffice 💅 Especially when you realize it was the traditional answer to the neophyte programmer's query about how come there were firms making good livings selling Sort-Merge utilities for System X when one came with the operating system (X = 7094 and the Operating system was IBSYS, to date the author). But that's all somewhat "cynical," even if it's accurate. Is there any evidence in today's world? 🧐

Well, by their fruits shall you know them 🍓 1. The feature of the NBS Transport Protocol alluded to earlier was an every 15-second "probe" of an open connection ("to be sure the other guy's still there"). In the early days of the ARPANET, one Host elected to have its Host-Host protocol (popularly miscalled "NCP" but more accurately AH-HP, for ARPANET Host-Host Protocol) send an echo ("ECO") command to each other Host each minute. The "Network Daemon" on Multics (the process which fielded AH-HP commands) found its bill tripled as a result 😭 The ECMA-desired protocol would generate four nuisance commands each minute, from every Host you're talking to! (The "M", recall, is for Manufacturers.)* 2. X.25 is meant to be a network interface. Even with all the ambiguities of the ISORM, one would think the "peer" of a "DTE" (Host) X.25 module (or "entity") would be a "DCE" (comm subnet processor) X.25 module. But you can also "talk to" at least the foreign DCE's X.25 and (one believes) even the foreign DTE's; indeed, it's hard to avoid it. Why all these apparently extraneous transmissions? CCITT is a body consisting of representatives of "the PTT's" (European for State-owned communications monopolies) 🏛️ 3. The ISORM legislates that "N-entities" must communicate through "N-1 entities." Doesn't that make for the needless multiplication of N-1 entities? Won't that require processing more state information than a closed (or even an open) subroutine call within level N? Doesn't anybody there care about Host CPU cycles and memory consumption? 🙃

Note particularly well that there is no need to attribute base motives to the designers of the ISORMS 🙏 Whether they're doing all that sort of thing on purpose or not doesn't matter. What does matter is that their environment doesn't offer positive incentives to design efficient protocols, even if it doesn't offer positive disincentives. (And just to anticipate a likely cheap shot: TCP checksums are necessary to satisfy the design goal of reliability; ECMA four pings a minute is[/was] unconscionable. 🫠)

TANSTAAFL 🍕

We're very near the end of our analysis ✨ Readers familiar with the above acronym might be tempted to stop now, though there are a few good points still to come. For the benefit of those who are not aware: "There Ain't No Such Thing As A Free Lunch." Achieving interoperability among vendor-supplied protocol interpreters won't come for free 💸 For that matter, what with all this "unbundling" stuff, who says even the incompatible ones come for free? You might make up those costs by not having to pay your maintenance programmers to reinsert the ARMS into each new release of the operating system from the vendor. But not only don't good operating systems change all that often, you'll also be paying out microseconds and memory cells at rates that can easily add up to ordering the next member up in the family. In short, even if the lunch is free, the bread will be stale and the cheese will be moldy, more likely than not 🥪🧀 It's also the case that as operating systems have evolved, the "networking" code has less and less need to be inserted into the hardcore supervisor or equivalent. That is, the necessary interprocess communication and process creation primitives tend to come with the system now, and device drivers/managers of the user's own devising can often be added as options rather than having to be built in. So the odds are good that it won't be at all hard to keep up with new releases anyway 🙌 Furthermore, it turns out that more and more vendors are supplying (or in the process of becoming able to supply) TCP/IP anyway, so the whole issue of waiting for vendor support might well soon become moot 🦋

*Rumor has it that the probes have since been withdrawn from the spec. Bravo. However, that they were ever in the spec is still extremely disquieting, and how long it took to get them out does not engender confidence that the ISORMS will be "tight" in the next few years. 😤

References 📚

[1] Padlipsky, M. A., "The Elements of Networking Style", M81-41, The MITRE Corporation, October 1981, attempts to clarify the distinction between "remote access" and "resource sharing" as networking styles.

[2] ----------, "A Perspective on the ARPANET Reference Model", M82-47, the MITRE Corporation, September 1982; also available in Proc. INFOCOM '83.