[aprssig] Packet routing, path specification.

Robert Bruninga bruninga at usna.edu
Thu Jun 23 10:03:56 EDT 2005


>>> HamLists at ametx.com 06/22/05 9:55 PM >>>
> There is no requirement to get "agreement" 
>amongst all the hams on the eastern seaboard 
>to effectively implement the NSR algorithm.

This seems inconsistent with the NSR stated
objective that "Each digi will only allow diigpeats
from those other digis that the sysop will allow."
By definition, this means the list is restrictive to
limit traffic to a reasonable level.  In this area
that is surely 2 tiers or less.

But I routinely like to check in to the Philly area
weekly APRS Sunday NIght check-in which is
3 hops away (because it is the ONLY live
humans on the air at the time).  Under the NSR
there is no way the Philly area digis are going to
allow packets from a Washington DC digi.

SImilarly under NSR, the stated objective is to
PREVENT me from directing my packets to an
area of my choosing.  Only the SYSOP of each
digi will decide where my packets can go.

>NSR has everything to do with implementing a
>diverse, yet stable network.  And that is exactly 
>what the NSR does.

But by defniition, that means a rigid, stagnant,
unresponsive network completely incapable of
AD-hoc response to an immediate need.  ANd
experience has shown that getting DIGI sysops
to respond quickly (read weeks) to needed
changes in many areas is a demosntrated problem.

The NSR approach by definition kills the original 
intent of APRS which was ad-hoc responsiveness
to what ever the need at hand.  And the need
at hand was NEVER intended to be 24/7 beacons
with lights on but no one home doing nothing
most of the time.   APRS was for facilitating real-time
human-to-human digital exchange of data of 
immediate use.

>True, you might not be able to work Philadelphia 
>from Annapolis on a direct RF path, but then 
>again you can't reliably do that now.  You can,
>however, work anyone in Philadelphia from Annapolis 
>today by specifying only one digi in your path and 
>using messaging (and the internet).

I fully suport the APRS-IS, and global messaging
via the internet, but it being able to use a reasonable
RF path as needed where needed is the essence of
HAM radio in my mind.  There is a big difference between
the distribution needs of APRS 24/7 home stations just 
doing nothing all day versus a real-live-HAM radio
activity with humans at both ends...

>Dallas is far from an "isolated" area.  We see 
>packets everyday from Kansas to South Texas, 
>New Mexico to Louisiana.   In fact, we don't 
>need to see the packets from users in Dallas 
>County (the next county south) or vice versa. 

I hope users in Dallas county are reading this and
understand the implication here that under NSR, 
they will not be allowed to send any packets into 
Dallas under any circumstances except via the
Internet.  O r without explicit attention by the
sysop to add them specifically to an exception list.

>This is not a matter of "agreement" with remote 
>users or sysops; it is a matter of usability of
>APRS for local users.

Usability is a subjective term.  If you dissalow any
packets from getting into your area except a 
given routine load of local packets only from a given
list of digis, then you preclude any responsiveness
to any other non-routine RF needs or situation.
In effect you turn APRS into any other bureaucratic
comms system that is un-responsive in non-routine
needs which is where HAM radio is supposed to excell.

>You have not shown a single example where it is 
>critical that a user be able to define where their 
>broadcast packets end up.  

I do it every night.  I look at the list of stations
using RELAY and WIDE and TRACE and W4-4
etc and send out a few messages.  I choose a
path of DIGI1, DIGI2, DIGI3 where digi 3 is the
digi in their area of the group of people I want
to hit.  THus I am easily able to get my packets
into New Jersy 150 miles away but with only 3 
total copies produced.

Compared with WIDE2-2 which in this area will
generate 10 to 15 total copies on the network.
It doesnt take a rocket scientist to see the
advantage of only 3 total packets to let me
communicate 3 hops to a specific area, versus
blathering my packets out 15 copies in all
directions and yet not reaching my intended
recepients.

You say, these packets should arrive via the 
Internet.  Believe me, it doesnt work.  When I
send a message via local RF to someone out
of area (where the APRS-IS should make it
work perfectly) I NEVER get an ack but in
maybe 5% or less of any attempts.  It simply
does not work.  Where a directed 3 hop path
works well (if there is a real human at the other
end).

Even in this ihigh density area, it sometimes
takes 3 hops to find another live human...
Remember, 3 hops via a 3 hop directed path
is 5 times more efficient than sending the
same packet only 2 hops via WIDE2-2.

APRS was designed for rapid path changing to
meet the immediate needs of the operator.
APRSdos provided for up to 12 pre-definedd
specific paths that could be INVOKED on
each message line by line by a simple two
character abbreviation at the front of a message
entry.

NW: Hey john, (northwest of me) did you get that radio?
SW: sam, where is tht new digi you were talking about
W2: This is a local messge packet going out WIDE2-2
DC:  This is a directed packet to Wash DC using the pre
        defined path to DC

In each case, it took less than 0.1 second for the sender
of a message line to indicate the path he wanted THAT
ONE PACKET to go by adding the two digit path
abbreviation for it.  THe problem is that NONE Of the
other APRS follow-on clone software implented any of this.

They just set a one-path-fits all mentality and the
result is the mess we see today.  Remember this
is radio and the rule has always been, use the minimum
power (read path) to get the job done.  I can not
help it that other clone software overlooked this
fundamental aspect of APRS.  and not only that
but did not even display the PHG data on the map
so that one could easily SEE the best path to use.

de WB4APR, Bob

Bob





More information about the aprssig mailing list