January 2009


XMPP, the Internet Standard eXtensible Messaging and Presence Protocol is being widely adopted for Instant Messaging (IM), Group Chat and Presence services in military networks. This paper starts by looking at the military tactical chat server requirements for IM, Group Chat and Presence. It discusses briefly why XMPP is ideal for these services, and also as a building block for situational awareness systems and in support of voice and video communication.

Tactical networks often need to make use of Radio and Satellite networks with constrained bandwidth, high latency and difficult operational characteristics. This paper looks at the problems of deploying XMPP over such networks, and shows how XMPP can be effectively deployed in such environments.

Creative Commons License

IM, Presence & Group Chat for Tactical Networks

Modern tactical communication has a complex mix of requirements:

  • Deployed units with a variety of communication links.
  • Participants from multiple countries working closely together.
  • Close involvement of field HQ.
  • Involvement of remote personnel, for example to provide specialist advice, or legal involvement with decisions to engage.

The Instant Messaging family of services is a useful and important component of tactical communications.

One-to-one Chat

There will be situations when using 1:1 IM to send or exchange short messages will be more effective that formal messaging or voice communication:

  • When communication links have capacity to send data but not voice.
  • In very noisy situations where voice cannot be heard.
  • In situations where absolute silence must be maintained.
  • To provide information from a location where typing is easy (e.g., field HQ) to field locations in order to provide information that can complement voice.

Group Chat

In some operational deployments (including many military scenarios) group communication is used more than 1:1 IM communication. If data is being provided, it makes sense to share it so that all interested parties can see it. For example, it will enable external strategists or lawyers to observe communication in real time, and provide input as appropriate. It often makes sense to share information in the field, for example a group of ships jointly working out who will target what and how. Group chat is an important operational capability.


Information on online presence can be useful information in support of other communication. Extended presences (additional information associated with presence) can also enable useful sharing. In particular geo-location can be supported as extended presence, enabling presence as a means of location tracking.

Radio & Satellite Constraints on Tactical Networks

Tactical communication needs to use data communication links of widely varying speed and quality. It is important to be able to gain the benefits of fast networking when it is available to support a range of modern applications. However it is also important to be able to use slower links, when they are the only option available. As well as speed, latency and reliability are important characteristics that impact applications using data communications links. Key network technologies are:

  • Satellite. Modern satellite systems provide bandwidth of 1 Mbps and higher, although many deployed systems are much slower (e.g., 4800 bps). Geostationary satellites have a latency of about 0.5secs. It is quite common to chain multiple satellite links, giving greater end to end latency.
  • Line Of Sight Radio (VHF). VHF Radio is widely used in tactical communications. Data links usually operate at 9600 bps (single VHF channel). Multiple channels can be combined to give full duplex communication and higher data rates. Although the physical latency is low, for a standard half duplex link, the low data rate will lead to turnaround times of half a second or more.
  • Line Of Sight Radio (UHF and faster). Higher frequency radio will provide higher bandwidth than VHF. Different bands give different operational characteristics, ranges and opportunities for deployment. All are restricted to line of sight communications.
  • Beyond Line Of Sight Radio (HF). HF Radio provides data rates from 75-9600 bps. Data rates can be highly variable. Turnaround time is typically 5-30 seconds. In order to optimize link utilization, data link protocols will hold the link open, leading to operational latency of two minutes or so. HF links can often be unreliable.

In many deployments, data communication links are shared between multiple applications. Link capacity may be partitioned, to ensure that specific applications do not take more that an allotted share of the bandwidth. This may reduce available bandwidth for a specific application to considerably less than the physical limit.

Why XMPP for Tactical Networks

XMPP is the protocol family of choice for military networks for one simple reason: Standardization. It enables interconnection of heterogeneous components, and integration of partner networks from other countries. In particular:

  • The standard client/server protocol enables integration of users on a wide variety of systems, from specialized deployed units to office systems at HQ.
  • The standard server/server protocol enables easy peer system integration.

