| |
ZL3AI > APRDIG 02.10.03 10:10l 395 Lines 16996 Bytes #999 (0) @ WW
BID : 2050-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 6/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
LU6DTS<ZL2TZE<VK3KAY<ZL2BAU<ZL3VML
Sent: 031001/1358Z @:ZL3VML.#80.NZL.OC #:9450 [Chch-NZ] FBB7.00i $:2050-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI (1)
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 17:19:52 -0400 (EDT)
X-Message-Number: 29
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>OK I am taking the bait....
>
>Turning off WIDEn-N will not solve the over loading problem on
>the local LAN. The problem is not WIDEn-N. The problem is a
>fundamental philosophical APRS issue, digipeater owner
>understanding of how the network should work, and an end user
>education on how and why the PATH setting causes problems.
I think you missed the point but we agree almost completely. My WIDEn-N
fixes are just PART of the overall fix. The BIG FIX is based on these
conerstones:
1) We return to a support of RELAY and WIDE in all local area networks.
2) We educate everyone about the ALOHA circle concecpt and the golden
rule "Thou shalt not QRM your neighbors beyond the nearest 50).
3) The default path for everyone is RELAY,WIDE for mobiles or
WIDE,WIDE for others (or DIGI1,WIDE)
4) Use of multihops beyond your 50 user LAN is NOT WELCOME in general
5) USERS MUST BE EDUCATED in the above 4 rules.
Now, all of my WIDEn-N concepts are a simple cold-turkey way of cutting
off incoming DX that is flooding some networks and giving the SYSOP an
immediate way to take control. THen the LANn-N concept is another tool
to let the SYSOP help enforce #2, that is, keep packets within workable
LANS.
Sure, WIDE7-7 is more efficient than W,W,W,W,W,W,W, but that is not the
point. The point is that our network in MOST areas cannot afford
anything more than 2 hops. And, since we want netork point of entry,
then even tto get 2 hops with WIDEn-N you have to use WIDE,WIDE1-1 which
is pointless. THus, lets abandon LONG paths with WIDEn-N entirely and
use the UIFLOOD paramter much better. As in the LANn-N and LINKn-N
concepts...
>Add to this the frequency of a user beacon and how it
>affects some distant location outside their local area. Add the
>growing popularity of APRS and the addition of weather
>stations and the load has naturally increased. Again, WIDEn-N
>itself has nothing to do with the end result of the load or the
>QRM.
Unless you turn it off completely and convert the multi-hops to linear
paths (LINKn-N concept) or self limiting LANS (as in the LANn-N
concept..)
>The bottom line is WIDE7-7 performs no differently ...
>... to WIDE,WIDE,WIDE,WIDE,WIDE,WIDE,WIDE....
But we aint gonna do none of that no more...
>This has everything to do with user education. It is no
>different than educating folks digipeating through the ISS. It
>is a constant battle and one that never ends.
Ah, but the problem is that right now in APRS, we cannot even get TWO
sysops to agree on what is the correct settings, much less get agreement
on what to tell the users. That is what I am trying to force. Lets get
back to BASICS and get EVERYONE to march to the same tune, and not until
then can we have any hope of educating the users...
Bob
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI (2)
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 17:21:16 -0400 (EDT)
X-Message-Number: 30
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>There is a fundamental problem with the RELAY,WIDE aspect,
>especially, when a digipeater is configured to perform callsign
>substitution. Let's take a look at a local reality example of
>something I think is far worse than using WIDEn-N:
Any example should use only RELAY,WIDE, or WIDE,WIDE, because from now on
out, we are not going to welcome ANYTHING longer. If you want to go
farther than 2 hops, you MUST use WIDE,WIDE2-2 or WIDE,LAN2-2, or
LINK2-2, or whatever....
AGAIN. COMMON RULES for the users... that will work everywhere...
>My analysis is that callsign substitution, as advocated by
>WB4APR, is not a good implementation when the current digpeaters
>do not understand that the packet path has been altered by
>callsign substitution by neighboring digipeaters.
This is where everyone is throwing out he baby with the bathwater. The
original path of RELAY,WIDE or WIDE,WIDE may generate an extra DUPE or
so, but it aint going no farther than the original 2 tier system that
needs to get it reliably in the first place. And callsign substitution
assures that NO DIGI will ever do the same packet twice.
>...At the current time with the given digipeater firmware available, I
>think callsign substitution is a bad idea in this area and in most areas
>that employ callsign substitution. We should rely on TRACE for that
>purpose when it is necessary to debug the network issues. This example
>should speak for itself and how callsign substitution causes packet
>duplication.
Callsign substitution is not the problem. Callsign substitution assures
no dupes from any digi.
>N8DEU-4>APS221,WIDE3-3/1:=3444.17NI08639.33W&PHG4330 Huntsville Alabama
Madison Co IGate
>N8DEU-4>APS221,WIDE3-2/1:=3444.17NI08639.33W&PHG4330 Huntsville Alabama
Madison Co IGate
>N8DEU-4>APS221,WIDE3-2/1:=3444.17NI08639.33W&PHG4330 Huntsville Alabama
Madison Co IGate
>N8DEU-4>APS221,WIDE3-1/1:=3444.17NI08639.33W&PHG4330 Huntsville Alabama
Madison Co IGate
But it still produces a flood of from 21 to 36 copies of the same packet
going out a hundred or more miles in all directions. You are only
shwoing the 4 heard in the general area of where it started.
We can no longer affford to flood our networks...
>Here are some examples of no callsign substitution along with NOID
>WIDEn-N digis:
>
>K4GIG-7>S4TT9V,RELAY,WIDE2-2/1:'rDFog#k/]"61}
>K4GIG-7>S4TT9V,RELAY*,WIDE2-2/1:'rDFog#k/]"61}
>K4GIG-7>S4TT9V,RELAY*,WIDE2-2/1:'rDFog#k/]"61}
>K4GIG-7>S4TT9V,RELAY*,WIDE2-1/1:'rDFog#k/]"61}
>K4GIG-7>S4TT9V,RELAY*,WIDE2-1/1:'rDFog#k/]"61}
We must remove all non-callsign subsitituting DIGIS from service ASAP.
We can no longer afford to have any digis that dont do callsign
substitution....
>K4DOH>CQ,RELAY,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,RELAY*,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,WC4ADG*,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,WC4ADG*,WIDE2-1/1:>TinyTrakII v1.00
>K4DOH>CQ,WC4ADG*,WIDE2/1:>TinyTrakII v1.00
>K4DOH>CQ,RELAY,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,RELAY*,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,W4GPS-7*,WIDE2-2/1:>TinyTrakII v1.00
>K4DOH>CQ,RELAY*,WIDE2-1/1:>TinyTrakII v1.00
>K4DOH>CQ,WC4ADG*,WIDE2-2/1:>TinyTrakII v1.00
Solution is easy. Get rid of the RELAY (without substitution digi)
and get rid of the WIDE2-2...
>My point is that WIDEn-N is not the problem. We have other bigger
>problems wasting bandwidth on the APRS network.
I disagree completely. Get rid of ANY long hops (most abused by WIDEn-N
users, get back to LOCAL use of APRS within the local 50 user ALOHA
circle and you will have a reliable network... FAR more reliable than it
is today...
Bob
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI (3)
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 17:21:56 -0400 (EDT)
X-Message-Number: 31
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>1. Do we need callsign substitution?
> I think it causes more duplication than anything because the
> present day digis do not handle duplicate packets when the
> path has been altered by another digipeater.
No, its because we are not using the network right..
>
>2. Some digipeater owners still do not understand how to configure
> their WIDEn-N as a NOID digipeater. This causes duplication of
> packets because the path is altered.
Yes, we must get all digis to NOID...
>3. WIDEn-N works perfectly well when no callsign substitution and
> WIDEn-N digis are configured as NOID.
Yes, and even better when the WIDEn-N digis are in the middle of the
great out-west where packets can go hundreds of miles and still not QRM
more than 50 people in the area...
It also will work perfefctly well, when SYSOPS limit n-N paths to LANn-N,
where irregardless of the size of N, the packet cannot propagate beyond X
digipeaters no matter what...
>>UNIVERSAL: Advantage #2 is that it can be applied to ANY existing
>>digipeater. It doesnt require special ROMS or new hardware AND Draconian
>>filtering. Disabling WIDEn-N in selected digis is something that can be
>>done now, today, on ANY digi and it can even be done remotely! AND it
>>puts the solution to the LOCAL problem Local.
>
>I must be missing something. 7 WIDE's in my path is no different
>than a WIDE7-7 as far as the area that is going to be covered.
We are never going to tolerate that kind of abuse. It is killing us...
>In every case I have approached a local station about the misuse
>of the WIDEn-N, I found it was they did not understand how it
>worked....
Yes, that is why we * must get back to basics*. And then we can educate
EVERYONE at once...
>I would really prefer to use RELAY,WIDE2-2 in the mobile versus
>RELAY,WIDE,WIDE and save the 7 bytes. The use of WIDEn-N in this
>case is not going to make any difference how far it travels. It
>is simply going to increase the probability of the shorter
>packet payload to make the trip.
Ah, but I want us to get away from even 3 hops and get to 2. Now, at 2
hops, beginning with RELAY, you have the choice of RELAY,WIDE1-1 or
RELAY,WIDE. Guess what, the one with WIDE1-1 does not do callsign
substitution and therefore does not do ANY dupe elimination. THus
RELAY,WIDE is the more powerful dupe elimination process.
>>NO MORE FLOODING: There is a reason we named the WIDEn-N parameter in
>>the digis as UIFLOOD. The intent of a WIDEn-N packet is to FLOOD the
>>network. We can no longer afford that kind or RF polution.
>
>I can only agree that the function works as intended, but it is
>not the problem.
I cannot see how you can possibly draw that conclusion. A FLOOD of any
single user that floods beyond his ALOHA circle of the 50 nearest users is
beyond what the 1200 baud channel can reliably accomodate.
>What I see happening is if we remove WIDEn-N from the network,
>the person who uses the WIDE6-6 will learn that WIDE,WIDE,WIDE,
>WIDE,WIDE,WIDE will accomplish the same job.
AH, but we are not removing WIDE6-6 from the network. We are encouraging
it. Because in those areas that can tolerate 6 hops because of very low
population density, then the 6 hop packet will work perfectly.. But in
other areas where it would propagate into an already overlaoded LAN, it is
stopped at the border. And the local sysop there had the choice...
But the RULE WILL BE that MULTIPLE WIDES,WIDES,WIDES, is BAD PRACTICE.
And now we have ONE RULE that applies everywhere. But if we keep trying
to say that WIDE3-3 or WIDE5-5 is BAD, then we are making it impossible
to use them. They CAN be used to do good in APRS. But
WIDE,WIDE,WIDE,WIDE can NEVER be considered good. THUS we finally get
back to a set of rules that works EVERYWHERE...
That is my objective ..... CONSISTENCY so that we can TRAIN the users
EVERYWHERE... and it will work EVERYWHERE. And within those simple
rules, we can still use WIDE5-5 if we want to and it will not cause
damage where it is NOT wanted.. Not shouting here, just emphasizeing the
key words...
>If you do this now, you have to start re-education process all
>over. I think this is going to confuse the APRS population for
>some time to come and could potentially distract some potential
>players with complication. The use of WIDE and WIDEn simply
>stated is very trivial or I do not understand the problem at
>all.
We agree. Nothing could be simpler than using RELAY,WIDE or WIDE,WIDE.
or any combinateion of WIDE,WIDEn-N or WIDE,LANn-N and we no longer have
to care what N is. The QRM is limited by how we layout the WIDEn-N in
the wilderness and the LANn-N's in the cities or LAN boundaries...
>From what I have read in this post, WIDEn-N is bad. That seems
>to be the underlying message because users abuse it. What I see
>happening is the WIDE6-6 user moving to WIDE,WIDE,WIDE,WIDE,
>WIDE,WIDE. Then, what have you accomplished?
Very simply. We have accomplished CONTROL over the damage of WIDEn-N
while still allowing it to be used. and we have DECLARED BY DECREE that
any combination of WIDE's beyond 2 hops in most areas is BAD AMATEUR
PRACTICE. Now we have a consistent rule and we can start educating...
>This is too confusing for Joe HAM. If you want to simplify
>it then eliminate WIDEn-N completely.
I think that as this becomes more clear, people will understand that it is
really a return to basics and only a few simple rules that will work
everywhere if properly applied by SYSOPS. That is the neat part, is tht
SYSOPS can now finally do something about the mess instead of hacking the
system to inoperability...
>For the traveler, this adds confusion and an incompatibility in the
>system if WIDEn-N is not globally accepted.
Its not now. That is what is broken, ther is no one path works all path
becuse so many local SYSOPS have totally broken the network by droping
RELAY or WIDE. If we get back to basics, RELAY,WIDE will work everywhere
and will NOT be a problem...
>In our area RELAY's are a bigger problem than WIDEn-N. There are
>too many that explode into action on the same packets. We have
I agree completely. We must get all home-RELAY's off by default, and then
only turn on the ones that are in locaitons where a RELAY only digipeater
is needed, and it must do callsign substitution...
>If we turn off WIDEn-N in this area after it has been preached
>for so long it will take time for folks to get back up to speed.
>Maybe a better use of WIDEn-N here will be to change it to ALn-N
>for a flooding of the state of Alabama and we can keep all of
>our NWS weather bulletins in the state.
Yes, that is exatly the LAN-N concept. AL7-7 will hit every digipeater
in alabama if that is the intent but it will go no further. But this
will not be reliable if ther are more than 50 users in Alabama. If so,
then there will be lost data...
>The problem now is we will all be confused by what name the N-N
>path will be called if it is not WIDEn-N. I think we are breaking
>something that is trivial and not the real issue.
Doesnt matter. WIDEn-N will still work anywhere (where it can be
tolerated) but RELAY or WIDE will work everywhere. And if someone is
going to move to Alabama and wants to QRM the whole state with AL7-7,
then you want him to "learn about the local LAN", first , not just flood
the area because he drove intot he state...
>>BOTTOM LINE. We must get APRS back to some fundamental rules that work
>>locally everywhere so that:
>>
>>1) We can publish those rules and educate users
>>2) APRS will work locally EVERYWHERE
>>3) SYSOPS will have a GUIDING objective to build to
>>4) We wont have local hacks that destroy the system
>>5) Long haul on RF will still work where needed
>>6) There are no draconian arbitrary rules being imposed locally>
>
>How long has it taken to get to this point with some generally
>accepted rules. Changing them now to work around the real problem
>only prolongs the education cycle to the point it may never
>happen. Let's work on the issues we face in the reality of the
>network and what it can accomplish for us today.
The problem is that not even the sysops are marching to the same tune,
because some of them think that the ideal network should be able to see
500 uers from the surrouding 500 miles. This is killing APRS...
>My proposal would be the following:
>
>1. Eliminate callsign substitution immediately. It causes more
> duplication than any good until digi firmware and FindU can
> recognize the duplication.
Totally a wrong approach. Callsign substituion ELIMINATES dupes
completely an djust as effectively as WIDEn-N filtering given that we
want first hop identification...
>2. Digi owners need to implement NOID now or turn off WIDEn-N
> support. We can identify the ID digi's very easily and contact
> them to make the necessary change.
Agree.
>3. Educate users and digi owners at club meetings, through club
> newsletters, through QST, hamfests, etc.
To WHAT? I say to these simple rules:
Mobiles RELAY,WIDE
Homes WIDE,WIDE
All home stations disable RELAY Alias unless their QTH is ideal
All old MYALIAS TNC's tht do not do callsign substitution should
be upgraded.
Using WIDE,WIDEn-N will continue to work and may be used, but its
long distance propogation will only go where the network thinks
it CAN go without damage
Find out what the LANn-N name is for your group or area and use it.
>4. Educate weather stations and fixed users to remove RELAY from
> their path if they can hit a WIDE directly.
Yes. Furhter, decide where the weather data needs to go, and set up
a SKY path to match. Thus, all the skywarn data all goes wehre it
needs to go, but does not add unnecessary QRM...
ANyway, thanks for the comments.
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
