[Standards] mobile optimizations

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 15 16:06:33 UTC 2008

Dave Cridland wrote:
> 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:
> 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.

I haven't read those yet, because you scared me off. :P

> 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

That's interesting. The reuse (overloading?) of SASL EXTERNAL is
creative. :) I tend to agree with your speculation that we might want to
define a family of EXTERNAL-like mechanisms, rather than forcing a wide
variety of credential types (X.509 certs, IPSec, reauth) into the one
EXTERNAL mechanism.

> 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.

Yes, I need to update that spec real soon now (to incorporate some
feedback that Justin hasn't had time to work in).

> 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. 

Rosters are so core to how both clients and servers work that I somewhat
doubt if changes thereto will see wide implementation or deployment
anytime soon.

> 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.

Yay, another RFC to read. :)

> 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.

More to talk about at the devcon...


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080215/955f395f/attachment.bin>

More information about the Standards mailing list