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

Overwrite XEP-0286 instead of submitting a new XEP

Browse Source
This commit is contained in:
Sam Whited 2015-07-22 22:57:42 -05:00 committed by Matthew A. Miller
parent 4c2052ffcc
commit 8d691de73a
2 changed files with 178 additions and 327 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

203
inbox/mobile-concerns.xml
View File

@ -1,203 +0,0 @@
<?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 &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.
</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 &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>.
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>

298
xep-0286.xml
View File

@ -6,8 +6,11 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>XMPP on Mobile Devices</title> <title>Mobile Considerations</title>
<abstract>This document provides background information for XMPP implementors concerned with mobile devices operating in a cellular network such as 3G.</abstract> <abstract>
This document provides background information for XMPP implementors
concerned with mobile devices operating on an LTE cellular network.
</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0286</number> <number>0286</number>
<status>Deferred</status> <status>Deferred</status>
@ -26,6 +29,18 @@
<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>
<firstname>Sam</firstname>
<surname>Whited</surname>
<email>sam@samwhited.com</email>
<jid>sam@samwhited.com</jid>
</author>
<revision>
<version>0.2</version>
<date>2015-07-22</date>
<initials>ssw</initials>
<remark><p>Overhaul to include LTE.</p></remark>
</revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2010-09-15</date> <date>2010-09-15</date>
@ -40,140 +55,179 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>The use of XMPP on mobile devices is little understood, since few XMPP implementors have good mobile knowledge, and few mobile engineers have good XMPP knowledge. In addition, as the mobile landscape has changed, optimal protocol designs and usage patterns have also changed. This has led to the sub-optimal combination of a large amount of mostly undocumented lore, as well as several outdated concepts being discussed as fact.</p> <p>
<p>This XEP aims to provide useful background knowledge of mobile handset behaviours, and essentially distills a number of conversations with experienced mobile engineers and XMPP implementors, providing useful background as general suggestions.</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>
<section1 topic='Overview' anchor='overview'> <section1 topic='Overview' anchor='overview'>
<p>Mobile handsets typically have two constraints - power and bandwidth. The advent of 3G technology and beyond has tended to mean that bandwidth is radically higher, and comparable to broadband speeds - however many operators still charge based on transferred data, hence bandwidth remains an important issue for cost purposes.</p> <p>
<p>The major cost of power in the handset for our purposes is the radio - here, too, bandwidth plays a part, but as this document will show, the time the radio is forced to be available to receive also costs substantially.</p> The two major constraints on mobile devices are power and bandwidth. With
<p>Whilst this document refers to &rfc3920;, implementors are advised to take note of &rfc6120;.</p> 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>
<section1 topic='Compression'>
<p>XMPP is known to compress well. Both TLS, part of &xmppcore;, and &xep0138; can provide access to the DEFLATE codec (<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 <section1 topic='Compression' anchor='compression'>
&lt;<link url='http://tools.ietf.org/html/rfc1951'>http://tools.ietf.org/html/rfc1951</link>&gt;.</note>), which provides access to simple stream compression.</p> <p>
<p>Compression ratios vary with usage, however, typical usage by a general client appears to show a 20% ratio (an 80% reduction in bandwidth) in longer sessions<note>Fixed-purpose clients, such as the Buddycloud client, do see even lower ratios, approaching 10%.</note>. Server implementors should note that there is a substantial memory cost per codec of 300KB assuming maximum settings - this may be dramatically reduced by reducing the memory level and window bits of the implementation - lowering memory level primarily causes increased CPU usage, whereas lowering the window bits directly degrade compression.</p> XML, and by extension XMPP, is known to be highly compressible. In a simple
<p>At an exemplary point in one experiment, the author found the following figures<note>The compression ratio is here given as Original/Compressed, hence a 100% compression ratio is no compression at all, and 0% would represent infinite compression.</note>:</p> test of a small (266089 byte) XMPP stream (connection, stream
<table> initialization, feature discovery, roster loading, several presence stanzas
<tr> sent and received, disconnect), the entropy of the stream was found to be
<th>Window Bits</th> 5.616313 bits per byte. Using the `gzip` tool to apply Lempel-Ziv coding
<th>Compression Ratio (approx)</th> (LZ77) without concern for server-side CPU usage resulted in a compression
</tr> ratio of 21% (a 79% reduction in bandwidth). In one test with a much larger
<tr> dataset typical of a corporate environment (many hundreds of users in the
<td>15</td> roster), the ratio was as low as 13%, an 87% reduction in bandwidth!
<td>20%</td> </p>
</tr> <p>
<tr> Compression of XMPP data can be achieved with the DEFLATE algorithm
<td>14</td> (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138;. While the
<td>22%</td> security implications of stream compression are beyond the scope of this
</tr> document (See the aforementioned RFC or XEP for more info), mitigating them
<tr> may affect compression ratios. The author does not recommend using TLS
<td>13</td> compression with XMPP (or in general). If compression must be used, stream
<td>25%</td> level compression should be implemented instead. Compressing at the stream
</tr> level gives us the benefit of being able to flush the compression stream on
<tr> stanza boundaries to help prevent information from leaking. This, however,
<td>12</td> may drastically increase compression ratios.
<td>30%</td> </p>
</tr> <p>
<tr> While the CPU cost of compression directly translates to higher power
<td>11</td> usage, it is vastly outweighed by the benefits of reduced network
<td>38%</td> utilization, especially on modern LTE networks which use a great deal more
</tr> power per bit than 3G networks as will be seen later in this document.
<tr> </p>
<td>10</td> <p>
<td>43%</td> Supporting compression and flushing on stanza boundaries is highly
</tr> recommended.
<tr> </p>
<td>9</td>
<td>60%</td>
</tr>
</table>
<p>Although there is an equal cost for the mobile device to compress, it is considered that the compression codec memory and CPU costs - while certainly translating into power cost - are outweighed by two factors. Firstly, they're likely to reduce the transmission cost by a greater amount, and secondly they will also reduce the encryption cost in TLS.</p>
<p>Care, however, should be taken not to use XEP-0138 compression when TLS compression is in effect.</p>
</section1> </section1>
<section1 topic='Radio Power'> <section1 topic='Power Consumption' anchor='power'>
<p>Mobile handsets have a number of levels for radio activity. 3G radios can be either Idle, or else in an increasingly capable - and increasingly power-hungry - series of levels, through FACH to DCH.</p> <p>
<p>For the purposes of investigating this, power consumption (or rather battery depletion rate, as current) and timeouts where measured on the 3UK network, with a Nokia E71, using the Energy Profiler. A "typical handset" mentioned here has a 1000mAh battery - some smartphones have up to 1500mAh. Note that all timeouts are under the control of the network operator, not the handset or application.</p> While the wide spread adoption of LTE has dramatically increased available
<section2 topic='Idle'> bandwidth on mobile devices, it has also increased power consumption.
<p>Idle state is when the radio is neither receiving nor transmitting. It may have live (although silent) TCP connections. The cost is low. There is also a PCH level, which is similarly low-power, and again is only used when the radio is silent.</p> According to one study, early LTE devices consumed 5&#x2013;20% more power
<p>The current here was measured as 8mA - likely affected more by the energy profiler than much else.</p> 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.
</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 &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>.
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>
<section2 topic='FACH'> <section2 topic='Transmit as much data as you can at once'>
<p>FACH uses a shared channel for low-bandwidth communications. Packet sizes must be small - around 128 octets maximum, although this is operator controlled. Raising to this state takes around 2.5 seconds before the data can flow - although the power cost rises instantly - and after the session has returned to silence, it will remain at FACH level for some time.</p> <p>
<p>Note that this threshold includes the overheads from TCP and TLS, which are 52 and 5 octets respectively, leaving around 70 octets for the payload data.</p> If one is on 3G, transmitting a small amount of data will cause the radio
<p>Here, the current was measured as 140mA, and a timeout of 8 seconds - this timeout is at the lower end of the expected range, which could be up to around 2 minutes. On a typical handset, this will exhaust the battery in around 7 hours.</p> 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> </section2>
<section2 topic='DCH'>
<p>DCH uses a dedicated channel for high bandwidth communications. Again, raising to this state takes 2.5 seconds at the DCH power level, and there is a timeout before dropping back. Some operators will drop back to FACH for the duration fo the FACH timeout - others will drop back to Idle/PCH.</p>
<p>Sending more than the FACH threshold will raise the radio all the way to DCH - taking, again, 2.5 seconds.</p>
<p>The measurements here were 380mA and 8 seconds - this is sufficient to flatten a typical handset battery in less than 3 hours, and the figures are considered normal.</p>
</section2>
<p>Transmission of data can use up to 2W<note>The author's hazy recollection of P=IV suggests around a 570mA current</note>, and raising the level itself takes between 2 and 3 seconds to take effect - during which time the handset cannot receive or transmit, but still incurs the power cost. There are packets sent from and to the handset during this time.</p>
<p>Experimentation suggests that uncompressed XMPP will never trigger the FACH state, leaping directly into the more costly DCH state. However, compression does make FACH possible, if rare.</p>
</section1> </section1>
<section1 topic='Conclusions'> <section1 topic='Notable Extensions' anchor='xeps'>
<p>As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:</p> <p>
<dl> This section provides pointers to other documents which may be of interest
<di> to those developing mobile clients, or considering support for them in
<dt>Transmit no data.</dt> servers.
<dd>Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.</dd> </p>
</di> <p>&xep0138; provides stream level compression.</p>
<di> <p>
<dt>If you must transmit, then transmit only a small volume.</dt> &xep0115; provides a mechanism for caching, and hence eliding, the
<dd>If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.</dd> disco#info requests needed to negotiate optional features.
</di> </p>
<di> <p>
<dt>If you must transmit, then compress as hard as possible.</dt> &xep0237; provides a relatively widely deployed extension for reducing
<dd>Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.</dd> roster fetch sizes.
</di> </p>
<di> <p>
<dt>If you have transmit a lot, then do a lot</dt> &xep0198; allows the client to send and receive smaller keep-alive
<dd>If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.</dd> messages, and resume existing sessions without the full handshake. Useful
</di> on unstable connections.
<di> </p>
<dt>If you receive, then transmit</dt> <p>
<dd>If your peer raises the radio state, you may as well use it.</dd> &xep0357; implements push notifications (third party message delivery),
</di> which are often used on mobile devices and highly optimized to conserve
</dl> battery. Push notifications also allow delivery of notifications to
<p>And for servers, similar rules apply:</p> mobile clients that are currently offline (eg. in an XEP-0198 "zombie"
<dl> state).
<di> </p>
<dt>Send no data.</dt> <p>
<dd>Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.</dd> &xep0313; lets clients fetch messages which they missed (eg. due to poor
</di> mobile coverage and a flakey network connection).
<di> </p>
<dt>If you must send, send tiny bits.</dt>
<dd>Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.</dd>
</di>
<di>
<dt>If you receive, then send anything you have.</dt>
<dd>Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.</dd>
</di>
<di>
<dt>If you must send when not receiving, send plenty.</dt>
<dd>Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.</dd>
</di>
</dl>
<p>Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.</p>
</section1>
<section1 topic='Notable Extensions'>
<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 application stream level compression, useful if the device TLS stack does not support TLS-based 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 the roster fetch bandwidth, in most cases reducing it to a simple affirmation that the client has the current roster. This saves not only bandwidth, but also reduces local storage writes.</p>
<p>&xep0198; provides session resumption over TCP, enabling a client to handle the case where the coverage is patchy. The &lt;r/> and &lt;a/> elements also provide a keepalive facility in a small number of octets.</p>
<p>&xep0273; provides a mechanism which, amongst other things, would allow a presence "hush", buffering presence during certain states.</p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>
<p>The author is not a mobile expert, and relied on the knowledge and patient help of several others. In particular, thanks are due to Jussi Laako, Markku Vampari, and Markus Isomaki of Nokia, and Simon Tennant of Buddycloud.</p> <p>
<p>The attribution of any mistakes herein is zealously guarded by the author, however.</p> This XEP was originally written by Dave Cridland, and parts of his original
work were used in this rewrite.
</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>This document does not discuss a protocol, thus introduces no new security considerations.</p> <p>This document introduces no new security considerations.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p> <p>
This document requires no interaction with the Internet Assigned Numbers
Authority (IANA).
</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>None.</p> <p>
No namespaces or parameters need to be registered with the XMPP Registrar
as a result of this document.
</p>
</section1> </section1>
</xep> </xep>