[aprssig] Maximum APRS Packet Lengths

[Kenneth Finnegan]

So I was chatting with some other APRS developers, and we got talking about
the Maximum Transmission Unit (MTU) used for APRS and maximum APRS message
length, particularly while considering UTF-8. Like usual, I started digging
into it, and have come back up with more questions than answers... (You
guys missed these from when I was working on my thesis, right?)

A summary of my digging is posted here:
https://github.com/PhirePhly/aprs_notes/blob/master/APRS_MTU.md

So I ask myself, what is the maximum length for an APRS packet?

An APRS packet needs to fit inside the Information Field of an AX.25 UI
packet, which is 1-256 bytes long in the context of APRS (It seems like
AX.25 allows for zero length information fields, but I'd vote for not
allowing zero length APRS packets inside of the Information Field, and
APRS101.PDF lists 1-256).

So 256 is an upper limit, but there's also the risk that an APRS packet
will get I-gated, and then be RF-gated somewhere else, at which point it
needs to be encapsulated as a third-party packet. The way I see it, a
third-party packet looks something like this:
}[SRCCALL]>[TNCID],[NETWORKID],[IGATECALL]*:[PACKET PAYLOAD]

The original APRS101.PDF document seems to encourage that you include all
of the originally used path before the NETWORKID, but that seems to have
gone out of vogue and only the fields shown above are included, from what
I've seen.

Adding those up, we get 1+9+1+9+1+9+1+9+2 = 42 overhead for encapsulation
in a third-party packet assuming you only include those four callsigns
(SRCCALL, TNCID, NETWORKID, IGATECALL). 256 - 42 = 214! So the way I
figure, 214 is the real MTU for APRS packets. I had always kind of assumed
that this kind of encapsulation was the driver behind the length limits on
things like APRS messages, but that doesn't seem to be the case.

APRS Message contents are limited to 67; add in the addressing and you get
up to 84.
:[DESTCALL+PADDING]:[MESSAGE]{[MESSAGEID]
1+9+1+67+1+5 = 84

84 is way less than 214... Where in the world did this 67 come from? Even
including 8 digipeater hops in the third party header, I still haven't been
able to justify why we constrain the APRS messages so badly.

So then I ask the question of what the maximum length is for other packet
formats, and continue digging:

 * Location packets - 1+8+1+9+1+43 = 63
 * Time stamped location - 1+7+8+1+9+1+7+36 = 70
 * NMEA position - 1+209 = 210
 * DF Report - 1+8+1+9+1+7+8+28 = 63
 * DF Report w/ time - 1+7+8+1+9+1+7+8+28 = 70
 * Compressed location - 1+1+4+4+1+2+1+40 = 54
 * Compressed location w/ time - 1+7+1+4+4+1+2+1+40 = 61
 * Object - 1+9+1+7+8+1+9+1+43 = 80
 * Compressed object - 1+9+1+7+13+43 = 74
 * PARM. - 1+9+1+5+7+7+6+6+5+6+5+4+4+4+3+3+3 = 79 (THIS IS LONGER THAN 67!)
 * BITS. - 1+9+1+5+8+23 = 47
 * Status report - 1+7+62 = 70

Man did that NOT help. Where in the world did these numbers come from?! Why
are some comment fields limited to 43, where others are 28 or 40?

My favorite is the PARM. and UNIT. telemetry formatters which specify a 68
byte long message contents, which exceeds the 67 limit clearly documented
for the ':' data type payload.

So then there's the question of what actual APRS devices do. I know that
many TNCs support way less than 256 byte long APRS packets, since some of
them only HAVE 256 bytes of RAM. That being said, they're already deficient
since many of these packets + third party encapsulation exceed the TNC's
capabilities. Checking Xastir and APRSdroid, they both enforce 67 byte
limits, but APRSdroid interestingly will ack and display a 220 byte message
sent to it, as will EMAIL-2... I can even send a message from Xastir with
MORE than 67 bytes in it using multi-byte characters, since it seems to be
enforcing 67 *characters*. Unsurprisingly, it would seem that Xastir does
not handle rendering the extended character sets well either... APRSdroid
did handle what gibberish I sent at it over APRS Messages from a telnet
client (§,×,Δ, etc), which makes sense coming from Georg.

So my questions:

1. Do we still want RF-gates including consumed hops in third-party
packets, or is that deprecated in favor of the
"}[SRCCALL]>[TNCID],[NETWORKID],[IGATECALL]*:" 42 byte format? (If we're
going to clarify that as being deprecated, we should probably include AEA
format while we're at it)

2. Are there any other Network IDs in actual use except for TCPIP for
APRS-IS? (Remember that TCPXX is already deprecated)

3. Where did all of these different lengths for comment fields come from?!

4. Do we want to consider loosening up the maximum packet length for some
of these data types?

The way I figure, we could support 197 byte messages for APRS Messages.
This is going to break sending long-winded messages to many devices, but 67
is awfully restrictive compared to modern features like SMS... Clearly new
software is deliberately constraining fields based on the spec. I'll need
to test length limits on the D700 I've got sitting on my bench.

5. Does anyone happen to know the actual length limits on messaging for
various devices out in the wild already?

6. If not messaging, do we want to loosen some of the comment fields? 23
bytes for the BITS. Project Title seems like a strong contender for first
to consider. Remember that we're talking about bytes here, not characters;
many non-English languages using UTF-8 can burn through 23 bytes very
quickly, so I'm talking about making Project Titles allowed up to something
CRAZY like 190 so length just isn't an issue anymore.

7. Where did this 67 character limit on messages come from?! This really
bothers me now.


--
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/20161128/0957a08c/attachment.html>