aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSam Whited <sam@samwhited.com>2017-09-17 11:19:16 -0500
committerSam Whited <sam@samwhited.com>2017-09-20 10:41:04 -0500
commit50373de4adece2868061fb3b7aa22a45e3f5ce41 (patch)
treeff8491daa9b679ff1379fbdc286ea6fde5eba609
parent965e863a1678669f63403eb3e34a1b4f1a305387 (diff)
xep-0286: remove EXI reference
Other minor editorial and citation fixes.
-rw-r--r--xep-0286.xml72
1 files changed, 38 insertions, 34 deletions
diff --git a/xep-0286.xml b/xep-0286.xml
index c2fcb34..c8898a7 100644
--- a/xep-0286.xml
+++ b/xep-0286.xml
@@ -2,11 +2,13 @@
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
+<!ENTITY nokia11 "<note>LTE Smartphone measurements &lt;<link url='https://web.archive.org/web/20160624043050/http://networks.nokia.com/system/files/document/lte_measurements_final.pdf'>http://networks.nokia.com/system/files/document/lte_measurements_final.pdf</link>&gt;</note>">
+<!ENTITY huang12 "<note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks &lt;<link url='https://doi.org/10.1145/2307636.2307658'>doi:2307636.2307658</link>&gt;</note>">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
- <title>Mobile Considerations</title>
+ <title>Mobile Considerations on LTE Networks</title>
<abstract>
This document provides background information for XMPP implementors
concerned with mobile devices operating on an LTE cellular network.
@@ -31,6 +33,17 @@
</author>
&sam;
<revision>
+ <version>0.4.1</version>
+ <date>2017-09-17</date>
+ <initials>ssw</initials>
+ <remark>
+ <ul>
+ <li>Minor editorial fixes.</li>
+ <li>Remove reference to EXI which has no implementations.</li>
+ </ul>
+ </remark>
+ </revision>
+ <revision>
<version>0.4.0</version>
<date>2017-01-17</date>
<initials>ssw</initials>
@@ -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.
</p>
<p>
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
- <em>decrease</em> 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).
+ <em>decrease</em> 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.
</p>
<p>
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&#x2013;20% more power
- than their 3G counterparts
- <note>LTE Smartphone measurements &lt;<link url='http://networks.nokia.com/system/files/document/lte_measurements_final.pdf'>http://networks.nokia.com/system/files/document/lte_measurements_final.pdf</link>&gt;</note>.
+ 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.
</p>
<p>
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
- <note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks &lt;<link url='http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf'>http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf</link>&gt;</note>.
+ 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.
</p>
</section2>
- <section2 topic='Transmit as much data as you can at once'>
+ <section2 topic='When transmitting, transmit as much as you can'>
<p>
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 @@
</p>
<p>
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.
</p>
</section2>
</section1>
@@ -213,7 +218,6 @@
optimizations for them in servers.
</p>
<p>&xep0138; provides stream level compression.</p>
- <p>&xep0322; allows XMPP streams to use the EXI XML format.</p>
<p>
&xep0115; provides a mechanism for caching, and hence eliding, the
disco#info requests needed to negotiate optional features.
@@ -247,8 +251,8 @@
<p>
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.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>