XMPP is a rich protocol family, which high functionality and security capabilities. It supports the core services of IM, Group Chat, and Presence. It also supports advanced capabilities, such as geo-location shared by extended presence and is a communications platform suitable to support future applications.

XMPP appears to be an ideal base for a standardized situational awareness protocol family. This gives interoperability benefits over proprietary systems, where all participants must use the same product.

XMPP Configuration Options

XMPP Configuration Options

The above diagram shows two options for providing XMPP service over a slow link to a single client using standard XMPP protocols. In XMPP a client connects to a single server, and then there are direct server to server connections to support communication with clients on other servers.

In the first option, the client connects to its server over a slow link. In the second option, the client is local to its server (fast) and the server communicates with other XMPP servers over a shared slow link. The relative performance of the two configurations can be considered for basic traffic:

  1. For message exchange, a message will traverse exactly one link in each case, so traffic load is similar.
  2. Per connection overhead (setup and keepalive) is higher in option 2, as there are more connections over the slow link.
  3. When a peer changes its presence status, this will be transmitted exactly once to the client, so overhead is the same in both scenarios.
  4. When the client changes its presence status, this will be sent once over the client/server link and then over each of the server/server links which has a client that is monitoring presence. This gives a higher overhead for option 2.

This shows clearly that for a single client, operating the client/server protocol over the slow link (option 1) is going to be most efficient at the network level. So, analysis in the next section is focused on client/server.

XMPP Protocol Performance

This section looks at some XMPP protocol examples, to give a sense of the protocol overhead associated with XMPP. It is not intended as a formal analysis. XMPP protocol uses an XML text encoding.

<message from='juliet@example.com'
<body>Art thou not Romeo, and a Montague?</body>

This is an example message taken from the core XMPP standard (RFC 3920). A minimal message such as this example will have an overhead of around 100 bytes. Typical XMPP clients will use more features leading to a typical operational overhead of 2-300 bytes per message. The overhead for messages to group chat is similar. The main difference is that a client will send the message to a room, and then the same message will come back again (from the room) so the line is used twice.

Presence updates (Chat State Notifications) are a similar size to messages (2-300 bytes). One of these will be received whenever a roster member changes status. When the client changes status, one will be sent and then returned back from the server.

Another common message type is IQ, which is used by the client to check server status from time to time. This has a typical overhead of 70 bytes each way.

Startup has the highest overhead. The following measurements use two popular XMPP Clients (Pidgin; PSI) for a user with about 20 entries on the roster. Basic data transfer as follows:

  • Pidgin: 32 kbytes (4.6 kbytes sent to the server; 27 kbytes back)
  • PSI: 48 kbytes (10.6 Kbytes sent to the server; 37.4 kbytes back)

This data is primarily to ensure client and server are in sync. The main reason for this difference is the PSI is an XMPP only client that makes use of a number of advanced capabilities that give higher protocol costs, as opposed to Pidgin which is multi-protocol and makes more basic use of XMPP.

The startup retrieves a fairly large JPEG photo as a part of the user profile. If this is not done, the modified data is:

  • Pidgin: 13.9 kbytes (4 kbytes sent to the server; 9.9 kbytes back)
  • PSI: 31.3 kbytes (9.3 Kbytes sent to the server; 21.9 kbytes back)

It is worth considering "handshakes", as this can be an issue with high latency networks. Once operational, XMPP is an asynchronous protocol, so the only handshaking would be due to TCP level traffic. On startup, a total of approximately 9 handshakes

XMPP Compression

XMPP provides compression using the DEFLATE algorithm. This can be applied in one of two ways:

  • Directly with the XMPP protocol.
  • Within TLS (Transport Layer Security)

