[aprssig] The new N-N paradigm summary (fwd)

[Greg Noneman]

Bob,

I have been following the threads on this subject and have been 
collecting data on the network traffic in the Southern California area. 
  We are trying to organize a meeting of digipeater owners to discuss 
future operations in the area.  Seeing Cap's message (and the various 
responses) has prompted me to add my two cents.

First of all, correct me if I'm wrong, but I see the main motivation 
for your new N-N paradigm is to minimize the amount of flooding in high 
congestion areas due to excessive WIDEn-N paths (WIDE5-5, WIDE7-7, 
etc.).

Now I'm not going to disagree that the SoCal area is a heavily 
congested area and that a 5W tracker doesn't get into the network 100% 
of the time.  But contrary to what you might expect, I believe the 
probability of this 5 watt tracker getting into the local network is 
higher today than it was four years ago.   The reasons for this are the 
bandwidth savings associated with WIDEn-N and the education and gradual 
adoption of WIDEn-N by the local users. I realize this goes against 
what you are now arguing for, but in our particular situation, I 
believe it to be the case.

I tend to agree with Cap that getting rid of WIDEn-N and going back to 
generic RELAY and WIDE would be a  step backwards in our area.  Here 
are my arguments:

1)  Excessive WIDEn-N paths have an insignificant impact on channel 
loading in the Los Angeles/Orange County area.  When you first proposed 
the change, I took a sample of data in the area.  I then analyzed the 
data to determine the paths used for all packets.  Here are the results 
(expressed as a percentage of total packets):

WIDE2-2		51%
Hops <= 1	4%
Hops <= 2	58%
Hops <= 3	89%
Hops <= 4	98%
Hops <= 5	99%
Hops > 5		0.7%

I was pleasantly surprised to see the 51% WIDE2-2 statistic, since this 
is the generic path the we have been pushing for several years.  It 
would be nice to see some of the WIDE3-3 users (19% of total) cut their 
path length down, so there's still some work to be done, education-wise 
(this applies no matter what paradigm you follow).  What does stand out 
is the relatively low number of "excessive" length packets.  Now, this 
may be different in other parts of the country, but as you can see, the 
number of packets coming from DX stations here is very low.  Yes, we 
see the beacons from the Nevada, Utah, Colorado, etc., but these occur 
very infrequently.  I don't think they can be blamed for the 
congestion.


2)  Going back to RELAY and WIDE is going to increase the total 
bandwidth for each packet launched.  The reason for this is two-fold.  
To illustrate this, I quote your DIGIS.TXT file from several years ago:

(a)  "SHORT PACKETS!  The biggest advantage of WIDEn-n routing is that 
every packet still only has one DIGIpeater call.  This means that only 
7 bytes of overhead no matter how far the packet goes..."
Nothing has changed here.  Certainly a WIDE2-2 packet is shorter than 
WIDE,WIDE.  Increase the path length and the problem gets worse.

(b)  "For four years, we have been asking for someone to develop the 
WIDEn-n digipeater code. The WIDEn-n digi simply repeats ANY packet 
with the VIA address of WIDEn-n; but ONLY ONCE.  It keeps a copy (or 
checksum) of the last 30 seconds of packets, and compares each new 
packet that it hears with the last ones to avoid dupes. This completely 
eliminates the multiple looping of packets caused by multiple generic 
paths such as WIDE,WIDE,WIDE.  Without WIDEn-n, such a three hop path 
launched in the middle of 3 WIDE digipeaters that all hear each other 
can generate as many as 3x3x3 or 27 dupes!  In a WIDEn-n network, there 
would only be three packets outward bound 3 hops."

This is the main problem I have with getting rid of WIDEn-N in SoCal.  
The example you quoted above is entirely possible in the SoCal area, 
and in 2000, I participated in some testing that showed the massive 
duplicate packet generation created by use of paths with generic RELAY 
and WIDE.  This is what prompted us to go away from the use these paths 
with our digis.   I have heard that Kantronics has released a version 
9.0 ROM, but reading the new manual, I have not seen any indication 
that the anti-duplication algorithm has changed to extend the more 
robust checksum method used on UIFLOOD and UITRACE to the UIDIGI 
callsign entries.  If this is the case, the same problem that you 
described in 1998 still applies today.

