First draft.
+ 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 + 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. +
++ 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 + (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138;. 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. + Setting security considerations aside and thinking only of power + consumption and bandwidth, supporting compression is highly recommended. +
+
+ 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
+
+ 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
+
+ Whenever possible, data that is not strictly needed should not be + transmitted (by the server or client). Supporting &xep0352; 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. +
++ 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. +
++ This section provides pointers to other documents which may be of interest + to those developing mobile clients, or considering support for them in + servers. +
+&xep0138; provides stream level compression.
++ &xep0115; provides a mechanism for caching, and hence eliding, the + disco#info requests needed to negotiate optional features. +
++ &xep0237; provides a relatively widely deployed extension for reducing + roster fetch sizes. +
++ &xep0198; allows the client to send and receive smaller keep-alive + messages, and resume existing sessions without the full handshake. Useful + on unstable connections. +
++ The original mobile XEP, &xep0286;, was written by Dave Cridland, and parts + of it were used when writing this XEP. +
+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. +
+