[FADCA] Things of note

[Chuck Hast]

My having to dig into the ax25 how-to and at the same time dig into the
operation of the communications stack in the linux box has showed me
some interesting tools that we have at hand.

Here is one that is built in and on a busy link could really speed things
up particulary if it is full duplex.

AX25 has a extended mode, what this implies is the following

1. It uses modulo 127 rather than 7 for the number of frames that
    can be in flight at any given time.
2  It uses SELECTIVE REJECT to speed up the recovery from lost
    frames in a group of sent frames. 
       Under a maximum of 7 frames sent the authors of AX25 deemed
        that there was no need for selective reject, so if you send 6 frames
        but number 3 gets lost, you have to resend 3,4,5, and 6.
       With selective reject if you lost #3 the far end request a retry on #3
3. It allows for max frame of up to 512 bytes. This would allow much more
    level 3 efficiency.

Here is a copy of the settings for the ax25 link layer. Looks like the
mailer has murdered it, but you can also see it if you look at it in
the ax25 how-to

The two of interest here are:
ax25_default_mode
and:
maximum_packet_length|

The structure of the files in /proc/sys/net/ax25/portname/ is as follows:

+---------------------+------------------+-----------------------+-------+
|Filename             |Meaning           |Values                 |Default|
+---------------------+------------------+-----------------------+-------+
|ip_default_mode      |IP Default Mode   |0=DG 1=VC              |0      |
+---------------------+------------------+-----------------------+-------+
|ax25_default_mode    |AX.25 Default Mode|0=Normal 1=Extended    |0      |
+---------------------+------------------+-----------------------+-------+
|backoff_type         |Backoff           |0=Linear 1=Exponential |1      |
+---------------------+------------------+-----------------------+-------+
|connect_mode         |Connected Mode    |0=No 1=Yes             |1      |
+---------------------+------------------+-----------------------+-------+
|standard_window_size |Standard Window   |1 .. 7                 |2      |
+---------------------+------------------+-----------------------+-------+
|extended_window_size |Extended Window   |1 .. 63                |32     |
+---------------------+------------------+-----------------------+-------+
|t1_timeout           |T1 Timeout        |1s .. 30s              |10s    |
+---------------------+------------------+-----------------------+-------+
|t2_timeout           |T2 Timeout        |1s .. 20s              |3s     |
+---------------------+------------------+-----------------------+-------+
|t3_timeout           |T3 Timeout        |0s .. 3600s            |300s   |
+---------------------+------------------+-----------------------+-------+
|idle_timeout         |Idle Timeout      |0m or greater          |20m    |
+---------------------+------------------+-----------------------+-------+
|maximum_retry_count  |N2                |1 .. 31                |10     |
+---------------------+------------------+-----------------------+-------+
|maximum_packet_length|AX.25 Frame Length|1 .. 512               |256    |
+---------------------+------------------+-----------------------+-------+


In the end, if we could extend these two settings to the user end, we would
see even greater link effciency.

Some will ask why this was not implemented in the TNC's I think it had to
do with the amount of memory available, if you had say 64 frames in flight
you had to keep copies of them for the selective reject mechanisim, but
at the same time you had more data coming in from either end so you would
quickly run out of memory, our computers and even newer TNC's no longer
have this limitation, even a regular TNC running KISS or 6pack would have
plenty of memory to handle what needs to be done because the actual frames
are retained in the ax25 layer on the computer.

If any of you are looking at doing a ax25 layer for windows, this would be a
very good thing to implement on a selectable basis, a poor link would not
probably work very well with this mechanisim, but a clean fast one would
be so much faster and more efficient.

-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."