doc: Add RFC documents

1 files changed, 549 insertions, 0 deletions

diff --git a/doc/rfc/rfc872.txt b/doc/rfc/rfc872.txt
new file mode 100644
index 0000000..c53bcb2
--- /dev/null
+++ b/doc/rfc/rfc872.txt
@@ -0,0 +1,549 @@
+
+
+     RFC 872                                            September 1982
+                                                                M82-48
+
+
+
+
+
+
+
+                               TCP-ON-A-LAN
+
+
+
+
+     
+     
+
+     
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              M.A. PADLIPSKY
+                           THE MITRE CORPORATION
+                          Bedford, Massachusetts
+     
+
+
+
+
+                                 Abstract
+     
+
+     
+
+          The sometimes-held position that the DoD Standard
+     Transmission Control Protocol (TCP) and Internet Protocol (IP)
+     are inappropriate for use "on" a Local Area Network (LAN) is
+     shown to be fallacious.  The paper is a companion piece to
+     M82-47, M82-49, M82-50, and M82-51.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                     i
+     
+     
+     
+     
+                              "TCP-ON-A-LAN"
+
+                              M. A. Padlipsky
+
+     Thesis
+
+          It is the thesis of this paper that fearing "TCP-on-a-LAN"
+     is a Woozle which needs slaying.  To slay the "TCP-on-a-LAN"
+     Woozle, we need to know three things:  What's a Woozle?  What's a
+     LAN?  What's a TCP?
+
+     Woozles
+
+          The first is rather straightforward [1]:
+
+               One fine winter's day when Piglet was brushing away the
+          snow in front of his house, he happened to look up, and
+          there was Winnie-the-Pooh.  Pooh was walking round and round
+          in a circle, thinking of something else, and when Piglet
+          called to him, he just went on walking.
+               "Hallo!" said Piglet, "what are you doing?"
+               "Hunting," said Pooh.
+               "Hunting what?"
+               "Tracking something," said Winnie-the-Pooh very
+          mysteriously.
+               "Tracking what?" said Piglet, coming closer.
+               "That's just what I ask myself.  I ask myself, What?"
+               "What do you think you'll answer?"
+               "I shall have to wait until I catch up with it," said
+          Winnie-the-Pooh.  "Now look there."  He pointed to the
+          ground in front of him.  "What do you see there?
+               "Tracks," said Piglet, "Paw-marks."  he gave a little
+          squeak of excitement.  "Oh, Pooh!  Do you think it's a--a--a
+          Woozle?"
+
+          Well, they convince each other that it is a Woozle, keep
+     "tracking," convince each other that it's a herd of Hostile
+     Animals, and get duly terrified before Christopher Robin comes
+     along and points out that they were following their own tracks
+     all the long.
+
+          In other words, it is our contention that expressed fears
+     about the consequences of using a particular protocol named "TCP"
+     in a particular environment called a Local Area Net stem from
+     misunderstandings of the protocol and the environment, not from
+     the technical facts of the situation.
+
+
+
+
+
+
+                                     1
+     RFC 872                                            September 1982
+
+
+     LAN's
+
+          The second thing we need to know is somewhat less
+     straightforward:  A LAN is, properly speaking [2], a
+     communications mechanism (or subnetwork) employing a transmission
+     technology suitable for relatively short distances (typically a
+     few kilometers) at relatively high bit-per-second rates
+     (typically greater than a few hundred kilobits per second) with
+     relatively low error rates, which exists primarily to enable
+     suitably attached computer systems (or "Hosts") to exchange bits,
+     and secondarily, though not necessarily, to allow terminals of
+     the teletypewriter and CRT classes to exchange bits with Hosts.
+     The Hosts are, at least in principle, heterogeneous; that is,
+     they are not merely multiple instances of the same operating
+     system.  The Hosts are assumed to communicate by means of layered
+     protocols in order to achieve what the ARPANET tradition calls
+     "resource sharing" and what the newer ISO tradition calls "Open
+     System Interconnection."  Addressing typically can be either
+     Host-Host (point-to-point) or "broadcast." (In some environments,
+     e.g., Ethernet, interesting advantage can be taken of broadcast
+     addressing; in other environments, e.g., LAN's which are
+     constituents of ARPA- or ISO-style "internets", broadcast
+     addressing is deemed too expensive to implement throughout the
+     internet as a whole and so may be ignored in the constituent LAN
+     even if available as part of the Host-LAN interface.)
+
+          Note that no assumptions are made about the particular
+     transmission medium or the particular topology in play.  LAN
+     media can be twisted-pair wires, CATV or other coaxial-type
+     cables, optical fibers, or whatever.  However, if the medium is a
+     processor-to-processor bus it is likely that the system in
+     question is going to turn out to "be" a moderately closely
+     coupled distributed processor or a somewhat loosely coupled
+     multiprocessor rather than a LAN, because the processors are
+     unlikely to be using either ARPANET or ISO-style layered
+     protocols.  (They'll usually -- either be homogeneous processors
+     interpreting only the protocol necessary to use the transmission
+     medium, or heterogeneous with one emulating the expectations of
+     the other.)  Systems like "PDSC" or "NMIC" (the evolutionarily
+     related, bus-oriented, multiple PDP-11 systems in use at the
+     Pacific Data Services Center and the National Military
+     Intelligence Center, respectively), then, aren't LANs.
+
+          LAN topologies can be either "bus," "ring," or "star".  That
+     is, a digital PBX can be a LAN, in the sense of furnishing a
+     transmission medium/communications subnetwork for Hosts to do
+     resource sharing/Open System Interconnection over, though it
+     might not present attractive speed or failure mode properties.
+     (It might, though.)  Topologically, it would probably be a
+     neutron star.
+
+
+
+                                     2
+     RFC 872                                            September 1982
+
+
+          For our purposes, the significant properties of a LAN are
+     the high bit transmission capacity and the good error properties.
+     Intuitively, a medium with these properties in some sense
+     "shouldn't require a heavy-duty protocol designed for long-haul
+     nets," according to some.  (We will not address the issue of
+     "wasted bandwidth" due to header sizes. [2], pp. 1509f, provides
+     ample refutation of that traditional communications notion.)
+     However, it must be borne in mind that for our purposes the
+     assumption of resource-sharing/OSI type protocols between/among
+     the attached Hosts is also extremely significant.  That is, if
+     all you're doing is letting some terminals access some different
+     Hosts, but the Hosts don't really have any intercomputer
+     networking protocols between them, what you have should be viewed
+     as a Localized Communications Network (LCN), not a LAN in the
+     sense we're talking about here.
+
+     TCP
+
+          The third thing we have to know can be either
+     straightforward or subtle, depending largely on how aware we are
+     of the context estabished by ARPANET-style prococols:  For the
+     visual-minded, Figure 1 and Figure 2 might be all that need be
+     "said."  Their moral is meant to be that in ARPANET-style
+     layering, layers aren't monoliths.  For those who need more
+     explanation, here goes:  TCP [3] (we'll take IP later) is a
+     Host-Host protocol (roughly equivalent to the functionality
+     implied by some of ISO Level 5 and all of ISO Level 4).  Its most
+     significant property is that it presents reliable logical
+     connections to protocols above itself.  (This point will be
+     returned to subsequently.)  Its next most significant property is
+     that it is designed to operate in a "catenet" (also known as the,
+     or an, "internet"); that is, its addressing discipline is such
+     that Hosts attached to communications subnets other than the one
+     a given Host is attached to (the "proximate net") can be
+     communicated with as well as Hosts on the proximate net.  Other
+     significant properties are those common to the breed:  Host-Host
+     protocols (and Transport protocols) "all" offer mechanisms for
+     flow Control, Out-of-Band Signals, Logical Connection management,
+     and the like.
+
+          Because TCP has a catenet-oriented addressing mechanism
+     (that is, it expresses foreign Host addresses as the
+     "two-dimensional" entity Foreign Net/Foreign Host because it
+     cannot assume that the Foreign Host is attached to the proximate
+     net), to be a full Host-Host protocol it needs an adjunct to deal
+     with the proximate net.  This adjunct, the Internet Protocol (IP)
+     was designed as a separate protocol from TCP, however, in order
+     to allow it to play the same role it plays for TCP for other
+     Host-Host protocols too.
+
+
+
+
+                                     3
+     RFC 872                                            September 1982
+
+
+          In order to "deal with the proximate net", IP possess the
+     following significant properties:  An IP implementation maps from
+     a virtualization (or common intermediate representation) of
+     generic proximate net qualities (such as precedence, grade of
+     service, security labeling) to the closest equivalent on the
+     proximate net. It determines whether the "Internet Address" of a
+     given transmission is on the proximate net or not; if so, it
+     sends it; if not, it sends it to a "Gateway" (where another IP
+     module resides).  That is, IP handles internet routing, whereas
+     TCP (or some other Host-Host  protocol) handles only internet
+     addressing.  Because some proximate nets will accept smaller
+     transmissions ("packets") than others, IP, qua protocol, also has
+     a discipline for allowing packets to be fragmented while in the
+     catenet and reassembled at their destination.  Finally (for our
+     purposes), IP offers a mechanism to allow the particular protocol
+     it was called by (for a given packet) to be identified so that
+     the receiver can demultiplex transmissions based on IP-level
+     information only. (This is in accordance with the Principle of
+     Layering:  you don't want to have to look at the data IP is
+     conveying to find out what to do with it.)
+
+          Now that all seems rather complex, even though it omits a
+     number of mechanisms.  (For a more complete discussion, see
+     Reference [4].)  But it should be just about enough to slay the
+     Woozle, especially if just one more protocol's most significant
+     property can be snuck in.  An underpublicized member of the
+     ARPANET suite of protocols is called UDP--the "User Datagram
+     Protocol."  UDP is designed for speed rather than accuracy.  That
+     is, it's not "reliable."  All there is to UDP, basically, is a
+     mechanism to allow a given packet to be associated with a given
+     logical connection. Not a TCP logical connection, mind you, but a
+     UDP logical connection.  So if all you want is the ability to
+     demultiplex data streams from your Host-Host protocol, you use
+     UDP, not TCP.  ("You" is usually supposed to be a Packetized
+     Speech protocol, but doesn't have to be.)  (And we'll worry about
+     Flow Control some other time.)
+
+     TCP-on-a-LAN
+
+          So whether you're a Host proximate to a LAN or not, and even
+     whether your TCP/IP is "inboard" or "outboard" of you, if you're
+     talking to a Host somewhere out there on the catenet, you use IP;
+     and if you're exercising some process-level/applications protocol
+     (roughly equivalent to some of some versions of ISO L5 and all of
+     L6 and L7) that expects TCP/IP as its Host-Host protocol (because
+     it "wants" reliable, flow controlled, ordered delivery [whoops,
+     forgot that "ordered" property earlier--but it doesn't matter all
+     that much for present purposes] over logical connections which
+     allow it to be
+
+
+
+
+                                     4
+     RFC 872                                            September 1982
+
+
+     addressed via a Well-Known Socket), you use TCP "above" IP
+     regardless of whether the other Host is on your proximate net or
+     not.  But if your application doesn't require the properties of
+     TCP (say for Packetized Speech), don't use it--regardless of
+     where or what you are.  And if you want to make the decision
+     about whether you're talking to a proximate Host explicitly and
+     not even go through IP, you can even arrange to do that (though
+     it might make for messy implementation under some circumstances).
+     That is, if you want to take advantage of the properties of your
+     LAN "in the raw" and have or don't need appropriate applications
+     protocols, the Reference Model to which TCP/IP were designed
+     won't stop you.  See Figure 2 if you're visual.  A word of
+     caution, though:  those applications probably will need protocols
+     of some sort--and they'll probably need some sort of Host-Host
+     protocol under them, so unless you relish maintaining "parallel"
+     suites of protocols....  that is, you really would be better off
+     with TCP most of the time locally anyway, because you've got to
+     have it to talk to the catenet and it's a nuisance to have
+     "something else" to talk over the LAN--when, of course, what
+     you're talking requires a Host-Host protocol.
+
+          We'll touch on "performance" issues in a bit more detail
+     later. At this level, though, one point really does need to be
+     made:  On the "reliability" front, many (including the author) at
+     first blush take the TCP checksum to be "overkill" for use on a
+     LAN, which does, after all, typically present extremely good
+     error properties. Interestingly enough, however, metering of TCP
+     implementations on several Host types in the research community
+     shows that the processing time expended on the TCP checksum is
+     only around 12% of the per-transmission processing time anyway.
+     So, again, it's not clear that it's worthwhile to bother with an
+     alternate Host-Host protocol for local use (if, that is, you need
+     the rest of the properties of TCP other than "reliability"--and,
+     of course, always assuming you've got a LAN, not an LCN, as
+     distinguished earlier.)
+
+          Take that, Woozle!
+
+     Other Significant Properties
+
+          Oh, by the way, one or two other properties of TCP/IP really
+     do bear mention:
+
+          1.   Protocol interpreters for TCP/IP exist for a dozen or
+               two different operating systems.
+
+          2.   TCP/IP work, and have been working (though in less
+               refined versions) for several years.
+
+
+
+
+
+                                     5
+     RFC 872                                            September 1982
+
+
+          3.   IP levies no constraints on the interface protocol
+               presented by the proximate net (though some protocols
+               at that level are more wasteful than others).
+
+          4.   IP levies no constraints on its users; in particular,
+               any proximate net that offers alternate routing can be
+               taken advantage of (unlike X.25, which appears to
+               preclude alternate routing).
+
+          5.   IP-bearing Gateways both exist and present and exploit
+               properties 3 and 4.
+
+          6.   TCP/IP are Department of Defense Standards.
+
+          7.   Process (or application) protocols compatible with
+               TCP/IP for Virtual Terminal and File Transfer
+               (including "electronic mail") exist and have been
+               implemented on numerous operating systems.
+
+          8.   "Vendor-style" specifications of TCP/IP are being
+               prepared under the aegis of the DoD Protocol Standards
+               Technical Panel, for those who find the
+               research-community-provided specs not to their liking.
+
+          9.   The research community has recently reported speeds in
+               excess of 300 kb/s on an 800 kb/s subnet, 1.2 Mb/s on a
+               3 Mb/s subnet, and 9.2 kbs on a 9.6 kb/s phone
+               line--all using TCP.  (We don't know of any numbers for
+               alternative protocol suites, but it's unlikely they'd
+               be appreciably better if they confer like
+               functionality--and they may well be worse if they
+               represent implementations which haven't been around
+               enough to have been iterated a time or three.)
+
+          With the partial exception of property 8, no other
+     resource-sharing protocol suite can make those claims.
+
+          Note particularly well that none of the above should be
+     construed as eliminating the need for extremely careful
+     measurement of TCP/IP performance in/on a LAN.  (You do, after
+     all, want to know their limitations, to guide you in when to
+     bother ringing in "local" alternatives--but be very careful:  1.
+     they're hard to measure commensurately with alternative
+     protocols; and 2.  most conventional Hosts can't take [or give]
+     as many bits per second as you might imagine.)  It merely
+     dramatically refocuses the motivation for doing such measurement.
+     (And levies a constraint or two on how you outboard, if you're
+     outboarding.)
+
+
+
+
+
+                                     6
+     RFC 872                                            September 1982
+
+
+     Other Contextual Data
+
+          Our case could really rest here, but some amplification of
+     the aside above about Host capacities is warranted, if only to
+     suggest that some quantification is available to supplement the a
+     priori argument:  Consider the previously mentioned PDSC.  Its
+     local terminals operate in a screen-at-a-time mode, each
+     screen-load comprising some 16 kb.  How many screens can one of
+     its Hosts handle in a given second?  Well, we're told that each
+     disk fetch requires 17 ms average latency, and each context
+     switch costs around 2 ms, so allowing 1 ms for transmission of
+     the data from the disk and to the "net" (it makes the arithmetic
+     easy), that would add up to 20 ms "processing" time per screen,
+     even if no processing were done to the disk image.  Thus, even if
+     the Host were doing nothing else, and  even if the native disk
+     I/O software were optimized to do 16 kb reads, it could only
+     present 50 screens to its communications mechanism
+     (processor-processor bus) per second.  That's 800 kb/s. And
+     that's well within the range of TCP-achievable rates (cf.  Other
+     Significant Property 9).  So in a realistic sample environment,
+     it would certainly seem that typical Hosts can't necessarily
+     present so many bits as to overtax the protocols anyway.  (The
+     analysis of how many bits typical Hosts can accept is more
+     difficult because it depends more heavily on system internals.
+     However, the point is nearly moot in that even in the intuitively
+     unlikely event that receiving were appreciably faster in
+     principle [unlikely because of typical operating system
+     constraints on address space sizes, the need to do input to a
+     single address space, and the need to share buffers in the
+     address space among several processes], you can't accept more
+     than you can be given.)
+
+     Conclusion
+
+          The sometimes-expressed fear that using TCP on a local net
+     is a bad idea is unfounded.
+
+     References
+
+     [1]  Milne, A. A., "Winnie-the-Pooh", various publishers.
+
+     [2]  The LAN description is based on Clark, D. D.  et al., "An
+          Introduction to Local Area Networks,"  IEEE Proc., V. 66, N.
+          11, November 1978, pp. 1497-1517, several year's worth of
+          conversations with Dr. Clark, and the author's observations
+          of both the open literature and the Oral Tradition (which
+          were sufficiently well-thought of to have prompted The MITRE
+          Corporation/NBS/NSA Local Nets "Brain Picking Panel" to have
+
+
+
+
+
+                                     7
+     RFC 872                                            September 1982
+
+
+          solicited his testimony during the year he was in FACC's
+          employ.*)
+
+     [3]  The TCP/IP descriptions are based on Postel, J. B.,
+          "Internet Protocol Specification," and "Transmission Control
+          Specification" in DARPA Internet Program Protocol
+          Specifications, USC Information Sciences Institute,
+          September, 1981, and on more than 10 years' worth of
+          conversations with Dr. Postel, Dr. Clark (now the DARPA
+          "Internet Architect") and Dr. Vinton G. Cerf (co-originator
+          of TCP), and on numerous discussions with several other
+          members of the TCP/IP design team, on having edited the
+          referenced documents for the PSTP, and, for that matter, on
+          having been one of the developers of the ARPANET "Reference
+          Model."
+
+     [4]  Padlipsky, M. A., "A Perspective on the ARPANET Reference
+          Model", M82-47, The MITRE Corporation, September 1982; also
+          available in Proc. INFOCOM '83.
+
+     ________________
+     *  In all honesty, as far as I know I started the rumor that TCP
+        might be overkill for a LAN at that meeting.  At the next TCP
+        design meeting, however, they separated IP out from TCP, and
+        everything's been alright for about three years now--except
+        for getting the rumor killed.  (I'd worry about Woozles
+        turning into roosting chickens if it weren't for the facts
+        that:  1.  People tend to ignore their local guru; 2.  I was
+        trying to encourage the IP separation; and 3.  All I ever
+        wanted was some empirical data.)
+
+     NOTE:  FIGURE 1. ARM in the Abstract, and FIGURE 2.  ARMS,
+        Somewhat Particularized, may be obtained by writing to:  Mike
+        Padlipsky, MITRE Corporation, P.O. Box 208, Bedford,
+        Massachusetts, 01730, or sending computer mail to
+        Padlipsky@USC-ISIA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                     8
\ No newline at end of file