mobile strengths and weaknesses

Here is another data point regarding strengths and
weaknesses of XMPP in
the mobile space. I received this offlist from someone who
has
experience building mobile application with IMPS,
SIP/SIMPLE, and XMPP
(but not recent XMPP experience I think -- this person may
not be aware
of things like BOSH and stream compression)...

******

Strengths:

1. Speed - servers are superb and latency is minimal

2. Simplicity - easy to implement

3. Extensibility - easy to add custom protocol extensions

4. Low data usage - especially compared to SIP - a binary
encoding of
XML would help even more (like OMA IMPS has) - but OMA IMPS
loses the
race due to large HTTP headers

5. Large developer community (gateways to many other
protocols, other
cool features)

Weaknesses:

1. Reliable message delivery

- Since XMPP is using TCP as transport method, it assumes
that if the
TCP connection is active, then all the data transferred is
reliably
delivered. However this is not true in mobile environments.
GPRS
networks try to keep TCP connection active during brief
out-of-coverage
situations, and sometimes the data sent during that period
is lost when
the GRPS is unable to re-establish the radio-link between
the user agent
and the base station.

- OMA IMPS protocol uses HTTP as the transport mechanism and
provides
information about whether a transaction has been
successfully delivered.

- SIP/SIMPLE uses TCP/UDP and also has a transaction based
model with
clear rules for when a transaction should be re-sent.

* Basically the biggest problems come from the fact that on
mobile
devices the network access is not that reliable and the
interface can go
down at any time. Also the device might end up switching
between
different radio interfaces (e.g., Wifi <-> GPRS).
Taking that into
consideration when designing the protocol would have solved
many of the
problems we faced with XMPP.

_Solution_: add transaction model to content that is
considered vital
(or content that might cost the end-user). Create rules for
how to
handle re-sending of the content.

(PSA NOTE: it seems that BOSH could help us here, though at
the cost of
HTTP headers...)

2. XMPP requires a persistent TCP connection, which leads to
battery
drain - as the network connection is required always when
client is
online, the WiFi / GPRS / 3G connection is required as well.
The "always
active" radio transceiver will consume a lot of power
and drain the battery.

- OMA IMPS has a solution for this: the client can turn off
the
signalling channel when the client is not in active use
(chatting/etc),
and tell the server to fall back to SMS-based signalling.
When the
server receives new messages that are destined for the
client, it will
inform the client (using a special SMS message) that content
is
available. The client will then resume the network + normal
signalling.

(PSA NOTE: this is the "session pause" or
"session hush" idea...)

******

Thanks for the update. Some notes below

On Sat, Mar 22, 2008 at 1:37 AM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
> Here is another data point regarding strengths and
weaknesses of XMPP in
>  the mobile space. I received this offlist from someone
who has
>  experience building mobile application with IMPS,
SIP/SIMPLE, and XMPP
>  (but not recent XMPP experience I think -- this person
may not be aware
>  of things like BOSH and stream compression)...
>
>  ******
>
>  Strengths:
[...]

Nice to know all this is recognized ;)

>
>  Weaknesses:
>
>  1. Reliable message delivery
>
>  - Since XMPP is using TCP as transport method, it
assumes that if the
>  TCP connection is active, then all the data
transferred is reliably
>  delivered. However this is not true in mobile
environments. GPRS
>  networks try to keep TCP connection active during
brief out-of-coverage
>  situations, and sometimes the data sent during that
period is lost when
>  the GRPS is unable to re-establish the radio-link
between the user agent
>  and the base station.

