Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!bellcore!petrus!karn From: karn@petrus.UUCP (Phil R. Karn) Newsgroups: net.ham-radio.packet Subject: Re: General questions on packet Message-ID: <667@petrus.UUCP> Date: Fri, 1-Nov-85 01:44:00 EST Article-I.D.: petrus.667 Posted: Fri Nov 1 01:44:00 1985 Date-Received: Sun, 3-Nov-85 05:47:51 EST References: <1260@sphinx.UChicago.UUCP> Organization: Bell Communications Research, Inc Lines: 73 > I have a few questions regarding the current state of packet radio. > > 1) Where can I get lots of information about it? The only > documentation I have so far is the November CQ magazine. What kind of information are you looking for? Offhand, I can suggest the following for starters: 1. The AX.25 Level 2 Version 2 protocol specification 2. Proceedings from the four ARRL-sponsored Amateur Digital Communications conferences Both of the preceeding items are available from the League. > 2) What is the maximum size of an AX.25 packet? The spec says an I-frame may contain a maximum of 256 bytes. Most of the actual implementations, however, use a contiguous ring buffer so it is the total amount received that matters, not the size of each frame. In some (e.g., the code I wrote for the Xerox 820) the buffers are on linked lists, and the size allocated for each one is an operator parameter. > 3) What plans are there for the next level of network software > to be add to the basic network layer of error checking > packet communications that has been provided by AX.25. No other issue within packet radio has generated more intense and prolonged controversy than this question. There are perhaps three schools of thought: those who want to base the upper layers on a virtual circuit protocol patterned after X.75, the CCITT's standard for public packet network interconnection; those who prefer a datagram approach, i.e., the DoD/ARPA standard TCP and IP protocols; and those who couldn't care less but just want to use something without worrying about the details. Side issues, such as the proper placement of the various protocol modules and the need for TNC software enhancements, are also quite controversial. The amateur packet radio protocol debates are a perfect miniature of past debates in packet switching as a whole, and most of the arguments are the same. Since I am one of the major protagonists in this debate, I will refrain from soapboxing unless I am deliberately provoked. > 4) Why has the FCC limited H.F. data transmission rates to 300 > baud? I'm aware of the the limits on 2 meters and above. Probably for bandwidth reasons, since FSK has to run in the CW bands on HF. Personally, I have very little faith in high speed HF data transmission because of the severe multipath disperson problems, but I may be biased because of my involvement with the amateur satellite program. > 5) I'm particularly intersted in H.F. (D.X.) packet radio. How > much success has been made on the long distance bands? > I'm aware of the digirepeater capabilities of most of the > packet boxes, however I'm thinking more of long distance > point to point transmission because of the sacrificed speed > that digirepeating inherently requires. There has been moderate success over very long paths (i.e., Maryland to New Zealand) on 10 meters when the band conditions are right. It is best to operate on frequencies just under the MUF in order to reduce the aforementioned dispersion problems. I should point out here that a major shortcoming of amateur packet radio is in RF modem technology. The modems that are used are extremely non-optimal in terms of bandwidth and power efficiency, and much improvement could be gained if a talented and determined group were to really take this job on. The use of minimum shift keying (MSK) has been proposed for HF and some work has been done on a prototype, but progress has been slow. The same is true with a PSK modem for satellite work. Phil Karn, KA9Q