[aprssig] smart IGates

[Lee Bengston]

On Wed, Jun 22, 2011 at 2:50 AM, Heikki Hannikainen <hessu at hes.iki.fi> wrote:

> I don't think the RF to IS direction requires any filtering at the igate
> level. The IS servers already do relatively good job of duplicate filtering
> (it's not possible to make it perfect, but that's not the IS server's
> fault). The igates can't do the duplicate filtering any better than the IS
> servers either - they don't have the full view of the IS traffic because of
> they're not connected to the full feed.

It's certainly not a bandwidth problem like it is with IS to RF.  In
the case of a distance or hopcount limit, that technically would not
be duplicate filtering - more like duplicate avoidance.  If everyone
is content to just filter the dups at the servers, though, I'm fine
with it.

> It's also "cleaner" and easier to upgrade the IS servers if the duplicate
> filter algorithms require fine tuning than to upgrade the igates, simply
> because there's not so many of them. The IS servers tend to be more actively
> maintained and upgraded than the igates. I'd rather keep the igate logic as
> simple as possible so that the numerous different implementations would be
> more likely to be correct, and so that the technical barrier to implement a
> new igate software would stay low.

That makes sense.

>> Another feature I've seen implemented in the IS to RF direction that would
>> be interesting in the RF to IS direction is a hold-off timer. Basically hold
>> off and listen for the same packet on the internet side that you just
>> received via RF.  If you don't hear it after 5 seconds, for example, then
>> send it into the IS - otherwise drop it.
>
> This would have a couple of shortcomings:
>
> This would require the igate to actually receive the packets from the IS.
> Normally the igates are connected to the 14580 port of the server, and most
> run with no filter set. They do not receive any packets from the IS at all,
> unless the IS server figures out that an APRS message should be transmitted
> by the igate (IS->RF), together with an associated position. Very little
> traffic is sent from the IS server to the igate, so the total outgoing
> network traffic from the IS server stays low, which is good! We don't want
> to change that.

The 'full-blown' software packages like Xastir or APRSIS32, however,
tend to be set up to receive from the IS anyway for map display.  What
gave me the idea was an observation after watching packets being
received from both RF and IS.  On more than one occasion I saw a
specific packet received on IS first, followed by the same one on RF
that had been digipeated.  Then I saw the RF version get gated - just
seemed silly.

> I believe that the cost of transmitting larger feeds downstream to the
> igates would be larger than the cost of transmitting a few extra copies of
> the received packets upstream.

Perhaps, but I don't see the feeds really needing to be that large -
only need packets for the local area - a selected radius, and as I
mentioned above, many IGates are probably already receiving feeds for
local map display, which is exactly what I was doing with Xastir when
I saw the extra packets gated.
>
> The additional 5 second hold-off delay on some igates would add up to the
> other delays in the network, making it more probable that the packet would
> escape the 30-second dupe filter window.

Yes, and in hindsight the behavior I saw probably would not need a
hold off timer to help mitigate it given the packets were seen on IS
before being seen on RF.

> Also, having the IS servers see all the duplicates received by the different
> igates allows them to make smarter decisions on where to send the APRS
> messages destined for the users. The IS servers actually get to know all the
> igates which can receive the user at any time, and which can possibly relay
> messages for them.

Interesting - did not realize that.

I was tossing out some food for thought for the IGate software
developers, but perhaps it's not worth it given the high bandwidth of
the Internet and the strong competence level of the servers.

Regards,
Lee - K5DAT