That's the first point where its seems that our friend isn't
aware of
BOSH. We regularly keep the session open when our mobile
client
disconnects and we can do interesting things like modifying
the
presence when the client si disconnected (e.g. put the
client xa with
a proper status message, and autoreply to messages telling
the sender:
hey the recipient is temporary disconnect though you see it
online,
don't worry the message will be delivered asap)
The feature is not yet in the released version of the client
(which
uses tcp sockets) just because we are not ready yet for
going public
with this connection manager, but it works without troubles.
It's even
possible to reconnect after rebooting the client and,
therically, it
should be possible to migrate the session to a different
device.

>  - OMA IMPS protocol uses HTTP as the transport
mechanism and provides
>  information about whether a transaction has been
successfully delivered.

See again BOSH for this

>  - SIP/SIMPLE uses TCP/UDP and also has a transaction
based model with
>  clear rules for when a transaction should be re-sent.
>
>  * Basically the biggest problems come from the fact
that on mobile
>  devices the network access is not that reliable and
the interface can go
>  down at any time. Also the device might end up
switching between
>  different radio interfaces (e.g., Wifi <->
GPRS). Taking that into
>  consideration when designing the protocol would have
solved many of the
>  problems we faced with XMPP.
>
>  _Solution_: add transaction model to content that is
considered vital
>  (or content that might cost the end-user). Create
rules for how to
>  handle re-sending of the content.
>
>  (PSA NOTE: it seems that BOSH could help us here,
though at the cost of
>  HTTP headers...)

Yep, again BOSH is the solution. BOSH headers however aren't
so large,
the <body/> bag is sometimes heavier. If this is a
problem it's not a
big deal designing HTTP like binary headers, thus adding few
bytes of
overhead each message. Of course there is a price for this:
you lose
the capability of passing through real HTTP servers and
proxies, but I
don't think it could be a big issue, since this would be
just an
optional optimization for mobiles.

>  2. XMPP requires a persistent TCP connection, which
leads to battery
>  drain - as the network connection is required always
when client is
>  online, the WiFi / GPRS / 3G connection is required as
well. The "always
>  active" radio transceiver will consume a lot of
power and drain the battery.
>
>  - OMA IMPS has a solution for this: the client can
turn off the
>  signalling channel when the client is not in active
use (chatting/etc),
>  and tell the server to fall back to SMS-based
signalling. When the
>  server receives new messages that are destined for the
client, it will
>  inform the client (using a special SMS message) that
content is
>  available. The client will then resume the network +
normal signalling.

>  (PSA NOTE: this is the "session pause" or
"session hush" idea...)

We were talking last week about the same idea with the
people at Sapo.
The SMS option is possible also with XMPP since any mobile
application
(J2ME, Symbian or the coming Android) can listen for
incoming SMSes on
a given port and be automatically scheduled. Besides the
session pause
feature, with BOSH again it's possible to stop the
connection and
re-establish it when we receive an SMS. However this is
feature for
carriers, since I don't think that free server operators or
users will
pay the cost of an SMS for almost any incoming message.
Unfortunately this is design flaw  of GPRS/ 3G networks, and
we have
to live with it unless there won't be install battery
refills with
fuel cells ;)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com

On Tue, Mar 25, 2008 at 9:28 PM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
>
>  So do you think that we need to define a generic
session pause feature,
>  or is it handled well enough already in BOSH?

We need it, at least for discriminating between these two
cases:
- the client unadvertitely loses the connection and we don't
know
whether and when it will become available
- the client itself suspends the connection and tells the CM
something
like: I will reconnect within 15', don't bother me with new
messages,
unless there is something coming from the contacts in the
urgent list;
and if I don't connect within 60' consider this session
lost

Still don't know how to exactly handle these case at server
side,
since we haven't enough use cases yet, but I'm sure that we
must be
able to distinguish between "connection errors"
and voluntary
suspends.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com

If this conversation ever continues on elsewhere, please
keep me in
the know. I'm interested in contributing where possible as
I'm looking
at developing a mobile presence+messaging client.

