No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0286.xml 12KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. <!ENTITY nokia11 "<note>LTE Smartphone measurements &lt;<link url=''></link>&gt;</note>">
  6. <!ENTITY huang12 "<note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks &lt;<link url=''>doi:2307636.2307658</link>&gt;</note>">
  7. ]>
  8. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  9. <xep>
  10. <header>
  11. <title>Mobile Considerations on LTE Networks</title>
  12. <abstract>
  13. This document provides background information for XMPP implementors
  14. concerned with mobile devices operating on an LTE cellular network.
  15. </abstract>
  17. <number>0286</number>
  18. <status>Active</status>
  19. <lastcall>2017-11-15</lastcall>
  20. <type>Informational</type>
  21. <sig>Standards</sig>
  22. <approver>Council</approver>
  23. <dependencies>
  24. <spec>XMPP Core</spec>
  25. </dependencies>
  26. <supersedes/>
  27. <supersededby/>
  28. <shortname>NOT_YET_ASSIGNED</shortname>
  29. &dcridland;
  30. &sam;
  31. <revision>
  32. <version>1.0.0</version>
  33. <date>2018-01-25</date>
  34. <initials>XEP Editor (jwi)</initials>
  35. <remark><p>Advance to Active as per Council vote on 2018-01-10.</p></remark>
  36. </revision>
  37. <revision>
  38. <version>0.4.1</version>
  39. <date>2017-09-17</date>
  40. <initials>ssw</initials>
  41. <remark>
  42. <ul>
  43. <li>Minor editorial fixes.</li>
  44. <li>Remove reference to EXI which has no implementations.</li>
  45. </ul>
  46. </remark>
  47. </revision>
  48. <revision>
  49. <version>0.4.0</version>
  50. <date>2017-01-17</date>
  51. <initials>ssw</initials>
  52. <remark>
  53. <ul>
  54. <li>Attempt to fix some confusing paragraphs.</li>
  55. <li>Add Client State Indication to Notable Extensions.</li>
  56. </ul>
  57. </remark>
  58. </revision>
  59. <revision>
  60. <version>0.3</version>
  61. <date>2015-07-24</date>
  62. <initials>ssw</initials>
  63. <remark>
  64. <p>
  65. Include real world compression numbers and additional recommended
  66. reading.
  67. </p>
  68. </remark>
  69. </revision>
  70. <revision>
  71. <version>0.2</version>
  72. <date>2015-07-22</date>
  73. <initials>ssw</initials>
  74. <remark><p>Overhaul to include LTE.</p></remark>
  75. </revision>
  76. <revision>
  77. <version>0.1</version>
  78. <date>2010-09-15</date>
  79. <initials>psa</initials>
  80. <remark><p>Initial published version.</p></remark>
  81. </revision>
  82. <revision>
  83. <version>0.0.1</version>
  84. <date>2010-07-13</date>
  85. <initials>dwd</initials>
  86. <remark><p>First draft. Also John's birthday.</p></remark>
  87. </revision>
  88. </header>
  89. <section1 topic='Introduction' anchor='intro'>
  90. <p>
  91. XMPP as a protocol was designed before the wide spread adoption of mobile
  92. devices, and is often cited as not being very mobile friendly as a result.
  93. However, this mostly stems from undocumented lore and outdated notions of
  94. how XMPP works. As the Internet and protocol design have changed to be
  95. more accommodating for mobile, so has XMPP.
  96. </p>
  97. <p>
  98. This XEP aims to provide useful background knowledge of mobile handset
  99. behavior, and those considerations that client and server designers can
  100. take to ensure that bandwidth and battery are used efficiently.
  101. </p>
  102. </section1>
  103. <section1 topic='Overview' anchor='overview'>
  104. <p>
  105. The two major constraints on mobile devices are power and bandwidth.
  106. With the wide spread proliferation of 3G and LTE technologies, mobile
  107. bandwidth and speeds have become broadly comparable to broadband.
  108. However, they are still relatively expensive compared to traditional wired
  109. networks, and therefore conserving them is still desirable.
  110. This XEP mostly focuses on LTE as it already has a very wide deployment
  111. and will only continue to further replace 3G technologies.
  112. </p>
  113. </section1>
  114. <section1 topic='Compression' anchor='compression'>
  115. <p>
  116. XML, and by extension XMPP, is known to be highly compressible.
  117. Compression of XMPP data can be achieved with the DEFLATE algorithm
  118. (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also
  119. supports other compression algorithms).
  120. A description of the security implications of stream compression is beyond
  121. the scope of this document (See &rfc3749; or &xep0138; for more
  122. information), but the author does not recommend using TLS compression with
  123. XMPP (or in general).
  124. If compression must be used, stream level compression should be
  125. implemented instead, and the compressed stream should have a full flush
  126. performed on stanza boundaries to help prevent chosen plaintext attacks.
  127. While this may mitigate some of the benefits of compression by raising
  128. compression ratios, in a large, real world deployment, network traffic was
  129. still observed to decrease by a factor of 0.58 when enabling &xep0138;
  130. with ZLIB compression.
  131. </p>
  132. <p>
  133. While the CPU cost of compression may directly translate to higher power
  134. usage, it is vastly outweighed by the benefits of reduced network
  135. utilization, especially on modern LTE networks which use a great deal more
  136. power per bit than 3G networks as will be seen later in this document.
  137. However, CPU usage is also not guaranteed to rise due to compression.
  138. In the aforementioned deployment of stream compression, a
  139. <em>decrease</em> in CPU utilization by a factor of 0.60 was observed,
  140. presumably due to reductions in TLS and packet handling overhead.
  141. Therefore CPU time spent on compression (for ZLIB, at least; other
  142. algorithms were not tested) can be considered negligable.
  143. </p>
  144. <p>
  145. Supporting compression and performming a full flush on stanza boundaries
  146. is recommended for mobile devices.
  147. </p>
  148. </section1>
  149. <section1 topic='Power Consumption' anchor='power'>
  150. <p>
  151. While the wide spread adoption of LTE has dramatically increased available
  152. bandwidth on mobile devices, it has also increased power consumption.
  153. According to one study, early LTE devices consumed 5&#x2013;20% more power
  154. than their 3G counterparts &nokia11;.
  155. On some networks that support the legacy SVLTE (Simultaneous Voice and
  156. LTE) or CSFB (Circuit-switched fallback) instead of the more modern VoLTE
  157. (Voice Over LTE) standard, this number would (presumably) be even higher.
  158. </p>
  159. <p>
  160. XMPP server and client implementers, bearing this increased power usage in
  161. mind, and knowing a bit about how LTE radios work, can optimize their
  162. traffic to minimize network usage.
  163. For the downlink, LTE user equipment
  164. (UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
  165. somewhat inefficient &huang12;.
  166. On the uplink side a different technology, Single-carrier frequency
  167. division multiple access (SC-FDMA) is used, which is slightly more
  168. efficient than traditional OFDM, slightly offsetting the fact that
  169. broadcasting requires more power than receiving.
  170. LTE UE also implements a Discontinuous reception (DRX) mode in which the
  171. hardware can sleep until it is woken by a paging message or is needed to
  172. perform some task.
  173. LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE.
  174. DRX is supported in both of these power modes.
  175. By attempting to minimize the time which the LTE UE state machine spends
  176. in the RCC_CONNECTED state, and maximize the time it stays in the DRX
  177. state (for RCC_CONNECTED and RRC_IDLE), we can increase battery life
  178. without degrading the XMPP experience.
  179. To do so, the following rules should be observed:
  180. </p>
  181. <section2 topic='Transmit no data'>
  182. <p>
  183. Whenever possible, data that is not strictly needed should not be
  184. transmitted (by the server or client).
  185. Supporting &xep0352; is recommended.
  186. Most importantly, XMPP pings should be kept as far apart as possible and
  187. only used when necessary.
  188. Server operators are encouraged to set high ping timeouts, and client
  189. implementors are advised to only send pings when absolutely necessary to
  190. prevent the server from closing the socket.
  191. </p>
  192. </section2>
  193. <section2 topic='When transmitting, transmit as much as you can'>
  194. <p>
  195. If one is on 3G, transmitting a small amount of data will cause the
  196. radio to enter FACH mode which is significantly cheaper than its high
  197. power mode.
  198. On LTE radios, however, transmitting small amounts of data is vastly
  199. more expensive per bit due to the higher tail-time (the time it takes
  200. for the radio to change state) of approximately 11 seconds&huang12;.
  201. On LTE radios, one should transmit as much data from the client as
  202. possible when the radio is already on (eg. by placing messages in a send
  203. queue and executing the queue as a batch when the radio is on).
  204. Similarly, when data is being received from the server, the mobile
  205. devices radio is already in a high power state and therefore any data
  206. that needs to be sent to the server should be transmitted.
  207. </p>
  208. <p>
  209. These rules also apply to server operators: If the server receives data,
  210. the phones radio is already on, therefore you should flush any pending
  211. data as soon as possible after receiving data from a client.
  212. </p>
  213. </section2>
  214. </section1>
  215. <section1 topic='Notable Extensions' anchor='xeps'>
  216. <p>
  217. This section provides pointers to other documents which may be of interest
  218. to those developing mobile clients, or considering implementing
  219. optimizations for them in servers.
  220. </p>
  221. <p>&xep0138; provides stream level compression.</p>
  222. <p>
  223. &xep0115; provides a mechanism for caching, and hence eliding, the
  224. disco#info requests needed to negotiate optional features.
  225. </p>
  226. <p>
  227. &xep0237; provides a relatively widely deployed extension for reducing
  228. roster fetch sizes.
  229. </p>
  230. <p>
  231. &xep0198; allows the client to send and receive smaller keep-alive
  232. messages, and resume existing sessions without the full handshake.
  233. This is useful on unstable connections.
  234. </p>
  235. <p>
  236. &xep0352; allows clients to indicate to the server that they are inactive,
  237. allowing the server to optimize and reduce unnecessary traffic.
  238. </p>
  239. <p>
  240. &xep0357; implements push notifications (third party message delivery),
  241. which are often used on mobile devices and highly optimized to conserve
  242. battery.
  243. Push notifications also allow delivery of notifications to mobile clients
  244. that are currently offline (eg. in an XEP-0198 "zombie" state).
  245. </p>
  246. <p>
  247. &xep0313; lets clients fetch messages which they missed (eg. due to poor
  248. mobile coverage and a flaky network connection).
  249. </p>
  250. </section1>
  251. <section1 topic='Acknowledgements' anchor='acks'>
  252. <p>
  253. This XEP was originally written by Dave Cridland, and parts of his
  254. original work were used in this rewrite.
  255. Thanks to Atlassian (HipChat) for allowing me to release numbers from
  256. their XMPP compression deployment.
  257. </p>
  258. </section1>
  259. <section1 topic='Security Considerations' anchor='security'>
  260. <p>This document introduces no new security considerations.</p>
  261. </section1>
  262. <section1 topic='IANA Considerations' anchor='iana'>
  263. <p>
  264. This document requires no interaction with the Internet Assigned Numbers
  265. Authority (IANA).
  266. </p>
  267. </section1>
  268. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  269. <p>
  270. No namespaces or parameters need to be registered with the XMPP Registrar
  271. as a result of this document.
  272. </p>
  273. </section1>
  274. </xep>