[aprssig] Digi Deduplication Behavior

[Stephen H. Smith]

On 5/20/2014 11:05 PM, Kenneth Finnegan wrote:
> Gentlemen,
>
> I'm trying to fully define the deduplication behavior for digipeaters.
> This is to prevent any echos from other digipeaters of the same packet
> from being digipeated again by the local repeater. Each transmitted
> packet is somehow remembered for a period of time and all further
> packets are compared against this list of previous packets.

The dupe checking function is in virtually all software/firmware that handles 
APRS-style  n-N SSID decrementing.     The KPC3s handle this correctly on n-N 
type paths; i.e. WIDEn-N, TRACEn-N, SSn-N, etc.  They DO NOT do this on classic 
RELAY and plain WIDE path elements.

Apparently the dupe checking was part of the added code module that implemented 
n-N decrementing when that capability was introduced, instead of being applied 
to ALL path elements.

It was the lack of dupe checking on non-n-N traditional paths like RELAY and 
WIDE that led to my inventing the "double WIDEn-N" scheme so that packets both 
from home digis and from high-level true wides could be dupe-checked by KPC3s.


>
> I've seen two values for the dedup table age-out; 28 and 30 seconds.
> I'm thinking the 30 is the correct value, for what little difference
> it makes. Thus an identical packet received at least 31 seconds later
> is considered a "new" packet (which is what makes the KCP-3 KISS
> memory leak bug so fatal).
>

In some devices and applications, this value is user-changeable.  You can't 
count on it ALWAYS being around 30 secs.


>
>  From reading the spec, it looks like the full list of fields that we
> could dedup based on is the source callsign, the destination callsign
> (except for the SSID?), the AX.25 control and PID fields, and the APRS
> payload.

I think it's purely done on the payload, but not 100% certain.

>
>
> The destination SSID is documented as being overloaded for routing
> aliases, but grepping through my four day sample of APRS-IS, although
> I see 2% of packets with non-zero destination SSIDs, most of them also
> include WIDEn-N paths (usually entirely unrelated to the generic path)
> and a quick sampling doesn't show any evidence that the destination
> SSIDs were ever used.
 >
> Did the destination SSID get deprecated at some point? Does anything
> actually change it (the expected behavior for generic paths wasn't at
> all clear from reading chapter 4 of APRS 1.01)?

It's one of those promulgated schemes that never gained traction.

The UIdigi firmware replacement for TNC2s actually had lines where you could 
enter actual calls of adjacent digis at different headings from yours. These 
would replace the next path element such as a generic WIDE, based on the 
destination SSID value of the incoming packet . (I.e. a process similar to 
substituting a real call for TRACE, but for the next digi down the line, rather 
than your own.)   All guides I have seen to configuring UIdigi have advised 
users to just ignore these lines and leave them blank.

I suspect that part of the reason this never took off is that as you travel, 
the desired direction you want to propagate toward would be constantly 
changing. This would force you to keep changing the SSID enroute; a real pain 
for trackers buried in the car's trunk.



A bigger problem with doing anything with destination IDs is that the Mic-E 
compressed position format puts the latitude value here.    Any moving station 
with a north-south vector in it's velocity shows a constantly-changing value in 
the destination field.  Note that the Mic-E format is used exclusively by all 
Kenwood and Yaesu APRS radios, and is a default option on TinyTracks; i.e. very 
widely used by mobiles.