RFC relevance of september

As per Relevance of the word september, we have this rfc below:

---------

< INC-PROJECT, MAP-ILLUSION.NLS.8, >, 12-Aug-83 11:44 AMW ;;;;

RFC 873 September 1982
M82-49

THE ILLUSION OF VENDOR

M.A.
THE MITRE
Bedford, Massachusetts

The sometimes-held position that "vendor supplied
intercomputer networking protocols based upon the
Standards Organization's Reference Model for Open
Interconnection are worth waiting for, in particular
preference to protocols based upon the ARPANET Reference
(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

M. A.

Even one or two members of the DoD Protocol
Technical Panel join with many others (including, apparently
some members of the DoD Protocol Standards Steering Group,
clearly, somebody at the GAO) in expressing a desire to "go
vendor-supported intercomputer networking protocols instead
using our own." The author's view of the implications of
desire should be clear from the title of this paper.
evidence, then, is there to so stigmatize what is clearly
well-meant desire to save the Government money

First, we must consider what is meant by "vendor-
protocols." It can't be just X.25, because that only gets
through the network layer whether you're appealing to
International Standards Organization's widely-
Reference Model for Open System Interconnection (ISORM) or to
unfortunately rather tacit reference model (ARM) to which
ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed.
also can't be just X.25 and X.28/X.29 (even with X.75 tossed
to handle "internetting" and X.121 for addressing) because: 1.
They don't serve as a protocol suite for resource sharing (
known as OSI), but rather only allow for remote access [1]. 2.
They (coming as they do from the Consultative Committee
International Telegraphy and Telephony--and including one or
other protocols, in reality) don't even constitute the
protocol suite being worked on by the U. S. National Bureau
Standards, much less the somewhat different suite being
by ISO. So it must be a suite from NBS or ISO, and for
purposes we needn't differentiate between them as their
Models are close enough to be shorthanded as the ISORM

Realizing that we're being asked to consider
ISORM-related protocol suite as what the vendors are expected
support has one immediate consequence which in some sense can
considered to dominate all of the other points to be raised
That is, the DoD procurement process entails quite long
times. Yet the ISORM suite is by no means complete at present
Without prejudice to

1
RFC 873 September 1982

