Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
Creative Commons
Isode's whitepapers are licenced under a Creative
Commons Licence.
isode.com / whitepapers
/Measuring MMHS Performance over HF Radio and Satellite: STANAG 4406 Annex E Encoding and Compression
Purpose
This white paper is the first of a set of papers reporting on measurements made of MMHS (Military Message Handling Systems) operating over HF Radio and Satellite. This paper looks at the encoding and compression of STANAG 4406 Annex E messages, which is common to both HF Radio and Satellite transmission.
The paper shows that the encoding of messages is reasonably efficient, and that effective compression can be achieved.
What is Being Measured
The diagram above shows the protocol layers for MMHS over HF Radio and Satellite. Details on these protocols and deployment configurations are given in the Isode whitepaper Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E.
This paper looks at the Message Format (top box), which is the static format common to both HF Radio and Satellite. The dynamic protocols for Radio and Satellite will be looked at in separate papers.
Network Bandwidth
Constrained bandwidth covers a range of speeds, and the numbers in this paper have differing impact across this range of speeds. The following table gives notes on different speeds:
| Speed | Notes |
|---|---|
| 1 Mbit/sec | Typical modern satellite throughput. Although very fast relative to speeds below, this is slow in comparison to commercial networks, and can be a significant bottleneck. |
| 9,600 bits/sec | Typical speed for currently deployed military satellites. Top end of HF throughput, which may be achieved in good conditions, with good aerials and strong transmitters (e.g., maritime deployment). |
| 1.200 bits/sec | Typical operational HF throughput. This number is taken as a figure for generic HF analysis. |
| 75 bits/sec | Bottom end of HF throughput |
| 10 bits/sec | Rate for ELF transmission to submarines |
The implications of the analysis in this paper and its companions will have quite different impact across this range of speeds.
Why Measure
When communicating over constrained networks such as HF Radio and Satellite, it is important to optimize use of the link. In order to do this, an understanding of the operation of the underlying protocols and the applied load is important. This set of papers provides basic analysis of the protocols involved.
For most scenarios, these measurements need to be interpreted in the context of anticipated traffic load, network configuration and network speed. Outcome of this interpretation may be one or more of:
- Information on the best approach to configuration and option selection for the applied load.
- An understanding that the protocols are performing well, and where the limits of performance are.
- Information on how protocols may be adapted to improve performance.
There are many ways that protocols can be modified. We have observed attempts and suggestions for change that we suspect will make little difference to performance for real traffic. This analysis aims to help determine the most effective points for protocol change to address real operational problems.
How Measurements Were Made
Messages were created using Isode’s test User Agent XUXA, and sent over STANAG 4406 Annex E.
The size of three things was measured:
- The Message Content (P2 or P772) size.
- The size of the uncompressed message envelope (including message content) in P1 format.
- The size of the compressed output of STANAG 4406 Annex E, which is passed to the ACP 142 layer.
The first two measurements show the ASN.1 encoded size of the data to be transferred, and the third measurement shows the effect of the STANAG 4406 Annex E encoding and compression. Annex E allows a choice of compression algorithm, but only one (zlib) is currently mandated. These tests use zlib compression.
An initial "base" test was done, which comprised a message with an absolute minimum of features, and short (but reasonable) X.400 addresses. Subsequent tests added one or more items relative to the "base", to show the effect of different services and attachments.
The Measurements
| Msg Content |
Msg Envelope |
STANAG 4406 Annex E |
||||||
|---|---|---|---|---|---|---|---|---|
| Size
|
Delta | Size |
Delta |
Size |
Delta |
Cmprsn | ||
| Base | 113 |
- |
382 |
- |
232 |
- |
39% | The "base" message, using P2 encoding
and a single recipient. |
| P772 | 113 |
- |
379 |
(3) |
233 |
1 |
39% | This changes the type to STANAG 4406 (P772)
which is compatible with P2, but indicates the presence of P7772
extensions in the message. |
| P772 Priority Qualifier | 113 |
- |
396 |
14 |
247 |
15 |
38% | This includes the P772 priority qualifier, that
XUXA always includes for military messages (although strictly
the encoding is only needed when the value is high). X.400 envelope
extensions such as this require encoding of both the extension
and the criticality. |
| Urgent Priority | 113 |
- |
385 |
3 |
236 |
4 |
39% | The default ("normal") message priority
is not encoded. This shows the overhead of adding a simple envelope
feature. |
| 1 char subject | 118 |
5 |
387 |
5 |
235 |
3 |
39% | The base message did not have a Subject. Adding
a very short subject shows the overhead of adding a heading extension.
This shows the typical overhead of a P772 extension, most of which
are heading extensions. |
| 5 char subject | 122 |
9 |
391 |
9 |
243 |
11 |
38% | This shows that adding characters to the subject
increases content and envelope size according to the subject size
(compare with one character subject). |
| 28 char subject | 148 |
35 |
418 |
36 |
270 |
38 |
35% | This shows a slightly larger increase than would
have been expected. This is because ASN.1 encoding is slightly
more efficient for values less than 128 characters long, and the
message size here increased over this limit. This affects both
content and envelope encoding. |
| Two recipients | 160 |
47 |
476 |
94 |
251 |
19 |
47% | Another recipient is added. This affects both
content and envelope, as the recipient is present in both. The
new recipient is similar to the first, which leads to very effective
compression of the new data. |
| Long recipient (added 10 address chars to address) | 123 |
10 |
402 |
20 |
253 |
21 |
37% | The recipient address is made longer. As above,
this affects both content and envelope. |
| DL Expansion Prohibited | 113 |
- |
396 |
14 |
248 |
16 |
37% | This is another example (like P772 priority
qualifier) of a simple envelope extension. |
| Latest Delivery Time | 113 |
- |
412 |
30 |
235 |
3 |
43% | This is an example of an envelope extension
containing more data. It compresses well, probably because of
the similarity of the date to others in the message. |
| Signature - co cert | 113 |
- |
544 |
162 |
410 |
178 |
25% | This uses an X.400 envelope signature (Message
Origin Authentication Check). STANAG 4406 messages use content
based signatures with CMS encoding. This is likely to add a little
more overhead. Signatures do not compress well. |
| Signature + cert | 113 |
- |
1,181 |
799 |
928 |
696 |
21% | Certificates are often included for the convenience
of the recipient. This has a quite high overhead for a small message,
and it may make sense to NOT include the certificate, allowing
the recipient to retrieve the certificate if needed. Certificates
do not compress well. |
| Text: 1 char | 123 |
10 |
400 |
18 |
247 |
15 |
38% | This shows the overhead of adding a basic body
part to the message. This also increases the envelope size, as
this includes “Encoded Information Types” reflecting
the body part. |
| Text: 5 char | 127 |
14 |
404 |
22 |
251 |
19 |
38% | This shows that once the body part is added,
that sizes increase linearly with the amount of data added. |
| Text: 354 bytes | 484 |
371 |
763 |
381 |
508 |
276 |
33% | Short text (start of a news article) gets some
compression. |
| Text: 4.68 kByte | 4,927 |
4,814 |
5,206 |
4,824 |
2,568 |
2,336 |
51% | Larger text (all of the news article) compresses
well. |
| Text: 17.8 kByte | 18,405 |
18,292 |
18,684 |
18,302 |
6,910 |
6,678 |
63% | Larger text (Isode white paper) gives good compression. |
| 1 byte Word Doc | 175 |
62 |
474 |
92 |
308 |
76 |
35% | Word document is added as a File Transfer Body
Part, which has quite a bit of auxiliary information, and reflects
several values in the envelope encoded information types. The
one byte document was “fake”, as real Word documents
are much larger. |
| 24.0 kByte Word doc (3 paras of text) | 24,768 |
24,655 |
25,068 |
24,686 |
3,401 |
3,169 |
86% | This is a minimal word document, which compresses
very well. |
| 74.0 kByte Word doc (2.5 pages of text) | 74,954 |
74,841 |
75,256 |
74,874 |
18,412 |
18,180 |
76% | This larger Word document also compresses well. |
| 748 kByte PowerPoint | 766,146 |
766,033 |
766,448 |
766,066 |
697,944 |
697,712 |
9% | PowerPoint uses internal compression, and so
only gives some compression. |
| 504 kByte (text heavy) PowerPoint | 516,808 |
516,695 |
517,110 |
516,728 |
422,939 |
422,707 |
18% | PowerPoint with a lot of text compresses somewhat
more. |
| 11.4 kByte JPEG | 11,612 |
11,508 |
11,921 |
11,539 |
11,524 |
11,292 |
3% | JPEG is a compressed format, and so there is
minimal compression. |
| 4.918 Mbyte JPEG | 5,035,428 |
5,035,315 |
5,035,730 |
5,035,348 |
5,035,616 |
5,035,384 |
0% | For a large JPEG, there is virtually no compression. |
Analysis & Conclusions
Looking at this data, the following conclusions can be drawn:
- The basic ASN.1 encoding used in X.400 and STANAG 4406 is a reasonably compact and efficient encoding (unlike Text and XML encodings) and the data sizes are reasonable for the information carried.
- The "base" size of data transferred of 233 bytes represents an approximate minimum data size. For most environments, this overhead will be quite acceptable. A future white paper will consider situations where this size may be too large.
- Addition of features appears to give a sensible "per feature" overhead for a range of different extensions. Where it is necessary or desirable to go beyond basic capabilities, the encoding cost of these additional features is acceptable.
- The standard zlib compression achieves 35-40% compression with the core message and message features. This seems reasonable. It is likely that some of this compression is due to regularity of the ASN.1 encoding.
- Body part compression is very much dependent on the compression achieved for the body part in question, and for larger messages compression will be dominated by body part compression. Compressed data types such as JPEG give almost no compression, whereas text documents and formats such as Word compress well. Where heavy use is made of a special body part type, it may be appropriate to use compression algorithms optimized for that sort of data.
The broad summary is that for most deployments and configurations that the STANAG 4406 Annex E encoding is appropriately compact and that the compression will work well, providing clear benefit.
