moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

xep-0286: remove EXI reference

Browse Source 
Other minor editorial and citation fixes.
This commit is contained in:
Sam Whited 2017-09-17 11:19:16 -05:00
parent 965e863a16
commit 50373de4ad
1 changed files with 38 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
xep-0286.xml
View File

@ -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.
@ -30,6 +32,17 @@
<jid>dave.cridland@isode.com</jid>
</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>
@ -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'>