moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

XEP-0286: Fix some confusing paragraphs.

Browse Source 
Add reference to CSI in Notable Extensions
Undefer
This commit is contained in:
Sam Whited 2017-01-17 20:43:42 -06:00
parent 0d37fc3b0e
commit 09627a4ef6
1 changed files with 62 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
xep-0286.xml
View File

@ -8,12 +8,12 @@
<header>
<title>Mobile Considerations</title>
<abstract>
This document provides background information for XMPP implementors
concerned with mobile devices operating on an LTE cellular network.
This document provides background information for XMPP implementors
concerned with mobile devices operating on an LTE cellular network.
</abstract>
&LEGALNOTICE;
<number>0286</number>
<status>Deferred</status>
<status>Experimental</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -35,6 +35,17 @@
<email>sam@samwhited.com</email>
<jid>sam@samwhited.com</jid>
</author>
<revision>
<version>0.4.0</version>
<date>2017-01-17</date>
<initials>ssw</initials>
<remark>
<ul>
<li>Attempt to fix some confusing paragraphs.</li>
<li>Add Client State Indication to Notable Extensions.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.3</version>
<date>2015-07-24</date>
@ -76,13 +87,13 @@
</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.
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 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>
@ -118,8 +129,8 @@
other algorithms were not tested) should be considered negligable.
</p>
<p>
Supporting compression and flushing on stanza boundaries is highly
recommended.
Supporting compression and performming a full flush on stanza boundaries is
recommended for mobile devices.
</p>
</section1>
<section1 topic='Power Consumption' anchor='power'>
@ -156,39 +167,43 @@
<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.
transmitted (by the server or client).
Supporting &xep0352; is 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.
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.
</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.
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.
</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.
This section provides pointers to other documents which may be of interest
to those developing mobile clients, or considering implementing
optimizations for them in servers.
</p>
<p>&xep0138; provides stream level compression.</p>
<p>&xep0322; allows XMPP streams to use the EXI XML format.</p>
@ -201,15 +216,20 @@
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.
&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>
&xep0352; allows clients to indicate to the server that they are inactive,
allowing the server to optimize and reduce unnecessary traffic.
</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).
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
@ -219,8 +239,9 @@
<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.
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'>