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!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-crg!seismo!harvard!think!mit-eddie!@DCN6.ARPA:mills@dcn6.arpa
From: @DCN6.ARPA:mills@dcn6.arpa
Newsgroups: net.ham-radio.packet
Subject: Essay for the Digital Committee
Message-ID: <559@mit-eddie.UUCP>
Date: Sun, 24-Nov-85 02:25:31 EST
Article-I.D.: mit-eddi.559
Posted: Sun Nov 24 02:25:31 1985
Date-Received: Thu, 28-Nov-85 04:25:15 EST
Sender: daemon@mit-eddi.UUCP
Organization: MIT, Cambridge, MA
Lines: 164

From: mills@dcn6.arpa
Folks,

There have been many informal discussions recently on the issue of
"level-three" or "long-haul" protocols. The ARRL is planning meetings which
will both create and solve problems in this areas. Phil Karn is trying to drum
up support for these meetings in general and for IP/TCP in particular. Like
some of the rest of us, Phil has learned a few lessons actually building and
using high-flake networks that bear a strong resemblance to those likely to be
built by the amateur community. On the other hand, there is a stong lobby,
including mostly those who have built low-flake commercial networks and those
who have built no networks at all, who display incandescant X.25/X.75/X.121
bumper stickers.

Personally, I think that conflict between the two lobbies is silly and that
both communities can co-exist quite handily, as long as care is taken in the
architecture. The best existence test might be the DARPA Internet, which
includes X.25 nets, Ethernets and all kinds of others, even AX.25 nets, right
now. However, I am worried that some zealot might cop off something silly at
one of these meetings and that may result in shutting down some very useful
options.

Accordingly, I herewith break my promise to confine mutterings to my own swamp
and offer the following essay. You should understand the opinions are
definitely my own and that the exposition is intentionally tart. My hope is to
get you all mad in the first five minutes after reading it, assuming you
survive that trip. Please do not compose a reply during that interval. Then,
I hope that you will think through the issues and direct buttals and rebuttals
not at me, but at the members of the ARRL Digital Committee.

On the Standards Process

Research tends to expand the number of options, while standards tends to
decrease them. One should push on either one until the rate of increase equals
the rate of decrease and so that the total number results in a healthy and
vigorous community.

Amateur radio is after all a recreational community, a fact which some of our
more agressive special-interest groups sometimes forget. As technology matures
standards often work to encourage new entrants and to stabilize exploitation,
with the amateur satellite community being a good example. Pre-emptive efforts
to standardize, especially in a recreational community, would work to
discourage innovation, enthusiasm and participation in the standards process
itself. Volunteer standards (e.g. bandplans) work only if there is a clearly
defined benefit which extends beyond the boundaries of the special-interest
group. In other words, resist telling someone what's good for him unless he
asks.

Any standards process that does not represent the consensus of a constituent
majority or is opposed by a significant minority who may be bound by it will
be unpopular, discredited or ignored, regardless of technical merit. Any
standards process that attempts to restrict the scope of design,
implementation and experiment must be thoroughly justified on engineering
grounds. Political justifications are unacceptable. The notion that our
community can't do something because the Europeans (or the Martians for that
matter) won't accept it is too preposterous for comment.

Every standard has a definite life cycle from the point at which a need for it
is identified, through the coordination and specification process, prototype
implementation and testing, then a period of refinement and evolution until
finally it is overtaken by a successor. A standard must never attempt to
stifle the evolution of successors; in fact, it must encourage it. One of the
implications is that every packet header must include a protocol identifier
and version number, so that different protocols and versions can co-exist in
the same system.

Any network-level standards proposed for use in the amateur packet-radio
community must address the issue of the radio channel a-priori. An "amateur"
standard requiring, for instance, use of X.25 or SLIP on wire links between
local-area gateways, is completely out of scope. Such would not be an amateur
packet-radio standard, merely a bilateral agreement between the gateway
operators. The amateur community is best served by concentrating on the
engineering problems and their solutions with respect to radio issues and only
secondarily on the more well-studied non-radio issues. The Manufacturing
Automation Protocol suite is a good example of how to resist the urge to
reinvent the wheel.

