Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site timeinc.UUCP Path: utzoo!decvax!decwrl!greipa!pesnta!phri!timeinc!dwight From: dwight@timeinc.UUCP (Dwight Ernest) Newsgroups: net.ham-radio.packet Subject: Networking Notes from N5EG (TEXNET) (1 of 4) Message-ID: <369@timeinc.UUCP> Date: Wed, 31-Jul-85 15:55:56 EDT Article-I.D.: timeinc.369 Posted: Wed Jul 31 15:55:56 1985 Date-Received: Sat, 3-Aug-85 02:40:09 EDT Reply-To: dwight@timeinc.UUCP (Dwight Ernest) Distribution: na Organization: Time, Inc. - New York Lines: 140 [ Note: This series of articles was found on Compuserve and downloaded from HAMNET there on 21 July 1985 by Dwight Ernest KA2CNN 70210,523. ] An Introduction to networks by T.C. McDermott, N5EG networks SIG, TPRS [ part 1 ] This article is an introduction to the subject of a packet network. It describes what a network is, why a network is necessary to support amateur packet radio activity, and considerations that govern how a network may be constructed. There are many ways that a network can be designed, and it is beyond the scope of this article to elucidate them all. Rather, this article will focus on the simplifing assumptions that may be made in describing a network, and more specifically will concentrate on some suggestions for the Texas Packet Radio Society network which is called "TEXNET". Most of us are familiar with packet radio activity through our operations with the TAPR TNC board. This board implements what is called a "Local Area Network", or LAN for short. When we wish to communicate, we ask our TNC to CONNECT to another station. If that station is not within range of our transmitter, then we may connect to that station through a digi-peater, or through several digipeaters. This is a convienent extension of the X.25 protocol, and forms a large part of the difference between X.25 and the amateur version called AX.25. It would be possible to construct a network of stations that are all within range of the next station, and then to connect to any station in the network using this digipeat method, up to 8 stations distant. This would not require the extension of any of the TAPR software, nor would it require the development of any new hardware. Why then is this not an acceptable method to construct a network? Basically this method, although simple to implement has a serious flaw, it lacks "robustness". That is, the method fails to support adequate communications in the presence of a radio path that is not perfect. Secondly, it assures communications integrity through a method known as "end- to-end ACK". To understand this, it is necessary to understand how a TAPR digipeater works. The TAPR digipeater is a "dumb" digipeater. That is - the digipeater does not understand anything about the state of the two stations that are trying to communicate to each other through it. When one station wishes to connect to another station through a digipeater, it simply adds the digipeater's address in series with the address field of each and every packet. When the digipeater recognizes it's callsign, it repeats the packet. The digipeater does not know what kind of packet is being digipeated, and does not really care. The packet could be a call-request packet, or user-data, or an acknowledge packet, it really doesn't matter, it digipeats them all, blindly. Why is this important? Because it affects how the transmission and acknowledgment of data is handled between the two end stations trying to communicate with each other. When the sender, S, tries to send data to the receiver, R, through one or more intervening digipeaters, D1, D2, ... , Dn, it does this as follows: S : sends a packet D1: digipeats packet D2: digipeats packet R : receives packet, R : sends acknowledge back D2: digipeats acknowledge D1: digipeats acknowledge S : receives acknowledge, S : sends next packet. Although there can be several packets sent per acknowledge, it requires that a packet, and the acknowledge (ACK) make the round-trip from the sender to the receiver. Thus, the more digipeaters, the longer the round-trip time, and the lower the packet throughput. The above example assumed that there were no errors in the transmission. What happens if one of the packets and one of the acknowldeges is corrupted during transmission? S : sends packet D1: digipeats packet D2: doesn't hear packet from D1, so doesn't do anything S : still waiting for ACK from the receiver S : still waiting for ACK from the receiver S : still waiting for ACK from the receiver S : still waiting for ACK from the receiver S : still waiting for ACK from the receiver S : times out waiting for ACK, and re-transmits packet D1: digipeats the packet D2: digipeats the packet R : receives the packet, R : sends ACK back to sender D2: digipeats the ACK D1: doesn't hear packet from D2, so doesn't do anything S : still waiting for ACK from the receiver S : times out waiting for ACK, and re-transmits packet D1: digipeats the packet D2: digipeats the packet R : receives the packet, but it's a duplicate - throw away R : sends ACK back to sender D2: digipeats the ACK D1: digipeats the ACK S : receives the ACK, S : sends the next packet How long did this take? About 25 packet times. The situation gets worse when 8 digipeaters are chained together. In fact with 8 digipeaters the round-trip time reduces the channel throughput by a factor of approximately 16 (8 hops to R, and 8 hops for the acknowledge to come back) if there are no channel errors. If the probability that any single transmission is corrupted is about 70 percent, then with 8 hops the average round trip will take about 1000 packet times. In other words, nothing will get through. Why is the TAPR TNC built this way you might ask? For a very good reason - simplicity. To build a digipeater that behaves in a more coordinated fashion turns out to be a very complicated problem. The TAPR digipeater extension is far superior to the other alternative - no digipeater at all. The TAPR digipeater is elegantly simple, and a reliable way to improve the communications between two stations that are reasonably close, but not able to communicate directly. We have seen that one or two digipeaters may not degrade the throughput terribly, provided that the RF paths are highly reliable. Thus the digipeater solution may be called an LAN solution. That is, it is an acceptable network for small numbers of digipeaters, and high-quality circuits. A single digipeater in a superior location allows many stations within the coverage area of the digipeater to communicate. But the digipeater is not an acceptable solution when the need is to communicate over long distances, and with less than high-quality communications circuits. Thus is born the requirement for a NETWORK. This will be discussed in the next article of this series. -- ----------------------------------------------------------------------------- --Dwight Ernest KA2CNN \ Usenet:...vax135!timeinc!dwight Time Inc. Edit./Prod. Tech. Grp., New York City Voice: (212) 554-5061 \ Compuserve: 70210,523 Telemail: DERNEST/TIMECOMDIV/TIMEINC \ MCI: DERNEST "The opinions expressed above are those of the writer and do not necessarily reflect the opinions of Time Incorporated." -----------------------------------------------------------------------------