On Tue, Mar 25, 2008 at 7:05 PM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
> Fabio Forno wrote:
>  > On Tue, Mar 25, 2008 at 10:08 PM, Peter
Saint-Andre <stpeterstpeter.im> wrote:
>  >
>  >>  Yes that makes sense. But it sounds as if we
don't yet know enough to
>  >>  define session hush and session pause very
well. Perhaps we need to talk
>  >>  with more people who care about this kind of
feature (as I did recently
>  >>  at the eComm conference).
>  >
>  > Indeed suspend is not difficult, it's just one
more "command" to be
>  > added to stanza acknowledgments (or an attribute
to the existing <r/>
>  > or <a/>), simply telling the server to
suspend the connection (timings
>  > can be negotiated at session level, such as we
already do in BOSH with
>  > a careful setting of "wait" and
"inactivity" attributes).
>
>  Yes I will add that to XEP-0198.
>
>
>  > Hush is the one that is difficult, since it is a
sort of dynamic
>  > privacy list in which we set which messages can
be considered
>  > important and at with which importance. Hush
moreover has a meaning
>  > both when connected (e.g. I'd like to delay some
messages for
>  > optimizing compression) and when disconnected
(which messages can
>  > start a new connection?), and for this reason I
think it fits a
>  > completely different XEP and we can wait for
it...
>
>  I wonder if hush is really just a special privacy
list, but I haven't
>  had time to work out if that's true.
>
>
>
>  Peter
>
>  --
>  Peter Saint-Andre
>  https://stpeter.im/
>
>

Fabio Forno wrote:
> Thanks for the update. Some notes below
> 
> On Sat, Mar 22, 2008 at 1:37 AM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
>
>>  2. XMPP requires a persistent TCP connection,
which leads to battery
>>  drain - as the network connection is required
always when client is
>>  online, the WiFi / GPRS / 3G connection is
required as well. The "always
>>  active" radio transceiver will consume a lot
of power and drain the battery.
>>
>>  - OMA IMPS has a solution for this: the client can
turn off the
>>  signalling channel when the client is not in
active use (chatting/etc),
>>  and tell the server to fall back to SMS-based
signalling. When the
>>  server receives new messages that are destined for
the client, it will
>>  inform the client (using a special SMS message)
that content is
>>  available. The client will then resume the network
+ normal signalling.
> 
>>  (PSA NOTE: this is the "session pause"
or "session hush" idea...)
> 
> We were talking last week about the same idea with the
people at Sapo.
> The SMS option is possible also with XMPP since any
mobile application
> (J2ME, Symbian or the coming Android) can listen for
incoming SMSes on
> a given port and be automatically scheduled. Besides
the session pause
> feature, 

So do you think that we need to define a generic session
pause feature,
or is it handled well enough already in BOSH?

> with BOSH again it's possible to stop the connection
and
> re-establish it when we receive an SMS. However this is
feature for
> carriers, since I don't think that free server
operators or users will
> pay the cost of an SMS for almost any incoming
message.
> Unfortunately this is design flaw  of GPRS/ 3G
networks, and we have
> to live with it unless there won't be install battery
refills with
> fuel cells ;)

Heh, yeah.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

On Tue, Mar 25, 2008 at 10:08 PM, Peter Saint-Andre
<stpeterstpeter.im> wrote:

>  Yes that makes sense. But it sounds as if we don't yet
know enough to
>  define session hush and session pause very well.
Perhaps we need to talk
>  with more people who care about this kind of feature
(as I did recently
>  at the eComm conference).

Indeed suspend is not difficult, it's just one more
"command" to be
added to stanza acknowledgments (or an attribute to the
existing <r/>
or <a/>), simply telling the server to suspend the
connection (timings
can be negotiated at session level, such as we already do in
BOSH with
a careful setting of "wait" and
"inactivity" attributes).
Hush is the one that is difficult, since it is a sort of
dynamic
privacy list in which we set which messages can be
considered
important and at with which importance. Hush moreover has a
meaning
both when connected (e.g. I'd like to delay some messages
for
optimizing compression) and when disconnected (which
messages can
start a new connection?), and for this reason I think it
fits a
completely different XEP and we can wait for it...

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ffjabber.bluendo.com