| |
ZL3AI > APRDIG 02.10.03 10:19l 327 Lines 16445 Bytes #999 (0) @ WW
BID : 2048-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 4/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<
ON0AR<VK6HGR<VK3AVE<ZL2BAU<ZL3VML
Sent: 031001/1346Z @:ZL3VML.#80.NZL.OC #:9448 [Chch-NZ] FBB7.00i $:2048-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI part 2
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 13:58:58 -0500
X-Message-Number: 18
>LOCAL CONTROL: Advantage #1 is that it gives sysops some control over
>incoming DX packets without disabling local operation and without hacking
>up the standardized fundamentals of APRS. (RELAY,WIDE or WIDE,WIDE should
>work everywhere) (and for DX, WIDEn-N should still work)
What control does a local digipeater have beyond limiting the hops beyond
using the simple WIDE and RELAY paths that limit the hops to 8 in the AX.25
protocol?
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:
(these example are for education purposes only and are not intended to
offend or single out the stations identified as causing any problem on the
network)
KE4ROC-9>BEACON,RELAY,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,RELAY*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,W4GPS-7*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,W4GPS-7,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,WC4ADG*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,WC4ADG,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,RELAY,W4SBO-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX
StationKE4ROC-9>BEACON,WC4ADG,W4GPS-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000
WX Station
KE4ROC-9>BEACON,RELAY,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
The first issue is user education. The transmitting station should not be
using RELAY since they can hit a WIDE digipeater directly, but this could
easily be a mobile station traveling through the area.
In this equation, KE4ROC-7 is a Kantronics digipeater using no callsign
substitution. W4GPS-7 is a local WIDE digipeater. WC4ADG is a local APRS
station at the EMA office. W4SBO-7 is a WIDE digipeater located at the next
largest population mass outside of Huntsville.
The second line in the packet listing shows that KE4ROC-7 has digipeated
the packet without callsign substitution.
The third line shows W4GPS-7 acting on the RELAY in the path and
substituting its callsign in place of the RELAY as advocated by WB4APR.
The fourth line shows KE4ROC-7 digipeating what comes from W4GPS-7 without
callsign substitution. This is a Kantronics digi that does not understand
that it digipeated the first RELAY of this packet. Then again, how could it
understand it because the packet path has been altered with callsign
substitution by W4GPS-7. Otherwise, it might have a chance in understanding
that it already digipeated this packet. This is a problem with callsign
substitution in present day network!
In in fifth line, we see WC4ADG finally get a chance to transmit a response
to the first RELAY in the path and employ callsign substitution. Dupes are
suppose to be OK but watch what happens next.
In the sixth line, we see that KE4ROC-7 once again digipeats a packet from
WC4ADG because it does not understand it already digipeated the packet as a
RELAY and as a WIDE for the third time. Do you start to see the problem
with callsign substitution. Does the Kantronics not have the ability to
understand callsign substitution exists?
In line 7, we see W4SBO-7 respond to the WIDE with callsign substitution in
the path as sent from the RELAY at KE4ROC-7.
In line 8, we see W4GPS-7 respond to the WIDE with callsign substitution in
the path as sent from the RELAY at WC4ADG. Again, we see another example of
a digi not being able to understand it has already digipeated the packet as
a RELAY previously. What I see happening here is that neither Kantronics
nor UIDIGI seem to handle callsign substitution and realize they have
already digipeated this packet. Is callsign substitution a problem here?
In line 9, we see W4GPS-7 respond to the WIDE with callsign substitution in
the path as sent from W4SBO-7 that also substituted the WIDE with its
callsign earlier (UIDIGI).
In the last line, we see KE4ROC-7 respond to the WIDE from W4GPS-7 without
callsign substitution. KE4ROC-7 is a Kantronics digi that does not
understand that it has already digipeated the same packet for the 4th time.
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.
I think we need to address this problem. 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.
Let's take a look at another example of what happens in a RELAY,WIDE2-2
scenario:
WC4ADG>APS214,RELAY,WIDE2-2/1:>251458z[214]Huntsville / Madison County RACES
WC4ADG>APS214,RELAY*,WIDE2-2/1:>251458z[214]Huntsville / Madison County RACES
WC4ADG>APS214,W4GPS-7*,WIDE2-2/1:>251458z[214]Huntsville / Madison County RACES
WC4ADG>APS214,W4GPS-7*,WIDE2-1/1:>251458z[214]Huntsville / Madison County RACES
WC4ADG>APS214,W4LAW-2*,WIDE2/1:>251458z[214]Huntsville / Madison County RACES
In the above example, the second line shows KE4ROC-7 without callsign
substitution acting on the RELAY.
Line three shows W4GPS-7 with callsign substitution acting on the RELAY.
Line four shows W4SBO-7 acting on the WIDE2-2-2 and counting down to
WIDE2-1.
Line five shows W4LAW-7 acting on the WIDE2-2-2 and counting down to
WIDE2-1. W4LAW-7 uses a Kantronics that ID's as a NOID digipeater, but it
indeed operates as an ID digipeater by performing a callsign substitution
where it should not replace the callsign already in the RELAY slot. This is
a problem not only here but when W4LAW acts on any WIDEn-N it will replace
the callsign in that slot altering the packet path since it operates as a
WIDEn-N ID digi.
This is another example that callsign substitution and ID WIDEn-N
digipeaters are not good for this network. Not only does it cause altering
of the packet path and duplication issues, but it also hides the fact that
it is a dupe on FindU since the packet path has been altered and none of
the systems seem to be able to handle this in their dupe checking. Thus, in
effect our APRServe network cannot handle these types of duplicates either
and in turn increases the Internet backbone traffic with duplications.
Below is a pure WIDEn-N example of no drastic flooding in this area, but
the main difference is there is no callsign substitution taking place to
muddy the clean path it takes. By the way, fewer digipeaters are tied up
with this traffic and the bandwidth is conserved. This works very well to
avoid dupes caused by callsign substitution and misconfigured WIDEn-N digis
that DO NOT employ true NOID handling.
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
In the above example, compare the traffic to that of the RELAY,WIDE,WIDE
path shown earlier with numerous dupes at various digipeaters. What is
different here. KE4ROC-7 and WC4ADG do not handle WIDEn-N traffic. in this
case we only see Hiding's in operation. The second and third line show
W4GPS-7 and K4GIG-7 responding to the first WIDE3-3 request in the path and
W4SBO-7 responding to the WIDE3-2 from W4GPS-7. There is no duplication
here and how does this flood some distant location. Please compare it with
the RELAY,WIDE,WIDE example earlier to see that WIDEn-N is not going to
cause any more problem than the RELAY,WIDE,WIDE example. The effect of
WIDEn-N is far less in this example.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 13:59:22 -0500
X-Message-Number: 19
>The solution has been staring us in the face for years and I am amazed it
>never occurred to me until this week. Turn off WIDEn-N FLOODING algorithm
>in areas that need to limit Distant QRM. But protect it in areas where it
>is needed by giving it a place (IGate) where it can dump the traffic on
>the edge of town. Here is the plan:
For the traveler, this adds confusion and an incompatibility in the system
if WIDEn-N is not globally accepted. The communications link will be broken
for the casual traveler. The last thing I need to be worrying about is
constantly fiddling with my radio on the road to make sure I have the
correct path set. This type of operation would most likely cause me to turn
off my radio to stop the frustration and slide a CD in my player and listen
to some soothing music. When the system becomes complicated wit ha bunch of
rules because the system lacks the intelligence to control misguided
behavior, there will always be frustration.
>DUPES AREN'T BAD: Not ALL DUPES are bad. APRS needs some redundancy in
>order to improve the probablity of receipt. No dupes means some packets
>are probably being lost. 3 dupes is too many. So judge the network on
>these realistic expectations. Silence is also good.
This depends on your definition of dupes. There are some dupes that are a
direct result of a misconfigured system and callsign substitution. I am
talking about when a digi or other system mungs the packet path and the
other digi cannot determine that it is a duplicate. See the multiple
examples earlier in this post that support this comment.
>PATH INJECTION: For network management, we want all packets to self
>identify their point of entry into the system. This means we want
>all packets to begin with either RELAY or WIDE so that the first digi
>can do callsign substitution and the packet will arrive everywhere
>with that knowledge intact. (We can turn off TRACEn-N too!) We dont
>need to Trace DX, where we dont want DX anyway)...
There are some issues with this type of strategy. The first is the
assumption that all digi's will substitute their callsign in place of the
RELAY and WIDE entries. When this happens, you have packets with altered
paths that may get duplicated. I know you say duplication is good in some
cases and I will not disagree, but the fact that a duplicate occurs because
the packet path is altered is different. FindU does filtering of packets,
but the altered packet paths are a little disturbing because most systems
cannot differentiate the same original packet that gets bastardized by
non-conforming digipeaters. In this case, WIDEn-N is better, but then again
you have those improperly configured digipeaters that bastardize the packet
path causing some digipeaters to duplicate a packet that has been altered
by another. In essence I think the proper configuration of digipeaters is a
bigger problem than WIDEn-N and I am will to bet the farm it can be easily
be proved comparing packets of WIDEn-N and WIDE directed to the same number
of digipeaters in their path. The WIDEn-N will statistically makes its
journey more times than the WIDE designation of the same path. Just look at
the examples.
Perhaps, I am missing the boat completely at this point. If so, I am open
to what is wrong with the logic.
>HOME RELAY's OFF: In 1994, the model was ALL aprs stations can serve
>as a RELAY to help others. Now we must cut that back to make sure
>that RELAY is OFF except where needed. And RELAY-only digis should
>be doing callsign substitution. The rule is simple. If a mobile
>in the vicinity of your home station can also hit the local digi,
>then your RELAY should be off.
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 reduced the number
through discussion with those that do not understand the impact. However,
it is callsign substitution that causes a bigger problem in duplication of
packets.
>MULTI-HOPS: Remember, at any time and even by remote-sysop control in
>local WIDEn-N can be re-enabled to support any special needs. Also there
The problem with this idea is the issue of maintenance. If it requires
continued human intervention there will be issues.
>is NOTHING wrong with using WIDE,DIGI2,DIGI3,DIGI4 if you need a packet to
>go beyond your LAN to DIGI4 area for example. This cuts APRS back to
>LOCAL FLOODing (WIDE,WIDE) which is what it was designed to do, and
>limiting DX FLOODING in busy areas. And it forces long hop needs into
>linear paths that reduce QRM by the SQUARE of the number of hops.
What is the difference between WIDE,WIDE and WIDE2-2 ?
In my view it is 7 bytes less data and increased reliability of the shorter
packet using WIDEn-N.
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.
Please help us to understand the difference between WIDE2-2 and WIDE,WIDE
paths. Be sure to include the math of the extra data at all the digi's
affected in the size of the payload along with accounting of the longer
WIDE,WIDE payload not making the haul but still causing interference by
being undecoded. The later is hard to determine because you do not have
decoded data.
>ABUSE: Users can still try to use W,W,W,W,W,W, But the fix is easy,
>because now whe have a universal rule that works everywhere. THus we
>can now HARD filter only W,W,W,W,W,W type packts where the number of W's
>is greater thatn X and X is now a LOCALLY determined limit. People who
>still need long paths can use N-N paths becasue now we have designed our
>system to handle them where they can be supported! Again, simple rules
>that work EVERYWHERE, and simple fixes.
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.
>PROPOSAL: Again, I am not saying that -you- should turn off WIDEn-N in
>-your- area. I am saying, however, that I can fully support this as a
You will in effect turn it off if you use another flooding name.
How many different names will a digi support?
>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.
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.
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.
3. Educate users and digi owners at club meetings, through club
newsletters, through QST, hamfests, etc.
4. Educate weather stations and fixed users to remove RELAY from their path
if they can hit a WIDE directly.
73's,
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
