[aprssig] New WIDEn-N Paradigm (MAJOR MOD)

[Wes Johnston]

I'm not missing that at all... hihi...  I just know the practicality of it.
(just to poke fun at you this time Bob... you shoot me in the foot with
practicality all the time!!)

You are correct in that _if_ every digi used these same filters (if everyone
could /would filter wide7-7's) then we'd have a decent fix... but if one digi
up in VA digipeats a wide7-7, next thing you know, it's a wide7-6 and it
squeezed thru the next digi's filters.... It's like having a firewall with a
few paper windows.  and once the fire (the wide7-6 packet) is in my house,
there's no stopping it.   At least with the SSn-n system (two letter state
abbreviation), we have a (if you'll allow me the analogy) a gap between our
houses.  A packet (fire) might consume one house (network) but it couldn't
spread across state lines.

Now on the other hand, let's consider one of your earlier proposals...
supporting WIDE2-2 universally...  By placing specific wide callsigns in the
UIDIGI setting like WIDE2-2 or wide3-3, and NOT (repeat NOT) putting WIDE in
the UIFLOOD or UITRACE, we end up with an OPT-IN type of model.  This permits
us to give the guys with WIDE2-2 or WIDE3-3 in their trackers at least one hop
as a courtesey if they are not familiar with our local methods.

I think of your FEB 5th proposal to stop the WIDE7-7 or WIDE6-6 as an OPT-OUT
network model... the digi owners have to opt-out of the specific WIDE packets
which are deemed harmful to the network.  The problem is, there are a total of
35 combinations of various WIDEx-y packets.  And in a 2 hop network, we'd need
to remove 21 that could be considered harmful.  Problem is, we only have the
ability to filter 4 of them with a KPC3.

With an OPT-IN system, the digi owners would choose the WIDE packet which were
not harmful - and there's a lot fewer of them - actually, in a two hop network
there are 14 of them we'd need to opt-in on, and we only have 4 we can opt-in
on.

Neither solution is ideal, but I'd rather err on the side of limting the network
than trusting my neighboring digipeaters to catch the errant packets as they
enter the system because if they mess up and pass them, my network is
saturated.

Wes
--



Quoting Robert Bruninga <bruninga at usna.edu>:

> Wes,
> What you are missing is that we want ALL digipeaters to
> capture and stop at least WIDE5-5, 6-6, 7-7, and then
> there is no where that the packets can get into the system,
> therefore you wont get any 7-3's into your area either.
> Its a big plan.  But each digi that switches over, helps out
> ALL digis around it...  And eventually the network is better.
>
> Bob
>
> >>> Wes Johnston <aprs at kd4rdb.com> 2/6/05 8:28:10 AM >>>
> Bob...
>
> I know your recommendations are always grounded in pracitcality.  But
> until the
> TNC manu's come out with firmware that lets us limit UIFLOOD or UITRACE
> hop
> count (ie only digipeat UIFLOOD < 2-2), this solution is hokey at
> best.
>
> The 3rd recommendation below defies belief... (the others too, but I'm
> going to
> pick on number 3)
>
> 1- RELAY, WIDE5-5, WIDE6-6, WIDE7-7 in wilderness areas
> 2- RELAY, WIDE4-4, WIDE5-5, WIDE6-6 in rural areas more than 3 hops
> from Metro
> Areas
> 3- RELAY, WIDE3-3, WIDE4-4, WIDE5-5 in populated areas where even 3-3
> is too
> much
> 4- RELAY, WIDE2-2, WIDE2-1, WIDE3-3 with UIFLOOD and UITRACE OFF in
> Very High
> Density local area
>
> I understand that UIDIGI settings take precedence over UIFLOOD
> settings.  So you
> can put a callsign in there with the SSID such as WIDE5-5... and when a
> WIDE5-5
> is heard he'd be digipeated using the UIDIGI setting and get one hop
> and no
> more.  But this still does nothing to stop the WIDE5-4 that my
> neighbor's digi
> just repeated.  Or the WIDE7-3 that my neighbor just digipeated that
> originated
> 350 miles away.  I still end up with my local lan flooded with the lids
> from
> >200 miles away!  In order for this plan to work, every digi has to
> catch the
> WIDE7-7 or WIDE5-5 on the first hop.  And if the first digi to hear
> WIDE7-7
> doesn't "gobble it up" with a digipeat under the UIDIGI rules (ie
> doesn't
> decrement N and does set the HID flag), then that packet becomes
> WIDE7-6 which
> I can't filter out.  There are too many permutations - we're limited to
> FOUR in
> the UIDIGI setting.
>
> The whole point for me to switching away from WIDEn-n was to segment
> the network
> becuase we _didn't_ have a way to filter packets based on the value of
> "n".  I
> realize that the SSn-n is still recommended, but I just can't see
> supporting
> WIDEn-n anymore.  My network is working better than ever since the
> switch to
> SCn-n here.
>
> If we start digipeating WIDEn-n here, even with the suggested settings,
> we'll
> end up seeing as much traffic as we used to as the WIDE7-7's and
> WIDE5-5's come
> rolling in at various stages of 7-6,7-5,7-4,7-3,7-2 or 5-4,5-3,5-2,5-1.
>  I never
> saw any WIDE7-7's locally.  I never saw any WIDE5-5's locally... they
> were all
> WIDE7-1 or 7-3... how would I stop them?  Ideally, the digipeaters in
> VA would
> catch these packets under the UIDIGI setting, but practically speaking,
> they
> will not have setup their digipeaters to catch them, and will allow
> these
> network cluttering packets to propagate outward as WIDEn-n's.
>
> FWIW, the local digi for me is KC4PL and he runs javaaprs which
> supports count
> limits. It counts all hops in a packet (ie RELAY,WIDE counts as 2
> hops,
> RELAY,WIDE5-5 counts as 6 hops) and will not digipeat any packet with
> >x
> hops(here, x is set for 3 hops).  They don't even get one hop.... They
> do get
> IGATED, but do not propagate on RF.  So a trucker passing thru running
> WIDE7-7
> gets to the internet as he obviously is trying to do, but does not
> damage our
> RF network.
>
> I do really like the idea of giving the WIDE7-7's one hop... so they
> emirge from
> the digi as WIDE7-7*.  This is so much better than budlisting the guy
> because
> when he isn't digipeated, he'll get angry and up his RF power and get
> very
> creative with his paths.
>
> Wes
> --
>
>
>
> Quoting Robert Bruninga <bruninga at usna.edu>:
>
> > After a lot of debate over the last 2 months we have again
> > modified the plan for the New n-N Paradigm to an even better
> > and simpler design.  See the web page:
> >
> > http://web.usna.navy.mil/~bruninga/aprs/fix14439.html
> >
> > Summary:
> >
> > WIDEn-N    works everywhere,  but large N's are traped
> >                    depending on the area.
> > WIDE2-2     is guaranteed to work everywhere
> > SSn-N         is also supported for area use
> > ##LNKn-N  interstate idea is abandoned
> >
> > Secondary effects:
> >
> > TRACE and TRACEn-N are not supported
> > WIDEn-N replaces it and is Traceable everywhere
> > RELAY,WIDE and WIDE,WIDE are no longer desired
> > WIDE may eventually be dropped if this all works.
> >
> > All digis will include a list of what they support
> > in a consistent manner in the Position Text that
> > will show up well on mobiles.
> >
> > This plan even works in the highest density system
> > in the USA in the Los Angeles Basin and a test of it
> > was initiated there last week.
> >
> > I have not completely re-editied all of my old WEB
> > pages to reflect all thse changes, so if you find
> > conflicts, then point me to them so I can fix them.  But
> > in general, the above plan is what is currently on the
> > table.
> >
> > Thanks
> > Bob, Wb4APR
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
>
>