doc: Add RFC documents

1 files changed, 579 insertions, 0 deletions

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