[ax25-layer2] even more thoughts

[Jason Winningham]

This doesn't really follow any one thread, so I'm starting a new one to 
voice some thoughts/opinions.

First, users and change: "backwards compatibility forever" will result 
in kludges and problems.  I think this is a big part of the reason why 
a PC feels so clunky and difficult to work with for me; I'm used to 
working on Sun machines, where the user interface to the hardware at 
various levels has actually improved over the years.  They also abandon 
old hardware platforms in order to better support new hardware 
platforms, instead of expending effort making sure you can run Solaris 
10 on that old MC680x0 based Sun2 in the closet.  Every so often, Sun 
says, "hey everybody, we're going to stop supporting old platform XYZ."

It's sometimes painful, but sooner or later you have to abandon a 
platform (protocol, way of doing things, etc) and grow.  I am not 
saying that is required in this case, but failing to consider the need 
for such is a serious failure in designing a new system.

One of the things that should be eliminated is the provision for source 
routing.  IMO, as long as it is available, that's what will be used.  
For the most part, users will not change unless they are pushed. Hard.  
With sharp sticks.  Or cattle prods.  Or horse whips.

I think the current addressing scheme is mildly inefficient and needs 
more SSIDs.  I also disagree that the destination address should be a 
specific station - there is a place for broadcast and multicast 
addresses.  Please don't bring up the old argument "this is RF, 
everything is broadcast."  This is _not_ RF, this is the data link 
layer, and different things are happening.  For starters, I could 
figure out whether or not I even need to listen to a particular packet, 
much less go to the trouble of saving it and calculating the FCS.  I 
could even power down my receiver for a little while, if I'm really on 
a tight power budget.

I think a hop count/time-to-live field would be useful.  We already do 
this in a backhanded sort of way with the H bit, and also with n-n 
digipeating.  Whether or not we use a field for TTL, we need some 
method of keeping a packet from looping forever.

Some folks seem obsessed with "some other node (really some other ham, 
I think) deciding what will happen to my packet".  News flash: this is 
how networks _work_.

My problem with having some other node decide what to do with a packet 
is the static nature of the current algorithms.  To take an APRS 
example, if I'm in a WIDE3 area and pass through a WIDE2 area, I must 
_manually_ change my PATH so that my packets keep going out.  I don't 
have a problem being limited to 2 hops if that's appropriate for the 
LAN I'm in, but the network should just handle it, without my 
intervention.

NSR is also static.  It requires manual intervention to make changes to 
the network topology.  This is _bad_.  In order for NSR to be useful, 
there _must_ be some protocol to allow devices to populate the "must 
digipeat" (and maybe even "exclude") tables automatically, based on 
information gathered from network traffic.  This is roughly analogous 
to an ethernet switch: a switch repeats packets on all ports until it 
can learn where specific stations are located and direct the traffic 
accordingly.

For example, look at the famous digi in NO that stayed on the air when 
most of the city went off.  If it had been configured with NSR, I could 
not set up an emergency digi between it and the surrounding area and 
have traffic flow normally, without editing the "must digipeat" table 
on that "big" digi that stayed on the air.  As it was, APRS users going 
into the area would have to figure out what path it would digipeat 
before the could may effective use of APRS.  The time immediately 
following a major calamity is _not_ the time to have to screw with 
digipeater settings to get your network working.

On the APRS SIG some have said that APRS basically isn't ready for 
prime-time when it comes to emergency communications.  I agree.  The 
reason is not necessarily APRS itself.  The problem is the 
too-fragmented, too-static network that APRS runs on.

On the subject of "AX.25 is obsolete":  it may be; I'm not prepared to 
argue either way.  What may be an even more important discussion and 
probably outside the scope of this list, is how to get other 
applications to use a network layer.  If APRS used an actual network 
layer one could design a network that included other data link layers.  
An APRS position report could hop from AX.25 to 802.11 wireless to 
D-Star to whatever, allowing the interface between the APRS network 
layer and the data link layer to "do the right thing" for that 
particular LAN.

I do think that one way to push users toward a layer 3 is to remove the 
source routing crutch.

-Jason
kg4wsv