[aprssig] smart IGates

[Heikki Hannikainen]

On Mon, 20 Jun 2011, Lee Bengston wrote:

> I haven't researched all of the capabilities of the various IGate
> capable software, but looking at the few that I have, I don't see
> options for things like distance limits or hop count limits that can
> be imposed in the RF to IS direction.

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

> In my area, it's probably safe to assume that if I receive a packet with 
> a hop count greater than 1, or if I receive a packet further away then 
> say 25 miles, it's probably already been gated to IS by an IGate closer 
> to the packet source, so the preference would be to ignore it.
>
> 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.

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.

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.

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.

   - Hessu