From bddd8a4177e55ba7f663b6ce113d630b8bad17bc Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Tue, 21 Jul 2015 11:48:40 +0200 Subject: [PATCH] ProtoXEP.modile-concerns v0.0.1: first draft. --- inbox/mobile-concerns.xml | 203 ++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 204 insertions(+) create mode 100644 inbox/mobile-concerns.xml diff --git a/inbox/mobile-concerns.xml b/inbox/mobile-concerns.xml new file mode 100644 index 00000000..c2cdac0f --- /dev/null +++ b/inbox/mobile-concerns.xml @@ -0,0 +1,203 @@ + + +%ents; +]> + + +
+ Mobile Considerations + + This document provides background information for XMPP implementors + concerned with mobile devices operating on an LTE cellular network. + + &LEGALNOTICE; + NOT_YET_ASSIGNED + ProtoXEP + Informational + Standards + Council + + XMPP Core + + + XEP-0286 + + + NOT_YET_ASSIGNED + + Sam + Whited + sam@samwhited.com + sam@samwhited.com + + + 0.0.1 + 2015-07-18 + ssw +

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

+ +

+ 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. +

+ + diff --git a/xep.ent b/xep.ent index ca451217..b2146cc3 100644 --- a/xep.ent +++ b/xep.ent @@ -405,6 +405,7 @@ THE SOFTWARE. RFC 1939 RFC 1939: Post Office Protocol - Version 3 <http://tools.ietf.org/html/rfc1939>." > RFC 1945 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0 <http://tools.ietf.org/html/rfc1945>." > RFC 1950 RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://tools.ietf.org/html/rfc1950>." > +RFC 1951 RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 <http://tools.ietf.org/html/rfc1951>." > RFC 2026 RFC 2026: The Internet Standards Process <http://tools.ietf.org/html/rfc2026>." > RFC 2045 RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://tools.ietf.org/html/rfc2045>." > RFC 2068 RFC 2068: Hypertext Transport Protocol -- HTTP/1.1 <http://tools.ietf.org/html/rfc2068>." >