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

[Phillip B. Pacier]

Greg, how do you account for the packet traffic in areas that have 
dropped WIDEn-N going down significantly?  Sure, you're not going to get 
everyone to get on any same page, but there are two truths that must be 
addressed:

RELAY MUST be supported for mobiles.  There is no reason why a mobile 
should have to change their path when they go from metro to rural to the 
next metro.

Second, it is precisely the WIDEn-N that is bringing in packets from 
Colorado, Utah, etc. into southern California via the high-level 
digipeaters.  K6TVI-1 has made the switch and dropped WIDEn-N, and since 
that has happened I have not seen the 500 mile packets.  If you really 
think it's necessary to leave a WIDEn-N digi or two down low in the 
basin, that's fine, but RELAY should be supported for mobiles passing 
through.  I'll never forget when I first went mobile APRS back in 2000 
and I read on Bob's page that mobiles should be set to RELAY,WIDE.  I 
wondered for days why I couldn't get any packets out, and I still get 
questions from new mobile operators.  There needs to be a standardized 
mobile path.

San Diego and Yuma are on the new system and things are working great so 
far.

73
Phil - AD6NH
http://www.aprsca.net

Greg Noneman wrote:

> 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
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>