[nos-bbs] AX.25 status reporting

[Barry Siegfried]

[wa7nwp at jnos.org wrote]:

> > everyone told us that 'datagram' was good (simply
> > because it reduced channel traffic by eliminating the AX.25 I-frame
> > acknowledgements).  Unfortunately, that was a lie.  The fact is, an
> > underlying 'datagram' AX.25 "system" is probably not performing very
> > well at all with carrying IP content.  For every IP frame that gets
> > lost due to hidden terminals and collisions, the TCP/IP system relies
> > on the TCP retry parameters that are set at each end of the TCP
> > transport circuit and these will normally back off to much greater
> > amounts than an AX.25 t1 (retry) timer will.  This is why it is
> > *good* to use 'virtual circuit' mode on channels which are carrying
> > IP.  And you will also see your AX.25 "stats" that way...
>
> It depends on the circuit...
>
> With a "packet repeater" where there are (essentially) no collisions,
> then DG mode works well.  In a typical ad-hoc senario, VC would make
> for more robust data circuits and faster retries.

Agreed!  Under that scenario, you have a much higher rate of success
using DG mode.  I was primarily referring to the normal kind of packet
radio channel typical TCP/IPers might use when they first get on the
air.  Around here, packeteers struggled with DG mode for years on busy
2 meter channels with lots of disappointment.

> At one time I used a mountain top node in mixed mode.  I would send
> to it in VC mode since there were collisions and retries.  I had it
> set to send to me as Datagrams because it was 110% loud and clean
> into my location.
>
> Fun stuff eh?  Really nice to be able to tune it for the situation
> at hand.

Yes indeed it is!

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> OK Barry (& Bill) I think I might be there...
>
> On Mon, 2006-09-25 at 18:46 -0400, Barry Siegfried wrote:
>
> >>SNIP<<
>
> > ARP doesn't find the path.  IP finds the path.  ARP finds the
> > hardware that answers for the network (IP) address.
>
> Yours are strict use of wired environment words ARP.
>
> Try:
>
> ARP finds an AX.25 station that answers for the network (IP) address.

In this case, "station" = "hardware".  Functionally, they are the same
and provide the same service at the same point in the networking
diagram.

> This action "fleshes out" the TCP/IP routing process to determine
> the "path"?
>
> Accept those semantics?

Oh sure, why not.  :)

> > > Little depends on ACK stuff - but as you point out both AX and
> > > IP contain (redundant?) rules for various types of content.
> >
> > As a level 2 protocol, AX.25 does not care what it is carrying
> > and has no knowledge of it.
>
> And since AX is performing the data integrity checks before passing a
> datagram to IP, TCP/IP integrity checks always pass to remove the need
> for that protocol's retry mechanism.

Actually, that statement alone could open up a very LARGE discussion
about AX.25's failings and the medium over which we use it to carry
our packets.  But without going into too much detail in *that*
discussion, the proper place for data integrity checks and the retry
mechanism is at level 4 (TCP).  The only reason they are also in
AX.25 is because it needed them to survive.

AX.25, to put it into simple terms, was deployed totally incorrectly!
The proper way to have deployed AX.25 would have been to use it strictly
as a link protocol similar to 802.11 where your callsign/ssid is the
link identifier (and functionally, that is exactly what it already
is) and a true network routing protocol such as IP would ride along
underneath it so that hams can basically "point and click" their way
around applications using packet as transport medium.

But back in the early 1980s, hams were too anxious to get AX.25 up
and running because they needed to get their applications (at the
time it was only keyboard-to-keyboard and PBBSs followed shortly
thereafter) talking to each other through simple link level circuits
over RF.  So they had to design AX.25 with several of the transport
layer mechanisms included in it that had functionality to manage
"connections" from "end-to-end".  And that is what we're stuck with
AX.25 being today.

> >>SNIP<<
>
> > > Right on - I have grown up in "datagram" mode.   Although I'd
> > > still like to see "A" is linked to "B" at the AX level I guess...
> >
> > You can't.  There is no "link".
>
> If this were strictly true, there is no need for a "to address" in
> the UI frames?

AX.25 UI is the true equivalent of ethernet (which is also
"connectionless").  Each frame has a 'from' and 'to' address.  But
there is no "connection" between them that is counting frames such
that the receiver must acknowledge the data it has received back to
the sender.  The only reason 'virtual circuit' exists is because hams
invented it to insure the integrity of simple application data
travelling across a layer 2 link over a very unreliable medium
without the benefit of any higher layer network and transport
to route and retry the packets, respectively.

> And perhaps they are in fact redundant... it remains what I'd *like*
> to see at a higher level than trace.

As I said, with DG there is absolutely nothing to "see" except perhaps
what the number of packets sent and received are.  And that is what
'ax25 heard' is for.  :)

> > By definition, the "link" is the virtual circuit.  There is no
> > virtual circuit when AX.25 is sending UI frames, and that is what
> > it is doing in 'datagram' mode.  We are *hoping* that the intended
> > receiver hears the frame.  But most of the time, HTS and collisions
> > do us in.
>
> Perhaps the IP error recovery is not as strong as the AX error
> recovery when IP is carried over AX...

In fact, much of AX.25 "error recovery" was based on that which was
in TCP.  The code is very similar, particularly with the way the
AX.25 T1 and TCP retry timers work.  However, the time frames are
slightly different.  Since an end-to-end TCP transport circuit can
go through many mediums and span a large distance, the retry timers
are permitted to go significantly higher than what the AX.25 maximum
retry caps are, where a link circuit is {usually} between two
"stations" that can hear themselves directly.  AX.25 retrying is
therefore expected to be more robust than that which is in TCP
over packet RF circuits.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+