OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   06.03.04 13:10l 239 Lines 9187 Bytes #999 (0) @ WW
BID : 2962-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 04, 4/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<LZ3NP<VK6ISP<ZL2TZE<N1UAN<
      ZL2BAU<ZL2BAU<ZL3VML
Sent: 040306/1024Z @:ZL3VML.#80.NZL.OC #:20450 [Chch-NZ] FBB7.00i $:2962-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: RE: stir up the path pot!
From: Mark Cheavens <mcheavens@usa.net>
Date: Thu, 04 Mar 2004 13:09:24 -0600
X-Message-Number: 25

The two items you are overlooking are these:
RELAY, RELAY, WIDE, WIDE, WIDE (or similar paths)
Wide2-7 would still make it through 5 hops away when it reaches WIDE2-2.
(Only the SSID is decremented, the number before the ssid is only a courtesy).

The exclusion list would have to be quite large!

Mark
KC5EVE

>Would this work?
>
>1)  All IGATE clients DEFAULT to not accepting any packet
>   with a path length greater than WIDE2-2.
>2)  Local IGate SYSOP can determine based on TRAFFIC,
>   and local topology whether 3-3, 4-4, 5-5, or even 7-7 are
>   permissible in his area.
>
>Then again, where 5-5 can be used, then it can be used.
>But where it is intolerable, the IGate filters it out.  It puts
>the IGate sysops in control of stuff in their areas, and because
>of the penalty, the end user learns why he is not getting in.
>
>And its all a LOCAL thing, solving LOCAL problems
>Locally...
>
>Am I missing something?
>
>de WB4APR, Bob

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: "Dennis Hudson, N2LBT" <n2lbt@n2lbt.com>
Date: Thu, 4 Mar 2004 14:17:50 -0500
X-Message-Number: 26

If these "needs" exceed the capacity of the network then what gives one 
person the right to abuse the network over other users rights to 
properly use the network?

The statement about the igate being the final stage might not be 
completely correct, but it is a common goal of many users. The beauty 
of the IS is it can be used to overcome the inability for unconnected 
packet to span these distances without building the dedicated RF 
infrastructure to carry the packet properly.

On Mar 4, 2004, at 1:08 PM, Mark Earle wrote:

>Sometimes, the goal of the user is not to get to the IS or a gateway,
>but to have the posit reports seen over a wide area via rf only.
>
>I generally have more of a need for my packets to be displayed on rf
>than over the internet. Not everyone's goals are to get to the IS.
>
>>some multiple hops.   But once he gets the traffic in earshot of an IGATE,
>>any further relaying is ony a waste of bandwidth.  Right?

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From:     Jeff King <jeff@aerodata.net>
Date: Thu, 4 Mar 2004 14:21:33 -0500
X-Message-Number: 27

On Thu, 04 Mar 2004 13:46:30 -0500, Robert Bruninga wrote:

>is intolerable, the IGate filters it out.  It puts the IGate sysops
>in control of stuff in their areas, and because of the penalty, the
>end user learns why he is not getting in.

.....

>Am I missing something?

Is this a road you want to go down? I mean, ham radio is supposed to be about 
radio, not internet. IMHO, it would be better to do this at the source, and 
that would be the digipeater's not the IGATES. The IGATES are only a penalty 
if the end user gives a damn, and this solution does nothing to fix the root 
problem, that is, wide digi's trashing the fragile low speed RF WLAN.

I admit I've not been following this thread until Curt responded, so maybe I 
am missing something, I always find if you can fix the problem directly, that 
is the best solution. It can be assumed that anyone running a high profile 
digi knows their network structure, and any fixes that can be applied their 
make the most sense.

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 04 Mar 2004 14:24:15 -0500
X-Message-Number: 28

>Would this work to give negative feedback to 7-7 users?
>
>1)  All IGATE clients DEFAULT to not accepting any packet
>   with a path length greater than WIDE2-2.
>2)  Local IGate SYSOP can determine based on TRAFFIC,
>   and local topology whether 3-3, 4-4, 5-5, or even 7-7 are
>   then permissible in his area and change it.
>
>And its all a LOCAL thing, solving LOCAL problems
>Locally...

Curt said:

>As long as the IGATE sysop could change it from the default, I like
>the idea.  If it was hard-coded, then people in rural areas without
>much infrastructure would suffer terribly.

