GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc873

———

   < 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
/data/webs/external/dokuwiki/data/pages/rfc/rfc873.txt · Last modified: 1992/09/23 20:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki