[aprssig] Aprx v2 beta, now with Viscous Digipeater

[Robert Bruninga]

> The results [for viscous digipeating] are 
> visible on this article, [and] its graphics:
>   http://wiki.ham.fi/Viscous_APRS_Digipeater

First let me say that this is great info!  And I want to give
full support to this kind of research and testing.  We need more
rigorous research and testing in APRS and such testing needs to
be done to good standards...  (to avoid the downside of
meaningless testimonials)...

So, I hope you don't mind if I critique the study for
clarification and add some very strong CAUTIONS.  Such data
needs to stand up to the full rigor of review, such as...

1) It needs clarification about what the station IS?  I assume
it is at a location suitable to be called a FILL-IN digi?  If
so, this needs to be stated specifically.  

2) Also the exact environment of that FILL-IN digi needs to be
-well- quantified, or the data is meaningless.  Such as:

3) How many WIDE-AREA digis does the FILL-IN hear?

4) How many of those packets were heard DIRECT from users before
the first hop?

5) IMPORTANT: What is the relative RF signal strength of each of
the surrounding digis as heard on the FILL-IN exact antenna
location.  This is VERY important.  Because if any two of them
are within say 13 dB of each other, then this FILL-IN will NEVER
HEAR *any* packet heard by those two digis simultaneously and
will COMPELTELY skew the data to the point of being useless.

6) The meaning of the plots is not perfectly clear.

 A) The first chart is ALL packets heard?
 B) The second one is all packets NOT-Digipeated by this
FILL-IN?
 C) The third are the packets that the FILL-IN did not hear from
any other source, and so   it delayed and transmitted them?
 D) Each plot needs to indicate the RULES used.  Are these only
the subset of packets that are "heard direct by the FILL-IN" and
thus eligible for digipeating? (a classic outbound-fill-in
only), or all packets?(a new two-way-fill-in)?

The reason all of this is so important is issue #5 and #6 above.
The plot at the bottom which suggests the overall "value" of
visious digipeating can be *completely missleading* if it is
hearing two digis with near equal strength.  And in that case,
*all* of those packets could simply be *all* of the packets that
the FILL-IN did *not* hear because of  the fundamental APRS
network principle of fratricide designed-into the main digis.

If that is the case, then this last plot *could be* relabled as
*ADDED QRM, ADDED TO THE CHANNEL BY THE FILL-IN, BECAUSE IT IS
INCAPABLE OF HEARING EVERY PACKET FROM EVERY DIGI WITHOUT ANY
POSSIBILITY OF COLLISION*.

Thus, exactly the wrong result and proving the opposite
conclusion.

This is my biggest fear of this concept of "visious"
digipeating, because it abandons the fundamental principle of
APRS DIGIPEATING...

*****************************************************
* APRS digipeating  channel EFFICIENCY  is designed *
* around the  principle of "fratricide" which means *
* that all digipeaters  that hear a packet at the   *
* same time, are all supposed to have a D-wait of 0 *
* and all are  supposed to  re-transmit that packet *
* at the *same time*  so that a total of only ONE   *
* slot  time is consumed at  each outward radiating *
* tier in the network.                              *
*****************************************************

To do otherwise, is to add N delays to the network for EVERY N
digipeaters that all hear the same packet!  And typically, N is
maybe 4 or more.    Meaning, the undermining of Fratricide can
burden the network by a FACTOR of 4 times the QRM and dupes...
 
> The bottom graph is number packets sent 
> (per 10 minutes) by that node.
> At first with normal delayless digipeat, 
> and then with 5 seconds of viscousness 
> configured in.

Ah, now I see.  The graph needs a POINTER to show the boundary.
When I frist saw this, I thought the 5 second viscous delay
applied to the whole chart and the label was only where it is
because that is where it fit best.

> Really an excellent reducer of transmissions 
> for systems considered to be in a "fill in" role.

Depends on the exact environment... Can I ask you to add
clarification. FILL-IN to me has always meant a one-way-outward
function to help get weak mobiles in bad areas OUT to the
network.  Maybe here, you are talking about letting the FILL-IN
be a two-way-fill-in for all high level traffic and digipeating
it again locally (and adding QRM and collisions with other users
elsewhere)?  If so, this needs to be clearly indicated.

> The system has also tons of built-in default 
> behaviours documented elsewhere, like 
> limiting the total number of requested and 
> completed hops to 4 each.

I wonder how the function of all these draconian rules are going
to be unambiguously conveyed to the user who wanders into the
footprint of this digi and begins to see inconsistent results to
his normal expectations?

> One can freely put in a request like: 
>      OH2XYZ>APRS,WIDE2-2,WIDE2-2,WIDE2-2

Which violates the recommendations for APRS operations.

These violations should be fixed at the source by user education
and feedback.  Otherwise, human nature and psychological theory
predicts that this user will not know -why- he is not getting
out as he expects, and will only INCREASE the number of hops in
any way possible even up to 7-7,7-7,7-7 and just keep flooding
the network with MORE attempts instead of fixing *the* problem.

> Also if the New-N-request is written like:  
> WIDE3-6,   this one considers it bogus, 
> and drops it.

And then what?  Where is the mechanism for educating or feeding
back to the user his abuse of the system?  If the user needs 6
hops to attempt a DX packet, then he should use
DIGI1,DIGI2,DIGI3,DIGI4,DIGI5,DIGI6 and his packet will go where
intended with only 6 dupes on the system.  This 6 hop path
generates only HALF the number of packet as the usual WIDE2-2
(which would generate up to 12 copies in a typical area)...  Of
course, anyone with any knowledge of packet should realize that
the chance of that packet getting through is vanishingly small,
but still it is possible, and it does generate little QRM.

> Also, when this sees bogus UIDIGI output 
> of  WIDE3  without H-bit, this one sets 
> the H-bit and checks the next field for 
> possible trace/wide operation.  

This is a good fix.  Because the above packets are unfortunately
transmitted by some broken digipeaters or settings, and usually
these cannot be fixed by anyone at the source.

If there is no next field, no digipeat is done.

Again, I am not trying to degrade this experimentation.  In
fact, I like to see more of it.  But we must eliminate all
ambiguity in how the results of the testing are presented so we
can draw the proper conclusions.

> Further links:
>   http://wiki.ham.fi/Aprx.en
>   http://ham.zmailer.org/oh2mqk/aprx/

Good work! Thanks
Bob, Wb4APR