Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site ky2d-2.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!drutx!mtuxo!mtunh!ky2d-2!k2sk
From: k2sk@ky2d-2.UUCP (Bob)
Newsgroups: net.ham-radio.packet
Subject: Re: Essay for the Digital Committee
Message-ID: <73@ky2d-2.UUCP>
Date: Wed, 4-Dec-85 14:43:00 EST
Article-I.D.: ky2d-2.73
Posted: Wed Dec  4 14:43:00 1985
Date-Received: Thu, 5-Dec-85 09:01:41 EST
References: <559@mit-eddie.UUCP>
Organization: KY2D-2 Packet Radio Gateway, Little Silver, NJ
Lines: 182

> 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
> -------


Dave and all other high level planners -

Fellas  its like this: You are 6 months to a year behind
schedule on long haul high speed "backbone" systems. It will
take several years to get them all up and running. If you 
start now, it will be too late to prevent the furious mess
that will occur when all those TNC2 clones are unwrapped on 
channukah and christmas mornings! The sad result of that will
be that many will give up on packet as being "too slow" and
"too unreliable" "no good for dx" etc. The flea mkts. will
be flooded with TNCs and we will never be seen again!
I have a message for all of you:
While I enjoy reading these essays and arguements (some of
which are so steeped in jargon I can barely follow them),
they AREN'T GETTING THE NETWORKS BUILT!! We don't need it
PERFECT fellas, we need it TUESDAY!   - Bob   >>