merits or demerits, only X.25 (as levels 1-3, and with
ambiguity as to what level X.75 belongs at) is as yet firmly
the ISORM suite (which it will be convenient to refer to
"ISORMS"), and there is even some doubt as to how firmly they'
there. (E.g., a British observer at a recent PSTP
assured the author that "We in the U.K. don't believe X.25
officially part of the ISORM.") There are proposals which
been circulating for some time at Level 4, and less far
through the international (or even national, remembering NBS
standardization process, ones at Level(s) 5-7. It must be
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
standardization process "takes years." So if the DoD is to
buying what might turn out to be a series of pigs in a series
pokes, it can't wait for the ISORMS

On the other side of the coin, the DoD is
intercomputer networking contracts right now. And, right now
there does exist a suite of protocols designed to the
Reference Model (ARMS, with no pun intended). Implementations
the ARMS already exist for a number of operating systems
in use in the DoD. Now, it is not argued that the ARMS
come "for free" in upcoming acquisitions (contractors fuss
the style of the available specifications, system
fear incursions of non-vendor supplied code into
systems, and so on), but it is unarguable that the ARMS can
procured significantly more rapidly than the ISORMS. (It is
unarguable that those who speak of their unwillingness to see
DoD "develop new protocols rather than employ
standards" haven't done their homework; we're not talking
new protocols in the ARMS, we're talking about protocols
have been in real use for years.)

Quality of

The timeliness argument can lead to a counterargument
the ISORMS is "worth waiting for," though, so we're not done yet
Let's look further at what "vendor support" means. Clearly,
proponents of the position expect that vendors'
of protocols will be in conformance with the Standards for
protocols. Given the nature of these specifications, though
what can we infer about the quality of support we can expect
the vendors

There are two problem areas immediately apparent
ambiguities and options. Let's take ambiguities first.
following are some of the questions raised by
observers about the present state of the ISORMS

2
RFC 873 September 1982

1. Can an X.25 comm subnet offer alternate routing? (
answer depends on whether "DCE's" are expected
follow X.25 between themselves. The situation
further complicated by the fact that some
advocates don't even include the Data
Elements in their depictions of the Model; this
to the metaphorical question* "Are there
garages between the highrises?") If you can conform
X.25 and not offer alternate routing--which
appears to be consistent with the spec, and might
be construed as required by it--the DoD's
interest in "survivability" cannot be served by you

2. Can an X.75 internet offer alternate gatewaying? (
answer is almost surely no, unless the X.75 spec
re-written.) If not, again the DoD's interest is
served

3. Does "Expedited Data" have semantics with regard to
L4-L5/L7 interface? (Not as I read the spec, by
way.) If not, the ISORMS lacks the ability to convey
"Out-of-Band-Signal" to an Application protocol. (
leads to the metaphorical question, "What good is
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,
apparently the answer is yes at present.) If so,
DoD's inherent interest in efficiency/timeliness
be served. (This leads to the metaphorical question
"Are there elevators inside the highrises, or
staircases?")

5. Can an implementation be in conformance with the
and yet flout the prescription that "N-entities
communicate with each other by means of N-1 entities"?
(Not as I read the spec.) If not,
implementations must be inefficient, because
prescription represents an inappropriate legislation
implementation detail which can only lead
inefficient implementations

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

3
RFC 873 September 1982

6. Is each layer one protocol or many? (The point
in 5 would seem to imply the latter, but many
advocates claim it's the former except for L1 and L7.)
If each layer is a "monolith", the DoD's interest
not served because there are many circumstances
which applications of interest require different L1-3
and L4 protocols in particular, and almost
different L5 and L6 protocols. (Areas of concern
Packetized Speech, Packet Radio, etc.)

The upshot of these ambiguities (and we haven't
the subject) is that different vendors could easily
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
decided to vote against acceptance of the ISORM as
standard--while endorsing it as valuable descriptively--
of that standards committee's realization of just the point
are making here: that requiring contractual compliance with
Reference Model can only be desirable if the Reference Model
articulated with utter--and probably
unattainable--precision.)

The area of options is also a source for concern over
interoperability of ISORMS implementations from
vendors. There's no need to go into detail because the
concern borders on the obvious: What happens when Vendor A'
implementations rely on the presence of an optional feature
Vendor B's implementations don't choose to supply?
winds up paying--and it's unlikely to be either Vendor

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

To conclude this section, then, there are grounds to
that the quality of vendor support will be low unless the
of vendor support is high

Nature of the Design

The advantage of having colleagues design protocols
on above leads to another area which gives rise to concern
how valuable vendor-supported protocols really are. Let'
consider how international standards are arrived at

4
RFC 873 September 1982

The first problem has to do with just who participates
the international standardization process. The author
occasionally chided two different acquaintances from NBS
they should do something about setting standards for
on standards committees. The uniform response is to the
that "They are, after all, voluntary standard organizations,
we take what we're given." Just how much significance
properly attached to this insight is problematical. Even
line of argument that runs, "How can you expect
institutions which have votes to send their best technical
to a standards committee? Those are precisely the people
want to keep at home, working away," while enticing, does not
after all, guarantee that standards committees will attract
less-competent technicians. There are even a few Old
Boys from the ARPANET involved with the ISORM, and at least
at NBS. However, when it is realized that the rule that
active implementers of TCP were allowed on the design team
precluded the present author's attendance (one of the oldest
the Old Network Boys, and the coiner of the phrase, at that),
should be clear that the ARMS enjoys an almost
advantage when it comes to technical quality over the ISORMS
without even appealing to the acknowledged-by-most
of the international standards arena

What, though, of the NBS's independent effort? They
access to the experienced designers who evolved the ARMS, don'
they? One would think so, but in actual practice the NBS'
perception of the political necessities of their situation
one of their representatives at a PSTP (the Department of
Protocol Standards Technical Panel) meeting to reply to
reminder that one of the features of their proposed
Protocol was a recapitulation of an early ARPANET Horror
and would consume inordinate amounts of CPU time on
Hosts only with a statement that "the NBS Transport Protocol
to be acceptable as ECMA [the European Computer Manufacturer'
Association] Class 4." And even though NBS went to one of
traditional ARPANET-related firms for most of their
proposals, curiously enough in all the Features Analyses
author has seen the features attributed to protocols in the
are almost as likely to be misstated as not

The conclusion we should draw from all this is not
there's something wrong with the air in Gaithersburg, but
that there's something bracing in the air that is exhaled
technical people whose different "home systems'"
lead naturally to an intellectual cross-fertilization, on the
hand, and a tacit agreement that "doing it right"
precedence over "doing it expediently," on the other hand. (
that sounds too corny, the reader should be aware that the
attended a large number

5
RFC 873 September 1982

ARPANET protocol design meetings even if he wasn't eligible
TCP: in order to clarify our Host-parochial biases, we
at each other a lot, but we got the job done.)

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

"Space-Time"

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

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

Well, by their fruits shall you know them: 1. The
of the NBS Transport Protocol alluded to earlier was an
15-second "probe" of an open connection ("to be sure the
guy's

6
RFC 873 September 1982

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

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

We're very near the end of our analysis. Readers
with the above acronym might be tempted to stop now, though
are a few good points to come. For the benefit of those who
not aware: "There Ain't No Such Thing As A Free Lunch."
Achieving interoperability among vendor-supplied
interpreters won't come for free. For that matter, what with
this "unbundling

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

7
RFC 873 September 1982

stuff, who says even the incompatible ones come for free?
might make up those costs by not having to pay your
programmers to reinsert the ARMS into each new release of
operating system from the vendor, but not only don't
operating systems change all that often, but also you'll
paying out microseconds and memory cells at rates that can
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
will be moldy, more likely than not. It's also the case that
operating systems have come to evolve, the "networking" code
less and less need to be inserted into the hardcore supervisor
equivalent. That is, the necessary interprocess
and process creation primitives tend to come with the system now
and device drivers/managers of the user's own devising can
be added as options rather than having to be built in, so
odds are good that it won't be at all hard to keep up with
releases anyway. Furthermore, it turns out that more and
vendors are supplying (or in process of becoming able to supply
TCP/IP anyway, so the whole issue of waiting for vendor
might well soon become moot

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

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

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX