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