3)  Discounting 1) and 2) above, if WIDEn-N was eliminated, what is to 
say that the same people who are using WIDE5-5 currently won't 
eventually switch to WIDE,WIDE,WIDE,WIDE,WIDE.  People seem to forget 
that several years ago (before the popularity of WIDEn-N digis) this 
was a very serious problem.  At least when they went to WIDE5-5 the 
packets got significantly shorter (per 2a, above).  Bottom line is, if 
people want the long path, they're going to find a way to get it 
(unless we go to smarter digipeaters).

4)  The UIFLOOD and UITRACE  commands of the KPC-3 TNC are two of the 
most powerful parameters for APRS operation.  Your new N-N paradigm has 
removing WIDEn-N and TRACEn-N from these parameters and replacing them 
with LINKn-N and SSn-N.  While I can see the utility of  the ##LINKn-N 
feature in areas with one (or a few) major highways running through 
town, the fact that SoCal has many many major interstate, US and state 
highways running through the area would seem to make this impractical.  
You mention that this feature might be beneficial for the long-haul 
trucker who wants to directionally flood his packets along a major 
corridor.  To me, this seems like too valuable a parameter to dedicate 
to a relatively low percentage of APRS users.  You mention using SSn-N 
for state or ARRL section routing.  I don't know what others think, but 
I just don't see these being used much.  The beauty of WIDEn-N and 
TRACEn-N is that they work (or should) everywhere.  Many users don't 
want to worry about (or in some cases CAN'T) easily change paths as 
they move from highway to highway or region to region.  You may say, 
"Well you can always stick with RELAY,WIDE. It will work everywhere", 
but if you're saying that the vast majority should use RELAY,WIDE it 
seems like you're just wasting the power of the UIFLOOD and UITRACE 
parameters.

I have more, but I think I've exceeded my word count for one evening:)  
I know I sound pretty negative on your proposal, but I do want to talk 
with others in the area and come up with a group decision on which way 
to go.  I appreciate your efforts to address this issue.  To me, the 
best way to optimize performance is to continually remind people of the 
importance of minimizing their on-the-air time (less is more):

-  Use the shortest path necessary
-  Beacon no more frequently than necessary
-  Keep position packets as short as possible (Mic-E based units (D7, 
D700, etc.) have big impact)
-  Minimize use of text messages and other excessively long packets

As you have demonstrated before, a small change can have a remarkable 
impact when it is multiplied across the many users of a network.


73,
Greg
WB6ZSU
Orange County, CA



On Jan 4, 2005, at 8:14 AM, Robert Bruninga wrote:

> Cap,
> Thanks for your good opinion on the true potential of un-abused
> WIDEn-N.  But you can do all of what you want under the new
> n-N paradigm and keep WIDEn-N too.
>
> 1) California can keep WIDEn-N and continue to focus on
>     education to keep people from routinely using anything over
>    W2-2.   And, as you say,  using ONLY W2-,2 instead of
>     WIDE,W2-2 is prefererd to reduce dupes.   (but change the
>    digis to UITRACE WIDEn-N so that the source digi is retained).
>    Then you still have WIDEn-N but can use UIFLOOD for
>     ##LNKn-N's as a bonus.  (No need for TRACEn-N anymore)
>
> 2) OR.. Change them all to the state version of CAn-N and it will
>     work identically to your existing WIDEn-N, yet protect
>     surrounding states from california abuses.
>
> 3) AND Use the Interstate LNKn-N's for backbones.  Dont worry
>     about local LA Basiin interstates.  They are already covered
>     by CAn-N or Wn-N if you keep it.
>
> When you say WIDEn-N works in California, I assume that means
> that a low power tracker running less than 5 Watts can be tracked
> anywhere  in Calif reliably.  That is the measure of "works" in APRS,
> not just a measure of how many other stations you can see which
> usually is a measure of "QRM" and not reliability.
>
> Bob