Join us on LinkedIn Read our Blog

ACP 142 Parameters for Radio and Satellite Networks

Purpose

ACP 142 specifies a protocol for reliable multicast. It is used for message transmission over networks such as Radio and Satellite. ACP 142 defines a number of protocol parameters which are discussed in the context of different networks. The goals of this paper are to:

  1. Provide some understanding of the parameters and appropriate settings for different networks.
  2. To explain the M-Switch configured settings.
  3. To enable feedback from protocol experts and from deployment experience on appropriate values for the various parameters. Isode plans to share this information in updated versions of this document, and to use it in future versions of the Isode management tools, to enable easy setting of optimal parameters.

ACP 142

ACP 142 defines a reliable multicast protocol, sometimes referred to as P_Mul. ACP 142 was originally designed to support STANAG 4406 formal military messaging. ACP 142 and its use with STANAG 4406 are described in the Isode white paper Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E. Use of ACP 142 to support Internet email is described in the Isode white paper Messaging Protocols for HF Radio. As well as supporting multicast, ACP 142 supports nodes that do not transmit data (EMCON or Emission Control).

ACP 142 operates over an unreliable connectionless service that will typically be provided by one of:

  • UDP (User Datagram Protocol) running over IP.
  • UDOP (Unreliable Datagram Oriented Protocol) running over STANAG 5066.

The connectionless nature of the bearer service requires ACP 142 to define a number of timers. Configuring these timers is the primary subject of this paper.

Network Characteristics

There are a number of network types that ACP 142 may be used for, with widely varying characteristics, that have significant impact on ACP 142

Network Bandwidth Latency Reliability Recommended Bearer
Satellite 4800 bits per second to 1 Mbit per second 0.5 seconds physical latency for a geostationary satellite. Use of multiple satellites is common Very high IP
Radio above UHF Fast Low Fair IP
UHF 9600-56,000 bits per second Low Fair IP or STANAG 5066
VHF 9600 bits per second Low Fair STANAG 5066. IP will degrade performance but is acceptable
HF (Beyond Line of Sight Radio) 75-9600 bits per second

Bandwidth can often vary dynamically and dramatically

Minimum latency is typically 5-30 seconds. Data link layer will often increase latency (up to two minutes) in order to optimize link utilization

 Fair to poor STANAG 5066. IP performance would be unacceptable

Isode Management Tool Goals

The current release of the Isode configuration GUIs for ACP 142 allow direct configuration of the ACP 142 parameters described in this paper. The primary reason for this is that there is relatively little operational experience, and it is likely to be important to tune some of these parameters in order to gain optimum performance.

As experience is gained, Isode plans to provide a higher level interface that will set parameters that can be easily determined (such as the type of network used) and set the ACP 142 parameters according to this. Explicit control of some parameters may be retained as an advanced option.

Parameter Algorithms

Sensible values for ACP 142 parameters vary significantly, dependent on operating conditions. However, direct setting of these parameters will be too complex for most system administrators. The Isode approach for our planned new UI is to have the UI set a number of “high level” parameters, which the system administrator can reasonably be expected to understand. The ACP 142 parameters will be derived from these parameters, with advanced option to set the parameters directly. The parameter descriptions explain how the Isode settings are derived from these high level parameters using pseudo-code. This will be helpful to advanced system administrators, and may also help to review the algorithms that Isode uses. The directly set high level parameters are:

  • Max link speed.
  • Min link speed. (This and the next parameter are important for HF and other systems with variable link speed)
  • Typical link speed.
  • Network Type: Satellite; VHF/UHF; HF.
  • IP or STANAG 5066 (Does link use IP, or is direct use of STANAG 5066 made).

One pseudo-parameter is used in the algorithms below.

  • IP-over-STANAG-5066 is considered set if both IP and HF are selected. Isode strongly recommends against using IP over STANAG 5066, but notes that this can be needed for interoperability reasons.

ACP 142 Parameters

The ACP 142 parameters are discussed in three groups:

  1. Parameters for general use.
  2. Parameters used for EMCON transmission.
  3. Parameters used for setting up dynamic multicast.

Each parameter is described, with notes on the effect of it being set too high or too low. Then values are suggested for a range of networks. Many of these values are suggested based on theoretical analysis of what makes sense, and practical input on these numbers would be very desirable. All times are in seconds and bandwidths in bits/second unless explicitly noted otherwise.

These STANAG 5066 values assume that a node will break transmission after 127.5 seconds and allow other nodes to transmit. Some STANAG 5066 servers will transmit until all data is sent. For such systems, it may make sense to set some values (in particular RE-TRANSMISSION_TIME, BACKOFF_FACTOR, an ACK-PDU_TIME) to larger values.

General Parameters

Bandwidth (DATA_ PDU)

Controlling the bandwidth is key for a rate controlled protocol such as ACP 142. Note that this value is set in bytes per second. When operating over STANAG 5066, rate control is provided by the modem (STANAG 5066 Server) Flow control is asynchronous, and so rate should be set to a value where flow control will work without extra data being sent (i.e., not too fast).

Isode M-Switch enables configuration of the bandwidth for operation over IP. If the rate is set too low, network bandwidth may be wasted. If set too high, packets will end up being dropped, leading to retransmission, with associated inefficiency and delay.

If the network is being shared, this should be set according to bandwidth allocated to the application. If the network is not being shared, bandwidth should be set to slightly less than the underlying network bandwidth.

ALGORITHM:

If (STANAG 5066) THEN 128 kbits/sec
ELSE IF (IP-OVER-STANAG 5066) Then 60% Typical Bandwidth
ELSE 80% Typical Bandwidth

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
205 kbps 7680 bps 45 kbps 7680 bps 128 kbits/sec 128 kbits/sec

 

