Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!think!mit-eddie!brian@SDCSVAX.ARPA
From: brian@SDCSVAX.ARPA
Newsgroups: net.ham-radio.packet
Subject: Re: IP/TCP bumps and grinds
Message-ID: <108@mit-eddie.UUCP>
Date: Wed, 16-Oct-85 20:59:38 EDT
Article-I.D.: mit-eddi.108
Posted: Wed Oct 16 20:59:38 1985
Date-Received: Sat, 19-Oct-85 06:36:49 EDT
Sender: daemon@mit-eddi.UUCP
Organization: MIT, Cambridge, MA
Lines: 50

From: brian@SDCSVAX.ARPA (Brian Kantor)
Actually, the reason for x.25 under tcp/ip is a practical one only - the
equipment is there already.  Think of them as error-free radio modems.

By using existing packet radio boxes to implement the point-to-point
links in a packet network, we get error-free links between the nodes in
the network.  If data traversing the network is sent as IP datagrams
over such a network, it can be rerouted in true datagram style at each
network node, thus giving the flexibility of a datagram based service
with the high reliability of connected nodes.

Certainly some other transport mechanism could be used between network
nodes.  AX.25 boxes exist and will simplify getting a network built.
Although they have disadvantages (such as really short maximum packet
sizes), their existance and useability means that we only have to build
the network, not also design a new transport mechanism for it.

Undoubtably you are aware, Erik, that the Internet Protocol packets are
almost never sent in raw form.  They are usually encapsulated in an
underlying transport protocol such as ethernet, slip, 1822, etc.  No,
its not exactly ISO 7-layer standard.  But this is the real world.  And
it works well.

There are some philosophical arguments (perhaps they are practical
arguements also) as to whether the IP datagram should be generated in
the user's equipment, or in the network connection node.  You can
compare this to whether your terminal at home is using a modem (and thus
212 or 103 protocol) to connect to your vax at work, which generates the
IP stuff for you, to the idea of having a standalone system at home that
actually makes IP packets and sends them to your vax which gateways them
onto the network (as with a Sun running SLIP, for example).  

Both will work just fine.  The second requires more processor power in the 
user's equipment, but provides a much more flexible facility.  What we
are trying to do in building the ham packet radio network (AMPRNET) is
to provide the most flexible, most useable, and least restrictive
network we can within a framework of almost no money and complete
anarchy.  The idea is to accomodate both the dude who just bought a
packet box for local communication, and now wants to use the network,
and also the guru who has a lot of computing power and builds an IP box.
The guru is clearly going to get more out of the network than the
appliance operator, but both can use the network.

Gad I've typed a lot before 7 am....

	Brian Kantor WB6CYT	UC San Diego Network Services Group

	decvax\ 	brian@ucsd.arpa
	ihnp4  >---  sdcsvax  --- brian
	ucbvax/		Kantor@Nosc