[aprssig] APRS Message workarounds

Wed Jan 16 15:15:11 EST 2008

As a followon to my MESSAGES 101 email...

MESSAGE OPERATIONS:

There are several things EVERYONE is supposed to be doing to
make APRS messaging work best.  This makes messaging using the
simplistic clients possible, and really fast on the full ones:

1) Never try to message beyond 1 or 2 hops reliably.

2) Recognize that your message had 2 to 4 times higher chance of
getting through then you will ever see in getting an ACK back.

3) If you think the other guy got the first message, kill it so
that the next line can go out even if the first ACK never got
back.

4) When you see an INCOMMING message.  ALWAYS answer it (human
response).  This accomplishes MANY things in a real-time
network:
  (A) Messages are for HUMANS.  Give the HUMAN response!
  (B) outgoing messages have double the reliability of an ACK
via 1 hop and FOUR times the reliability via 2 hops!  This tells
him you got the message even if the ACK didn't make it.
  (C) if you are using one of the fully implemented APRS
clients, then this same multiplication in success will get his
ACK back to him so his system will send the next line.

5) If you must use a 3 hop path for a special message from point
A to point B, then use WIDE2-2,DIGI3, never WIDE3-3!  The
directed  hop on the end will have little more QRM than 2 hops,
but will improve the reliability that DIGI3 gets it. NEVER use
W3-3 or the QRM kills the network.

6) NEVER use REPLY-MSGS.  They are Just QRM.  They do NOT have
any of the above advantages because they are not "pushed" but
are just like another ACK, but one that does absolutely nothing.
The only time to use REPLY-MESsAGES are in a REAL time event,
when the operator might need to disappear for 20 minutes.  Then
a REPLY-MESSAGE saying "Ill be back at 1330" is a GOOD use of
this capability.  In the original APRS, any such REPLY message
is automatically canceled whenever the sender returns and
touches his keyboard.  IE, we never want reply messages that are
not providing REAL-TIME INFO to the other end.

These rules above about messages are fundamental to real-time
APRS.

Bob, Wb4APR

> -----Original Message-----
> Sent: Wednesday, January 16, 2008 2:49 PM
> Subject: [aprssig] APRS Reply ACKS and message lesson 101
> 
> >>> 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
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 