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