[aprssig] Tracker Smart Pathing

[scott at opentrac.org]

> Ok, that would work when statically configured(remotely or  
> otherwise), could it be made to respond to channel load?

The problem is defining channel load.  When it comes to accepting inbound
remote traffic, then deciding not to digipeat when the local channel load is
too high makes sense.  For outbound traffic, it might not matter as much to
the local network.

I kind of like the way frame relay deals with congestion - frame get a
forward congestion notification bit set when they pass through a congested
network, and return packets get a backward congestion notification bit set.
That way, both ends get notification of congestion and can deal with it at a
higher layer.  Less important data goes out with a discard eligible bit set,
and will get dropped if it encounters congestion.  The DE thing might be
useful for APRS, but the congestion mechanism is probably only useful for
end to end connections.

> overload.  What should the response  of the Digi be? And how 
> does one  
> determine the channel is overloaded? (I'm not the expert here)

That's a good question.  The easy metric is packets-per-minute.  Or possibly
percentage of time that the squelch is open or tones are present - that'd
count collisions as well.  You'd just have to be careful that a little bit
of interference wouldn't cause your digi to clam up when it's actually
quiet.

> If its just too much traffic from too many stations, should the  
> default action to be stop using 'AUTO'(premption) and just become a  
> normal WIDE2-2 digi? This could, potentially, make the 

The AUTO alias could drop to a lower setting, like WIDE1-1, or stop
digipeating entirely.  The AUTO thing would also only affect the first digi
to hear a packet - after that it'd be replaced with something else.

> Should the Digi try and do some calculations and drop the packets  
> coming from furthest away? basically protecting the 
> 'locality' of the  
> APRS net from outside incursion.

I'm trying to avoid that kind of complexity.  I'd prefer a more elegant
solution, that doesn't rely so much on site-specific setup.

> Scott, if you do put something like AUTO into the OT2, I'll 
> help test  
> it for you (when they arrive).  I'm trying to think now how it would  

No problem, shouldn't take too long to write up.  I don't have a
configuration utility for it, though - it's all in a C data structure.
Maybe I'll get a chance to write something this weekend.

> fit in with NSR? I do like the idea of a DIGIs being able to 
> discover  
> each other, figure out their 'place' in the network and acting  

No idea.  I've read over the documents, but it hasn't really 'stuck' yet.

Scott
N1VG