[aprssig] UIDIGI and the New Paradigm - WARNING - LONG!

[Ron Stordahl]

Bob...comments in line....

Robert Bruninga wrote:

>Ron,
>
>What an excellent assessment of UIDIGI ROM support
>for the New n-N Paradigm.  Great work!
>I can think of two comments:
>
>1)  One of the issues you raise does not appear to be 
>unique to the new Paradigm but may just be a bug no one 
>has noticed before.  From what you wrote, it appears to me 
>that a UIDIGI ROM counts down the WIDEn-N algoirthm 
>differently than any other application and adds an extra 
>digi hop on the end of every such use.    This might explain 
>why you get an  extra hop.
>
>What we expect from WIDEn-N:
>
>   Send WIDE2-2:  then WIDE2-1, then WIDE2*
>
>What UIDIGI appears to be doing is:
>
>   Send WIDE2-2: then WIDE2-1, then WIDE2, then WIDE2*
>
>Appearing to imply that UIDIGI ROMS do not set the 
>*has-been-digipeated-bit* when 2-0 has been reached, 
>but only does it on the NEXT additional digipeat.  Thus,
>all along, UIDIG ROMS have been adding an additional
>hop to all WIDEn-N paths.  So this bug should not be
>attributed to the New n-N paradigm per se.
>  
>

You may be on to something here.  I was a little surprised with what I 
was seeing, but not having any other digi's to compare I figured that 
this was normal.  If it's not then Marco will have to look at it.

>2)  The inability to not-trap out *intentional* abusive behavior
>is not a failing of the New n-N Paradigm.  No one is traping
>them out now, so the fact that we can trap out unintentional
>mistakes with the New n-N Paradigm is only a plus.  No 
>other stand-alone digi can trap out all possible intentional
>abusive paths either.  So again, this is not considered a
>fault of the UIDIGI ROM
>  
>
That's true and stopping intentional  abuse is pretty difficult in any 
case.  Until (or should I say IF) Marco can put 'N' limits in the code 
this may be the best we can do.

>3) There is no need to worry about the *unintentional* bad
>path combinations where N does not equal "n" anyway, 
>because if ALL digis simply trap out the 4-4, 5-5, 6-6, 7-7 
>at the point of entry, then no other digi will see the other
>combinations in the first place.  They wont get into the
>system.
>  
>
But if the sender starts out with 7-6 you get 7 hops and you can't stop 
them.  Again this is an extreme case.  But I wanted to point it out as 
it surprised me.

>4)  Thus the only failing you found left is the fact that you
>have to use WIDE1-1, as an alias instead of letting the
>WIDEn-N algorithm handle it.  Again, this is not any problem
>at all, beacuse (I think) the UIDIGI ROM uses one overall
>dupe-elimination algorithm no matter what digi method was
>used.  Thus the UIDIGI ROM digi does perfect dupe
>elimination on all packets and so having to use WIDE1-1
>as an alias is not a problem at all.
>
>Thus, in my accounting, of all the issues you raised, there
>is nothing wrong with using a UIDIGI ROM to support the
>New n-N Paradigm (with WIDE1-1 as an alias)...   And secondly
>there are two things we ask the author to fix in his next release:
>
>1) Allow the sysop to set  a MAX-N limit
>2) Fix the beacon algorithm so that the UIDIGI ROM beacons
>    can go out locally more often and via 1 hop and 2 hops
>    less and less often
>
>Did I miss anything or missinterpret anything?
>  
>
 From the tables you have presented on your web page (fix14439) showing 
how quickly the number of packets increase when a route calls for 3 vs 2 
hops, or worse 4 hops, and considering the congestion in many areas good 
control over the number of hops permitted appears essential if service 
is to be useful in such areas.  Proper set up of UIDIGI can help, but 
even the well meaning are going to violate the ground rules since the 
controls we can put in place with the existing UIDIGI firmware are 
lacking.  Better than nothing Ill agree, but here is a simple example:

Lets say you are going to permit RELAY and it's cousin WIDE1-1 to be 
used.  And you are in a '3 hop allowed' region.  Then with the parms as 
I offer you would have to allow a path of WIDE3-3 to work.  But if you 
do allow that, then RELAY,WIDE3-3 will also work, allowing 4 hops (and 
RELAY,RELAY,WIDE3-3 will produce 5 hops and on and on...).  Similarly 
for a '2 hop allowed' region, both WIDE2-2 and RELAY,WIDE2-2 will work, 
the latter allowing 3 hops.  So no mater what you do you will have this 
one additional hop which you can't get rid of.  If you don't permit 
RELAY at all, nor the special use of WIDE1-1 as a surrogate for RELAY, 
then in a 3 hop allowed region only these paths would be permitted:

WIDE1-1
WIDE2-2
WIDE3-3

