[aprssig] APRS Reply ACKS and message lesson 101

[Robert Bruninga]

>>> REPLY ACKS was a really good spec addition that 
>>> speeds up messaging.  You send the ack for the 
>>> other station [embedded in] your next message...

History lesson:  For those that are new to packet, please,
please, learn and understand these facts which are fundamental
to packet radio system with ACKS:

1) Packet success via multiple hops is abismal.  This is because
for say a 50% reliable channel, the chance of getting a message
packet through 2 hops is 25%.  The chance of getting the ACK
back is 50% of 50% of that 25% or only 6%.  Thus, the ability to
get more than ONE line from station A to station B is 6% for
each line try.

2) The original APRS was designed with this in mind.  The first
fundamental technique was the Decay Algorithm with the High
initial 8 second RETRY rate.  This meant in less than a minute,
the packet was tried 4 times!   Not ONCE like most follow-on
clones.  This improves the message throughput SPEED by a factor
of FOUR.

3) The second technique was the Delayed ACK.  This is necessary
as proved in number 1, because the propability of success for
ACKS is so much worse than for the outgoing message.  So the
original APRSdos then always scheduled a second redundant ACK 30
seconds after each outgoing ACK.  If one of the other 2 in the
first 30 seconds had already gotten through, then good, this and
subsequent ones were canceled.  But if they had not, then this
one further DOUBLED the throughput.

Combined, Decay-with-initial-high rate, and delayed-ACK made
APRSdos potentially 8 times faster message throughput on a busy
channel than most clones that ignored these fundamental
techniques.  Yet, on a 5 minute average, used no more overall
packets because of the decay algorithm.

4) REPLY-ACK then gains even further speed advantage.  See
example #1.  In this case, MESSAGES get through with FOUR TIMES
the reliability of the ACK getting back.  By placing an outgoing
REPLY-ACK in any next outgoing MESSAGE back to the original
originator, then the ACK's reliaiblity is improved by ANOTHER
factor of FOUR in a dialog.  

Factor this factor of 4 into the above, and in a DIALOG between
two APRS clients that FULLY implemented all of these techniques
and message throughput can be 32 times better than the
simplistic 1 minute retry implemented in some of the most
popular clients.

THIS IS WHY these days, hardly anyone believes that APRS
messages are practical.  But this is because of the abismial
simplistic implementation in some clients that they see, not the
way it is supposed to work.  And REAL events require REALTIME
messaging!

EXMPLE 1.  A 50% RELIABLE PATH (per hop):
 
I am not a mathematician that can rigorously present all this,
but lets compare two stations trying to exchange 3 message lines
over the 50% channel using two hops above.  Using the simplistic
fixed 1 minute rate will probably take about...never mind.  It
will never happen even if the messages are set to timeout after
TEN retries.  Because at a 6% probable success rate, it may take
more than 10 retries just to get the frist line through before
the next line can begin... (Even though the probability that
each received the others message is VERY HIGH, the second lines
cannot be transmitted because the ACKS probability is VERY LOW).
It might get through in 30 minutes before all retries are
exhausted.  The system fails.

Now using the full APRS Message protocol with DECAY, DELAYED-ACK
and REPLY-ACK the messages are probably deliverd in a minute or
so.

A's 1st message has FOUR 25% tries in first minute (average
100%)
B's 1st message has FOUR 25% tries in first minute (average
100%)
(Their acks have only ONE 25% chance of getting back (average
25%)

But as soon as ONE of A's (Four 25% tries) gets through, then
now B's ACK is added to B's (four 25% tries) message and it is
almost assured of being deliverd in that first minute.  Same
goes for B's message to A.  His ACK is mostly assured of being
delivered in that same minute.  Then the next line and so on
down...

The difference is complete failure of the simplistic fixed rate
system, but reliable delivery in a few minutes with the original
APRS system.

EXAMPLE 2.  A 70% RELIABLE PATH (per hop):

With a 70% reliable digipeat, after 2 hops, the message has a
50% chance of delivery and the ACK a 25% chance.  On average
then the simplistic 1 minute system will take about 4 minutes
per line, or about 12 minutes to deliver the 3 line message.  An
EXTREMELY FRUSTRATING DIALOG!

The fully implemented APRS system will do this dialog in about
48 seconds.

EXAMPLE 3.  A THREE HOP PATH:  

(Not using WIDE3-3 of course, but using WIDE2-2,DIGI3).  Forget
even attempting a message with the simplistic 1 minute client.
It is most certain to fail.  In the 50% system, the
probabilities are near 1% and in the 70% system the
probabilities are near 12%.

But you will be successful every time with the original APRS if
the RECEPIENT when he sees your incoming message ANSWERS with a
"Roger, got it" message.  His outgoing retries are now carrying
the ACK of the incoming, and each of these has a 8 or 16 times
better chance of closing the QSO.

Now I hope you see why I complain so much about the loss of APRS
Realtime functionality because everyone's experience these days
is by poorly implemented or incomplete APRS clones.

It would make a nice research paper to do a rigorous probability
and statistcs study of these techniques.

But APRS messaging does work well.... If you use the right
client with all the fundamental APRS protocol implemented.

Bob, Wb4APR