[aprssig] APRS Message Retransmissions

[Robert Bruninga]

> I'm trying to determine when an APRS client 
> program should invoke the decaying 
> retransmission algorithm...

Anytime it introduces a NEW packet of information into the APRS
system.

Message, Bulletin, Object, Position... Everything....

> "Messages with a message identifier are intended 
> to be acknowledged by the addressee. The sending 
> station will repeatedly send the message until it
> receives an acknowledgment, or it is canceled, 
> or it times out."
> 
> This implies that only identified messages (those 
> with a {xxxx ID) are "repeatedly" transmitted.

Or the other (correct) interpretation is that "only messages
transmitted with an ID number are intended to be acked..." which
is the correct interpretation.

> I cannot locate any definition in that 
> document of what repeatedly is nor have 
> I found... the decay other than some 
> references to "fast" as starting at 8 seconds.

See page 10 of the spec "Packet Timing".

> And should non-identified messages (ack-less 
> messages) be retransmitted or sent but a 
> single time?

Anything of interest to everyone over an extended period (more
than a passing one-time info) sh ould be repeated for redundancy
and improved reliability.  This means Bulletins and
Announcements, and all other packets of "new" information (or
changed information).

> "In either of these two situations, multiple 
> message acknowledgments should be separated 
> by at least 30 seconds (this is because some 
> network components such as digipeaters will 
> suppress duplicated messages within a
> 30-second period)."

This is true, but also the original APRS always scheduled an
additional redundant ack 30 seconds after the first one (since
ACKS by definition always have a lower probability of receipt
than the original message).  Though very few if any of the
follow-on clients implemented this.  In effect, this DOUBLED the
ACK success of APRSdos (and maybe APRS+SA and maybe Xastir) for
messages on loaded channels.

Oh, also these 3 clients had other ACK imporovement methods
built in also to make message DIALOGS really fly compared to
some of the many simplistic APRS clients....

1) Fast initial retries on messages(8 seconds and decay beyond
that)
2) Redundant 30 second delayed aack
3) Reply Acks (puts acks for old lines in outgoing new lines)

See www.aprs.org/aprs11/replyacks.txt

> So I really wonder what benefit the fast 8 second 
> retransmission rate accomplishes unless the sender 
> and receiver are in APRS-simplex range.  

It gets the message out 52 seconds faster if the original
suffered a collision.  It gets the second retry out in 16
seconds instead of 2 minutes.  And it tries the third retry in
30 seconds instead of 3 minutes.

Thus FAST.  It is the abismally slow message throughput and poor
ACK performance of some of the simplistic APRS implementations
that have given APRS messages poor expectations. 

> Any Digi (provided it heard the first one) will be 
> suppressing the retransmissions turning them into 
> local QRM for the remainder of the 
> first 30 seconds, or am I missing something here?

If the digi heard it and digipeated it, then the recepient
probably heard it and Acked and so within that first 8 seconds,
the message is delivered and acked and done, and ready for the
next line.  If the digi heard a collision and missed it the
first time, then it is not "QRM" since it never made it out, and
is then a first-time heard new info packet...

> PS.  I have read about REPLY-ACKs and do plan 
> to implement those in my client as well.

Great! Thanks
Bob
WB4APR