xeps/xep-0286.xml

<?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>0286</number>
  <status>Experimental</status>
  <type>Informational</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  <author>
    <firstname>Dave</firstname>
    <surname>Cridland</surname>
    <email>dave.cridland@isode.com</email>
    <jid>dave.cridland@isode.com</jid>
  </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>
    <version>0.1</version>
    <date>2010-09-15</date>
    <initials>psa</initials>
    <remark><p>Initial published version.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2010-07-13</date>
    <initials>dwd</initials>
    <remark><p>First draft. Also John's birthday.</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.
	</p>
	<p>
		Supporting compression and flushing on stanza boundaries 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&#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.
	</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>
	<p>
		&xep0357; implements push notifications (third party message delivery),
		which are often used on mobile devices and highly optimized to conserve
		battery.  Push notifications also  allow delivery of notifications to
		mobile clients that are currently offline (eg. in an XEP-0198 "zombie"
		state).
	</p>
	<p>
		&xep0313; lets clients fetch messages which they missed (eg. due to poor
		mobile coverage and a flakey network connection).
	</p>
</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.
	</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>