From 50373de4adece2868061fb3b7aa22a45e3f5ce41 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sun, 17 Sep 2017 11:19:16 -0500 Subject: [PATCH] xep-0286: remove EXI reference Other minor editorial and citation fixes. --- xep-0286.xml | 72 +++++++++++++++++++++++++++------------------------- 1 file changed, 38 insertions(+), 34 deletions(-) diff --git a/xep-0286.xml b/xep-0286.xml index c2fcb34c..c8898a72 100644 --- a/xep-0286.xml +++ b/xep-0286.xml @@ -2,11 +2,13 @@ %ents; +LTE Smartphone measurements <http://networks.nokia.com/system/files/document/lte_measurements_final.pdf>"> +A Close Examination of Performance and Power Characteristics of 4G LTE Networks <doi:2307636.2307658>"> ]>
- Mobile Considerations + Mobile Considerations on LTE Networks This document provides background information for XMPP implementors concerned with mobile devices operating on an LTE cellular network. @@ -30,6 +32,17 @@ dave.cridland@isode.com &sam; + + 0.4.1 + 2017-09-17 + ssw + +
    +
  • Minor editorial fixes.
    • +
  • Remove reference to EXI which has no implementations.
    • +
+ + 0.4.0 2017-01-17 @@ -103,17 +116,17 @@ 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). + A description of the security implications of stream compression is beyond + the scope of this document (See &rfc3749; or &xep0138; for more + information), but 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. + performed on stanza boundaries to help prevent chosen plaintext attacks. 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! + compression ratios, in a large, real world deployment, 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 @@ -122,13 +135,10 @@ 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). + decrease in CPU utilization by a factor of 0.60 was observed, + presumably due to reductions in TLS and packet handling overhead. Therefore CPU time spent on compression (for ZLIB, at least; other - algorithms were not tested) should be considered negligable. + algorithms were not tested) can be considered negligable.

Supporting compression and performming a full flush on stanza boundaries @@ -140,12 +150,10 @@ 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>. + than their 3G counterparts &nokia11;. 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. + LTE) or CSFB (Circuit-switched fallback) instead of the more modern VoLTE + (Voice Over LTE) standard, this number would (presumably) be even higher.

XMPP server and client implementers, bearing this increased power usage in @@ -153,12 +161,11 @@ 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>. + somewhat inefficient &huang12;. 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. + efficient than traditional 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. @@ -182,14 +189,14 @@ 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). + more expensive per bit due to the higher tail-time (the time it takes + for the radio to change state) of approximately 11 seconds&huang12;. 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). @@ -199,10 +206,8 @@

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. + the phones radio is already on, therefore you should flush any pending + data as soon as possible after receiving data from a client.

@@ -213,7 +218,6 @@ 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. @@ -247,8 +251,8 @@

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. + Thanks to Atlassian (HipChat) for allowing me to release numbers from + their XMPP compression deployment.