From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc873.txt | 579 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 579 insertions(+) create mode 100644 doc/rfc/rfc873.txt (limited to 'doc/rfc/rfc873.txt') diff --git a/doc/rfc/rfc873.txt b/doc/rfc/rfc873.txt new file mode 100644 index 0000000..0c0d949 --- /dev/null +++ b/doc/rfc/rfc873.txt @@ -0,0 +1,579 @@ + + + + + +--------- + + + < 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 \ No newline at end of file -- cgit v1.2.3