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 whitepaper [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 whitepaper [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 for use by CO ACP 142
  3. Parameters used for EMCON transmission.
  4. 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, message transmission is initiated with an Address PDU (to indicate recipients) and then as sequence of data PDUs. After the last data PDU, an ack will be received from all recipients.

This timer is set by the sender when the last PDU of the message is sent. This timer is designed for three situations:

  1. When no data is received by a recipient. Here the approach is to send the message again.
  2. If no acks are received by the sender. This might be due to network conditions or an EMCON situation that the sender is not aware of. Again, the approach is to send the message again.
  3. If the initial address PDU is lost. If this happens, the receiver is not able to send acks, so the address PDU must be sent again.

Note that this timer is not intended to deal with partial data loss. This is handled by receiver timers described later.

After this timer goes off, an Address PDU will be sent, followed by the Data PDUs after an optional delay described in the next section.
If this value is set too low, bandwidth may be wasted due to repeat transmission . If set too high, overall latency will increase, in the event of address PDU loss or total message loss on first transmission. For HF, this interval is set on the basis of a reasonably short turnaround time at the end of message transmission.

ALGORITHM:

IF (HF) THEN 30
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 30 30

Retransmission Delay Time

This is an optional sender side timer, introduced in ACP 142(A). After an Address PDU is sent following the retransmit timer described above, this delay is added before retransmitting the message data. The benefit of this delay is that if the reason for the timer going off is loss of address PDU, the retransmission of the address PDU will trigger Acks from the receiver. This in turn will avoid resending the message.

We recommend to set the basic retransmit timer fairly aggressively and this timer conservatively, as retransmission of address PDU is a small additional cost and retransmission of the entire message is a high cost.

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.

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 1.2 1.5 1.5 2 2

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 due to extra Acks and Address PDUs sent in response. Setting this too high will cause the clearing of message status to be delayed and may lead to message retransmission. As the cost of sending multiple acks is much lower than message retransmission, this timer should be set more aggressively than sender side retransmission timers

ALGORITHM:

IF (HF) THEN 120
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 120 120

Last PDU Timer

This is a receiver side timer, set as an estimate of when the Last PDU will arrive. It provides receiver side protection on loss of data. This is set as the higher of two values:

  1. A time based on the arrival rate of Data PDUs.
  2. A fixed configured time, which is also the value used prior to arrival of any data. This is done to deal with bursty transmission with long gaps, for example as seen with HF Radio

If set too low, some bandwidth will be wasted due to the NACK and duplicate transmission. If set too high, overall message latency will increase.

The default value is set so that it is aligned to gaps in bursty transmission.

ALGORITHM:

IF (HF) THEN 150
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 150 150

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. This should be set to slightly longer than the anticipated maximum message transmission time.
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 2 hours
ELSE IF (min link speed < 28 kbps) THEN 1 hour
ELSE 30 mins

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
30 mins 1 hour 30 mins 1 hour 2 hours 2 hours

CO ACP 142 Parameters

Connection oriented ACP 142 (CO ACP 142) may be enabled to optimize connections to a single peer. This has two parameter which needs to be tuned.

PDU Size

The PDU size is by default 64 kBytes. Reducing this will slightly reduce protocol efficiency. However, this size determines the interval at which a message can be pre-empted. This means that the default is too tight for very slow networks.

ALGORITHM

The algorithm is based on having a pre-emption interval of 1 minute or less. This will happen with max PDU size for speeds of 8500 bits/second and greater. The algorithm also requires a minimum PDU size of 2kbytes, which means having a pre-emption time of longer than a minute for speeds of less than 267 bits/second.

IF (typical speed > 8500 bps) THEN 64 kByte
ELSE IF (typical speed < 267 bps ) THEN 2 kByte
ELSE ( typical speed (bps) * 60 )

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
64 kByte 64 kByte 64 kByte 64 kByte 18 kByte 2.25 kByte

Message Timeout

This is set at the beginning of transfer of a PDU. If this timer goes off, the message acknowledgement is assumed to be lost, and the message will be sent again.

ALGORITHM

The algorithm calculates the time that wold be taken to transfer the message at minimum network speed and then adds 5 minutes for HF Networks and 2 minutes for other networks.

IF (HF) Then PDU Size / Minimum Link Speed + 5 minutes
ELSE PDU Size / Minimum Link Speed + 2 minutes

Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
122 secs
173 secs 129 secs 173 secs
360 secs 360 secs

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

n/a
Satellite 256 kbps Satellite 9600 bps UHF 56 kbps VHF 9600 bps HF 2400 bps HF 300 bps
2 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