[Standards] Using XMPP In A Mobile Environment

Sergey Dobrov binary at jrudevels.org
Fri Feb 13 11:35:14 UTC 2015

On 02/11/2015 12:12 AM, Florian Schmaus wrote:
> Hi Sergey, thanks for you reply. :)
Hey Florian, thanks you are interested in this question.

> On 10.02.2015 09:11, Sergey Dobrov wrote:
>> On 02/10/2015 01:57 AM, Florian Schmaus wrote:
>>> But IMHO there is one piece missing. If we assume that the outbound
>>> traffic of a mobile device is not causing any unwanted battery drain,
>>> that is because if the device sends something it usually has a pretty
>>> good reason to do so, it becomes obvious that we need to focus on
>>> inbound traffic.
>> I'd say it another way: we can move the responsibility to client as it
>> tightly depends on client's UI and approaches so they need to decide,
>> this will be a way of competing among clients :)
> Yep, but not all XMPP clients have an UI. It basically comes down to
> "The XMPP client is responsible to avoid sending data where possible,
> and if it does send data it should send as less data as possible, e.g.
> by omitting the 'from' stanza attribute".
>>> Let's start by classifying inbound stanzas into three types. There are
>>> stanza that…
>>> 1. require immediate delivery
>> Even those stanzas can be slightly deferred and be bundled, I believe.
>> Just the interval will be much thicker, and still it can reduce number
>> of necessary wakes up.
> I'm not sure about that, Even if you defer all messages for only 30
> seconds, realtime (chat) communication would become a pain. And there is
> also little gain in that. I guess that only if your defer interval is
> something > 15 minutes you will see a measurable positive effect on the
> battery consumption.
I'm not sure here. This page
says that it can take few dozen seconds for the radio to go to dormant
state to conserve radio and each next wake up of it can consume up to
100ms and corresponding battery consumption.

I have no idea if there's an API on mobile device that can say if the
radio is in active state or not but I guess it could be a good
optimisation to flush our buffer when someone else woke up the radio.
>From the other hand, if stanza requires immediate delivery, it's
unlikely we can defer it even for a minute, so it's probably useless anyway.

But from now it's a good question on how to classify the stanzas. For
example, chatstates can be slightly deferred in an expectation that
someone else will wake up the radio, right?

I also think, that even 5 minutes interval (for incoming stanzas from
client side) can be a good deal still. Also, when the client sees that
radio has been woken up, it can send a request to server to flush the
buffers quickly without any hurt to battery (but this can require
additional CSI state).

I have more ideas but need to do some investigation of what APIs modern
mobile platforms provide to track those states. (for example, there is a
persistent low-bandwidth outgoing channel on HSDPA networks which can be
used to deliver small payloads regardless of the current radio states
which could have interesting applications in our case)

So, I think that the best performance can be achieved when we have long
intervals (15 minutes looks good) and when we ask server to flush the
queue each time our radio wakes up.

>>> 2. can be delayed
>>> 3. should not be delivered at all
>>> The appealing simplicity of CSI is that it categorizes presences
>>> stanzas as type 2., and simply delays them until the client reports
>>> that it is active.
>> I think that we also should remove presences from sending queue when new
>> presence from the same full JID has came, as old ones are not needed
>> anymore anyway.
> IIRC that is what most CSI implementations already do.

>>> I pointed out a possible attack scenario at my lightning talk [1],
>>> where a malicious entity drains the victims battery by repeatedly
>>> sending XMPP stanzas to the victims mobile. The stanzas originating by
>>> the malicious entity obviously are of type 3.
>> I think that this is a completely different problems actually because
>> this can happen also with subscribed contacts, so it's unnecessary to
>> focus on this problem in as part of CSI. Instead, some new security
>> protocols should be invented including spam protection. (They are too
>> complicated to discuss them here, I think?)
> Please note that I'm not describing an extension of CSI. Bundling and
> Deferring is a concept unrelated to CSI, their only relation is that
> both come in handy in a mobile environment and that they are useless in
> an environment where traffic volume and battery consumption doesn't count.
> Also this is not meant as SPAM protection measure. That's not the scope
> of the bundle and defer mechanism.
>>> A possible countermeasure would be using Privacy Lists (XEP-16) to
>>> block all incoming stanzas from entities not in the user's
>>> roster. When I told Chris Deering about that, his response was that
>>> this would yield a bad UX. And he is of course right. There is no way to
>>> reliable know if a stanza is of type 3. But do we really need that?
>> Probably, those security protocols should be extensions to Privacy Lists...
> Yeah, but I guess exploring how this could be used together with SIFT
> too. If it only had a roster/subscription state based filtering mechanism.
>>> The missing piece I was talking about at the beginning, is a mechanism
>>> to *bundle and defer* stanzas (usually messages): Particular stanzas are
>>> bundled and their delivery to the (mobile) user is deferred, so that the
>>> stanzas are send in bulk, giving the mobile device the possibility to
>>> enter sleep mode while the stanzas are deferred. This could (typically)
>>> apply to stanzas send from entities which don't have a subscription to
>>> the users presence.
>> ALSO, if client supports such a feature, we could actually hide the
>> message content (if it exceeds certain size) and offer to fetch it with
>> MAM later if needed. (just as PubSub does when content delivery in
>> events is switched off in node configuration).
> Not sure about the hiding of message content if the message already was
> deferred. It seems to add just extra complexity without no big advantage.
That's may be another issue. Just it's possible to waste your traffic as
it still can be a problem especially in some special environments like
an international roaming. But yeah, this is for another thread.

>>> So the basic idea is clear, but I'm undecided how to specify such an
>>> mechanism. For example:
>>> - Should the stanzas which are bundled and deferred be matched by
>>>   - Privacy Lists
>>>   - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is
>>>     not subscribed to my presence, defer and bundle the stanza he
>>>     wants to send to me" :-( )
>>> - Delay Time? I'm thinking about recommending 15-30 minutes, while
>>>   warning that it should be not less then 15 minutes (a typical SMTP
>>>   greylisting timeout).
>> But it can be less than 15 minutes if device wakes up earlier, right?
> Well we could say that if the client becomes active (by means of CSI),
> all bundled and deferred stanzas are flushed (just like the presences
> are). I would maybe mention this optimization in the spec but make it
> optional, while noting that bundling and deferring should still happen
> if the client is in active (CSI) state, because otherwise you circumvent
> the protection.
I don't see why the circumvention happens here? Inactive state does not
mean you don't want anything to be received but rather means that it
would be better to not receive because I don't wait for the data. But if
smth urgent happens, we can deliver it all because it actually doesn't
affect battery consumption again and from the other hand it keeps the
xml stream sorted by time.

>>> - Should the server send a "your message has been queued for later
>>>   delivery" message back to the sender?
>> Yes, I believe it is must have. Just like the notifying that the message
>> has been stored in the offline storage.
> Are those notifications if a message got stored offline mandatory? I
> think they are optional.
That actually was defined in XEP-0022 which is obsolete now and it has
been replaced with chatstates which does not support this at all, so
generally we don't have such ability now but still server will return
<service-unavailable> if it can't store message offline (which is not
the same, yeah :( )

So it's actually a question how we can implement this.

> - Florian

With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

More information about the Standards mailing list