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

[Greg Noneman]

Phil,

See embedded responses.

On Jan 5, 2005, at 7:20 AM, Phillip B. Pacier wrote:

> 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:

I am not surprised that this has happened.  If you make sudden changes 
at the digipeaters without giving users time to react, you will see a 
lot of users not getting digipeated.  What I would expect to see, is a 
gradual increase  after the initial transient.  Whether it returns to 
the original levels or not depends on the particular situation.  In 
some cases it could remain less, but on the other hand, I could also 
see things getting worse, due to the problem I mentioned due to 
duplicate packets being generated with RELAY and WIDE  vs. WIDEn-N.

>
> 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.

I understand the desire for having common national path.  Believe me, 
this was considered when RELAY was dropped from high-level digis in 
favor of WIDEn-N only.  It was a compromise that was made.  But the 
hope was that the extensive network of home stations using an alias of 
RELAY would accommodate those stations with RELAY as a first hop.

>
> 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.

I agree that WIDEn-N was bringing in these stations.  But, is one 
packet an hour  from a handful of DX stations really going to kill the 
local network.  Also, if everyone suddenly got rid of WIDEn-N, what do 
you think these DX digis would do to their paths?  Back to long WIDE 
paths, like was the case before?  And with this, the packets get REALLY 
long and can chew up a lot of bandwidth.

>  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.

As said above, the network of low-level home stations should provide 
the RELAY hop option.  If you monitor local traffic, you will see this 
often works (granted, not always).

> 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.

This was right during the massive transition to WIDEn-N.  The proposed 
"standard path" was in a state of flux.  As WIDEn-N was taking hold, 
new proposed "standard paths" were being considered.   First WIDE2-2, 
then RELAY, WIDE2-2.  I know Bob always wanted RELAY, WIDE to work 
everywhere, but the shortcomings in the Kantronics dupe checking 
algorithm for UIDIGI callsign entries vs. UIFLOOD and UITRACE make the 
use of paths such as RELAY, WIDE or RELAY,WIDE,WIDE with SoCal's 
digipeater system a disaster.  Reread the quote from Bob regarding dupe 
possibilities without WIDEn-N (2b in my original message) or, if you 
have a KPC-3 Plus manual, look at pages 149 and 150 to get an idea of 
the difference in duplications that can be created between the two 
options.  Granted these are worst case situations and don't frequently 
happen.  But believe me Phil, before WIDEn-N, we were getting many, 
many dupes that were really chewing up bandwidth.  If this dupe 
checking shortcoming was eliminated we would have a completely 
different situation.  Maybe version 9.0 fixes this, but the manual 
doesn't seem to indicate this.

> San Diego and Yuma are on the new system and things are working great 
> so far.
>
> 73
> Phil - AD6NH
> http://www.aprsca.net