@DCN6.ARPA:mills@dcn6.arpa (11/24/85)
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 -------
k2sk@ky2d-2.UUCP (Bob) (12/04/85)
> 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 >>
karn@petrus.UUCP (Phil R. Karn) (12/05/85)
> 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 >> Lots of things ARE going on in the way of packet development. I am working on a portable TCP implementation in C which is undergoing debugging at the moment. I also plan on bringing up the BRL Gateway or something similar on a small cheap machine like the 820 or any of the various networking controllers now under development. I have already written an AX.25 implementation for the 820 that will serve as the foundation for the gateway. Note that my last three sentences began with "I". That's because, to my knowledge, I'm the only person doing all this work. Since you agree that work needs to be done, how about taking your hands out of your pockets and helping out instead of just griping? There's no money in this business, and there's other things I have to do to earn a living, so there's plenty of ways you could help. Remember, folks, this is a hobby, and it's also supposed to be an EDUCATIONAL one. If all you want is reliable communications without bothering with the gritty details, go buy it from AT&T or GTE or any other common carrier and pay for the privilege. I'd like to learn something along the way, and I like to think that SOME other hams feel the same way. 73, Phil
@DCN6.ARPA:mills@dcn6.arpa (12/08/85)
From: mills@dcn6.arpa Bob, Your enthusiasm is wonderful, your impatience understandable and even your irritation tolerable. Those of us who have built or used networks professionally understand that it is easy to sling wires but extraordinarily hard to build large networks that are always there when you wnat them, adapt handily to changing traffic and know where everybody is, even if they are trotting around the expressways. I have a fabulous suggestion. While some of us are fumbling around trying to build the network of your dreams, why not use the telephone system? Or better yet, linked (audio) repeaters? I'm entirely serious. You and others who want simply to hook widely separated digipeaters together and ragchew with your friends could form an appropriate committee and work out how to do that using telephones and linked repeaters. Meanwhile some of the rest of us can have a wonderful time figuring out how to do that with packet switching. Not necessarily better, but certainly different. Dave -------