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

[Georg Lukas]

* Bob Bruninga <bruninga at usna.edu> [2011-12-28 20:44]:
> Yep.  It is a proposal that requires change.  (APRS needs to evolve!).

The proposed changes look to me like proposed to the sake of change
only. That should not be our goal.

> 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.

Instead of requiring one change, you require two changes to achieve the
desired goal. I think the question this part of the discussion boils
down to is: are we able to make a system which works for existing
APRS-IS clients without breaking APRS-RF?

Your suggestion implies a "no". However, maybe we can work out a
solution working at the iGates only, that preserves the quality of APRS
even when hammered by misconfigured / badly written IS clients.

> 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.

The KISS approach would only break existing APRS if implemented wrongly.

> > 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.

By over-standardizing it we can easily make it (almost) unimplementable
due to its sheer complexity. Personally, I did not understand much of
your initial RGATEn-N / ONEHOP / RANGE / LIMIT proposal, besides of the
point of using proportional pathing. How am I supposed to correctly
implement it then?

Also, how are SmartBeaconing[TM] packets to be weighted? With periodic
posits the 1/2/1/4/1 scheme is easy. But it does not work well with SB.

> > 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.

I am opposed to require changes in the client software to make this idea
work. However, if it is decided upon by this group, I would prefer a
minimal (and KISS-conforming) RGATE flag implementation.

I also think (naively) that using an RGATE,TCPIP* path should not break
packet propagation via IS. However, in case we decide to use an explicit
"please reverse igate this packet" flag, I would suggest to only use
"RGATE" and leave away the pathing part (see below for the reasoning).

> > 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.

Where do you see the danger for APRS consistency if an igate operator
selectively forwards packets from IS to RF? Currently, the consistency
is already jeopardized due to the fact that you can not programmatically
see if a (local or remote) iGate is reverse-forwarding, unless you have
an APRS rig listening when you inject your message/posit.

Maybe we should invest our standardization efforts into marking rgates
properly in their beacons?

> > 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.  

That would be a great idea if paths / repeater counts would work (and be
understandable by "normal" APRS rig operators). However, as many
discussions on this list indicate, normal users have a hard time
understanding what "WIDE1-1,WIDE2-2" or similar strings might mean. The
situation is made even worse for mobile operators: If you are driving
cross-country, you are inevitably going to use the wrong path settings,
either flooding a crowded area or not getting digied often enough.

Now, you are adding a second dimension of path counting (one is on the
client, the other on the igate), and it is not clear to me how these two
are going to interact with each other.

IMHO, the igate operator should know best what propagation path is the
"right" one in his RF area. It _might_ be useful for the IS client (user
or app) to indicate the importance of individual messages (use RGATE0 ..
RGATE2 for that, no SSID needed!). However, it is in the responsibility
of the iGate to decide which paths to use for these settings.

> 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.

And the complexity. Also, the rgate has to implement rate filtering
based on callsigns, packet types and global filtering, just to prevent
abuse. All this makes it really hard to implement the proposed
versatility in the right way.

Also, the rgate has to set a range filter for which to forward
IS-originated packets. Depending on the path, different areas/ranges are
relevant. This adds further complexity.

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

Why not make it backwards-compatible instead?

> > 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.

I do not see a management load. You set up global thresholds and
two per-callsign thresholds, the software does the management.

> >  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 only thing he will achieve that way is that _more_ of his packets
are dropped. The rate limit must be absolute (packets per minute), not
relative (percentage of received packets).


73 de Georg DO1GL
-- 
APRSdroid - Open Source APRS Client for Android ++ http://aprsdroid.org/m
     ++ https://market.android.com/details?id=org.aprsdroid.app ++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20111228/ead6c381/attachment.asc>