The compression effect is that same, but TLS would increase the overheads at startup. The data from the previous section is without TLS or compression. With both types of compression, DEFLATE will give two effects:

  1. XMPP is a text encoded protocol, and DEFLATE will give an immediate benefit for typical traffic.
  2. XMPP has a regular structure, and common elements are often repeated. DEFLATE optimizes for this by reference to data transmitted, and will give substantial compression as use increases. For example, if a peer user is changing presence status between a small number of values, the same packets will be used to report this change, and DEFLATE will give very high compression.

It is worth considering how much compression is provided. The DEFLATE specification in RFC 1951 notes that "English text usually compresses by a factor of 2.5 to 3" (i.e., to 33-40% of the original size). Given that IM and MUC traffic is the primary user data carried by XMPP,

Protocol also compresses effectively. Ad hoc measurements of a short lived connection suggest that typical presence updates will compress from 100 to 50 bytes, and typical message overhead will compress from 300 bytes to 120 bytes. Other measurements suggest that higher compression can be achieved (factor 4.5-5.8, so reducing data to range 17%-23% of original size).

Startup measurements using PSI (Pidgin does not support compression) and the earlier setup gives:

  • Without Compress: 31.3 kbytes (9.3 kbytes sent to the server; 21.9 kbytes back)
  • With Compression: 8.2 kbytes (3 kbytes sent to the server; 5.2 kbytes back).

This is a factor of 3.8 (reduction to 26% of original size).

These compression characteristics and the high startup overhead mean that network performance is strongly optimized for long lived connections.

XMPP Design and Scaling

When looking at the data numbers in the context of very slow networks, it might appear that XMPP has poor optimization. It is worth considering the broad characteristics and design goals of XMPP:

  • XMPP is designed to provide an extensible communications and information publishing infrastructure. XML is a natural choice to achieve this, and provides an extensible approach that can be easily used in many environments. Although XML is not very compact, the data sizes are small on modern networks, particularly in comparison with voice, video and other data in wide use.
  • On a modern network, XMPP's network usage is very light.
  • XMPP clients are generally developed to provide "best service" to the user. There is no need for focus on optimizing network traffic.
  • The hard problem for a distributed or federated IM system is support of presence. Message switching load scales in a natural manner, with load proportional to usage. With presence, there is a need to update many clients over the network for each status change. Care needs to be taken to ensure that this scales well, and the XMPP design has taken considerable care on this point. This is described in "Interdomain Presence Scaling Analysis for the Extensible Messaging and Presence Protocol (XMPP)".

Client/Server Deployment over Medium Speed Networks

With this basic understanding in place of XMPP performance, we can consider performance of XMPP Client/Server interaction over a medium speed network of 28 kbits per second (3.5 kbytes per second).

Startup of a typical client/server connection will take a few seconds and saturate the network during this time. After this two things will come into play:

  • Compression (which should be used) will work increasingly effectively to optimize data transfer volumes.
  • The traffic caused by typical short message and chat use (e.g., participating in a number of simultaneous 1:1 chats and group chat sessions) and presence update from a moderate sized roster will be feasible. A link of this speed would support a peak load of around 20 short messages per second. This would appear sufficient.

A key characteristic to understand is that startup is slow, and so it will be important to maintain long lived client/server connections in order to efficiently use a network of this sort of speed.

Some optimization could be achieved by using XMPP in a "more efficient" manner and to reduce the number of messages sent. For example, many clients send information of the form "User XXX is Typing". It could be argued that this is not really needed and is just wasting network capacity. On the other hand, in many situations there is ample network capacity to do this, and this additional information provides value to the recipient (they may have an urgent requirement on the response, and it is useful to know that it is being prepared). There is a danger that attempts to optimize traffic will reduce the value of the service. This will be particularly difficult to handle in a network that has

It is suggested that in all but the very slowest of networks, that straightforward deployment of XMPP will be viable and sensible.

HF Radio & STANAG 5066

