RFC873
From RFC-Wiki
�
< INC-PROJECT, MAP-ILLUSION.NLS.8, >, 12-Aug-83 11:44 AMW ;;;;�
RFC 873 September 1982 M82-49
THE ILLUSION OF VENDOR SUPPORT
M.A. PADLIPSKY
THE MITRE CORPORATION
Bedford, Massachusetts�
ABSTRACT
The sometimes-held position that "vendor supplied" intercomputer networking protocols based upon the International Standards Organization's Reference Model for Open System Interconnection are worth waiting for, in particular in preference to protocols based upon the ARPANET Reference Model (ARM), is shown to be fallacious.
The paper is a companion piece to M82-47, M82-48, M82-50, and M82-51.
i�
THE ILLUSION OF VENDOR SUPPORT
M. A. Padlipsky
Introduction
Even one or two members of the DoD Protocol Standards Technical Panel join with many others (including, apparently, some members of the DoD Protocol Standards Steering Group, and clearly, somebody at the GAO) in expressing a desire to "go with vendor-supported intercomputer networking protocols instead of using our own." The author's view of the implications of this desire should be clear from the title of this paper. What evidence, then, is there to so stigmatize what is clearly a well-meant desire to save the Government money?
Scope
First, we must consider what is meant by "vendor-supported protocols." It can't be just X.25, because that only gets you through the network layer whether you're appealing to the International Standards Organization's widely-publicized Reference Model for Open System Interconnection (ISORM) or to the unfortunately rather tacit reference model (ARM) to which the ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed. It also can't be just X.25 and X.28/X.29 (even with X.75 tossed in to handle "internetting" and X.121 for addressing) because: 1. They don't serve as a protocol suite for resource sharing (also known as OSI), but rather only allow for remote access [1]. 2. They (coming as they do from the Consultative Committee on International Telegraphy and Telephony--and including one or two other protocols, in reality) don't even constitute the full protocol suite being worked on by the U. S. National Bureau of Standards, much less the somewhat different suite being evolved by ISO. So it must be a suite from NBS or ISO, and for present purposes we needn't differentiate between them as their Reference Models are close enough to be shorthanded as the ISORM.
Timeliness
Realizing that we're being asked to consider an ISORM-related protocol suite as what the vendors are expected to support has one immediate consequence which in some sense can be considered to dominate all of the other points to be raised: That is, the DoD procurement process entails quite long lead times. Yet the ISORM suite is by no means complete at present. Without prejudice to its
1� RFC 873 September 1982
merits or demerits, only X.25 (as levels 1-3, and with some ambiguity as to what level X.75 belongs at) is as yet firmly in the ISORM suite (which it will be convenient to refer to as "ISORMS"), and there is even some doubt as to how firmly they're there. (E.g., a British observer at a recent PSTP meeting assured the author that "We in the U.K. don't believe X.25 is officially part of the ISORM.") There are proposals which have been circulating for some time at Level 4, and less far along through the international (or even national, remembering NBS) standardization process, ones at Level(s) 5-7. It must be noted that: 1. These are by and large "paper protocols" (that is, they have not been subjected to the test of actual use). 2. Even ISO and NBS's warmest supporters acknowledge that the standardization process "takes years." So if the DoD is 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 side of the coin, the DoD is letting intercomputer networking contracts right now. And, right now, there does exist a suite of protocols designed to the ARPANET Reference Model (ARMS, with no pun intended). Implementations of the ARMS already exist for a number of operating systems already in use in the DoD. Now, it is not argued that the ARMS protocols come "for free" in upcoming acquisitions (contractors fuss about the style of the available specifications, system maintainers fear incursions of non-vendor supplied code into operating systems, and so on), but it is unarguable that the ARMS can be procured significantly more rapidly than the ISORMS. (It is also unarguable that those who speak of 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
The timeliness argument can lead to a counterargument that the ISORMS is "worth waiting for," though, so we're not done yet. Let's look further at what "vendor support" means. Clearly, the proponents of the position expect that vendors' implementations of protocols will be in conformance with the Standards for those protocols. Given the nature of these specifications, though, what can we infer about the quality of support we can expect from the vendors?
There are two problem areas immediately apparent: ambiguities and options. Let's take ambiguities first. The following are some of the questions raised by knowledgable observers about the present state of the ISORMS:
2� RFC 873 September 1982
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. The situation is
further complicated by the fact that some ISORM
advocates don't even include the Data Communication
Elements in their depictions of the Model; this 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 to be consistent with the spec, and might even
be construed as required by it--the DoD's inherent
interest in "survivability" cannot 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 is not
served.
3. Does "Expedited Data" have semantics with regard to the
L4-L5/L7 interface? (Not as I read the spec, by the
way.) 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. Must all layers be traversed on each transmission?
(There are rumors of a new ISORM "null-layer" concept;
it's not in the last version I looked at, however, and
apparently the answer is yes at present.) If so, the
DoD's inherent interest in efficiency/timeliness cannot
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 yet 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, again
implementations must be inefficient, because the
prescription represents an inappropriate legislation of
implementation detail which can only lead to
inefficient implementations.
_______________
* This and other metaphorical questions are dealt with at
greater length in reference [2].
3� RFC 873 September 1982
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 is
not served because there are many circumstances in
which applications of interest require different L1-3
and L4 protocols in particular, and almost surely
different L5 and L6 protocols. (Areas of concern:
Packetized Speech, Packet Radio, etc.)
The upshot of these ambiguities (and we haven't exhausted the subject) is that different vendors could easily offer ISORMS's in good faith which didn't interoperate "off-the-shelf". Granted, they could almost certainly be fixed, but not cheaply. (It is also interesting to note that a recent ANSI X3T5 meeting decided to vote against acceptance of the ISORM as a standard--while endorsing it as valuable descriptively--because of that standards committee's realization of just the point we are making here: that requiring contractual compliance with a Reference Model can only be desirable if the Reference Model were articulated with utter--and probably humanly unattainable--precision.)
The area of options is also a source for concern over 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 winds 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.
To conclude this section, then, 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 touched on above leads to another area which gives rise to concern over how valuable vendor-supported protocols really are. Let's consider how international standards are arrived at:
4� RFC 873 September 1982
The first problem has to do with just who participates in the international standardization process. The author has occasionally chided two different acquaintances from NBS that they should do something about setting standards for membership on standards committees. The uniform response is to the effect that "They are, after all, voluntary standard organizations, and we take what we're given." Just how much significance is properly attached to this insight is problematical. Even the line of argument that runs, "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," while enticing, does not, after all, guarantee that standards committees will attract only less-competent technicians. There are even a few Old Network Boys from the ARPANET involved with the ISORM, and at least one at NBS. However, when it is realized that the rule that only active implementers of TCP were allowed on the design team even precluded the present author's attendance (one of the oldest of the Old Network Boys, and the coiner of the phrase, at that), it should be clear that the ARMS enjoys an almost automatic advantage when it comes to technical quality over the ISORMS, without even appealing to the acknowledged-by-most politicization of the international standards arena.
What, though, of the NBS's independent effort? They have access to the experienced designers who evolved the ARMS, don't they? One would think so, but in actual practice the NBS's perception of the political necessities of their situation led one of their representatives at a PSTP (the Department of Defense Protocol Standards Technical Panel) meeting to reply to a reminder that one of the features of their proposed Transport Protocol was a recapitulation of an early ARPANET Horror Story and would consume inordinate amounts of CPU time on participating Hosts only with a statement that "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, but rather that there's something bracing in the air that is exhaled by technical people whose different "home systems'" idiosyncracies lead naturally to an intellectual cross-fertilization, on the one hand, and a tacit agreement that "doing it right" takes precedence over "doing it expediently," on the other hand. (If that sounds too corny, the reader should be aware that the author attended a large number of
5� RFC 873 September 1982
ARPANET protocol design meetings even if 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 resultant 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"), this leads to a real problem at the organizational--psychological level. For each layer gets its own committee, and 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" which really must be touched on. Let's examine the likely motives of the Vendors with respect to "space-time" considerations. That is, 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 that it was the traditional answer to the neophyte programmer's query as to 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
6� RFC 873 September 1982
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 the 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 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"
________________
* 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.
7� RFC 873 September 1982
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, but also you'll 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 come to evolve, 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 process of becoming able to supply) TCP/IP anyway, so the whole issue of waiting for vendor support might well soon become moot.
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.
8�
