summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc874.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc874.txt')
-rw-r--r--doc/rfc/rfc874.txt874
1 files changed, 874 insertions, 0 deletions
diff --git a/doc/rfc/rfc874.txt b/doc/rfc/rfc874.txt
new file mode 100644
index 0000000..73ad4ec
--- /dev/null
+++ b/doc/rfc/rfc874.txt
@@ -0,0 +1,874 @@
+
+
+
+
+
+---------
+
+
+ < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;
+
+
+
+
+
+ RFC 874 September 1982
+ M82-50
+
+
+
+
+
+
+
+ A CRITIQUE OF X.25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ M.A. PADLIPSKY
+ THE MITRE CORPORATION
+ Bedford, Massachusetts
+
+
+
+
+
+ ABSTRACT
+
+
+
+
+ The widely touted network interface protocol, "X.25", and
+ its attendant conceptual framework, the International Standards
+ Organization's Reference Model for Open System Interconnection
+ (ISORM), are analyzed and found wanting. The paper is a
+ companion piece to M82-48, and M82-51.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ i
+
+
+
+
+ A CRITIQUE OF X.25
+
+ M. A. Padlipsky
+
+
+
+
+ Introduction
+
+ According to some sources, the International Standards
+ Organization's (ISO) "Open System Interconnection" (OSI) effort
+ has adopted the International Consultative Committee on Telephony
+ and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels
+ 1-3. ("Loose constructionists" of the ISORM would hold that X.25
+ is a mechanization of L1-L3 rather than the mechanization, and at
+ least one British source holds that "we in the U.K. don't believe
+ that ISO have adopted X.25.") In the U.S. Government arena,
+ where the author spends much of his time, the Government
+ Accounting Office (GAO) has suggested that the Department of
+ Defense (DoD) ought to consider adopting "X.25 networks,"
+ apparently in preference to networks based on protocols developed
+ by the DoD-sponsored intercomputer networking research community.
+ That intercomputer networking research community in turn has,
+ with a few recent exceptions, adhered to its commitment to the
+ Oral Tradition and not taken up the cudgels against X.25 in the
+ open literature, even though X.25 is an object of considerable
+ scorn in personal communications.
+
+ Although the DoD Protocol Standards Technical Panel has
+ begun to evolve a "Reference Model" different from ISO's for
+ reasons which will be touched on below, there seems to be a need
+ to address the deficiencies of X.25 on their own demerits as soon
+ as possible. Without pretending to completeness*, this paper will
+ attempt to do just that.
+
+ The overall intent is to deal with X.25 in the abstract;
+ because of who pays the bills, though, a necessary preliminary is
+ to at least sketch the broad reasons why the DoD in particular
+ should not
+
+ ________________
+ * Various versions of X.25 and ISO documentation were employed;
+ one incompleteness of note, however, is that no attempt has
+ been made to do proper bibliographic citation. Another
+ incompleteness lies in the area of "tutoriality"; that is,
+ appropriate prior knowledge is assumed on the part of the
+ reader. (The author apologizes for the omissions but hasn't
+ the time or the energy to be overly scholarly. Reference [3]
+ might be of use to the reader who feels slighted.)
+
+
+
+
+
+ 1
+ RFC 874 September 1982
+
+
+ employ intercomputer networks which base their protocol suites on
+ the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (Note
+ that this is a different formulation from "use communications
+ subnetworks which present an X.25 interface.") Very briefly, the
+ DoD has concerns with "survivability," reliability, security,
+ investment in prior art (i.e., its research community has a
+ working protocol suite in place on many different operating
+ systems), procurability (i.e., ISORM-related protocol suites do
+ not as yet fully exist even on paper and the international
+ standardization process is acknowledged even by its advocates to
+ require several years to arrive at full suite specification, much
+ less offer available interoperable implementation), and
+ interoperability with a much wider range of systems than are ever
+ likely to receive vendor-supplied implementations of ISORM
+ protocol suites. Regardless of which particular concerns are
+ considered to dominate, the DoD cannot be expected to await
+ events in the ISO arena. (Particularly striking is the fact that
+ DoD representatives are not even permitted under current doctrine
+ to present their specific concerns in the area of security in the
+ sort of unclassified environment the ISO arena constitutes.)
+
+ Some zealous ISORM advocates have suggested that the DoD
+ research community suffers from a "Not Invented Here" syndrome
+ with respect to ISORM-related protocols, though, so even if the
+ various reasons just cited were to prevail, there would still be
+ an open issue at some level. At least one or two zealous members
+ of the research community have asserted that the problem is not
+ Not Invented Here, but Not Invented Right, so an assessment of
+ the apparent keystone of the ISORM suite, X.25, from the
+ perspective of whether it's "good art" ought to be appropriate.
+ That's what we're up to here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 2
+ RFC 874 September 1982
+
+
+ Problems With the Conceptual Model*
+
+ There is confusion even amongst its advocates as to the real
+ conceptual model of X.25-based ISO networking. Some draw their
+ Reference Model as two "highrises," others draw "parking
+ garages" beside each highrise. That is, some draw the seven
+ ISORM layers in large rectangles (representing Hosts) next to one
+ another, showing each layer in communication with its "peer" in
+ the other Host/Open System; this implies an "end-to-end" view of
+ X.25. Others draw smaller rectangles between the larger ones,
+ with Levels 1-3 having peer relationships from the Host-OS ("Data
+ Terminal Equipment") to the Comm Subnet Node ("Data Circuit
+ Terminating Equipment"); this implies a "link-by-link" view of
+ X.25. This ambiguity does not engender confidence in the
+ architects, but perhaps the real problem is with the spectators.
+ Yet it is indisputable that when internetting with X.75, the
+ model becomes "hop-by-hop" (and it is likely it's meant to be
+ link-by-link even on a single comm subnet).
+
+ A major problem with such a model is that the designers have
+ chosen to construe it as requiring them to break the "virtual
+ circuit" it is supposed to be supporting whenever there is
+ difficulty with any one of the links. Thus, if internetting, and
+ on some interpretations even on one's proximate net, rerouting of
+ messages will not occur when needed, and all the upper levels of
+ protocols will have to expend space-time resources on
+ reconstituting their own connections with their counterparts.
+ (Note that the success of the reconstitution under DCE failure
+ appears to assume a certain flexibility in routing which is not
+ guaranteed by the Model.) This can scarcely be deemed sound
+ design practice for an intercomputer networking environment,
+ although many have conjectured that it probably makes sense to
+ telephonists.
+
+ ________________
+ * Note that we are assuming an ISO-oriented model rather than a
+ CCITT-oriented one (X.25/X.28/X.29) because the latter appears
+ to offer only "remote access" functionality whereas the sort
+ of intercomputer networking we are interested in is concerned
+ with the full "resource-sharing" functionality the former is
+ striving for. This might be somewhat unfair to X.25, in that
+ it is taking the protocol(s) somewhat out of context; however,
+ it is what ISO has done before us, and if what we're really
+ accomplishing is a demonstration that ISO has erred in so
+ doing, so be it. As a matter of fact, it can also be argued
+ that X.25 is itself somewhat unfair--to its users, who are
+ expecting real networking and getting only communication; cf.
+ Padlipsky, M. A., "The Elements of Networking Style", M81-41,
+ The MITRE Corporation, October 1981, for more on the extremely
+ important topic of resource sharing vs. remote access.
+
+
+
+
+
+ 3
+ RFC 874 September 1982
+
+
+ Indeed, it appears the virtual circuit metaphor is in some
+ sense being taken almost literally (with the emphasis on the
+ "circuit" aspect), in that what should be an environment that
+ confers the benefits of packet-switching is, at the X.25 level,
+ reduced to one with the limitations of circuit-switching. On the
+ other hand, the metaphor is not being taken literally enough in
+ some other sense (with the emphasis on the "virtual" aspect), for
+ many construe it to imply that the logical connection it
+ represents is "only as strong as a wire." Whether the whole
+ problem stems from the desire to "save bits" by not making
+ addresses explicitly available on a per-transmission basis is
+ conjectural, but if such be the case it is also unfortunate.
+
+ (As an aside, it should be noted that there is some evidence
+ that bit saving reaches fetish--if not pathological--proportions
+ in X.25: For instance, there does not even appear to be a Packet
+ Type field in data packets; rather--as best we can determine--for
+ data packets the low order bit of the "P(R)" field, which
+ overlaps/stands in the place of the Packet Type is always 0,
+ whereas in "real" Packet Type fields it's always 1. [That may,
+ by the way, not even be the way they do it--it's hard to tell ...
+ or care.])
+
+ There is also confusion even amongst its advocates as to
+ what implications, if any, the protocol(s) has (have) for comm
+ subnet node to comm subnet node (CSN) processing. Those who draw
+ just two highrises seem to be implying that from their
+ perspective the CSN (or "DCE") is invisible. This might make a
+ certain amount of sense if they did not assert that each floor of
+ a highrise has a "peer-relationship" with the corresponding floor
+ of the other highrise--for to do so implies excessively long
+ wires, well beyond the state of the wire-drawing art, when one
+ notices that the first floor is the physical level. (It also
+ appears to disallow the existence of concatenated comm subnets
+ into an internet, or "catenet," unless the CSN's are all
+ identically constituted. And those who hold that the ISORM
+ dictates single protocols at each level will have a hard time
+ making an HDLC interface into a Packet Radio Net, in all
+ probability.)
+
+ Those who, on the other hand, "draw parking garages," seem
+ to be dictating that the internal structure of the CSN also
+ adhere to X.25 link and physical protocols. This implies that
+ Packet Radio or satellite CSNs, for example, cannot "be X.25."
+ Now that might be heartening news to the designers of such comm
+ subnets, but it presumably wasn't intended by those who claim
+ universality for X.25--or even for the ISO Reference Model.
+
+
+
+
+
+
+
+
+ 4
+ RFC 874 September 1982
+
+
+ Even granting that ambiguities in the conceptual model do
+ not constitute prima facie grounds for rejecting the protocol(s),
+ it is important to note that they almost assuredly will lead to
+ vendor implementations based on differing interpretations that
+ will not interoperate properly. And the unambiguous position that
+ virtual circuits are broken whenever X.25 says so constitutes a
+ flaw at least as grave as any of the ambiguities.
+
+ Another, in our view extremely severe, shortcoming of the
+ X.25 conceptual model is that it fails to address how programs
+ that interpret its protocol(s) are to be integrated into their
+ containing operating systems. (This goes beyond the shortcoming
+ of the X.25 specifications in this area, for even the advocates
+ of the ISORM--who, by hypothesis at least, have adopted X.25 for
+ their Levels 1-3--are reticent on the topic in their literature.)
+ Yet, if higher level protocols are to be based on X.25, there
+ must be commonality of integration of X.25 modules with operating
+ systems at least in certain aspects. The most important example
+ that comes to mind is the necessity for "out-of-band signals" to
+ take place. Yet if there is no awareness of that sort of use
+ reflected in the X.25 protocol's specification, implementers need
+ not insert X.25 modules into their operating systems in such a
+ fashion as to let the higher level protocols function properly
+ when/if an X.25 Interrupt packet arrives.
+
+ Yet much of the problem with the conceptual model might turn
+ out to stem from our own misunderstandings, or the
+ misunderstandings of others. After all, it's not easy to infer a
+ philosophy from a specification. (Nor, when it comes to
+ recognizing data packets, is it easy even to infer the
+ specification--but it might well say something somewhere on that
+ particular point which we simply overlooked in our desire to get
+ the spec back on the shelf rapidly.) What other aspects of X.25
+ appear to be "bad art"?
+
+ "Personality Problems"
+
+ When viewed from a functionality perspective, X.25 appears
+ to be rather schizophrenic, in the sense that sometimes it
+ presents a deceptively end-to-end "personality" (indeed, there
+ are many who think it is usable as an integral Host-Host, or
+ Transport, and network interface protocol, despite the fact that
+ its specification itself--at least in the CCITT "Fascicle"
+ version--points out several functional omissions where a
+ higher-level protocol is expected--and we have even spoken to one
+ or two people who say they actually do -- use it as an end-to-end
+ protocol, regardless); sometimes it presents a comm subnet
+ network interface personality (which all would agree it must);
+ and sometimes (according to some observers) it presents a
+
+
+
+
+
+
+ 5
+ RFC 874 September 1982
+
+
+ "Host-Front End Protocol" personality. Not to push the "bad art"
+ methaphor too hard, but this sort of violation of "the Unities"
+ is, if demonstrable, grounds for censure not only to literary
+ critics but also to those who believe in Layering. Let's look at
+ the evidence for the split-personality claim:
+
+ X.25 is not (and should not be) an "end-to-end" protocol in
+ the sense of a Transport or Host-to-Host protocol. Yet it has
+ several end-to-end features. These add to the space-time expense
+ of implementation (i.e., consume "core" and CPU cycles) and
+ reflect badly on the skill of its designers if one believes in
+ the design principles of Layering and Least Mechanism. (Examples
+ of end-to-end mechanisms are cited below, as mechanisms
+ superfluous to the network interface role.) The absence of a
+ datagram mode which is both required and "proper" (e.g., not Flow
+ Controlled, not Delivery Confirmed, not Non-delivery mechanized)
+ may also be taken as evidence that the end-to-end view is very
+ strong in X.25. That is, in ISO Reference Model (ISORM) terms,
+ even though X.25 "is" L1-3, it has delusions of L4-ness; in
+ ARPANET Reference Model (ARM) terms, even though X.25 could "be"
+ L I, it has delusions of L II-ness.*
+
+ X.25 is at least meant to specify an interface between a
+ Host (or "DTE") and a comm subnet processor (or "DCE"),
+ regardless of the ambiguity of the conceptual model about whether
+ it constrains the CSNP "on the network side." (Aside: that
+ ambiguity probably reflects even more badly on certain X.25
+ advocates than it does on the designers, for there is a strong
+ sense in which "of course it can't" is the only appropriate
+ answer to the question of whether it is meant to constrain
+ generic CSN processors (CSNP's) in the general case. Note,
+ though, that it might well be meant to constrain specific DCE's;
+ that is, it started life as a protocol for PTT's--or Postal,
+ Telephone, and Telegraph monopolies--and they are presumably
+ entitled to constrain themselves all they want.) Yet the
+ end-to-end features alluded to above are redundant to the
+ interfacing role, and, as noted, extraneous features have
+ space-time consequences. There are also several features which,
+ though not end-to-end, seem superfluous to a "tight" interface
+ protocol. Further, the reluctance of the designers to
+ incorporate a proper "datagram" capability in the protocol (what
+ they've got doesn't seem to be
+
+ ________________
+ * For more on the ARM, see Padlipsky, M. A., "A Perspective on
+ the ARPANET Reference Model", M82-47, The MITRE Corporation,
+ September 1982; also available in Proc. INFOCOM '83. (Some
+ light may also be cast by the paper on the earlier-mentioned
+ topic of Who Invented What.)
+
+
+
+
+
+
+ 6
+ RFC 874 September 1982
+
+
+ usable as a "pure"--i.e., uncontrolled at L3 but usable without
+ superfluous overheard by L4--datagram, but instead entails
+ delivery confirmation traffic like it or not; note that "seem" is
+ used advisedly: as usual, it's not easy to interpret the
+ Fascicle) suggests at least that they were confused about what
+ higher-level protocols need from interfaces to CSNP's, and at
+ worst that there is some merit to the suggestion that, to
+ paraphrase Louis Pouzin, "the PTT's are just trying to drum up
+ more business for themselves by forcing you to take more service
+ than you need."
+
+ Examples of mechanisms superfluous to the interface role:
+
+ 1. The presence of a DTE-DTE Flow Control mechanism.
+
+ 2. The presence of an "interrupt procedure" involving the
+ remote DTE.
+
+ 3. The presence of "Call user data" as an end-to-end item
+ (i.e., as "more" than IP's Protocol field).
+
+ 4. The "D bit" (unless construed strictly as a "RFNM" from
+ the remote DCE).
+
+ 5. The "Q bit" (which we find nearly incomprehensible, but
+ which is stated to have meaning of some sort to
+ X.29--i.e., to at least violate Layering by having a
+ higher-level protocol depend on a lower level
+ machanism--and hence can't be strictly a network
+ interface mechanism).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 7
+ RFC 874 September 1982
+
+
+ The final "personality problem" of X.25 is that some of its
+ advocates claim it can and should be used as if it were a
+ Host-Front End protocol.* Yet if such use were intended, surely
+ its designers would have offered a means of differentiating
+ between control information destined for the outboard
+ implementation of the relevant protocols and data to be
+ transmitted through X.25, but there is no evidence of such
+ mechanisms in the protocol. "Borrowing" a Packet Type id for
+ H-FP would be risky, as the spec is subject to arbitrary
+ alteration. Using some fictitious DTE address to indicate the
+ proximate DCE is also risky, for the same reason. Further, using
+ "Call user data" to "talk to" the counterpart H-FP module allows
+ only 15 octets (plus, presumably, the 6 spare bits in the 16th
+ octet) for the conversation, whereas various TCP and IP options
+ might require many more octets than that. Granted that with
+ sufficient ingenuity--or even by the simple expedient of
+ conveying the entire H-FP as data (i.e., using X.25 only to get
+ channels to demultiplex on, and DTE-DCE flow control, with the
+ "DCE" actually being an Outboard Processing Environment that gets
+ its commands in the data fields of X.25 data packets)--X.25 might
+ be used to "get at" outboard protocol interpreters, but its
+ failure to address the issue explicitly again reflects badly on
+ its designers' grasp of intercomputer networking issues.
+ (Another possibility is that the whole H-FP notion stems from the
+ use of X.25 as a Host-Host
+
+ ________________
+ * That is, as a distributed processing mechanism which allows
+ Host operating systems to be relieved of the burden of
+ interpreting higher level protocols "inboard" of themselves by
+ virtue of allowing Host processes to manipulate "outboard"
+ interpreters of the protocols on their behalf. Note that the
+ outboarding may be to a separate Front-End processor or to the
+ CSNP itself. (The latter is likely to be found in
+ microprocessor-based LAN "BIU's.") Note also that when
+ dealing with "process-level" protocols (ARM L III;
+ approximately ISORM L5-7), only part of the functionality is
+ outboarded (e.g., there must be some Host-resident code to
+ interface with the native File System for a File Transfer
+ Protocol) and even when outboarding Host-Host protocols (ARM L
+ II; approximately ISORM L4 plus some of 5) the association of
+ logical connections (or "sockets") with processes must be
+ performed inboard--which is why, by the way, it's annoying to
+ find ISO L5 below ISO L6: because, that is, you'd like to
+ outboard "Presentation" functionality but its protocol expects
+ to interact with the "Session" protocol, the functionality of
+ which can't be outboarded. (Although this approach, not the
+ proper context for a full treatment of the H-FP approach, it
+ is also of interest that the approach can effectively insulate
+ the Host from changes in the protocol suite, which can be a
+ major advantage in some environments.)
+
+
+
+
+ 8
+ RFC 874 September 1982
+
+
+ protocol so that some might think of it in its Host aspect as
+ "simply" a way of getting at the H-HP. This interpretation does
+ give rise to the interesting observation that DCE's seem to need
+ a protocol as strong as TCP amongst themselves, but doesn't
+ strike the author as particularly convincing evidence for viewing
+ X.25 as anything like a proper H-FP--if for no other reason than
+ that a central premise of Outboard Processing is that the
+ Host-side H-FP module must be compact relative to an inboard
+ generic Network Control Program.)
+
+ X.25, then, is rather schizophrenic: It exceeds its brief
+ as an interface protocol by pretending to be end-to-end
+ (Host-Host) in some respects; it is by no means a full end-to-end
+ protocol (its spec very properly insists on that point on several
+ occasions); it's at once too full and too shallow to be a good
+ interface; and it's poorly structured to be treated as if it were
+ "just" an H-FP. (Some would phrase the foregoing as "It's
+ extremely ill layered"; we wouldn't argue.)
+
+ A Note on "Gateways"*
+
+ Although it was at least implied in the discussion of
+ conceptual model problems, one aspect of X.25/X.75 internetting
+ is sufficiently significant to deserve a section of its own: Not
+ only does the link-by-link approach taken by CCITT make it
+ unlikely that alternate routing can take place, but it is also
+ the case that ARPANET Internet Protocol (IP) based internetting
+ not only permits alternate routing but also could alt-route over
+ an "X.25 Subnet." That is, in IP's conceptual model, Gateways
+ attach to two or more comm subnets "as if they (the Gateways)
+ were Hosts." This means that they interpret the appropriate
+ Host-comm subnet processor protocol of whatever comm subnets
+ they're attached to, giving as the "proximate net address" of a
+ given transmission either the ultimate (internet addressed)
+ destination or the address of another Gateway "in the right
+ direction." And an implementation of IP can certainly employ an
+ implementation of ("DTE") X.25 to get a proximate net, so ... at
+ least "in an emergency" X.25 interface presenting Public Data
+ Networks can indeed carry IP traffic. (Note also that only the
+ proximate net's header has to be readable by the nodal processor
+ of/on the proximate net, so if some appropriate steps were taken
+ to render the data portion of such transmissions unintelligible
+ to the nodal processors, so much the better.)
+
+ ________________
+ * This section was added to address the ill-founded concerns of
+ several ISORMites that "TCP/IP won't let you use Public Data
+ Nets in emergencies."
+
+
+
+
+
+
+
+ 9
+ RFC 874 September 1982
+
+
+ (Further evidence that X.75 internetting is undesirable is
+ found in the fact that the U.S. National Bureau of Standards has,
+ despite its nominal adoption of the ISORM, inserted IP at
+ approximately L3.5 in its version of the Reference Model.)
+
+ The Off-Blue Blanket
+
+ Although touched on earlier, and not treatable at much
+ length in the present context, the topic of security deserves
+ separate mention. We are familiar with one reference in the open
+ literature [1] which appears to make a rather striking point
+ about the utility of X.25 in a secure network. Dr. Kent's point
+ that the very field sizes of X.25 are not acceptable from the
+ point of view of encryption devices would, if correct (and we are
+ neither competent to assess that, nor in a position to even if we
+ were), almost disqualify X.25 a priori for use in many arenas.
+ Clearly, uncertified "DCE's" cannot be permitted to read
+ classified (or even "private") data and so must be "encrypted
+ around," after all.
+
+ It would probably be the case, if we understand Dr. Kent's
+ point, that X.25 could be changed appropriately--if its
+ specifiers were willing to go along. But this is only one
+ problem out of a potentially large number of problems, and,
+ returning briefly to our concern with the interplay of X.25 and
+ the DoD, those persons in the DoD who know best what the problems
+ are and/or could be are debarred from discussing them with the
+ specifiers of X.25. Perhaps a sufficiently zealous ISORM
+ advocate would be willing to suggest that Professor Kuo's
+ publisher be subsidized to come out with a new edition whenever a
+ problem arises so that if Dr. Kent happens to spot it advantage
+ can continue to be taken of his ability to write for the open
+ literature--but we certainly hope and trust that no ISORMite
+ would be so tone-deaf as to fail to recognize the facetiousness
+ of that suggestion.
+
+ In short, it appears to be difficult to dispute the
+ assertion that whatever sort of security blanket X.25 could
+ represent would at best be an off shade of blue.
+
+ Space-Time Considerations
+
+ Another topic touched on earlier which deserves separate
+ mention, if only to collect the scattered data in a single
+ section, is that of what have been called space-time
+ considerations. That is, we are concerned about how well X.25 in
+ particular and the ISORM-derived protocols in general will
+ implement, both in terms of size of protocol interpreters (PI's)
+ and in terms of execution and delay times.
+
+
+
+
+
+
+ 10
+ RFC 874 September 1982
+
+
+ On the space heading, certainly the fact that X.25 offers
+ more functionality in its end-to-end guise than is required to
+ fulfill its network interface role suggests that X.25 PI's will
+ be bigger than they need be. As an aside--but a striking one--it
+ should be noted that X.25's end-to-end functions are at variance
+ with the ISORM itself, for the "peer entity" of a DTE X.25 entity
+ must surely be the local DCE X.25. Perhaps a later version of
+ the ISORM will introduce the polypeer and give rise to a whole
+ new round of Layering-Theologic controversy.* Speaking of the
+ ISORM itself, those who hold that each layer must be traversed on
+ each transmission are implicitly requiring that space (and time)
+ be expended in the Session and Presentation Levels even for
+ applications that have no need of their services. The Well-Known
+ Socket concept of the ARM's primary Host-Host protocol, the
+ Transmission Control Protocol (TCP), lets Session functionality
+ be avoided for many applications, on the other hand--unless ISORM
+ L5 is to usurp the Host's user identification/authentication role
+ at some point. (Yes, we've heard the rumors that "null layers"
+ might be introduced into the ISORM; no, we don't want to get into
+ the theology of that either.)
+
+ On the time heading, X.25's virtual circuit view can be
+ debilitating--or even crippling--to applications such as
+ Packetized Speech where prompt delivery is preferred over ordered
+ or even reliable delivery. (Some hold that the X.25 datagram
+ option will remedy that; others hold that it's not "really
+ datagrams"; we note the concern, agree with the others, and pass
+ on.) Speaking of reliable delivery, as noted earlier some
+ observers hold that in order to present an acceptable virtual
+ circuit X.25 must have a protocol as strong as TCP "beneath"
+ itself; again, we're in sympathy with them. Shifting focus again
+ to the ISORM itself, it must be noted that the principle that
+ "N-entities" must communicate with one another even in the same
+ Host via "N-1 entities" even in the same Host is an over-zealous
+ application of the Principle of Layering that must consume more
+ time in the interpreting of the N-1 protocol than would a direct
+ interface between N-level PI's or such process-level protocols as
+ FTP and Telnet, as is done in the ARPANET-derived model.
+
+ Other space-time deficiencies could be adduced, but perhaps
+ a shortcut will suffice. There is a Law of Programming
+ (attributed to Sutherland) to the effect that "Programs are like
+ waffles: you should always throw the first one out." Its
+ relevance should become
+
+ ________________
+ * And perhaps we now know why some just draw the highrises.
+
+
+
+
+
+
+
+
+ 11
+ RFC 874 September 1982
+
+
+ clear when it is realized that (with the possible exception of
+ X.25) ISORM PI's are in general either first implementations or
+ not even implemented yet (thus, the batter, as it were, is still
+ being mixed). Contrast this with the iterations the
+ ARPANET-derived PI's--and, for that matter, protocols--have gone
+ through over the years and the grounds for our concern over
+ X.25/ISORM space-time inefficiency become clear irrespective of
+ corroborative detail. Factor in the consideration that space-time
+ efficiency may be viewed as contrary to the corporate interests
+ of the progenitors of X.25 ("the PTT's") and at least the current
+ favorite for ISORM Level 4 (ECMA--the European Computer
+ Manufacturers' Association), and it should become clear why we
+ insist that space-time considerations be given separate mention
+ even though touched upon elsewhere.*
+
+ Getting Physical
+
+ Still another area of concern over X.25 is that it dictates
+ only one means of attaching a "DTE" to a "DCE." That is, earlier
+ references to "the X.25 protocol(s)" were not typographical
+ errors. Most of the time, "X.25" refers to ISORM Level 3;
+ actually, though, the term subsumes L2 and L1 as well. Indeed,
+ the lowest levels constitute particular bit serial interfaces.
+ This is all very well for interfacing to "Public Data Nets"
+ (again, it must be recalled that X.25's roots are in CCITT), but
+ is scarcely appropriate to environments where the communications
+ subnetwork may consist of geosynchronous communications satellite
+ channels, "Packet Radios," or whatever. Indeed, even for
+ conventional Local Area Networks it is often the case that a
+ Direct Memory Access arrangement is desired so as to avoid
+ bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25
+ interface" so prized by some won't be DMA either, one imagines.
+ (Speaking of LAN's, at least the evolving standard in that
+ arena--"IEEE 802"--apparently will offer multiple physical
+ interfaces depending on comm subnet style [although there is some
+ disagreement on this point amongst readers of their draft specs];
+ we understand, however, that their Level 2 shares X.25's end-end
+ aspirations--and we haven't checked up on DMA capability.) X.25,
+ then, imposes constraints upon its users with regard to interface
+ technology that are inappropriate.
+
+ ________________
+ * The broad issue of design team composition is amplified in
+ Padlipsky, M. A., "The Illusion of Vendor Support", M82-49,
+ The MITRE Corporation, September 1982.
+
+
+
+
+
+
+
+
+
+
+ 12
+ RFC 874 September 1982
+
+
+ Other Observers' Concerns
+
+ This paper owes much to conversations with a number of
+ people, although the interpretations of their concerns are the
+ author's responsibility. Mention should be made, however, of a
+ few recent documents in the area: The Defense Communications
+ Agency (DCA Code J110) has sent a coordinated DoD position [2] to
+ NBS holding that X.25 cannot be the DoD's sole network interface
+ standard; Dr. Vinton Cerf of the ARPA Information Processing
+ Technology Office made a contribution to the former which
+ contains a particularly lucid exposition of the desirability of
+ proper "datagram" capability in DoD comm subnets [3]; Mr. Ray
+ McFarland of the DoD Computer Security Evaluation Center has also
+ explored the limitations of X.25 [4]. Whether because these
+ authors are inherently more tactful than the present author, or
+ whether their positions are more constraining, or even whether
+ they have been more insulated from and hence less provoked by
+ uninformed ISORMite zealots, none has seen fit to address the
+ "quality" of X.25. That this paper chooses to do so may be
+ attributed to any one of a number of reasons, but the author
+ believes the key reason is contained in the following:
+
+ Conclusion
+
+ X.25 is not a good thing.
+
+ References
+
+ [1] Kent, S. T., "Security in Computer Networks," in Kuo, F.,
+ Ed., Protocols and Techniques for Data Communications
+ Networks, Prentice-Hall, 1981, pp. 369-432.
+
+ [2] Letter to NBS from P. S. Selvaggi, Chief, Interoperability
+ and Standards Office, 7 April 1982.
+
+ [3] Cerf, V. G., "Draft DoD Position Regarding X.25" in undated
+ letter to P. S. Selvaggi.
+
+ [4] Personal communications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 13 \ No newline at end of file