[aprssig] Why Not "Gate in Vicinity" because its a bad idea

[Bob Bruninga]

> You can not define a one-rate-fits-all limit. 
> Where I live, the total APRS activity is around 
> one packet every five minutes. 

That is an EXCELLENT APRS channel.  That would suggest a 99.3% probability of RF packet success.  Most people would envy such a reliable channel.

> Even if there was some misconfigured client flooding 
> the medium, I would be glad to see some activity... :-P

How much?  When the traffic load gets up to 3 packets per minute, and considering that each packet you hear includes the first hop you didn't hear, means that now the channel is 10% loaded and by definition, your probability of packet success had dropped to 90%.

When the packet load gets to say 6 packets per minute, now  your channel success rate is down near 80%.  How low do you want to destroy channel reliablity by bringing in out of area spam?  If everyone is using 2 hops, then 6 packets per minute is more like  30% loading or only 70% probability of success.

ANd if you think 70% is "good enough", remember that for a 2 hop packet from a mobile or HT, the chance that it will be heard after 2 hops is .7 X .7 or less than 50%.  That is a POOR APRS channel!

> Of course we should agree on a sane default which makes 
> reverse-igating usable even in crowded areas and which 
> does not require a ph.d. to adapt. IMHO, the best 
> suggestion so far was a per-callsign(*) limit for
> reverse-igating of maybe 1 pkt/minute, with a burst 
> limit of e.g. 4/minute (I have seen APRS-RF rigs with
> a 15 second corner pegging setting, so this seems sane 
> to me).

Yikes!  With 40,000 APRS-IS users in real time, that could be only 40,000 packets per minute.  Kinda hard to do on a 1200 baud channel that is optimum at about 6 packets per minute or less.

And corner pegging on the national channel at a 15 second rate?!  SOmeone has APRS confused with a vehicle tracking system.  APRS is not that.  It is a comm system where we like to know in the VHF RF domain, where someone generally is in the network.

I would say that ANY APRS network that is seeing more than about 6 packets per minute is a fully saturated RF network and there should be no frivolous injection of additional traffic.  

There is ONE exeption.  If the Injector station IS on the tip-top of the local mountain such that it hears DIRECT every station, and every digi DIRECT, then it can inject additional info, since it can guarantee a collision free transmission.  NO OTHER STATION in the entire area can do this.  So DONT DO IT.  No software can detect that it is in such a unique location, hence it is russian roulette to allow operators to configure that way.

Plus remember, that SOFTWARE HAS no clue about channel loading.  Hearing only 6 packets per minute can equally mean a totally saturated useless channel with 90% collisions as it can mean a successful channel with 70% throughput.


Just some thoughts.
Bob, Wb4APR

>
>(*): I would further suggest to have two limits per callsign:
>messages should have their own rate limit as opposed to posits,
>objects, weather reports etc, which can go together.
>
>> Again, this is amateur radio and because there is no way to throttle
>> what is passed through APRS-IS without breaking its underlying
>> premise, it cannot be assumed that the amateur radio operators must
>> alter their operation just to accommodate non-amateur radio equipment.
>
>But it is very well possible to throttle what is going from IS to RF on
>an igate without breaking anything.
>
>> The focus should not be "how to gate everyone to RF" but how to
>> provide for the primary purpose of APRS-IS: support amateur radio
>> communications.
>
>I'm in full agreement to this statement. It was my main motivation for
>developing APRSdroid and I have not given up on it since. An APRS-IS
>application on your cellphone gives you many advantages when mobile or
>portable: it frees up the second band on your dual-bander or allows to
>participate in APRS without spending >500$ for the gear.
>
>However, as it is now, APRS-IS stations have second class value because
>their positions are mostly not forwarded to RF at all and their messages
>get through with luck only. We as a community need to decide what way
>should be followed: should APRS-IS be kept a one-way street with no
>reverse igating at all, or should it become a full class citizen
>allowing 100% interaction between RF and IS?
>
>In the latter case, we need additional mechanisms to prevent flooding of
>RF by misconfigured software, as the responsibility for the RF
>transmissions is with the iGate operators. However, this problem is
>solvable in the iGate software.
>
>> But if you have "passcodes for everyone" as pushed by some recent
>> authors, you have third-party messaging occurring which also puts in
>> jeopardy the entire premise of APRS-IS.
>
>The APRS-IS passcode algorithm is well-documented for years and can be
>applied by anyone with half an hour of time and access to Google. So
>far, the doom of APRS-IS due to third-party messaging failed to appear.
>I am very positive that this will not change with the existence of
>smartphone APRS apps, as there are better alternatives out there for
>non-HAMs.
>
>> Unfortunately, to change either the underlying network protocol,
>> authentication, etc. will immediately disenfranchise thousands of hams
>> using clients that cannot be updated to any new protocol.
>
>That does not mean we should twiddle our thumbs and wait. The first step
>is to find a way to authenticate radio amateurs without significant
>overhead. Unfortunately, there is no globally available fully-automatic
>method available. EchoLink and LotW are using manual verification to
>issue access codes, IIRC with the LotW using SSL authentication (which
>is not only secure but may be also usable for our purpose).
>
>Secondly, we need to change the IS protocol. This depends on how
>authentication is performed and only has to change the initial login
>step.
>
>Then, we need to create proxy software to allow the use of old IS
>clients with new servers. This software can be run on the HAM's PC, load
>his certificate and connect to APRS-IS-new servers using proper
>authentication.
>
>Finally, we need to shut down the old APRS-IS servers or at least limit
>their functionality to RX only to prevent abuse.
>
>This is not an easy process, but it is the only option if you really
>want to do something against unauthenticated APRS-IS use, and it needs
>to be started now if you really believe that APRS-IS will explode due to
>abuse.
>
>
>Kind regards from Germany,
>
>Georg DO1GL
>-- 
>APRSdroid - Open Source APRS Client for Android ++ http://aprsdroid.org/m
>     ++ https://market.android.com/details?id=org.aprsdroid.app ++
>________________
>signature.asc (1k bytes)
>________________
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig