[Standards] Proposed XMPP Extension: Mobile Considerations
sam at samwhited.com
Tue Jul 21 13:20:08 UTC 2015
On Tue, Jul 21, 2015 at 6:41 AM, Georg Lukas <georg at op-co.de> wrote:
> * Dave Cridland <dave at cridland.net> [2015-07-21 12:52]:
>> However, I expected this to be a (sorely-needed) major edit to XEP-0286,
>> which I wrote some years ago and has lagged behind the times. For the
>> record, I'm perfectly happy to completely hand over authorship of that
>> specification to Sam.
> I would also favor merging the two documents, and keeping the 0286
>> I'd be very interested in hearing any opinions on this one.
> I would like to see multiple things covered in more depth by the
> new/merged XEP, especially by providing more specific suggestions to the
> poor implementors:
> 1. Compression: The text leaves the reader in a suspended state: some
> kinds of compression are evil, others are ineffective. If possible,
> please do some benchmarks of the stream compression with stanza-level
> flushing and provide the results of that, as well as a strong
> recommendation how to handle the whole issue. This point might be one
> for a wider debate, but the results should be placed into this XEP.
> (I'm not sure if we should have a debate about how far we can compromise
> security / provide alternative mitigations for the data leakage in order
> to get more effective stream compression on mobile)
I actually started to do this, and then it was on my roadmap but I
decided I wouldn't be able to get to it quick enough and wanted to go
ahead and put the XEP out there. A future update may include it
(unless someone else does it first). My personal recommendation (based
partially on my work with stream compression at HipChat, and partially
with my own tests that I did for this XEP) is that stream compression
should NEVER be done except if you're flushing at the stanza level.
If you'd like me to make this a clear / firm recommendation I'm happy
to do so, but without actual testing it might just be snake oil to say
that it saves you much of anything at all (if nothing else I can show
that a large roster or disco#items list when comrpessed at the stanza
level is well worth it... if you've ever tried to fetch a roster with
several thousand people in it w/o stream compression, and then with,
it's a noticable difference).
> 2. LTE vs. 3G: Modern handsets (and most Telcos) roam between different
> protocols depending on coverage. This can not be detected by the XMPP
> server, and is probably very hard to detect by the mobile client (some
> devices provide a protected API). Therefore, implementation advice
> should not assume an LTE link but also mention the older protocol
I also started out copying the 3G sections from the older XEP (when I
was originally writing it as an update), but decided that since LTE
coverage would only become more prolific in the future, and and that
optimizing got very hard if you tried to account for both (the 3G UE
state machine is much more complicated than the LTE one), that I'd
just stick with LTE. Since LTE already uses a lot more battery power
(and its considerations also apply to 3G, although not all 3G
considerations apply to LTE), it seemed better to me to just keep
things simple and discuss LTE. Further discussion about how they
differ, and why LTE considerations are probably good enough might be
> 3. Ping intervals and timeouts: please provide hard numbers for the ping
> intervals and ping timeouts to be implemented by servers and clients.
> From practical experience I would suggest both sides to send a ping
> after no data was received for 25~29 minutes(*), and to use a ping
> (response) timeout of at least 60 seconds. I am open for different
> numbers from other people though.
I agree that it needs this (and more hard numbers in general),
however, like my previous comments, I won't have the time to really
sit down and get numbers for a while (doing this properly takes a lot
longer than writing up recommendations and reading papers). I would
love to add this later, but can't guarantee that I'll be able to get
> 4. Connection interruptions: LTE handsets without VoLTE downgrade to 3G
> or 2G on incoming/outgoing phone calls. This can lead to immediate
> termination of all TCP connections, with no way to cleanly close the
> XMPP session. XEP-0198 allows for a clean resumption after the phone
> call has ended, unless the call takes longer than the 0198 session
> timeout. There is currently no sane workaround for that, but it should
> be mentioned as something that mobile client developers need to consider
> in their designs. In the future, we might be able to use XEP-0310 PSA to
> let the server tell the user's buddies that he's actually gone (0198
> zombie state) and keep the 0198 state for a longer time without
> compromising usability.
Excellent point; will make this clear.
> 5. XEP-0313 and XEP-0357 seem to be good additions to the "Notable
> Extensions" list.
Agreed; I thought I had MAM on there, but was forgetting that Lance
and Holger were doing the push one. Will add these.
Thanks for the feedback.
More information about the Standards