Variable C_PDU Segment Size (S5066-EP11)

This document specifies a modification of STANAG 5066 to allow more flexibility in selection of C_PDU segment size. This enables performance improvements. The complete set of documents in this series are:

  1. STANAG 5066 Extension Protocol Index (S5066-EP1)
  2. STANAG 5066 Padding DPDU (S5066-EP2)
  3. Pipelining the CAS 1 Linking Protocol (S5066-EP3)
  4. Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)
  5. STANAG 5066 Large Windows Support (S5066-EP5)
  6. Slotted Option for STANAG 5066 Annex K (S5066-EP6)
  7. Advertising Extended Capabilities (S5066-EP7)
  8. Block Based EOTs (S5066-EP8)
  9. Compact Acknowledgement (S5066-EP9)
  10. Extension DPDU (S5066-EP10)
  11. Variable C_PDU Segment Size (S5066-EP11)
  12. HF Wireless Token Ring Protocol (S5066-EP12)
  13. STANAG 5066 Routing Sublayer (S5066-EP13)
  14. STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)
  15. AES Key Distribution for TRANSEC and Half Loop (S5066-EP15)
Creative Commons License
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

1. The Constraint

STANAG 5066 Section C.4.1 (ARQ Mode Segmentation and Re-assembly) bullet e specifies:

“e. Only the last segment or the only segment taken from a C_PDU may be smaller than the Maximum C_PDU-Segment size. A C_PDU smaller than the Maximum C_PDU-Segment size shall (6) be placed only in the D_PDU that contains the last segment of the C_PDU, i.e., only in a D_PDU for which the C_PDU END field is set equal to one.”

An implementation following this specification may ignore this constraint.

An implementation following this specification shall advertise support following the mechanism defined in S5066-EP7 (“Advertising Extended Capabilities”).

2. Benefits of Removing The Constraint

There is one primary and two secondary benefits of removing the constraint

2.1 Filling Transmissions

STANAG 5066 transmissions need to fill an exact number of blocks, so the exact number of bytes to be transmitted is fixed. A very common situation will be for bulk ARQ transmission, where the full transmission takes multiple transmissions. It is highly likely that at the end of the transmission, the next DPDU to be sent is a C_PDU segment of maximum segment size. If this cannot be fitted in, it will need to wait for the next transmission and the space in the current transmission is wasted. On average, this wastage will be 50% of the maximum C_PDU segment size.

This inefficiency gets larger as speeds reduce. At 75 bps, if 50 byte segments are used (with 30% DPDU header overhead) there is a 3% overhead. If you move to 100 byte (18% DPDU header overhead) this overhead increases to 5.1%.

At 1200 bps with 300 byte segments (Annex H recommended size) there is an overhead of 0.8%. However, if transmissions are reduced to 20 seconds, the overhead increases to 5.4%. Shorter transmissions can be desirable for interactive traffic where bulk data needs to be transferred, such as Web.

If a TDMA approach, with much shorter transmissions, is used then the overheads become higher. For 1.5 second transmissions, the overhead is 14.5% at 19,200 bps and 2.3% at 120 kbps.

Removing the constraint allows the sending STANAG 5066 to construct a DPDU with a C_Segment size chosen to exactly fill the space. This is a useful optimization, particularly for lower speeds and TDMA.

2.2 Block Alignment of DPDUs

A transmission will comprise a sequence of modem blocks. For bulk data transfer a long block (interleaver) will generally be chosen to maximize throughput. If there is poor signal during the transfer of a block and there are a significant number of errors, it is likely that all of the DPDUs transferred in the block will be damaged. Because of this, it is desirable to send things so that DPDUs do not cross block boundaries.

Allowing flexibility of segment size will allow an implementation to send a smaller (or perhaps slightly larger) C_PDU segment at the end of the block to align DPDUs to the block boundary. This will improve performance.

2.3 Even C_PDU Segment Size

Consider a maximum size C_PDU of 2053 bytes with the maximum segment size of 1023 bytes. The current standard requires this to be transferred as 1023, 1023, 7. Relaxing the rules would allow this to be transferred as 685, 684, 684. This has the same first transmission overhead, but will have better performance characteristics in the event of data corruption.

3 Backwards Compatibility

C_PDU segments currently have variable size (as a consequence of C_PDU being variable size), so it is likely that most receiver implementations will handle the changes of this specification without modification. However, it is possible that receiver implementations may rely on the current constraint. So this extension shall only be used if the sender knows that the receiver can support it. This can be by:

  1. A priori knowledge; or
  2. By noting receiver capability advertisement following S5066-EP7.