[aprssig] IS-to-RF gating... A proposal

[Bob Bruninga]

Yep.  It is a proposal that requires change.  (APRS needs to evolve!).

Those IS-CLIENTS that want the new feature to be able to be RGATED will get
upgraded clients.  They will also recognize that it will not work until
their local IGATE also upgrades.  But they have begun the process of
evolution.

Those SYSOPS that want new IGate features such as RGATING will upgrade to
new IGATE code.  They too will recognize that their IGate will only RGATE
these new packets only from new clients.  But it does not break anything
that exists.

> I really don't see any need to impose new restrictions 
> and complexities on APRS-IS client software authors when 
> the ultimate decision is in the hands of the IGate operator.

I disagree! This kind of new capability in APRS MUST be well defined, must
be nailed-down hard, not only so that it provides a non-moving target for
implementation, but it also standardizes the SOURCE packets and the
"control" techniques available at the IGATEs.  It also prevents the spread
of crazy ideas that then become a never-ending game of SPAM and FILTER.  We
must standardize this new feature from BOTH ends and in the MIDDLE too.

> Also, I suspect (adding additional path components)
> to the "TCPIP*... will have undesirable ripple effects.

Worst case is that it makes the packet invalid for now.  But since the
packet does not presently exist, and since any new function based on it also
does not exist, then there is nothing to break.  When the new format
appears, the new RGATE process then can do its thing.

> KISS - Give a way for IGate operators to do more... and leave
> further decisions up to them within the capability of the new tool.

Yes, but give them a well defined NEW packet to contend with.  The current
system has GREAT potential for misconfiguration and I do not believe that
everyone of the millions of existing packets should be considered as
potential RF packets!  It must be a new uniquely identified packet indicated
by the originator the he requests an RF copy where applicable..   I want to
see the collective minds of the authors develop a SPEC for these new
capabilities so they can be developed consistently across all of APRS.  We
must avoid fractionalizing APRS into individual fiefdoms.

> It'll be easier to get 2,000+ IGate operators to (hopefully) 
> upgrade software than to get many more thousands of APRS-IS 
> clients to upgrade their code. 

The CLIENTS have to be part of the solution.  We want the client to be part
of the network and to have personal responsibility for what they are
transmitting.  That is why I am proposing a new unique packet format.  SO
that they MUST upgrade to use it.  And therefore the new CLIENT's will have
inherent protections applied at the SOURCE, not trashing the entire IS and
forcing all the IGates to have to sort it all out.

> there's nothing "magic" about mobile vs stationary APRS-IS clients 
> and no difference between a phone or a PC from a mobility standpoint.)

Agree.  Which is why the proposal includes RANGE limits and the DECAY and
PROPORTIONAL PATHING so that any platform that is on IS-only in a local area
can be seen via this mechanism and add no more to the local APRS RF than he
would if he were on RF directly.  

In fact, under some circumstances it might be BENEFICIAL for the local area
to have 100% collision-free ENTRY of local info on the IS into a well placed
IGate that then can use RF collision detect to inject these Local packets
into the local RF area with full collision avoidance.  An overall benefit to
local RF.  Everyone understands that the limits on APRS are on the INPUT
Contention, not on the distribution.  Allowing some bundling of local
IS-originated packets can be a NET BENEFIT.  IE, the every 10 minute local
FREQ INFO objects, at least one Local WX packet, and the occasionally mobile
IS client.

> Just as the -IS to RF messaging path is determined by the 
> IGate operator, so the path for anything else gated from 
> IS-to-RF should be locally determined.

Agreed.  But the proposal improves that by having the ORIGINATOR mark his
packets with a 4-to-1 pre selection as to what packets are important to HIM.
This only improves the power and versatility of the RGATE operator to
control his local RF gating.

>  If the IGate software author wants to do proportional pathing 
> for gated 3rd party packets, so be it, but it's not the 
> responsibility of the (non-RF) packet originator to determine 
> what paths would be suitable for RF transmission.

I fear you misunderstand Proportional Pathing in this proposal.  It is
completely a function of the ORIGINATOR.  It is a tagging by the originator
of a "weight" or importance" to his individual packets he is injecting into
the system.  His RGATE0-0 packets are the LEAST important to-him and so the
RGATE operator can chose to ignore them completely, or send them out direct
to a small local area with little impact on the network.  His RGATE1-1
packets are more important (to him), giving the RGATE process additional
selection.  And the RGATE2-2 packets are his most important packets.  These
he is sending out only once every 4 minutes while in motion, giving the
RGATE operator a signal as to his minimum request for RF.  There is NO
requirement for the RGATE operator to then turn around and proportional path
them outward.  Proportional Pathing is all about RATE selection.  Nothing
more.

