[aprssig] Maximum APRS Packet Lengths

[Kenneth Finnegan]

So no one on the list really touched on question 1, which I kind of thought
was the least open ended, and thus hopefully the most productive. I do have
people off-list telling me that there was agreement in the ~2000 time frame
to deprecate AEA format completely and the third-party format strictly
follows this with no origin routing path:
}[SRCCALL]>[TNCID],[NETWORKID],[IGATECALL]*:[PACKET PAYLOAD]

I'll observe that I'm hazy on how I was supposed to know that. I *had*
checked APRS1.1 and APRS1.2 and saw nothing about third party headers.

No one proffered any Network Identifiers other than TCPIP, but presumably
others are allowed to crop up, which is why the I-gate guidelines with
respect to not I-gating third party packets with TCPIP in it are so
carefully worded. I know as an I-gate author I certainly hadn't appreciated
the importance in properly handling third-party packets from other networks
than APRS-IS.

On Tue, Nov 29, 2016 at 5:48 AM, Jim Alles <kb3tbx at gmail.com> wrote:

> There is this thread:
>
> http://www.tapr.org/pipermail/aprssig/2012-November/040731.html
>
> On Tue, Nov 29, 2016 at 4:03 AM, Jim Alles <kb3tbx at gmail.com> wrote:

>
> #3, and 5: see http://www.tapr.org/pipermail/aprssig/2008-
> November/027554.html
>
>
D7: 45 characters
D700: 64 characters
VX8R: maybe 80 characters

None of those are 67. It makes an argument that we aren't that beholden to
67 anyways, but I won't die on that hill.

On Tue, Nov 29, 2016 at 5:44 AM, Robert Bruninga <bruninga at usna.edu> wrote:

> 7. Where did this 67 character limit on messages come from?
>
>
>
> What’s left on an 80 character line (PC AT) after displaying date/time and
> callsign.
>

That is a really satisfying answer. Thank you.

On Tue, Nov 29, 2016 at 5:55 AM, Robert Bruninga <bruninga at usna.edu> wrote:

> Because the probability of delivery success for a 214 long packet is only
> 30% of the shorter 67 byte packet.  Unacceptable.
>
> APRS was designed for short packets to keep the channel more reliable for
> everyone.


67 is in fact 30% of 214, but that's ignoring all the over-heads on top of
APRS which move this size difference to more like 40%. Regardless, this
argument implicitly uses a Poisson error model which a lot of people didn't
seem to much appreciate in my thesis. I do get your point though.

In any case, *absolutely* APRS is best enjoyed with short packets; everyone
should always prefer shorter packets to longer packets. My concern is that
when you bake in restrictions like 23 bytes for the project title of a
tracker, some software authors disregard those prohibitive limits while
others depend on them. Just because you loosen the MTU doesn't mean people
will make their packets bigger. Then again, it seems like some people are
running their packets longer regardless of the limits... I'm clearly coming
20 years late to this party, so I just need to come to terms with that.

On Tue, Nov 29, 2016 at 6:41 AM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

> This is why APRSISCE/32 allows the entry of longer messages to send, but
> internally word-wraps them to fit within the max message limit.  They are
> then queued to send back-to-back, but only as acks are recevied providing a
> throttle of sorts.  You might have to be quick to read the entire
> multi-line message as it is received on an APRS radio's small screen, but
> it works.
>
> I think this is really the right type of answer! I guess in some ways I'm
more annoyed by the sub-par user experience of where the text box just
stops working on many software packages than the actual 67 byte L4 MTU.


> As for multi-byte characters, I'm not at all sure any more if I handle
> splitting those properly/safely or if I just split bytes. I'll confess that
> I don't even know enough about them to even formulate and execute a test.


So let's speculate on the best way to split multi-packet text messages here:
Breaking on 0x20 space characters is safe, so start at byte 68 and scan
left for some distance looking for 0x20.
If that fails and you need to break in the middle of a word, you start at
the 68th byte and scan left for the first byte with the most significant
bit not set (0xxxxxxx - normal ASCII), or the first byte with both the 7th
and 6th bit set (11xxxxxx - Start of a UTF-8 encoding.)

UTF-8 is pretty slick how it's self-synchronizing. The first byte of every
extended code point starts with 11xxxxxx, and every follow-on byte starts
with 10xxxxxx.

There's also the consideration of adding SMS / Twitter rant style 1/3, 2/3,
3/3 at the end of each sub-divided packet.

And trust me, the irony that I'm speculating here on how to improve your
software's messaging behavior when Aprx still has an open ticket for not
having *any* messaging capability is not lost on me.

On Tue, Nov 29, 2016 at 10:00 AM, SARTrack Admin <info at sartrack.co.nz>
 wrote:

> Some years ago, when I changed my old compiler for a new one which uses
> Unicode strings...


Seriously, just go back and read Bart's email again; all good points.
That's really unfortunate that AGWTracker doesn't use UTF-8; the rest of us
seem to be standardizing on that.

We do seem to have many applications which are limiting to 67 *characters*
instead of 67 bytes, so which one is it? Because you need 268 bytes to be
able to guarantee storing 67 characters...

Hint: I think the right answer is 67 *bytes* per message, and I think it
would be good for applications to handle that cut-off better than to just
stop responding to key presses, be it via line breaks or Twitter-esque
feedback on length limits.


I am also getting reports of devices known to go catatonic when they
receive long packets. That is pretty silly, so I'd like to get on my soap
box and encourage my fellow developers (in all of our free time) to spend
some time either actively testing or at least pondering their software's
behavior when it receives unusual or illegal packets:
 * Messages with extended character sets. Send a message to "UTF-8" and see
what comes back!
 * Messages with fields grossly exceeding their length limits. A good place
to look for inspiration here is the aprsc test suite:
https://github.com/hessu/aprsc/tree/master/tests/t
Regardless of who's in the right, if you're using a 70 byte fixed width
field to save CPU cycles in 2016, you need to gracefully recover from when
you get a 73 byte payload off the wire.

As always, thanks for all the thoughts and input folks.

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161129/7655884c/attachment.html>