Aucbvax.5690
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Tue Jan 5 03:01:41 1982
TCP-IP Digest, Vol 1 #10
>From tcp-ip@brl Tue Jan 5 02:51:29 1982
TCP/IP Digest Tuesday, 5 Jan 1981 Volume 1 : Issue 10
Today's Topics:
Administrivia
ComputerWorld on the TCP/IP Cutover
Amateur Packet Radio using InterNet
Overloading the Poor Dot (.)
----------------------------------------------------------------------
From: Mike Muuss <MIKE@BRL>
Subject: Administrivia
Folks -
It looks like somebody on this list is feeding copies of the TCP/IP
Digest to ComputerWorld magazine, which seems delighted with this
newfound source of "inside" information. While it is my intention that
this list receive as broad a distribution as possible, several
tightropes must be carefully traversed:
Networking plays a vital part in the Mission of the Ballistic Research
Laboratory (BRL), which fully supports the distribution of the TCP/IP
Digest. However, the ArpaNet is intended for U.S. Government business,
and is not supposed to compete with commercial packet networks. This
has a rather limiting effect on the group of people who can freely use
the ArpaNet.
More importantly, though, is a question of content. If it becomes
known that contributions to the TCP/IP Digest will appear in ComputerWorld,
possibly verbatim, or perhaps cast in the wrong light, then I suspect that
there will be a marked decrease in the quantity of information that is offered.
Few of us expect our net mail to wind up published in the commercial press,
and only the brave will knowingly open themselves up to this kind of direct,
external exposure. And the cost? Those readers who desperately need the
information on what is happening may find their information sources again
reduced to RFC's and official notices, carefully worded for public scrutiny.
This digest was intended as an open forum? Is a direct pipeline
to the outside world too open? I solicit discussion on this matter.
Maybe we can reach a consensus?
Happy New Year!
-Mike Muuss
------------------------------
From: chico!duke!unc!grumpy.smb at Berkeley
Subject: Computerworld on the TCP/IP cutover
Well, they're at it again. Here are some excerpts from the December 14
issue:
Arpanet, the Pentagon-sponsored packet network that supports U.S.
computing research, is slated for Jan. 1, 1983 cutover to two
protocols that some experts predict will revolutionize
commercial data communications.
Considered the world's first packet network, Arpanet is expected
to become an internet -- a network of networks -- ... said an
informed source, who revealed the cutover date.
It was secret?
... Arpanet was not built to support wartime communications
among the military, but the planned cutover to TCP/IP -- roughly
a year away -- suggests that computer scientists have a lot of
confidence in the protocol pair. An Arpanet crash would
seriously disrupt American research and development in many
fields of science and technology, one expert maintained.
... A number of TCP/IP developers seem to believe that Arpanet
will be ready Jan. 1, 1983 cutover [sic] -- but not all of them,
Arpanet correspondence revealed.
Available to all Arpanet subscribers, electronic mail files on
TCP/IP include the following dispatch by a Stanford University
researcher:
"Some people [believe] that TCP work on [Digital Equipment
Corp.'s] Tops-20 [operating system] is 'done.'... I believe
the 1983 deadline for TCP conversion will not be met. I have
worked on BBN's TCP at the user program level; specifically, I
have implemented general user Telnet for TCP as part of a
general multiple-network Telnet for Tops-20.
"Briefly, the Tops-20 TCP implementation in its present form is
unacceptable to Stanford and many othe Tops-20 sites. It is sad
that so many bright people at BBN have had to maintain this dog
instead of working on a complete rewrite."
This critic wrote, in his Arpanet communique, that "the TCP
process consumes between 40% and 60% of the CPU. We simply
cannot sacrifice that much of an already-loaded CPU to implement
a network ."
[ I suppose that the TCP Digest quoting ComputerWorld quoting the TCP Digest
is only fair! -Mike ]
------------------------------
From: John C. Gilmore <GNU AT MIT-AI>
Subject: Amateur Packet Radio using Internet
To: CERF at USC-ISI
cc: Tcp-ip at BRL
From: CERF at USC-ISI
Your TCP-IP digest entry caught my attention concerning
addressing capability in the IP protocol. I'd like to know
more about your "internet packet radio" since it isn't
one of the projects ARPA is supporting. Is this something
you are pursuing as a graduate or undergraduate effort
or supported by another funding agency?
Vint Cerf
DARPA/IPTO
Amateur Packet Radio is an experimental networking implementation
among Amateur Radio Operators under the regulation of the FCC. It
is a group of "hams" creating a network for digital communication
among citizens. It is not supported by ARPA or any government agency
(although AMRAD hosted an "Amateur Radio Computer Networking
Conference" in conjunction with NBS in October).
We currently favor the Internet Protocols, with minimal modifications,
to encourage timely comprehension, software development, and
extramural connection. Our network has two constraints that we hope
are not unique, which is why I sent my query to TCP-IP, hoping for
known solutions. They are:
There is no underlying software protocol; IP Datagrams are
transmitted without enclosure at the lowest level. (This
is not, so far, a problem, but we're wondering if anyone else
is doing similarly.) The medium is broadcast and there are
contention problems.
There is no central authority; no user sign-up; no fixed
connectivity or user location. Each terminal node runs the
same program with a small number of variables different (at
least one unique). Nodes can appear, disappear, and move at
any time; connectivity depends on electromagnetic weather.
We had trouble with 24-bit addresses in this environment,
since we have no way to create unique addresses that short.
If the TCP-IP mailing list is for Official U. S. Government users
only, rather than for the clarification, distribution, evolution, and
improvement of the standard among all who are gaining experience with
it, then please excuse my assumption and have me removed from it.
[ Nope, you are in the right place. -Mike ]
------------------------------
Subject: Re: Amateur Packet Radio using Internet
From: CERF at USC-ISI
To: GNU at MIT-AI
Cc: Tcp-ip at BRL
In-Reply-To: Your message of 30 December 1981 05:51-EST
1. TCP-IP Digest is an open forum and your entry was perfectly
valid - just caught my attention since I didn't know about the
internet protocol choice by the Amatuer Packet Radio group. I did
know a little about the private Packet Radio work.
2. Use of raw IP formats could cause you some trouble. The current
architectural assumptions are that a gateway can "direct" an
IP THROUGH another gateway, but to do this, it uses a lower
layer of addressing (encapsulation philosophy). This seemed
quite natural to us during design of IP since all the nets we
were concerned with or knew about had a lower layer format with
local addressing - even Ethernets.
In a single network architecture, populated with a blizzard
of private packet radios, you are faced with a number of
challenges. First, the generation of unique identifiers.
Second, the use of these identifiers to aid in routing
decisions. I am not entirely convinced that a geographic
basis is necessarily helpful - in the ARPA packet radio net,
for example, the actual location of a radio is not always a
good indicator of its radio connectivity into the system.
Routing towards its geophysical location may in fact fail
while routing "away" toward the high mountain peak which is
in LOS may help.
In your case, some geographic knowledge may help to structure
the system hierarchically - this is sometimes used to effect
"area routing."
3. As long as you stay within the confines of a single net,
24 bits allows some 16 million destination identifiers
which seem to me to be quite a few for a respectable amateur
packet radio network. One might artificially use up several
network numbers if it appeared that 16 million wasn't enough.
The harder problem is to make these numbers useful for routing
purposes and to do this, one obviously needs to bind the
identifiers to some location. Clearly you have attempted to
do this with the lat/long strategy.
4. Quite frankly, we didn't envision this particular use when
we designed IP - and your trick of using an option format
to provide more detailed information is certainly the kind
of extension we designed options for - even if it does strain
your esthetic senses.
5. As to handling true internetting and providing for routing
THROUGH gateways without losing track of the final net/destination,
either the amateur packet radio network needs to define a lower
level addressing structure, or you need to consider another option
which identifies not only the source and destination but also
the "next" gateway. This is really just a form of source
routing.
6. The hardest problem, really, is going to be handling the
area routing and dissemination of routing information
throughout the system. If connectivity changes frequently
for physical reasons (propagation effects) or because repeaters
go up and down whimsically, then managing the routing problem
is going to be quite a challenge.
Vint Cerf
------------------------------
From: Schauble.Multics at MIT-Multics
Subject: Overloading the .
Tops-20 isn't the only system that has problems with that use of the
period. Multics does also. Notice, for instance, the sender of this
message.
Paul
END OF TCP-IP DIGEST
********************
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
