mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
ProtoXEP.modile-concerns v0.0.1: first draft.
This commit is contained in:
Matthew A. Miller
parent
31e612a9bd
commit
bddd8a4177
203
inbox/mobile-concerns.xml
Normal file
203
inbox/mobile-concerns.xml
Normal file
@ -0,0 +1,203 @@
|
|||||||
|
<?xml version='1.0' encoding='UTF-8'?>
|
||||||
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||||
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||||
|
%ents;
|
||||||
|
]>
|
||||||
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
|
<xep>
|
||||||
|
<header>
|
||||||
|
<title>Mobile Considerations</title>
|
||||||
|
<abstract>
|
||||||
|
This document provides background information for XMPP implementors
|
||||||
|
concerned with mobile devices operating on an LTE cellular network.
|
||||||
|
</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>NOT_YET_ASSIGNED</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Informational</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<approver>Council</approver>
|
||||||
|
<dependencies>
|
||||||
|
<spec>XMPP Core</spec>
|
||||||
|
</dependencies>
|
||||||
|
<supersedes>
|
||||||
|
<spec>XEP-0286</spec>
|
||||||
|
</supersedes>
|
||||||
|
<supersededby/>
|
||||||
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||||
|
<author>
|
||||||
|
<firstname>Sam</firstname>
|
||||||
|
<surname>Whited</surname>
|
||||||
|
<email>sam@samwhited.com</email>
|
||||||
|
<jid>sam@samwhited.com</jid>
|
||||||
|
</author>
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2015-07-18</date>
|
||||||
|
<initials>ssw</initials>
|
||||||
|
<remark><p>First draft.</p></remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
|
<p>
|
||||||
|
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.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
This XEP aims to provide useful background knowledge of mobile handset
|
||||||
|
behavior, and those considerations that client and server designers can
|
||||||
|
take to ensure that bandwidth and battery are used efficiently.
|
||||||
|
</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Overview' anchor='overview'>
|
||||||
|
<p>
|
||||||
|
The two major constraints on mobile devices are power and bandwidth. With
|
||||||
|
the wide spread proliferation of 3G and LTE technologies, mobile bandwidth
|
||||||
|
and speeds have become broadly comparable to broadband. However, they are
|
||||||
|
still relatively expensive compared to traditional wired networks, and
|
||||||
|
should therefore still be considered. 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'>
|
||||||
|
<p>
|
||||||
|
XML, and by extension XMPP, is known to be highly compressible. In a simple
|
||||||
|
test of a small (266089 byte) XMPP stream (connection, stream
|
||||||
|
initialization, feature discovery, roster loading, several presence stanzas
|
||||||
|
sent and received, disconnect), the entropy of the stream was found to be
|
||||||
|
5.616313 bits per byte. Using the `gzip` tool to apply Lempel-Ziv coding
|
||||||
|
(LZ77) without concern for server-side CPU usage resulted in a compression
|
||||||
|
ratio of 21% (a 79% reduction in bandwidth). In one test with a much larger
|
||||||
|
dataset typical of a corporate environment (many hundreds of users in the
|
||||||
|
roster), the ratio was as low as 13%, an 87% reduction in bandwidth!
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
Compression of XMPP data can be achieved with the DEFLATE algorithm
|
||||||
|
(&rfc1951;) via TLS compression (&rfc3749;) or &xep0138;. While the
|
||||||
|
security implications of stream compression are beyond the scope of this
|
||||||
|
document (See the aforementioned RFC or XEP for more info), mitigating them
|
||||||
|
may affect compression ratios. 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. Compressing at the stream
|
||||||
|
level gives us the benefit of being able to flush the compression stream on
|
||||||
|
stanza boundaries to help prevent information from leaking. This, however,
|
||||||
|
may drastically increase compression ratios.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
While the CPU cost of compression directly translates 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.
|
||||||
|
Setting security considerations aside and thinking only of power
|
||||||
|
consumption and bandwidth, supporting compression is highly recommended.
|
||||||
|
</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Power Consumption' anchor='power'>
|
||||||
|
<p>
|
||||||
|
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
|
||||||
|
<note>LTE Smartphone measurements <<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>></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.
|
||||||
|
</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
|
||||||
|
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
|
||||||
|
somewhat inefficient
|
||||||
|
<note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks <<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>></note>.
|
||||||
|
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.
|
||||||
|
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:
|
||||||
|
</p>
|
||||||
|
<section2 topic='Transmit no data'>
|
||||||
|
<p>
|
||||||
|
Whenever possible, data that is not strictly needed should not be
|
||||||
|
transmitted (by the server or client). Supporting &xep0352; is highly
|
||||||
|
recommended. Most importantly, XMPP pings should be kept as far apart as
|
||||||
|
possible and only used when necessary. Server operators are encouraged to
|
||||||
|
set high ping timeouts, and client implementors are advised to only send
|
||||||
|
pings when absolutely necessary to prevent the server from closing the
|
||||||
|
socket.
|
||||||
|
</p>
|
||||||
|
</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 significantly higher tail-times
|
||||||
|
(the time it takes for the radio to change state). On LTE radios, one
|
||||||
|
should transmit as much data as possible when the radio is already on
|
||||||
|
(eg. by placing messages in a send queue and executing the queue as a
|
||||||
|
batch). Similarly, when data is being received the radio is already in a
|
||||||
|
high power state and therefore any data that needs to be sent should be.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
These rules also apply to server operators: If you receive data, the
|
||||||
|
phones radio is already on therefore you should send anything you have.
|
||||||
|
Otherwise, batching data to be sent and sending it all at once (and as
|
||||||
|
much as possible) will help reduce power consumption.
|
||||||
|
</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Notable Extensions' anchor='xeps'>
|
||||||
|
<p>
|
||||||
|
This section provides pointers to other documents which may be of interest
|
||||||
|
to those developing mobile clients, or considering support for them in
|
||||||
|
servers.
|
||||||
|
</p>
|
||||||
|
<p>&xep0138; provides stream level compression.</p>
|
||||||
|
<p>
|
||||||
|
&xep0115; provides a mechanism for caching, and hence eliding, the
|
||||||
|
disco#info requests needed to negotiate optional features.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
&xep0237; provides a relatively widely deployed extension for reducing
|
||||||
|
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. Useful
|
||||||
|
on unstable connections.
|
||||||
|
</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Acknowledgements' anchor='acks'>
|
||||||
|
<p>
|
||||||
|
The original mobile XEP, &xep0286;, was written by Dave Cridland, and parts
|
||||||
|
of it were used when writing this XEP.
|
||||||
|
</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Security Considerations' anchor='security'>
|
||||||
|
<p>This document introduces no new security considerations.</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||||||
|
<p>
|
||||||
|
This document requires no interaction with the Internet Assigned Numbers
|
||||||
|
Authority (IANA).
|
||||||
|
</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>
|
||||||
1
xep.ent
1
xep.ent
@ -405,6 +405,7 @@ THE SOFTWARE.
|
|||||||
<!ENTITY rfc1939 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1939'>RFC 1939</link></span> <note>RFC 1939: Post Office Protocol - Version 3 <<link url='http://tools.ietf.org/html/rfc1939'>http://tools.ietf.org/html/rfc1939</link>>.</note>" >
|
<!ENTITY rfc1939 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1939'>RFC 1939</link></span> <note>RFC 1939: Post Office Protocol - Version 3 <<link url='http://tools.ietf.org/html/rfc1939'>http://tools.ietf.org/html/rfc1939</link>>.</note>" >
|
||||||
<!ENTITY rfc1945 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1945'>RFC 1945</link></span> <note>RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0 <<link url='http://tools.ietf.org/html/rfc1945'>http://tools.ietf.org/html/rfc1945</link>>.</note>" >
|
<!ENTITY rfc1945 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1945'>RFC 1945</link></span> <note>RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0 <<link url='http://tools.ietf.org/html/rfc1945'>http://tools.ietf.org/html/rfc1945</link>>.</note>" >
|
||||||
<!ENTITY rfc1950 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1950'>RFC 1950</link></span> <note>RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <<link url='http://tools.ietf.org/html/rfc1950'>http://tools.ietf.org/html/rfc1950</link>>.</note>" >
|
<!ENTITY rfc1950 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1950'>RFC 1950</link></span> <note>RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <<link url='http://tools.ietf.org/html/rfc1950'>http://tools.ietf.org/html/rfc1950</link>>.</note>" >
|
||||||
|
<!ENTITY rfc1951 "<span class='ref'><link url='http://tools.ietf.org/html/rfc1951'>RFC 1951</link></span> <note>RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 <<link url='http://tools.ietf.org/html/rfc1951'>http://tools.ietf.org/html/rfc1951</link>>.</note>" >
|
||||||
<!ENTITY rfc2026 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2026'>RFC 2026</link></span> <note>RFC 2026: The Internet Standards Process <<link url='http://tools.ietf.org/html/rfc2026'>http://tools.ietf.org/html/rfc2026</link>>.</note>" >
|
<!ENTITY rfc2026 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2026'>RFC 2026</link></span> <note>RFC 2026: The Internet Standards Process <<link url='http://tools.ietf.org/html/rfc2026'>http://tools.ietf.org/html/rfc2026</link>>.</note>" >
|
||||||
<!ENTITY rfc2045 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2045'>RFC 2045</link></span> <note>RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <<link url='http://tools.ietf.org/html/rfc2045'>http://tools.ietf.org/html/rfc2045</link>>.</note>" >
|
<!ENTITY rfc2045 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2045'>RFC 2045</link></span> <note>RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <<link url='http://tools.ietf.org/html/rfc2045'>http://tools.ietf.org/html/rfc2045</link>>.</note>" >
|
||||||
<!ENTITY rfc2068 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2068'>RFC 2068</link></span> <note>RFC 2068: Hypertext Transport Protocol -- HTTP/1.1 <<link url='http://tools.ietf.org/html/rfc2068'>http://tools.ietf.org/html/rfc2068</link>>.</note>" >
|
<!ENTITY rfc2068 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2068'>RFC 2068</link></span> <note>RFC 2068: Hypertext Transport Protocol -- HTTP/1.1 <<link url='http://tools.ietf.org/html/rfc2068'>http://tools.ietf.org/html/rfc2068</link>>.</note>" >
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user