Re: Extended sequence numbers for AX.25

[Gerald J Creager <gerry@cs.tamu.edu>]

Phil, Rob and others,

> Ok, I accept the validity of your analysis but my experience with packet
> radio is that even with 256-byte packets the bit errors already start
> to influence the results.  Probably this just means the BER is such that
> the optimum is below 256 bytes.

Based on some experiments in the Houston area, I suspect you're correct here.
For AX.25.  Not necessarily so, tho' for tcp/ip.

> > is that the packet loss rate should not exceed 1% for good
> > performance.
>
> With TCP (which has no feedback about lost packets and always assumes
> lost packets indicate congestion, not loss by transmission error) this
> is very true.  That is a reason why most of our network uses VC mode for
> IP traffic.  (actually, the current software automatically switches between
> VC and datagram mode depending on the results it gets from the link quality
> measurement)
>
> AX.25 tends to work OK with much higher loss rates, of course with less
> than ideal throughput.

I did cloed end testing with several stations using ax.25 and tcp/ip,
incorporating virtual circuits primarily with direct connections, digipeating
and netrom.  I transferred several fixed-length binary files constructed for
the tests, ranging in size from 512 bytes to 10kb.  I looked at the retry
rate, number of sequential errors, and number of received bad packets.  My
statistics for ax.25 were consistent with Phil's predictions.  TCP/IP fared
better than ax.25 overall both in speed of completion and error rates,
especially at larger packet lengths.  (Obviously, we didn't do 1500 byte
packets through netrom OR digipeaters...)  Ethernet-sized packets were very
useful when the link path was quiet, degrading pretty quickly to a stable
point representing loss of as much as 10% if either additional traffic or
terrestrial pulse-type noise appeared, suggesting that for dedicated,
non-competetive links, large packets are appropriate.

> I think the header overhead is only significant for small frames.
> (i.e. I don't believe 16 bytes of overhead for 256 bytes of user data
> is significant header overhead)
>
> So, "use larger frames" will not bring you anything when just increasing
> the PACLEN from 256 to 1024, as it won't help for frames that are smaller
> than PACLEN anyway.
> It could only help to pack multiple user data frames in a single link
> frame, with only length+PID inbetween (which reduces the header overhead
> from 16*n to 16+3*n bytes)

I suspect this would provide some pretty good economy.

> For modulo-8 sequence numbers and unknown MAXFRAME at the sending side,
> some extra protection is needed.  This takes the form of keeping a simple
> checksum (1 byte) for the past 8 sequence numbers, and not keeping a new
> frame in the resequencing queue when its checksum matches the value for
> the previous frame with that same sequence number (from the previous series).
> With modulo-128 this extra trick is not required as long as the MAXFRAME
> is guaranteed to be below 64.

Interesting.  I'd like to learn more on this.  Got a citation handy?

> > >- the CRC check becomes weaker with large frames
> >
> > Also true, but if you have TCP/IP on top...
>
> Please keep in mind for all suggestions and protocols proposed: while
> TCP/IP is widely used, mostly by "power users", the vast majority of
> traffic in the packet network (95% when I last checked) is pure AX.25
> and NET/ROM.
> The average HAM (at least in his first experiments), and *all* BBS and
> DX Cluster traffic is AX.25, not using TCP/IP.  So this case has to be
> covered well, at least for now.

Sounds, to me, like it's education time again.  The Clusters and the BBSs are
not always good neighbors, either...  Maybe developing better information on
characterizing links and doing look-ahead recalculation to determine the
optimal link parameters would help this!  Gee, Phil:  What about adaptive
power control?

73, gerry