[Standards] mobile optimizations (was: Re: Google Andro?d SDK not XMPP compliant ?)

Dave Cridland dave at cridland.net
Fri Feb 15 01:17:48 UTC 2008


On Thu Feb 14 22:49:20 2008, Peter Saint-Andre wrote:
> On Thu, Feb 14, 2008 at 08:39:29PM +0000, Dave Cridland wrote:
> > Lots of work from mobile email (ie, Lemonade) is transferrable  
> here.  > It'd be really nice if Tony Finch was coming, since he  
> could talk us  > through QTLS and QUICKSTART - they're SMTP fast  
> startup work he did a  > while back. Very interesting, but didn't  
> make it into the Lemonade  > Profile itself.
> 
> Do you have references? At least we could read up on it so we can
> discuss it intelligently at the devcon, then pester Tony with  
> questions
> afterward.
> 
> 
You don't need to read them, just say "Ah, yes, QTLS, hmmm", then nod  
sagely.

Or you could look at:

QTLS/QUICKSTART:

Two flavours; simple and full:
http://tools.ietf.org/html/draft-fanf-smtp-quickstart-a-00
http://tools.ietf.org/html/draft-fanf-smtp-quickstart-b-00

Both are really scary. I've always been a big fan of the detailed  
round-trip analysis at the end. I'm hoping Tony will notice this  
thread and do something similar for XMPP.

Then there's this evil trick of mine, which you can use in concert  
with Tony's insane hackery:
http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions-00

Otherwise, the remaining tricks we can use are fast resynchronization  
from a known state point, and fast reconnection.

Fast reconnection is essentially the case where there is a short time  
period between the end of the last connection and the beginning of  
the next, such that both ends can maintain full state. XEP-0198 is  
basically fully addressing this - it allows for the somewhat curious  
case of a client noticing it's offline and reconnecting before the  
server has a chance to notice what's happening.

Fast resynchronization is somewhat more complex - roster  
optimizations is one area we need, and I think I see a clear way of  
doing this. Whether it's implementable by everyone I don't know.  
Essentially, it would be a monotonically increasing modification  
sequence on the roster, and whenever a roster entry is changed,  
increasing the sequence and stamping the roster entry with the  
current value. It's more efficient than ETags on the entire roster,  
and would then give clients a simple "tell me stuff that's changed"  
operation. Roster removals would still be painful, but those are  
rather rarer than changes and additions, I think.

This is basically lifting RFC 4551's conditional fetch and reapplying  
it to rosters.

Presence and PubSub resynchronization I think would need addressing  
for this, too, but I don't have a clear idea of what can be done  
there.

One thing we can do is buffer... If you can get all the initial  
presence splurge into a single buffer before you  
compress/encrypt/send, you'll get much better compression.


> >> 5. Advisability of presence-only connections (no roster-get,  
> just send
> >> presence and whatever you receive is nice).
> >>
> > If you can optimize the roster fetch sufficiently, this really  
> isn't  > required.
> 
> Probably not.
> 
> 
Oh, definitely not - the only excess would be the first roster fetch  
- subsequent ones will yield no data in normal cases. Obviously we  
still need to discuss not fetching the roster carefully, since it'll  
be a useful tactic until we get an optimized roster thing widely  
deployed.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list