moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0286: Retab and rewrap

This commit is contained in:
Sam Whited 2017-01-28 10:26:24 -06:00
parent 09627a4ef6
commit 4ba979c91f
1 changed files with 266 additions and 254 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
xep-0286.xml
View File

@ -50,7 +50,12 @@
<version>0.3</version>
<date>2015-07-24</date>
<initials>ssw</initials>
<remark><p>Include real world compression numbers and additional recommended reading.</p></remark>
<remark>
<p>
Include real world compression numbers and additional recommended
reading.
</p>
</remark>
</revision>
<revision>
<version>0.2</version>
@ -76,8 +81,8 @@
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.
how XMPP works. As the Internet and protocol design have changed to be
more accommodating for mobile, so has XMPP.
</p>
<p>
This XEP aims to provide useful background knowledge of mobile handset
@ -92,8 +97,8 @@
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.
This XEP mostly focuses on LTE as it already has a very wide deployment
and will only continue to further replace 3G technologies.
</p>
</section1>
@ -102,35 +107,37 @@
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!
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!
</p>
<p>
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 <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). Therefore CPU time spent on compression (for ZLIB, at least;
other algorithms were not tested) should be considered negligable.
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).
Therefore CPU time spent on compression (for ZLIB, at least; other
algorithms were not tested) should be considered negligable.
</p>
<p>
Supporting compression and performming a full flush on stanza boundaries is
recommended for mobile devices.
Supporting compression and performming a full flush on stanza boundaries
is recommended for mobile devices.
</p>
</section1>
<section1 topic='Power Consumption' anchor='power'>
@ -140,14 +147,16 @@
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>.
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.
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.
</p>
<p>
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
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>.
@ -157,12 +166,14 @@
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:
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:
</p>
<section2 topic='Transmit no data'>
<p>
@ -178,24 +189,25 @@
</section2>
<section2 topic='Transmit as much data as you can at once'>
<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).
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.
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.
</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 send any pending
data.
Batching data to be sent and sending it all at once will help reduce
power consumption.
</p>
</section2>
</section1>
@ -216,8 +228,8 @@
roster fetch sizes.
</p>
<p>
&xep0198; allows the client to send and receive smaller keep-alive messages,
and resume existing sessions without the full handshake.
&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.
</p>
<p>
@ -238,10 +250,10 @@
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
<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.
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.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>