HF Radio is the most difficult communications medium for which there is a general support requirement. It has low bandwidth, very high latency, and poor reliability. In order to use HF efficiently for data traffic, STANAG 5066 is the approach of choice. To use the HF Network efficiently, it is important to operate the application directly over STANAG 5066, and not to use IP. This is discussed in the Isode white paper HF &Network Centric Warfare.

In order to use XMPP over HF Radio, it is important to include STANAG 5066 as a part of the solution architecture.

Point to Point Deployment over Slow Networks

Consider operating standard XMPP over a network running at 2.4 kbit/sec (300 bytes per second), which is a typical (but not minimum) HF radio speed. Startup at this speed is going to be very slow (over a minute for the example connection described earlier). This will be compounded by two things:

  1. Long Lived connections may be impractical for several reasons:
    • Slow networks are often unreliable, which would mitigate against long lived connections.
    • For a slow network, the overhead of maintaining an open connection may be unacceptable.
    • HF radio does not do data and voice simultaneously, so data links have to be closed for voice traffic.
  2. High latency will make things much worse. XMPP startup involves around nine handshakes, which will have a significant impact if network latency is high.

Even in steady state, 300 bytes per second is going to be tight for IM traffic. Consider (without protocol overhead) a user monitoring several group chats. It is easy to picture that there would be 300 bytes per second of user data, without even considering XMPP protocol and presence overhead.

It is very clear that simple deployment of XMPP over a slow network is not going to work. We now consider what needs to be done to address this.

The above diagram shows the architecture Isode recommends for deployment of XMPP over slow links. On both sides of the slow link is "standard XMPP" and a special protocol is used between the servers over the

  • The impact of the slow link is hidden from users not affected by it.
  • Standard XMPP clients can be used.
  • Multiple clients can be supported on an end system sharing access over a slow link, without significant overhead. Note that the slow link has only one server at each end, so that distribution of common data to multiple servers does not happen over the slow link.

The protocol should have a number of characteristics:

  1. There should be no connection establishment. This will be achieved in two ways:
    • It should offer a connectionless mapping onto IP using UDP, with reliability provided by the application.
    • There should be a mapping onto RCOP (STANAG 5066 Reliable Connection Oriented Protocol) to provide efficient operation for HF. This will typically be used for short data transfers.
  2. Data encoding should be optimized for each packet, as algorithms such as DEFLATE are not very useful for connectionless operation.
  3. There should be a filtering option, to remove traffic that is not considered necessary over the slow link.
  4. Retransmission should be XMPP aware. For example, when sending presence, the current value should always be used.

Multicast and EMCON

Many slow networks use underlying broadcast transmission, and it is desirable that the application can make use of this. A related problem is that it is desirable to support end point in radio silence (EMCON or Emission Control). This means operation without acknowledgements. The architecture for this is shown above.

The optimized protocol discussed in the previous section may be extended to support this.

  • Use of multicast will require a completely connectionless mapping: IP networks are supported with UDP and IP Multicast.
  • HF is supported with STANAG 5066 UDOP (Unreliable Datagram Oriented Protocol).
  • Presence status will always be broadcast, so that all interested parties can read it.
  • Group Chat messages will always be broadcast and selected by interested parties.
  • Retransmission's can be selective or automatic (to support EMCON).


XMPP is important technology for supporting military tactical communication. It is useful directly, and as a basis for interoperable situational awareness systems. The protocol has good functionality, extensibility and scaling characteristics and can be deployed directly over fast and medium speed networks.

For very slow networks (e.g., 2.4 kbits per second) and over HF Radio at all speeds, the protocol overheads of XMPP, in particular startup, are too high, and a modified approach is needed to take advantage of XMPP.

Isode recommends a server to server architecture, which isolates the performance impact of the slow link. Variants are proposed to deal with:

  • Operation over IP (using UDP) and over HF Radio using STANAG 5066.
  • Support of point to point links, and multicast configuration to optimize use of Satellite and Radio networks.

Isode's M-Link XMPP Server supports this architecture.