XEP-xxxx: XMPP on Mobile Devices

Abstract: This document provides background information for XMPP implementors concerned with mobile devices operating in a cellular network such as 3G.
Author: Dave Cridland
Copyright: © 2010 – 2010 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status: ProtoXEP
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <https://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Type: Informational
Version: 0.0.1 (2010-07-13)

Document Lifecycle

Experimental
Proposed
Active

1. Introduction¶

The use of XMPP on mobile devices is little understood, since few XMPP implementors have good mobile knowledge, and few mobile engineers have good XMPP knowledge. In addition, as the mobile landscape has changed, optimal protocol designs and usage patterns have also changed. This has led to the sub-optimal combination of a large amount of mostly undocumented lore, as well as several outdated concepts being discussed as fact.

This XEP aims to provide useful background knowledge of mobile handset behaviours, and essentially distills a number of conversations with experienced mobile engineers and XMPP implementors, providing useful background as general suggestions.

2. Overview¶

Mobile handsets typically have two constraints - power and bandwidth. The advent of 3G technology and beyond has tended to mean that bandwidth is radically higher, and comparable to broadband speeds - however many operators still charge based on transferred data, hence bandwidth remains an important issue for cost purposes.

The major cost of power in the handset for our purposes is the radio - here, too, bandwidth plays a part, but as this document will show, the time the radio is forced to be available to receive also costs substantially.

Whilst this document refers to XMPP Core [1], implementors are advised to take note of rfc3920bis [2].

3. Compression¶

XMPP is known to compress well. Both TLS, part of XMPP Core [1], and Stream Compression (XEP-0138) [3] can provide access to the DEFLATE codec (RFC 1951 [4]), which provides access to simple stream compression.

Compression ratios vary with usage, however, typical usage by a general client appears to show a 20% ratio (an 80% reduction in bandwidth) in longer sessions [5]. Server implementors should note that there is a substantial memory cost per codec of 300KB assuming maximum settings - this may be dramatically reduced by reducing the memory level and window bits of the implementation - lowering memory level primarily causes increased CPU usage, whereas lowering the window bits directly degrade compression.

At an exemplary point in one experiment, the author found the following figures [6]:

Although there is an equal cost for the mobile device to compress, it is considered that the compression codec memory and CPU costs - while certainly translating into power cost - are outweighed by two factors. Firstly, they're likely to reduce the transmission cost by a greater amount, and secondly they will also reduce the encryption cost in TLS.

Care, however, should be taken not to use XEP-0138 compression when TLS compression is in effect.

Window Bits	Compression Ratio (approx)
15	20%
14	22%
13	25%
12	30%
11	38%
10	43%
9	60%

4. Radio Power¶

Mobile handsets have a number of levels for radio activity. 3G radios can be either Idle, or else in an increasingly capable - and increasingly power-hungry - series of levels, through FACH to DCH.

For the purposes of investigating this, power consumption (or rather battery depletion rate, as current) and timeouts where measured on the 3UK network, with a Nokia E71, using the Energy Profiler. A "typical handset" mentioned here has a 1000mAh battery - some smartphones have up to 1500mAh. Note that all timeouts are under the control of the network operator, not the handset or application.

4.1 Idle¶

Idle state is when the radio is neither receiving nor transmitting. It may have live (although silent) TCP connections. The cost is low. There is also a PCH level, which is similarly low-power, and again is only used when the radio is silent.

The current here was measured as 8mA - likely affected more by the energy profiler than much else.

4.2 FACH¶

FACH uses a shared channel for low-bandwidth communications. Packet sizes must be small - around 128 octets maximum, although this is operator controlled. Raising to this state takes around 2.5 seconds before the data can flow - although the power cost rises instantly - and after the session has returned to silence, it will remain at FACH level for some time.

Note that this threshold includes the overheads from TCP and TLS, which are 52 and 5 octets respectively, leaving around 70 octets for the payload data.

Here, the current was measured as 140mA, and a timeout of 8 seconds - this timeout is at the lower end of the expected range, which could be up to around 2 minutes. On a typical handset, this will exhaust the battery in around 7 hours.

4.3 DCH¶

DCH uses a dedicated channel for high bandwidth communications. Again, raising to this state takes 2.5 seconds at the DCH power level, and there is a timeout before dropping back. Some operators will drop back to FACH for the duration fo the FACH timeout - others will drop back to Idle/PCH.

Sending more than the FACH threshold will raise the radio all the way to DCH - taking, again, 2.5 seconds.

The measurements here were 380mA and 8 seconds - this is sufficient to flatten a typical handset battery in less than 3 hours, and the figures are considered normal.

Transmission of data can use up to 2W [7], and raising the level itself takes between 2 and 3 seconds to take effect - during which time the handset cannot receive or transmit, but still incurs the power cost. There are packets sent from and to the handset during this time.

Experimentation suggests that uncompressed XMPP will never trigger the FACH state, leaping directly into the more costly DCH state. However, compression does make FACH possible, if rare.

5. Conclusions¶

As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:

Transmit no data.: Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
If you must transmit, then transmit only a small volume.: If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
If you must transmit, then compress as hard as possible.: Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
If you have transmit a lot, then do a lot: If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
If you receive, then transmit: If your peer raises the radio state, you may as well use it.

Send no data.: Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
If you must send, send tiny bits.: Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
If you receive, then send anything you have.: Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
If you must send when not receiving, send plenty.: Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.

Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.

6. 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) [3] provides application stream level compression, useful if the device TLS stack does not support TLS-based 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 the roster fetch bandwidth, in most cases reducing it to a simple affirmation that the client has the current roster. This saves not only bandwidth, but also reduces local storage writes.

Stream Management (XEP-0198) [10] provides session resumption over TCP, enabling a client to handle the case where the coverage is patchy. The <r/> and <a/> elements also provide a keepalive facility in a small number of octets.

7. Acknowledgements¶

The author is not a mobile expert, and relied on the knowledge and patient help of several others. In particular, thanks are due to Jussi Laako, Markku Vampari, and Markus Isomaki of Nokia, and Simon Tennant of Buddycloud.

The attribution of any mistakes herein is zealously guarded by the author, however.

8. Security Considerations¶

This document does not discuss a protocol, thus introduces no new security considerations.

9. IANA Considerations¶

10. XMPP Registrar Considerations¶

Appendices

Appendix A: Document Information¶

Appendix B: Author Information¶

Dave Cridland

Appendix C: Legal Notices¶

Copyright

Permissions

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 <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

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 <https://xmpp.org/community/> for a complete list.

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 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

2. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>.

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

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

5. Fixed-purpose clients, such as the Buddycloud client, do see even lower ratios, approaching 10%.

6. The compression ratio is here given as Original/Compressed, hence a 100% compression ratio is no compression at all, and 0% would represent infinite compression.

7. The author's hazy recollection of P=IV suggests around a 570mA current

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

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

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

11. XEP-0273: Stanza Interception and Filtering Technology <https://xmpp.org/extensions/xep-0273.html>.