So disallowing RELAY and the special relay surrogate WIDE1-1 you get the 
best control.

(Also WIDE2-1, WIDE3-2 and WIDE3-1 will work as initial paths with 
unexpected results (2, 3 and 3 hops respectively), and of course WIDE7-6 
and it's cousins, but since they will only be originated by the truely 
devious they won't happen enough to worry about!)

Perhaps I am guilty of making perfection the enemy of good, so Ill 
relent and say we can get half way there with the existing UIDIGI 
firmware. 

To help those interested..and has anyone else waded through my overly 
long diatribe?..Ill post suggested UIDIGI configuration files for the 
case of 2, 3 and 4 hop allowed areas on my web site and provide a link 
for direct http downloads of the zipped files, but probably not until 
tomorrow when I can get out from under this pile on my desk.

Ron, N5IN

>Bob, WB4APR
>
>
>
>  
>
>>>>Ron Stordahl <ron.stordahl at digikey.com> 4/7/05 12:05:42 AM >>>
>>>>        
>>>>
>Testing this evening produced some unexpected results and the
>conclusion 
>that the New Paradigm cannot be fully implemented in UIDIGI as it 
>currently exists.  Skip to the end for a summary.
>
>Wishing to allow only these paths to be fully functional:
>
>WIDE1-1 (for 1 hop)
>WIDE2-1 (for 1 hop) - but it's really 2 hops.
>WIDE2-2 (for 2 hops)
>WIDE1-1,WIDE2-1 (for 2 hops)
>WIDE1-1,WIDE2-2 (for 3 hops)
>
>I set the relevant parms thus on the nearby UIDIGI and surrounding 
>UIDIGI's that can hear the nearby UIDIGI:
>
>UIDigi WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN
>UIDCsb 1 (enable callsign substitution for UIDigi calls)
>UIFlood MN (call to be used in the flood algorithm)
>UIFLDfl 0 (make call substitution after last 'floodcall' digi'd)
>UITrace WIDE (call to be used in the trace algorithm)
>UITRFl 0 (make call substitution after last 'tracecall' digi'd)
>
>Then I generated from a TinyTrak3 packets with these paths:
>
>WIDE1-1  (it was digi'd once as expected) - shown in the dig'd packet
>as 
>N5IN-2*,WIDE1 and not digi'd further.  I can hear 1 level out and did 
>not hear another digi repeat the packet.
>
>WIDE2-1 First as N5IN-2*,WIDE2, and a second time as N5IN-2,WIDE2*  I 
>had expected it to act just as WIDE1-1, but in fact it acts as WIDE2-2
>
>(in regards to the number of hops allowed).
>
>WIDE2-2 - Shown in the first digi'd packet as N5IN-2*,WIDE2-1 and in
>the 
>second as N5IN-2,WB0WTI-11*,WIDE2. If it was digi'd further I have no 
>way to tell as I can't hear further out.  However I would be willing to
>
>bet that it is in fact limited to 2 hops as it should be.
>
>WIDE3-3 (it was digi'd once only as expected) - shown in the first 
>digi'd packet as N5IN-2* with nothing following.  There were no 
>additional hops, and I could hear them if they existed.
>
>WIDE3-2 Shown in the first digi'd packet as N5IN-2*,WIDE3-1, in the 
>second as N5IN-2,WB0WTI-11*,WIDE3 and I suspect there is a 3rd hop as 
>N5IN-2,WB0WTI-11*,WIDE3*, although it would be too far out for me to 
>hear. I draw that conclusion based upon what I could here in the case
>of 
>WIDE2-1, where there were 2 hops.  And if this is so I suspect that 
>WIDE3-1 will also produce 3 hops.
>
>Now for combined paths:
>
>WIDE1-1,WIDE1-1.  The first digi'd packet contains
>N5IN-2*,WIDE1,WIDE1-1 
>and is not repeated by any of the surrounding digi's.  I had expected a
>
>second hop, but it did not occur.
>
>WIDE1-1,WIDE2-1.  The first digi'd packet contains
>N5IN-2*,WIDE1,WIDE2-1 
>and is not repeated by any of the surrounding digi's.  I had expected a
>
>second hop (and maybe a 3rd) but it did not occur.
>
>WIDE1-1,WIDE2-2.  The first digi's packet contains
>N5IN-2*,WIDE1,WIDE2-2 
>and is not repeated by any of the surrounding digi's.  I had expected a
>
>total of 3 hops, but only one occurred.
>
>Apparently the WIDE1 is the end of the line, perhaps I should have 
>expected that.  In order to permit these to work I had to add WIDE1-1 
>into the UIDIGI list thus:
>
>UIDigi WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN  and I also 
>made this change in the surrounding UIDIGI's..
>
>Now combined paths again with this new setting:
>
>WIDE1-1,WIDE1-1 The first digi'd packet contains N5IN-2*,WIDE1-1 while
>
>the second and final digi'd packet contains N5IN-2,WB0WTI-10*
>
>WIDE1-1,WIDE2-1 The first digi'd packet contains N5IN-2*,WIDE2-1, the 
>second N5IN-2,WB0WTI-10*, and I suspect a third
>N5IN-2,WB0WTI-10,WIDE2*
>
>WIDE1-1,WIDE2-2 The first digi'd packet contains N5IN-2*,WIDE2-2, the 
>second N5IN-2,WB0WTI-10*,WIDE2-1 and I suspect a third 
>N5IN-2,WB0WTI-10,WIDE2*
>
>Finally approaching some conclusions:
>
>You can't shoehorn the New Paradigm into the UIDIGI, but you can get 
>part way there.  a UID of 
>WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 works thus:
>
>WIDE1-1,WIDE1-1 (works as expected producing 2 hops)
>WIDE1-1,WIDE2-1 (produces 3 hops and not 2 as hoped)
>WIDE1-1,WIDE2-2 (works as expected producing 3 hops)
>
>With RELAY added to UID (now both RELAY and WIDE1-1 are in UID)
>
>RELAY,WIDE1-1 works as WIDE1-1,WIDE1-1 (2 hops)
>RELAY,WIDE2-1 works as WIDE1-1,WIDE2-1 (3 hops not 2 as hoped)
>RELAY,WIDE2-2 works as WIDE1-1,WIDE2-2 (3 hops)
>
>WIDEn-N for n=N and n>2 but < 8 all terminate with a single hop, thus:
>WIDE1-1,WIDE4-4 allows just 2 hops.
>
>Unfortunately WIDE5-4 produces 5 hops (it is not trapped).
>
>For WideN-M where M<N the trapping fails.
>
>You will also note that in order to substitute WIDE1-1 for RELAY it is
>
>necessary to place WIDE1-1 in the UID list (otherwise serious problems
>
>result which are detailed above).  By doing so I believe RELAY and 
>WIDE1-1 act identically, the latter not producing any less QRM.
>
>=============================================================
>
>1) If you wish to support both RELAY and WIDE1-1 (in the UID list, and
>
>thus treated differently than WideN-n in that it is no longer a UIFlood
>
>or UITrace token) then both of these must be placed in the UID list. 
>By 
>doing so you will have space remaining for just additional 6 tokens. 
>If 
>you are in a 3 hop area then the UID list would have to contain:
>
>RELAY,WIDE1-1,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 plus 2 more tokens.  To 
>fully implement restrictions against excessive paths you would need to
>
>add WIDE4-3,WIDE4-2,WIDE4-1,WIDE5-4, etc which totals 18 tokens.  There
>
>is no room to do this.  And the result is inconsistent as while it 
>allows a path of WIDE3-3, it also allows a path of RELAY,WIDE3-3 or 
>WIDE1-1,WIDE3-3 which is 4 hops.  Someone who wishes to break the rules
>
>can use a path of WIDE7-6 and get 7 hops.  Also paths such as 
>RELAY,RELAY,RELAY,RELAY,RELAY will be supported.
>
>2)  If you wish to abandon RELAY and WIDE1-1 in its special application
>
>as a twin to RELAY, then the UID list for a 3 hop area will contain
>just 
>WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 giving you space for 4 additional
>tokens 
>out of the 18 additional spaces you would need to fully implement.  In
>
>this implementation the following paths will be permitted:
>
>WIDE1-1 (1 hop)
>WIDE2-2 (2 hops)
>WIDE3-3 (3 hops)
>
>but you will be able to block just 4 our of the remaining 18 paths such
>
>as WIDE7-6 which will produce 7 hops.
>
>3)  If you wish to retain RELAY, but not include the special
>application 
>of WIDE1-1, you gain one additional slot in the UID list.
>
>Conclusion:  The New Paradigm can only be poorly supported by UIDIGI at
>
>present.  Abandoning RELAY (and/or the special use of WIDE1-1 as an 
>equivalence for RELAY) simplifies things only slightly.  While I have
>no 
>means to test the KPC3+, I suspect it may the same shortcomings as
>UIDIGI.
>
>Assuming users are well behaved it may be worthwhile to implement, but
>
>if users were well behaved we wouldn't need to place limits upon them
>as 
>intended by the New Paradigm in the first place.
>
>I had hoped for better.
>
>Only Marco Savegnago IW3FQG, the author of UIDGI, is in a position to 
>fully solve this problem by allowing a simple hop limit to be enforced
>
>in the code irrespective of what paths a user tries.
>
>Ron, N5IN
>
>
>
>
>
>
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org 
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>  
>