diff --git a/xep-0286.xml b/xep-0286.xml index b04aa74a..fdf37db9 100644 --- a/xep-0286.xml +++ b/xep-0286.xml @@ -1,262 +1,274 @@ + %ents; ]> -
- Mobile Considerations - - This document provides background information for XMPP implementors - concerned with mobile devices operating on an LTE cellular network. - - &LEGALNOTICE; - 0286 - Experimental - Informational - Standards - Council - - XMPP Core - - - - NOT_YET_ASSIGNED - - Dave - Cridland - dave.cridland@isode.com - dave.cridland@isode.com - - - Sam - Whited - sam@samwhited.com - sam@samwhited.com - - - 0.4.0 - 2017-01-17 - ssw - -
    -
  • Attempt to fix some confusing paragraphs.
    • -
  • Add Client State Indication to Notable Extensions.
    • -
- - - - 0.3 - 2015-07-24 - ssw -

Include real world compression numbers and additional recommended reading.

 - - - 0.2 - 2015-07-22 - ssw -

Overhaul to include LTE.

 - - - 0.1 - 2010-09-15 - psa -

Initial published version.

 - - - 0.0.1 - 2010-07-13 - dwd -

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

- +
+ Mobile Considerations + + This document provides background information for XMPP implementors + concerned with mobile devices operating on an LTE cellular network. + + &LEGALNOTICE; + 0286 + Experimental + Informational + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Dave + Cridland + dave.cridland@isode.com + dave.cridland@isode.com + + + Sam + Whited + sam@samwhited.com + sam@samwhited.com + + + 0.4.0 + 2017-01-17 + ssw + +
    +
  • Attempt to fix some confusing paragraphs.
    • +
  • Add Client State Indication to Notable Extensions.
    • +
+ + + + 0.3 + 2015-07-24 + ssw + +

+ Include real world compression numbers and additional recommended + reading. +

+ + + + 0.2 + 2015-07-22 + ssw +

Overhaul to include LTE.

 + + + 0.1 + 2010-09-15 + psa +

Initial published version.

 + + + 0.0.1 + 2010-07-13 + dwd +

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 - (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also - supports other compression algorithms). While the security implications of - stream compression are beyond the scope of this document (See the - aforementioned RFC or XEP for more info), 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 a class of chosen plaintext attacks which can cause data - leakage in compressed streams. While this may mitigate some of the benefits - of compression by raising compression ratios, in a large, real world - deployment at HipChat, network traffic was still observed to decrease by a - factor of 0.58 when enabling &xep0138; 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 due to the fact that there - were fewer packets that needed to be handled by the OS (which also takes - CPU time), and, potentially more importantly, less data that needed to be - TLS-encrypted (which is a much more CPU-expensive operation than - compression). Therefore CPU time spent on compression (for ZLIB, at least; - other algorithms were not tested) should 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) - 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 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-times (the time it takes for the - radio to change state). - 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 send any pending data. - Batching data to be sent and sending it all at once will help reduce power - consumption. -

- - - -

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

-

&xep0138; provides stream level compression.

-

&xep0322; allows XMPP streams to use the EXI XML format.

-

- &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. - This is useful on unstable connections. -

-

- &xep0352; allows clients to indicate to the server that they are inactive, - allowing the server to optimize and reduce unnecessary traffic. -

-

- &xep0357; 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). -

-

- &xep0313; 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 for allowing me to release hard 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. -

- + +

+ XML, and by extension XMPP, is known to be highly compressible. + Compression of XMPP data can be achieved with the DEFLATE algorithm + (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also + supports other compression algorithms). + While the security implications of stream compression are beyond the scope + of this document (See the aforementioned RFC or XEP for more info), 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 a class of chosen plaintext + attacks which can cause data leakage in compressed streams. + While this may mitigate some of the benefits of compression by raising + compression ratios, in a large, real world deployment at HipChat, network + traffic was still observed to decrease by a factor of 0.58 when enabling + &xep0138; 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 due + to the fact that there were fewer packets that needed to be handled by the + OS (which also takes CPU time), and, potentially more importantly, less + data that needed to be TLS-encrypted (which is a much more CPU-expensive + operation than compression). + Therefore CPU time spent on compression (for ZLIB, at least; other + algorithms were not tested) should 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) 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 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-times (the time it takes + for the radio to change state). + 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 send any pending + data. + Batching data to be sent and sending it all at once will help reduce + power consumption. +

+ + + +

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

+

&xep0138; provides stream level compression.

+

&xep0322; allows XMPP streams to use the EXI XML format.

+

+ &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. + This is useful on unstable connections. +

+

+ &xep0352; allows clients to indicate to the server that they are inactive, + allowing the server to optimize and reduce unnecessary traffic. +

+

+ &xep0357; 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). +

+

+ &xep0313; 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 for allowing me to release hard 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. +

+