General Assumptions

While the existing CSMA/FM technology has little going for it on pragmatic
engineering grounds, its widespread use is a fact. The AX.25 frame-level
procedures are certainly useful, but badly matched to the CSMA/FM channel
characteristics. Much can be done to improve operational procedures to reduce
congestion and improve throughput, including the use of multiple channels and
cross-channel bridges. However, development of the long-haul system must not
presuppose such improvements.

The existing organization can be described as a datagram network with
stateless repeaters and reliablity provided by end-end resequencing and
retransmission. It may happen that some long-haul systems will include
internal provisions for resequencing and retransmission in order to improve
performance. However, such provisions must not obsolete existing end systems
and protocols. Specifically, this requires an overall system specification on
maximum permissable delay.

Datagram routing between end systems is presently determined by an explicit
indication of source route in every frame. Pragmatically, this can be
justified by the fact it works reasonably well in local-area systems where
there are limited choices of available routes and the number of hops is small.
It may happen that sophisticated routing algorithms will be developed for use
in some local areas; however, a long-haul system must not presuppose this.

Development of the long-haul system must not depend upon a particular choice
in addressing or routing semantics used in a local area and must not require
changes in existing local-area procedures when working other stations in the
local area. This implies the long-haul system must be able to interconnect
existing Vancouver and AX.25 communities and possibly others that may come
along, even if they share the same radio channel.

On Datagrams vs Virtual Circuits

Experience in the education, research and development community suggests the
use of an internetworking protocol and addressing paradigm based on either the
DARPA or ISO connectionless protocol suites. In this model end-end
connectionless (datagram) service is the primary communication mechanism, with
reliability achieved through the use of end-end internet virtual circuits,
perhaps supplemented by intranet virtual circuits. Gateways between
connectionless networks are stateless and operate only in datagram mode, so
are relatively simple.

Experience in the common-carrier community suggests the use of an
internetworking protocol based on the X.75/X.121 protocol suite. In this model
connection (virtual-circuit) service is the primary communication mechanism,
with reliability achieved through the use of concatenated virtual circuits
between the gateways. Gateways between connection networks must preserve state
for each individual end-end virtual circuit, so are relatively complex.

Given the present flux in design philosophy and opinion, it is inappropriate
for the views of either community to dominate the standards process. The
standardization, design and implementation of long-haul amateur packet-radio
systems should not preclude access from either communty to the other, perhaps
via strategically located protocol-translation gateways. Furthermore, the
basic long-haul transport mechanism must provide for both connectionless and
connection service on an end-end basis. Many examples of how to do this are
apparent in the DARPA Internet system.

On Interoperability

There are now and will be in the future numerous opportunities to proliferate
access to and between amateur packet-radio systems via public and private nets
including, but not limited to, the DARPA Internet, VAN nets (Telenet, etc.),
BITNET, USENET, MAILNET, CSNET and others. In many cases the access must by
controlled on economic or policy grounds. This is a very tricky issue in view
of the individual policies of these nets and the government regulations under
which the Amateur Service operates. In fact, the duly approved use of one or
another of these nets or even ordinary dial-up modem connections may be a
useful alternative to a strictly Amateur-Service backbone trunk in some cases.

The most important factor in these issues may be the need for survivability
and interoperability in case of civil emergency or disaster communications.
The standards process must consider these implications with respect to
interconnecting to other link technologies, for instance, an HF link as backup
for a 220-MHz multiple-hop backbone or an XMODEM or KERMIT dial-up link as a
bridge between mail forwarders.

Note very carefully that these factors must not be allowed to advance the
cause of any particular protocol, such as X.25, Internet or XMODEM, without
considering the entire protocol suite of which this protocol might be a
component. It makes no sense to blindly speak X.25 on the basis that
"everybody does it" without considering what applications above X.25 that the
emergency-communications community will need and have available.

Dave
-------