[aprssig] Preliminary delayed packet analysis

[AE5PL Lists]

> -----Original Message-----
> From: VE7GDH
> Posted At: Friday, June 16, 2006 8:20 PM
> Subject: RE: [aprssig] Preliminary delayed packet analysis
> 
> Re dupes... I actually think it would be a good thing if the  
> APRS-IS went back more than 30 seconds looking for dupes. I 
> don't know if the servers would need more horsepower or not, 
> but if they did dupe checks for a minute or even better, two 
> minutes, we would see less zig-zagging of stations caused by 
> delayed packets. I was watching a mobile station this morning 
> and many of the dupes were just over 60 seconds in age, but 
> some were up to two minutes.

Instead of masking problems (what the heck, why not do a 24 hour dupe
check on packet type x, y, and z but not packet types a, b, and c...),
fix the problem.  If the problem is on RF, you just partially hide it
from Internet users.  If the problem is at the IGates, then what about
all the dupe packets of non-posit types?  Bottom line: if you have
issues with a specific IGate or server, address it directly with them.
If it is "too difficult" for the affected sysops to diagnose or for you
to pursue, then that's too bad.  APRS-IS is not a plug-and-play network
where everything is rosy (heck, the Internet isn't either and that
compounds the problem).

Dupe checking was implemented on APRS-IS to reduce bandwidth
requirements (on clients and servers) and to prevent most loops.  The q
algorithm was added to further reduce looping.  Dupe checking was not
put in to mask malfunctioning software or devices.  In fact, wouldn't it
be better to fix the problem instead of someone wondering why their
packets never seem to make it in or why that ack just never seems to get
through because some server artificially duped it out?

I'm sorry for this bit of soapbox, but there has been a lot of comments
on this thread without much motion for _solutions_.  The solution is to
fix the problem IGates, digipeaters, and servers.  The solution is not
to implement 500 different kinds of specialty dupe-checking algorithms
which will only be implemented in a small percentage of servers and
never in the IGates or clients.  Those dupe-check algorithms only mask
malfunctioning devices and potentially make APRS-IS useless due to
eliminating useful packets, etc.

I did not design APRS-IS nor would I have designed it this way.
However, it is what we have to work with and I, for one, have done a
significant amount of work to make it as reliable as possible (don't
know if you were around 3-4 years ago when servers and clients couldn't
stay operational for more than 24 hours due to loops, bad
configurations, poor design, etc.).  Can it continue to be improved?
Yes.  Can the network design be modified in such a way as to prevent
these types of problems?  Not completely because we are using the
Internet for our backbone.  Can the base network design be changed
without adversely impacting the thousands (yes thousands) of clients,
IGates, and servers connected?  Not really.

So, focus on the problematic devices not APRS-IS as a whole.  APRS-IS is
what it is and does what it does surprisingly successfully.  The network
is not going to change significantly until there is a push for a
completely new design which utilizes more advanced protocol
implementations between network devices.

Identify specific problems, communicate _directly_ with the affected
sysops, and resolve the problems.

End of soapbox.  Flame away...

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net