XEP-0286: Mobile Considerations

Abstract: This document provides background information for XMPP implementors concerned with mobile devices operating on an LTE cellular network.
Authors:Dave Cridland, Sam Whited
Copyright:© 1999 - 2015 XMPP Standards Foundation. SEE LEGAL NOTICES.
Last Updated:2015-07-22

WARNING: This Informational document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction
2. Overview
3. Compression
4. Power Consumption
    4.1. Transmit no data
    4.2. Transmit as much data as you can at once
5. Notable Extensions
6. Acknowledgements
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

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.

2. Overview

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 should therefore still be considered. This XEP mostly focuses on LTE as it already has a very wide deployment and will only continue to further replace 3G technologies.

3. Compression

XML, and by extension XMPP, is known to be highly compressible. In a simple test of a small (266089 byte) XMPP stream (connection, stream initialization, feature discovery, roster loading, several presence stanzas sent and received, disconnect), the entropy of the stream was found to be 5.616313 bits per byte. Using the `gzip` tool to apply Lempel-Ziv coding (LZ77) without concern for server-side CPU usage resulted in a compression ratio of 21% (a 79% reduction in bandwidth). In one test with a much larger dataset typical of a corporate environment (many hundreds of users in the roster), the ratio was as low as 13%, an 87% reduction in bandwidth!

Compression of XMPP data can be achieved with the DEFLATE algorithm (RFC 1951 [1]) via TLS compression (RFC 3749 [2]) or Stream Compression (XEP-0138) [3]. While the security implications of stream compression are beyond the scope of this document (See the aforementioned RFC or XEP for more info), mitigating them may affect compression ratios. 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. Compressing at the stream level gives us the benefit of being able to flush the compression stream on stanza boundaries to help prevent information from leaking. This, however, may drastically increase compression ratios.

While the CPU cost of compression directly translates 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.

Supporting compression and flushing on stanza boundaries is highly recommended.

4. Power Consumption

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 [4]. On some networks that support the legacy SVLTE (Simultaneous Voice and LTE) instead of the more modern VoLTE (Voice Over LTE) standard, or even CSFB (Circuit-switched fallback) 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 [5]. On the uplink side a different technology, Single-carrier frequency division multiple access (SC-FDMA) is used, which is slightly more efficient than traditional (non linearly-precoded) 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:

4.1 Transmit no data

Whenever possible, data that is not strictly needed should not be transmitted (by the server or client). Supporting Client State Indication (XEP-0352) [6] is highly 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.

4.2 Transmit as much data as you can at once

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 significantly higher tail-times (the time it takes for the radio to change state). On LTE radios, one should transmit as much data as possible when the radio is already on (eg. by placing messages in a send queue and executing the queue as a batch). Similarly, when data is being received the radio is already in a high power state and therefore any data that needs to be sent should be.

These rules also apply to server operators: If you receive data, the phones radio is already on therefore you should send anything you have. Otherwise, batching data to be sent and sending it all at once (and as much as possible) will help reduce power consumption.

5. Notable Extensions

This section provides pointers to other documents which may be of interest to those developing mobile clients, or considering support for them in servers.

Stream Compression (XEP-0138) [7] provides stream level compression.

Entity Capabilities (XEP-0115) [8] provides a mechanism for caching, and hence eliding, the disco#info requests needed to negotiate optional features.

Roster Versioning (XEP-0237) [9] provides a relatively widely deployed extension for reducing roster fetch sizes.

Stream Management (XEP-0198) [10] allows the client to send and receive smaller keep-alive messages, and resume existing sessions without the full handshake. Useful on unstable connections.

Push (XEP-0357) [11] 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) [12] lets clients fetch messages which they missed (eg. due to poor mobile coverage and a flakey network connection).

6. Acknowledgements

This XEP was originally written by Dave Cridland, and parts of his original work were used in this rewrite.

7. Security Considerations

This document introduces no new security considerations.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

9. XMPP Registrar Considerations

No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document.


Appendix A: Document Information

Series: XEP
Number: 0286
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Informational
Version: 0.2
Last Updated: 2015-07-22
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Dave Cridland

Email: dave.cridland@isode.com
JabberID: dave.cridland@isode.com

Sam Whited

Email: sam@samwhited.com
JabberID: sam@samwhited.com

Appendix C: Legal Notices


This XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).


Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 <http://tools.ietf.org/html/rfc1951>.

2. RFC 3749: Transport Layer Security Protocol Compression Methods <http://tools.ietf.org/html/rfc3749>.

3. XEP-0138: Stream Compression <http://xmpp.org/extensions/xep-0138.html>.

4. LTE Smartphone measurements <http://networks.nokia.com/system/files/document/lte_measurements_final.pdf>

5. A Close Examination of Performance and Power Characteristics of 4G LTE Networks <http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf>

6. XEP-0352: Client State Indication <http://xmpp.org/extensions/xep-0352.html>.

7. XEP-0138: Stream Compression <http://xmpp.org/extensions/xep-0138.html>.

8. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

9. XEP-0237: Roster Versioning <http://xmpp.org/extensions/xep-0237.html>.

10. XEP-0198: Stream Management <http://xmpp.org/extensions/xep-0198.html>.

11. XEP-0357: Push <http://xmpp.org/extensions/xep-0357.html>.

12. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.2 (2015-07-22)

Overhaul to include LTE.


Version 0.1 (2010-09-15)

Initial published version.


Version 0.0.1 (2010-07-13)

First draft. Also John's birthday.