Yes, that is what I meant.  It defaults to 2-2 so that local IGate sysops
have to make a conscious decision to accept anything more.  Sure, many may
open it to 3-3 or higher, BUT at least now the "q" construct lets us see
where these packets are coming from if they are a problem and we can just
go to the IGate sysop for solutions instead of having to hunt down every
user.

Another advantage of the default 2-2, is that it might help a little bit on
the come-as-you-are occassional IGate client that is not a full time IGate,
but just a come-and-go user.

In fact, a filtered packet should still be INJECTED into the APRS-IS
with PATH INTACT, but the data field should be filled with
"Data truncated at IGate due to path-too-long for that area..."

or something like that.  So the end user SEE's why he isn't getting in..

Bob

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From:     Jeff King <jeff@aerodata.net>
Date: Thu, 4 Mar 2004 14:26:48 -0500
X-Message-Number: 29

On Thu, 4 Mar 2004 09:19:32 -0800 (PST), Curt, WE7U wrote:

>Another way:  Run digi_ned digipeaters and tweak the paths so that
>they make sense in the particular environment.

Yes, that makes sense. The RF GUYS know the network in a particular area, and 
this has real advantages, it both fixes the problem and improves the channel 
capacity.

>Yea, I know the arguments for/against.  They've been discussed here
>many times.  My opinion:  Sometimes one packet has to be sacrificed
>for the good of the many.  

Right. One must no loose site of the fact these Wide7's impact the RF NETWORK 
and any IGATE solution can only be a penalty to those that actually care. The 
problem must be address at the source, and the source is not the internet.

Fix the RF and it benefits the whole WLAN.

----------------------------------------------------------------------

Subject: RE: stir up the path pot! and flush twice
From: Bill Vodall - WA7NWP <wa7nwp@jnos.org>
Date: Thu, 4 Mar 2004 11:28:37 -0800 (PST)
X-Message-Number: 30

>In one of WB4APR's papers, a revealing analysis was done.  Assuming that
>each digi can hear three other digis, a single packet that originated with
>'wide7-7' ultimately creates a total of 111 packets!

Only if there are 111 digipeaters.   In general, the wideN-N paths don't
suffer from the ping pong digipeating back and forth of paths like
WIDE,WIDE,WIDE.

If everything is working perfectly, only one packet should be generated per
digipeater with the wideN-N scheme resulting in a pure flood out to 7 hops.

We're going to keep having these Path discussions until we move to smarter
digipeaters and virtual paths such as "REGION" and "LOCAL".

It is totally silly that users even have to deal with this -- if they don't
want to.  How many folks on here have tweaked their TCP TTL (Time to live)
parameter?   It's generally not needed for the task at hand.

Back to work on WinXastir and then Linux for embedded digipeaters.

73,
Bill - WA7NWP

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu,  4 Mar 2004 14:28:03 -0500
X-Message-Number: 31

On 3/4/04 at 1:46 PM Robert Bruninga <bruninga@usna.edu> sent:

>BUT!!!  we have to penalize the long term use of such paths
>somehow if we expect them to ever learn... and change...
>
>Eric's suggestion to Filter them from the APRS-IS is something
>worth considering...

I'm strongly opposed.

First, it does nothing to address the problem, since it assumes that
people's reason for setting these paths is to get the the APRS IS. The
reason people do this is ignorance, and filtering them out of the APRS IS
does nothing to address their ignorance. It does nothing to address the
congestion these packets cause, and as was pointed out, may worsten it for
those that know about and use the APRS IS, as they expand their path in an
attempt to get a position onto the internet.

Second, it makes it impossible for those outside the area to see these
packets, identify a problem, and attempt to educate the person.

Third, some areas accept these long paths, who gives you the right to
decide all areas must obey your idea of right and wrong? What is wrong with
local governance? Why should the APRS IS, which is completely unaffected by
these paths, be the place where the enforcing of other's wills is done? The
APRS IS was created to collect all APRS RF activity in the world, not just
that with paths you approve!

Fourth, I'm the guy that is going to get emailed by those hams when their
positions don't appear on findU, which is bad enough, but since their
packets have been filtered, I have no way of knowing what they are doing
wrong. This will waste my time and leave me unable to educate people.

Steve K4HG

----------------------------------------------------------------------



Read previous mail | Read next mail


 09.10.2026 22:01:16lGo back Go up