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

[Wes Johnston]

Greg is right... he makes a good point about the lids running r,w,w,w,w,w,w
eventually... it sure would be nice if we could limit the hops using either
Wn-n or w,w,w.  Well, we _can_, but it requires a PC and a floppy disc.

I guess the trick is to tell the lids about too many hops when they come to you
asking why WIDEn-n isn't working anymore!  8-)
Wes
--



Quoting "Phillip B. Pacier" <ad6nh at arrl.net>:

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