moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
Code Issues Releases Wiki Activity

XEP-0286: Retab and rewrap

Browse Source
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

520
xep-0286.xml
View File

@ -1,262 +1,274 @@
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [ <!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'> <!ENTITY % ents SYSTEM 'xep.ent'>
%ents; %ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>Mobile Considerations</title> <title>Mobile Considerations</title>
<abstract> <abstract>
This document provides background information for XMPP implementors This document provides background information for XMPP implementors
concerned with mobile devices operating on an LTE cellular network. concerned with mobile devices operating on an LTE cellular network.
</abstract> </abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0286</number> <number>0286</number>
<status>Experimental</status> <status>Experimental</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname> <shortname>NOT_YET_ASSIGNED</shortname>
<author> <author>
<firstname>Dave</firstname> <firstname>Dave</firstname>
<surname>Cridland</surname> <surname>Cridland</surname>
<email>dave.cridland@isode.com</email> <email>dave.cridland@isode.com</email>
<jid>dave.cridland@isode.com</jid> <jid>dave.cridland@isode.com</jid>
</author> </author>
<author> <author>
<firstname>Sam</firstname> <firstname>Sam</firstname>
<surname>Whited</surname> <surname>Whited</surname>
<email>sam@samwhited.com</email> <email>sam@samwhited.com</email>
<jid>sam@samwhited.com</jid> <jid>sam@samwhited.com</jid>
</author> </author>
<revision> <revision>
<version>0.4.0</version> <version>0.4.0</version>
<date>2017-01-17</date> <date>2017-01-17</date>
<initials>ssw</initials> <initials>ssw</initials>
<remark> <remark>
<ul> <ul>
<li>Attempt to fix some confusing paragraphs.</li> <li>Attempt to fix some confusing paragraphs.</li>
<li>Add Client State Indication to Notable Extensions.</li> <li>Add Client State Indication to Notable Extensions.</li>
</ul> </ul>
</remark> </remark>
</revision> </revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
<date>2015-07-24</date> <date>2015-07-24</date>
<initials>ssw</initials> <initials>ssw</initials>
<remark><p>Include real world compression numbers and additional recommended reading.</p></remark> <remark>
</revision> <p>
<revision> Include real world compression numbers and additional recommended
<version>0.2</version> reading.
<date>2015-07-22</date> </p>
<initials>ssw</initials> </remark>
<remark><p>Overhaul to include LTE.</p></remark> </revision>
</revision> <revision>
<revision> <version>0.2</version>
<version>0.1</version> <date>2015-07-22</date>
<date>2010-09-15</date> <initials>ssw</initials>
<initials>psa</initials> <remark><p>Overhaul to include LTE.</p></remark>
<remark><p>Initial published version.</p></remark> </revision>
</revision> <revision>
<revision> <version>0.1</version>
<version>0.0.1</version> <date>2010-09-15</date>
<date>2010-07-13</date> <initials>psa</initials>
<initials>dwd</initials> <remark><p>Initial published version.</p></remark>
<remark><p>First draft. Also John's birthday.</p></remark> </revision>
</revision> <revision>
</header> <version>0.0.1</version>
<section1 topic='Introduction' anchor='intro'> <date>2010-07-13</date>
<p> <initials>dwd</initials>
XMPP as a protocol was designed before the wide spread adoption of mobile <remark><p>First draft. Also John's birthday.</p></remark>
devices, and is often cited as not being very mobile friendly as a result. </revision>
However, this mostly stems from undocumented lore and outdated notions of </header>
how XMPP works. As the Internet and protocol design have changed to be more <section1 topic='Introduction' anchor='intro'>
accommodating for mobile, so has XMPP. <p>
</p> XMPP as a protocol was designed before the wide spread adoption of mobile
<p> devices, and is often cited as not being very mobile friendly as a result.
This XEP aims to provide useful background knowledge of mobile handset However, this mostly stems from undocumented lore and outdated notions of
behavior, and those considerations that client and server designers can how XMPP works. As the Internet and protocol design have changed to be
take to ensure that bandwidth and battery are used efficiently. more accommodating for mobile, so has XMPP.
</p> </p>
</section1> <p>
<section1 topic='Overview' anchor='overview'> This XEP aims to provide useful background knowledge of mobile handset
<p> behavior, and those considerations that client and server designers can
The two major constraints on mobile devices are power and bandwidth. take to ensure that bandwidth and battery are used efficiently.
With the wide spread proliferation of 3G and LTE technologies, mobile </p>
bandwidth and speeds have become broadly comparable to broadband. </section1>
However, they are still relatively expensive compared to traditional wired <section1 topic='Overview' anchor='overview'>
networks, and therefore conserving them is still desirable. <p>
This XEP mostly focuses on LTE as it already has a very wide deployment and The two major constraints on mobile devices are power and bandwidth.
will only continue to further replace 3G technologies. With the wide spread proliferation of 3G and LTE technologies, mobile
</p> bandwidth and speeds have become broadly comparable to broadband.
</section1> 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.
</p>
</section1>
<section1 topic='Compression' anchor='compression'> <section1 topic='Compression' anchor='compression'>
<p> <p>
XML, and by extension XMPP, is known to be highly compressible. XML, and by extension XMPP, is known to be highly compressible.
Compression of XMPP data can be achieved with the DEFLATE algorithm Compression of XMPP data can be achieved with the DEFLATE algorithm
(&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also
supports other compression algorithms). While the security implications of supports other compression algorithms).
stream compression are beyond the scope of this document (See the While the security implications of stream compression are beyond the scope
aforementioned RFC or XEP for more info), the author does not recommend of this document (See the aforementioned RFC or XEP for more info), the
using TLS compression with XMPP (or in general). If compression must be author does not recommend using TLS compression with XMPP (or in general).
used, stream level compression should be implemented instead, and the If compression must be used, stream level compression should be
compressed stream should have a full flush performed on stanza boundaries implemented instead, and the compressed stream should have a full flush
to help prevent a class of chosen plaintext attacks which can cause data performed on stanza boundaries to help prevent a class of chosen plaintext
leakage in compressed streams. While this may mitigate some of the benefits attacks which can cause data leakage in compressed streams.
of compression by raising compression ratios, in a large, real world While this may mitigate some of the benefits of compression by raising
deployment at HipChat, network traffic was still observed to decrease by a compression ratios, in a large, real world deployment at HipChat, network
factor of 0.58 when enabling &xep0138; with ZLIB compression! traffic was still observed to decrease by a factor of 0.58 when enabling
</p> &xep0138; with ZLIB compression!
<p> </p>
While the CPU cost of compression may directly translate to higher power <p>
usage, it is vastly outweighed by the benefits of reduced network While the CPU cost of compression may directly translate to higher power
utilization, especially on modern LTE networks which use a great deal more usage, it is vastly outweighed by the benefits of reduced network
power per bit than 3G networks as will be seen later in this document. utilization, especially on modern LTE networks which use a great deal more
However, CPU usage is also not guaranteed to rise due to compression. In power per bit than 3G networks as will be seen later in this document.
the aforementioned deployment of stream compression, a <em>decrease</em> in However, CPU usage is also not guaranteed to rise due to compression.
CPU utilization by a factor of 0.60 was observed due to the fact that there In the aforementioned deployment of stream compression, a
were fewer packets that needed to be handled by the OS (which also takes <em>decrease</em> in CPU utilization by a factor of 0.60 was observed due
CPU time), and, potentially more importantly, less data that needed to be to the fact that there were fewer packets that needed to be handled by the
TLS-encrypted (which is a much more CPU-expensive operation than OS (which also takes CPU time), and, potentially more importantly, less
compression). Therefore CPU time spent on compression (for ZLIB, at least; data that needed to be TLS-encrypted (which is a much more CPU-expensive
other algorithms were not tested) should be considered negligable. operation than compression).
</p> Therefore CPU time spent on compression (for ZLIB, at least; other
<p> algorithms were not tested) should be considered negligable.
Supporting compression and performming a full flush on stanza boundaries is </p>
recommended for mobile devices. <p>
</p> Supporting compression and performming a full flush on stanza boundaries
</section1> is recommended for mobile devices.
<section1 topic='Power Consumption' anchor='power'> </p>
<p> </section1>
While the wide spread adoption of LTE has dramatically increased available <section1 topic='Power Consumption' anchor='power'>
bandwidth on mobile devices, it has also increased power consumption. <p>
According to one study, early LTE devices consumed 5&#x2013;20% more power While the wide spread adoption of LTE has dramatically increased available
than their 3G counterparts bandwidth on mobile devices, it has also increased power consumption.
<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>. According to one study, early LTE devices consumed 5&#x2013;20% more power
On some networks that support the legacy SVLTE (Simultaneous Voice and LTE) than their 3G counterparts
instead of the more modern VoLTE (Voice Over LTE) standard, or even CSFB <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>.
(Circuit-switched fallback) this number would (presumably) be even higher. On some networks that support the legacy SVLTE (Simultaneous Voice and
</p> LTE) instead of the more modern VoLTE (Voice Over LTE) standard, or even
<p> CSFB (Circuit-switched fallback) this number would (presumably) be even
XMPP server and client implementers, bearing this increased power usage in higher.
mind, and knowing a bit about how LTE radios work, can optimize their </p>
traffic to minimize network usage. For the downlink, LTE user equipment <p>
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is XMPP server and client implementers, bearing this increased power usage in
somewhat inefficient mind, and knowing a bit about how LTE radios work, can optimize their
<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>. traffic to minimize network usage.
On the uplink side a different technology, Single-carrier frequency For the downlink, LTE user equipment
division multiple access (SC-FDMA) is used, which is slightly more (UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
efficient than traditional (non linearly-precoded) OFDM, slightly somewhat inefficient
offsetting the fact that broadcasting requires more power than receiving. <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>.
LTE UE also implements a Discontinuous reception (DRX) mode in which the On the uplink side a different technology, Single-carrier frequency
hardware can sleep until it is woken by a paging message or is needed to division multiple access (SC-FDMA) is used, which is slightly more
perform some task. LTE radios have two power modes: RRC_CONNECTED and efficient than traditional (non linearly-precoded) OFDM, slightly
RRC_IDLE. DRX is supported in both of these power modes. By attempting to offsetting the fact that broadcasting requires more power than receiving.
minimize the time which the LTE UE state machine spends in the LTE UE also implements a Discontinuous reception (DRX) mode in which the
RCC_CONNECTED state, and maximize the time it stays in the DRX state (for hardware can sleep until it is woken by a paging message or is needed to
RCC_CONNECTED and RRC_IDLE), we can increase battery life without degrading perform some task.
the XMPP experience. To do so, the following rules should be observed: LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE.
</p> DRX is supported in both of these power modes.
<section2 topic='Transmit no data'> By attempting to minimize the time which the LTE UE state machine spends
<p> in the RCC_CONNECTED state, and maximize the time it stays in the DRX
Whenever possible, data that is not strictly needed should not be state (for RCC_CONNECTED and RRC_IDLE), we can increase battery life
transmitted (by the server or client). without degrading the XMPP experience.
Supporting &xep0352; is recommended. To do so, the following rules should be observed:
Most importantly, XMPP pings should be kept as far apart as possible and </p>
only used when necessary. <section2 topic='Transmit no data'>
Server operators are encouraged to set high ping timeouts, and client <p>
implementors are advised to only send pings when absolutely necessary to Whenever possible, data that is not strictly needed should not be
prevent the server from closing the socket. transmitted (by the server or client).
</p> Supporting &xep0352; is recommended.
</section2> Most importantly, XMPP pings should be kept as far apart as possible and
<section2 topic='Transmit as much data as you can at once'> only used when necessary.
<p> Server operators are encouraged to set high ping timeouts, and client
If one is on 3G, transmitting a small amount of data will cause the radio implementors are advised to only send pings when absolutely necessary to
to enter FACH mode which is significantly cheaper than its high power prevent the server from closing the socket.
mode. </p>
On LTE radios, however, transmitting small amounts of data is vastly more </section2>
expensive per bit due to the higher tail-times (the time it takes for the <section2 topic='Transmit as much data as you can at once'>
radio to change state). <p>
On LTE radios, one should transmit as much data from the client as If one is on 3G, transmitting a small amount of data will cause the
possible when the radio is already on (eg. by placing messages in a send radio to enter FACH mode which is significantly cheaper than its high
queue and executing the queue as a batch when the radio is on). power mode.
Similarly, when data is being received from the server, the mobile devices On LTE radios, however, transmitting small amounts of data is vastly
radio is already in a high power state and therefore any data that needs more expensive per bit due to the higher tail-times (the time it takes
to be sent to the server should be transmitted. for the radio to change state).
</p> On LTE radios, one should transmit as much data from the client as
<p> possible when the radio is already on (eg. by placing messages in a send
These rules also apply to server operators: If the server receives data, queue and executing the queue as a batch when the radio is on).
the phones radio is already on therefore you should send any pending data. Similarly, when data is being received from the server, the mobile
Batching data to be sent and sending it all at once will help reduce power devices radio is already in a high power state and therefore any data
consumption. that needs to be sent to the server should be transmitted.
</p> </p>
</section2> <p>
</section1> These rules also apply to server operators: If the server receives data,
<section1 topic='Notable Extensions' anchor='xeps'> the phones radio is already on therefore you should send any pending
<p> data.
This section provides pointers to other documents which may be of interest Batching data to be sent and sending it all at once will help reduce
to those developing mobile clients, or considering implementing power consumption.
optimizations for them in servers. </p>
</p> </section2>
<p>&xep0138; provides stream level compression.</p> </section1>
<p>&xep0322; allows XMPP streams to use the EXI XML format.</p> <section1 topic='Notable Extensions' anchor='xeps'>
<p> <p>
&xep0115; provides a mechanism for caching, and hence eliding, the This section provides pointers to other documents which may be of interest
disco#info requests needed to negotiate optional features. to those developing mobile clients, or considering implementing
</p> optimizations for them in servers.
<p> </p>
&xep0237; provides a relatively widely deployed extension for reducing <p>&xep0138; provides stream level compression.</p>
roster fetch sizes. <p>&xep0322; allows XMPP streams to use the EXI XML format.</p>
</p> <p>
<p> &xep0115; provides a mechanism for caching, and hence eliding, the
&xep0198; allows the client to send and receive smaller keep-alive messages, disco#info requests needed to negotiate optional features.
and resume existing sessions without the full handshake. </p>
This is useful on unstable connections. <p>
</p> &xep0237; provides a relatively widely deployed extension for reducing
<p> roster fetch sizes.
&xep0352; allows clients to indicate to the server that they are inactive, </p>
allowing the server to optimize and reduce unnecessary traffic. <p>
</p> &xep0198; allows the client to send and receive smaller keep-alive
<p> messages, and resume existing sessions without the full handshake.
&xep0357; implements push notifications (third party message delivery), This is useful on unstable connections.
which are often used on mobile devices and highly optimized to conserve </p>
battery. <p>
Push notifications also allow delivery of notifications to mobile clients &xep0352; allows clients to indicate to the server that they are inactive,
that are currently offline (eg. in an XEP-0198 "zombie" state). allowing the server to optimize and reduce unnecessary traffic.
</p> </p>
<p> <p>
&xep0313; lets clients fetch messages which they missed (eg. due to poor &xep0357; implements push notifications (third party message delivery),
mobile coverage and a flaky network connection). which are often used on mobile devices and highly optimized to conserve
</p> battery.
</section1> Push notifications also allow delivery of notifications to mobile clients
<section1 topic='Acknowledgements' anchor='acks'> that are currently offline (eg. in an XEP-0198 "zombie" state).
<p> </p>
This XEP was originally written by Dave Cridland, and parts of his original <p>
work were used in this rewrite. &xep0313; lets clients fetch messages which they missed (eg. due to poor
Thanks to Atlassian for allowing me to release hard numbers from their XMPP mobile coverage and a flaky network connection).
compression deployment. </p>
</p> </section1>
</section1> <section1 topic='Acknowledgements' anchor='acks'>
<section1 topic='Security Considerations' anchor='security'> <p>
<p>This document introduces no new security considerations.</p> This XEP was originally written by Dave Cridland, and parts of his
</section1> original work were used in this rewrite.
<section1 topic='IANA Considerations' anchor='iana'> Thanks to Atlassian for allowing me to release hard numbers from their
<p> XMPP compression deployment.
This document requires no interaction with the Internet Assigned Numbers </p>
Authority (IANA). </section1>
</p> <section1 topic='Security Considerations' anchor='security'>
</section1> <p>This document introduces no new security considerations.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> </section1>
<p> <section1 topic='IANA Considerations' anchor='iana'>
No namespaces or parameters need to be registered with the XMPP Registrar <p>
as a result of this document. This document requires no interaction with the Internet Assigned Numbers
</p> Authority (IANA).
</section1> </p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>
No namespaces or parameters need to be registered with the XMPP Registrar
as a result of this document.
</p>
</section1>
</xep> </xep>