> every assumption made anywhere within the APRS-IS that 
> -IS-originated packets contain only TCPIP* as a path
> would have to change as well as all APRS-IS client software 
> and IGates as well.  

Yes.  It is something new.  It must be, so that we don't break something
that exists.

> In my KISS proposal, it's simply a new, more flexible
> configuration available to the IGate operators to 
> determine what additional packets should gate from -IS to RF.

A constant management load on that operator.  He must react to every new kid
on the block or that drives through.  I prefer the establishement of the
system where the originator and RGATE operator work from a pre-defined
pre-negotiated playlist, hence an end-to-end proposal.

>  See also http://en.wikipedia.org/wiki/Leaky_bucket and dream 
> of being able to apply it at a per station, per callsign, and 
> per interface level with independent settings for messages 
> w/courtesy posits vs "extra" posits for the local area...

The leaky-bucket analogy on APRS is unworkable.  The originator as soon as
he sees he is being throttled, simply increase his rate, or path to
compensate.  The originator and the GATER need to be working together.
Hence, the RGATE proposal works on both ends to find a working medium.

Bob, WB4APR


On 12/28/2011 10:28 AM, Bob Bruninga wrote:
> To avoid a lot of misplaced debate on apples and oranges and confusion,
the
> following is a collection of -a- proposal so we can all be sure we are
> debating the same thing.  I am not saying we agree to implement this.  I'm
> just making sure we are all looking at the same limited idea and debating
> only its merits, and not all the possible other bugaboos...
>
> PURPOSE:  To give IGate operators a local tool to allow local selective
> IS-to-RF gating while giving him the means to control it based on his
local
> environment (his IGate coverage range and channel loading).  For
> identification, lets call this process an RGATE.  Only IS packets
> specifically identified by the IS originator as potential for RF gating
are
> considered by the RGATE and then only the rules of the local RGATE owner
> permit transmission.
>
> IS CLIENT REQUIREMENTS:  Authors of mobile phone or other IS applications
> that inject such RF gating request packets into the APRS-IS would adhere
to
> a specific set of "rules".  Here are some specifics to limit rates:
>
> 1) Packets intended for consideration for RF must be flagged.  Flag could
> consist of RGATEx-X inserted in the IS path.  Such as:
> WB4APR>APVVVV,TCPIP*,RGATEx-X:packet_data_goes_here...
>
> 2) Packets flagged for RGATEs should be no more often than normal APRS
> packet rates.  Every 30 Minutes for benign fixed stations, every 10
minutes
> for operator-present stations, and a maximum for mobiles of 1 per minute,
> but must also be Decayed and Proportional-Pathed.
>
> 2) Such packets must use the APRS decaying algorithm.  Meaning, if the
> position or data is unchanging, then the period to the next packet is
> doubled down to the final rate of one per 30 minutes (same as all other
APRS
> stations).
>
> 3) Such packets must use Proportional Pathing to add a sliding "weight"
> potential to each packet.  This weight can be selectively used by RGATES
to
> best match his local loading.  The IS source would send every other packet
> to RGATE0-0. The alternating packets would be sent half the time via
> RGATE1-1 and the other half the time via RGATE2-2.  This in effect
> implements a 1, 2 or 4 minute rate selection potential while maintaining a
1
> minute rate on the APRS-IS.
>
> IGATE RGATING REQUIREMENTS:  The IGATE sysop can choose among a variety of
> settings:
>
> RGATE0-0 RANGE - sets the heard-range where these are gated
> RGATE1-1 RANGE - Sets the heard-range where these are gated
> RGATE2-2 RANGE - sets the heard-range where these are gated
>
> DIRECT = 0-0, 1-1, 2-2 will gate these RGATEn-N packets direct only
> ONEHOP = 1-1, 2-2  ... will gate these RGATEn-N packets only 1 hop
> TWOHOP = 2-2  ...  ... will gate these RGATEn-N packets only 2 hops
>
> RGATE0-0 LIMIT - Sets the number of such packets allowed per minute
> RGATE1-1 LIMIT - Sets the number of such packets allowed per minute
> RGATE2-2 LIMIT - Sets the number of such packets allowed per minute
>
> For example, a typical home IGate that (ideally) only uses a 1 hop RF path
> via the nearest local digipeaters might set his 1-1 RANGE to only include
> the reliable coverage area of his local digis and then set ONEHOP = 2-2.
> The result would be only one packet from any IS-mobile once every 4
minutes.
> Or he could set ONEHOP = 1-1,2-2 and then have these mobiles appear once
> every 2 minutes.  ETC.
>
> He sets the LIMITS as a failsafe mechanism.  There is also a BLOCK list
> where any abusers callsigns can be blocked if they try to induce spam.
>
> Something like that.
>
> Just an idea to consider.  What would need to be changed to allow this?
>
> Bob, WB4APR
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig