Advance to Active as per Council vote on 2018-01-10.
0.4.12017-09-17ssw
Minor editorial fixes.
Remove reference to EXI which has no implementations.
0.4.02017-01-17ssw
Attempt to fix some confusing paragraphs.
Add Client State Indication to Notable Extensions.
0.32015-07-24ssw
Include real world compression numbers and additional recommended
reading.
0.22015-07-22ssw
Overhaul to include LTE.
0.12010-09-15psa
Initial published version.
0.0.12010-07-13dwd
First draft. Also John's birthday.
XMPP as a protocol was designed before the wide spread adoption of mobile
devices, and is often cited as not being very mobile friendly as a result.
However, this mostly stems from undocumented lore and outdated notions of
how XMPP works. As the Internet and protocol design have changed to be
more accommodating for mobile, so has XMPP.
This XEP aims to provide useful background knowledge of mobile handset
behavior, and those considerations that client and server designers can
take to ensure that bandwidth and battery are used efficiently.
The two major constraints on mobile devices are power and bandwidth.
With the wide spread proliferation of 3G and LTE technologies, mobile
bandwidth and speeds have become broadly comparable to broadband.
However, they are still relatively expensive compared to traditional wired
networks, and therefore conserving them is still desirable.
This XEP mostly focuses on LTE as it already has a very wide deployment
and will only continue to further replace 3G technologies.
XML, and by extension XMPP, is known to be highly compressible.
Compression of XMPP data can be achieved with the DEFLATE algorithm
(RFC 1951RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 <http://tools.ietf.org/html/rfc1951>.) via TLS compression (RFC 3749RFC 3749: Transport Layer Security Protocol Compression Methods <http://tools.ietf.org/html/rfc3749>.) or Stream Compression (XEP-0138)XEP-0138: Stream Compression <https://xmpp.org/extensions/xep-0138.html>. (which also
supports other compression algorithms).
A description of the security implications of stream compression is beyond
the scope of this document (See RFC 3749RFC 3749: Transport Layer Security Protocol Compression Methods <http://tools.ietf.org/html/rfc3749>. or Stream Compression (XEP-0138)XEP-0138: Stream Compression <https://xmpp.org/extensions/xep-0138.html>. for more
information), but the author does not recommend using TLS compression with
XMPP (or in general).
If compression must be used, stream level compression should be
implemented instead, and the compressed stream should have a full flush
performed on stanza boundaries to help prevent chosen plaintext attacks.
While this may mitigate some of the benefits of compression by raising
compression ratios, in a large, real world deployment, network traffic was
still observed to decrease by a factor of 0.58 when enabling Stream Compression (XEP-0138)XEP-0138: Stream Compression <https://xmpp.org/extensions/xep-0138.html>.
with ZLIB compression.
While the CPU cost of compression may directly translate to higher power
usage, it is vastly outweighed by the benefits of reduced network
utilization, especially on modern LTE networks which use a great deal more
power per bit than 3G networks as will be seen later in this document.
However, CPU usage is also not guaranteed to rise due to compression.
In the aforementioned deployment of stream compression, a
decrease in CPU utilization by a factor of 0.60 was observed,
presumably due to reductions in TLS and packet handling overhead.
Therefore CPU time spent on compression (for ZLIB, at least; other
algorithms were not tested) can be considered negligable.
Supporting compression and performming a full flush on stanza boundaries
is recommended for mobile devices.
While the wide spread adoption of LTE has dramatically increased available
bandwidth on mobile devices, it has also increased power consumption.
According to one study, early LTE devices consumed 5–20% more power
than their 3G counterparts LTE Smartphone measurements <http://networks.nokia.com/system/files/document/lte_measurements_final.pdf>.
On some networks that support the legacy SVLTE (Simultaneous Voice and
LTE) or CSFB (Circuit-switched fallback) instead of the more modern VoLTE
(Voice Over LTE) standard, this number would (presumably) be even higher.
XMPP server and client implementers, bearing this increased power usage in
mind, and knowing a bit about how LTE radios work, can optimize their
traffic to minimize network usage.
For the downlink, LTE user equipment
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
somewhat inefficient A Close Examination of Performance and Power Characteristics of 4G LTE Networks <doi:2307636.2307658>.
On the uplink side a different technology, Single-carrier frequency
division multiple access (SC-FDMA) is used, which is slightly more
efficient than traditional OFDM, slightly offsetting the fact that
broadcasting requires more power than receiving.
LTE UE also implements a Discontinuous reception (DRX) mode in which the
hardware can sleep until it is woken by a paging message or is needed to
perform some task.
LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE.
DRX is supported in both of these power modes.
By attempting to minimize the time which the LTE UE state machine spends
in the RCC_CONNECTED state, and maximize the time it stays in the DRX
state (for RCC_CONNECTED and RRC_IDLE), we can increase battery life
without degrading the XMPP experience.
To do so, the following rules should be observed:
Whenever possible, data that is not strictly needed should not be
transmitted (by the server or client).
Supporting Client State Indication (XEP-0352)XEP-0352: Client State Indication <https://xmpp.org/extensions/xep-0352.html>. is recommended.
Most importantly, XMPP pings should be kept as far apart as possible and
only used when necessary.
Server operators are encouraged to set high ping timeouts, and client
implementors are advised to only send pings when absolutely necessary to
prevent the server from closing the socket.
If one is on 3G, transmitting a small amount of data will cause the
radio to enter FACH mode which is significantly cheaper than its high
power mode.
On LTE radios, however, transmitting small amounts of data is vastly
more expensive per bit due to the higher tail-time (the time it takes
for the radio to change state) of approximately 11 secondsA Close Examination of Performance and Power Characteristics of 4G LTE Networks <doi:2307636.2307658>.
On LTE radios, one should transmit as much data from the client as
possible when the radio is already on (eg. by placing messages in a send
queue and executing the queue as a batch when the radio is on).
Similarly, when data is being received from the server, the mobile
devices radio is already in a high power state and therefore any data
that needs to be sent to the server should be transmitted.
These rules also apply to server operators: If the server receives data,
the phones radio is already on, therefore you should flush any pending
data as soon as possible after receiving data from a client.
This section provides pointers to other documents which may be of interest
to those developing mobile clients, or considering implementing
optimizations for them in servers.
Entity Capabilities (XEP-0115)XEP-0115: Entity Capabilities <https://xmpp.org/extensions/xep-0115.html>. provides a mechanism for caching, and hence eliding, the
disco#info requests needed to negotiate optional features.
Roster Versioning (XEP-0237)XEP-0237: Roster Versioning <https://xmpp.org/extensions/xep-0237.html>. provides a relatively widely deployed extension for reducing
roster fetch sizes.
Stream Management (XEP-0198)XEP-0198: Stream Management <https://xmpp.org/extensions/xep-0198.html>. allows the client to send and receive smaller keep-alive
messages, and resume existing sessions without the full handshake.
This is useful on unstable connections.
Client State Indication (XEP-0352)XEP-0352: Client State Indication <https://xmpp.org/extensions/xep-0352.html>. allows clients to indicate to the server that they are inactive,
allowing the server to optimize and reduce unnecessary traffic.
Push Notifications (XEP-0357)XEP-0357: Push Notifications <https://xmpp.org/extensions/xep-0357.html>. implements push notifications (third party message delivery),
which are often used on mobile devices and highly optimized to conserve
battery.
Push notifications also allow delivery of notifications to mobile clients
that are currently offline (eg. in an XEP-0198 "zombie" state).
Message Archive Management (XEP-0313)XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>. lets clients fetch messages which they missed (eg. due to poor
mobile coverage and a flaky network connection).
This XEP was originally written by Dave Cridland, and parts of his
original work were used in this rewrite.
Thanks to Atlassian (HipChat) for allowing me to release numbers from
their XMPP compression deployment.
This document introduces no new security considerations.
This document requires no interaction with the Internet Assigned Numbers
Authority (IANA).
No namespaces or parameters need to be registered with the XMPP Registrar
as a result of this document.