Retransmit (RE-TRANSMISSION_ TIME)

In operation without data loss, after the end of the message, an ack will be received from all recipients. If one or more acks have not been received after this retransmission time, an address PDU is sent (indicating the peers for which acks have not been received). This will trigger the receiving application to resend the final ack.

If this value is set too low, bandwidth will be wasted if the PDU being timed out is delayed rather than missing. For HF, the interval will generally be longer than the 2 minute STANAG 5066 max transmit time. If set too high, overall latency will increase.

ALGORITHM:

IF (HF) THEN 180
ELSE IF (min link speed < 28 kbps) THEN 20
ELSE 10

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
10 20 10 20 180 180

 

Backoff factor (BACKOFF_ FACTOR)

The retransmission described above backs off exponentially according to this factor. For example if the backoff factor is 2, and retransmit interval is 10 seconds, then retransmit intervals will be 10, 20, 40, 80, 160 etc. Backoff factor needs to be 1 or greater. The current UI sets backoff as an integer of 100 times the backoff factor. This value is shown in brackets in the table below.

If the backoff factor is set too low, bandwidth will be wasted when transmission is blocked and an excess number of address PDUs will be queued, each of which will need to be acknowledged. If the backoff factor is set too high and the early address packet retransmissions are lost, then the very long later intervals may lead to message delay.

ALGORITHM:

IF (HF) THEN 2
ELSE IF (VHF/UHF) THEN 1.5
ELSE 1.2

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
1.2 (120) 1.2 (120 1.5 (150) 1.5 (150) 2 (200) 2 (200)

 

Max Missing (MM)

This controls the maximum number of missing PDUs that can be reported in an Ack. It should set to a value that does not require the Ack PDU to be split. The consequences of varying this are unclear.

ALGORITHM: 20

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
20 20 20 20 20 20

 

Ack Respond (ACK-PDU_ TIME)

After the receiver transmits the final ack, it expects to get an Address PDU confirming that the message is cleared. If it does not get this, the Ack is resent according to this timer.

Setting this too low will waste bandwidth. Setting this too high will cause the clearing of message status to be delayed.

ALGORITHM:

IF (HF) THEN 480
ELSE IF (VHF/UHF) THEN IF (min link speed < 28 kbps) THEN 120 ELSE 60
ELSE 10

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
10 10 60 120 480 480

 

Last PDU Timer

This controls behavior after the last PDU of a message is received. It will wait this amount of time to check for missing PDUs. This will deal with out of order PDUs. This may occur over IP networks, but should not occur with STANAG 5066. This parameter has a minimum value of two seconds. The minimum is recommended, except for slow networks where packets may be delivered out of order.

ALGORITHM:

IF (IP & min link speed < 28 kpbs) THEN 5
ELSE 2

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
2 5 2 5 2 2

 

Undef Data Valid

A receiver may get a Data PDU without an Address PDU. This parameter defines how long to hold onto this data, and wait for a retransmit of the address PDU.

Setting it too high has a marginal cost on internal receiver resource. Setting it too low wastes network resource if the Address PDU is retransmitted after the PDU is discarded.

ALGORITHM:

IF (HF) THEN 1 hour
ELSE IF (min link speed < 28 kbps) THEN 10 mins
ELSE 1 min

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
1 min 10 mins 1 min 10 mins 1 hour 1 hour

 

EMCON Parameters

EMCON Time (EMCON_RTI)

When a receiver is believed to be in EMCON, the entire message is retransmitted a number of times.

This timer controls the interval between retransmissions. The value of the interval depends very much on the reasons why data may not be received. If the main issue is loss of some packets, the interval should be short. If the main issue is that the receiver may be out of range and not receiving anything a longer interval is more likely to be appropriate.

The interval should in any event be commensurate with network bandwidth and latency.

ALGORITHM:

IF (HF) THEN 10 mins
ELSE IF (min link speed < 28kbps) THEN 5 mins
ELSE 1 min

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
1 min 5 mins 1 min 5 mins 10 mins 10 mins

 

EMCON Count (EMCON_RTC)

This is the number of times a message is retransmitted. This has similar considerations to the interval. The suggested parameters are on the basis that the primary concern is network reliability.

ALGORITHM:

IF (Satellite) THEN 2
ELSE 4

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
2 2 4 4 4 4

 

Dynamic Multicast Parameters

Dynamic multicast will not be used with STANAG 5066, and should generally only be used for faster IP networks with multiple network components.

Announce Count (ANNOUNCE_CT)

This is the number of announce PDUs to be sent. If set too low a recipient misses the announce, it will have a quite high network cost to sort out. If set too high, network resource will be wasted.

ALGORITHM:

IF (satellite) THEN 2
ELSE 4

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
2 n/a 4 n/a n/a n/a

 

Announce Interval

The time between sending out Announce PDUs. This gap should be sufficient to make data loss independent.

ALGORITHM: 5

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
5 n/a 5 n/a n/a n/a

 

Wait before Send (ANNOUNCE_DELAY)

The delay before sending the first message data after dynamic multicast is negotiated.

ALGORITHM: 10

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
10 n/a 10 n/a n/a n/a

 

Wait for reject (WAIT-FOR-REJECT_TIME)

The time that is waited for rejects. This should only be needed if different senders share the same dynamic multicast addresses. It is recommended to avoid this.

ALGORITHM: 10

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
10 n/a 10 n/a n/a n/a

 

End Session

The time before a dynamic multicast session is releases.

ALGORITHM: 60

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
60 n/a 60 n/a n/a n/a