-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a forward from an older discussion on the standards@xmpp.org
list. I will probably look into this for the -02 version of 3920bis and
might post about it again soon.

/psa

- -------- Original Message --------
Subject: Re: [Standards] mobile optimizations (was: Re:  Google Androïd
SDK not XMPP compliant ?)
Date: Mon, 18 Feb 2008 13:33:13 +0000
From: Tony Finch <dot@dotat.at>
Reply-To: XMPP Extension Discussion List <standards@xmpp.org>
To: XMPP Extension Discussion List <standards@xmpp.org>
References:
<6ca210320802140055m73133123t8dcb67e84644207@mail.gmail.com>
<14867.1202999962.276834@peirce.dave.cridland.net>
<47B49FD5.6050609@stpeter.im>

How important is session startup latency for mobile XMPP? The motivation
for SMTP quickstart was to make sending email faster. Sending email is
quite an interactive action (though good client software can hide the
latency). The equivalent in XMPP is sending a message on a connection
that's already open. Session startup, on the other hand, is tied in with
things like associating with an access point or starting a GPRS
connection, doing DNS lookups, and all sorts of slow things before XMPP
can get going.

With that in mind, if it is worth optimising XMPP startup, then it's
probably worth taking the simplest possible approach which does not
require any stunt buffer handling. From the specification writer's point
of view, it amounts to adding some text to 3920bis which explains where
XMPP is asynchronous / pipelinable and where it is not. If you allow
pipelining of startup utterances other than transitions between XML and
TLS, and SASL exchanges, you can get something like the following. By
startup utterances, I mean that client and server can say <stream> in
either order, and the client can cache the server's <features/> and
proceed with <starttls/> and <auth/> on the assumption that the
<features/> have not changed.


C: TCP SYN
S: TCP SYN/ACK
C: TCP ACK

client does not need to wait for server's <stream> header, since its
stream header is the same regardless. in principle it should wait for the
server's <features/> before issuing <starttls/> but (a) it can cache the
<features/>, (b) unexpected lack of TLS support is something worth warning
the user about, (c) the protocol allows it to recover gracefully from the
error.

C: XMPP1 <stream>
          <starttls/>

server has to wait for client syn

S: XMPP1 <stream>
          <features/>
          <proceed/>

layering switch here, so there must be a round trip delay. there are two
kinds of TLS negotiation, without and with a session cache hit.

without

C: TLS hello
S: TLS stuff
C: TLS again
S: TLS finish

with

C: TLS hello
S: TLS stuff
C: TLS finish

to properly benefit from session cache optimisation, you need to let
either the server or the client start the stream first. that is, the
following two utterances can be in either order. the server and the client
send these as soon as the TLS layer returns from the handshake, and with a
good TLS implementation one of these will piggy-back on the last TLS
finish packet.

with a TLS session cache hit the packets come in this order:

C: XMPP2 <stream>
          <auth/>

S: XMPP2 <stream>
          <features/>

the client now has to wait for the server's reply, which in this case
should come immediately. (without a TLS session cache there's another
round trip delay.) the server can re-start its stream immediately, since
it is always the last to speak in SASL. when the client gets the SASL
response it can re-start its stream (and XML parser).

S: XMPP2  <success/>
   XMPP3 <stream>
          <features/>

C: XMPP3 <stream>
          <iq><bind/></iq>

client must wait for <iq> reply before it can do anything useful

S: XMPP3 <iq><bind><jid/></bind></iq>

Without a TLS session cache hit, we get 6RTT before useful data can be
transferred:

C: TCP SYN
S: TCP SYN/ACK
C: TCP ACK
   TCP XMPP1 <stream><starttls/>
S: TCP XMPP1 <stream><features/><proceed/>
C: TCP XMPP1 TLS hello
S: TCP XMPP1 TLS stuff
C: TCP XMPP1 TLS again
S: TCP XMPP1 TLS finish
   TCP XMPP1 TLS XMPP2 <stream><features/>
C: TCP XMPP1 TLS XMPP2 <stream><auth/>
S: TCP XMPP1 TLS XMPP2 <success/>
   TCP XMPP1 TLS XMPP2 XMPP3 <stream><features/>
C: TCP XMPP1 TLS XMPP2 XMPP3 <stream><iq><bind/></iq>
S: TCP XMPP1 TLS XMPP2 XMPP3 <iq><bind><jid/></bind></iq>

With a TLS session cache hit, we get 5RTT:

C: TCP SYN
S: TCP SYN/ACK
C: TCP ACK
   TCP XMPP1 <stream><starttls/>
S: TCP XMPP1 <stream><features/><proceed/>
C: TCP XMPP1 TLS hello
S: TCP XMPP1 TLS stuff
C: TCP XMPP1 TLS finish
   TCP XMPP1 TLS XMPP2 <stream><auth/>
S: TCP XMPP1 TLS XMPP2 <stream><features/><success/>
   TCP XMPP1 TLS XMPP2 XMPP3 <stream><features/>
C: TCP XMPP1 TLS XMPP2 XMPP3 <stream><iq><bind/></iq>
S: TCP XMPP1 TLS XMPP2 XMPP3 <iq><bind><jid/></bind></iq>

Note that all the layers come in contiguous lumps. Stunt buffering is
required if they get interleaved in the packet trace, e.g.

C: TCP ACK
   TCP XMPP1 <stream><starttls/>
   TCP XMPP1 TLS hello
S: TCP XMPP1 <stream><features/><proceed/>
   TCP XMPP1 TLS stuff
C: TCP XMPP1 TLS finish
   TCP XMPP1 TLS XMPP2 <stream><auth/>
   TCP XMPP1 TLS XMPP2 XMPP3 <stream><iq><bind/></iq>
S: TCP XMPP1 TLS XMPP2 <stream><features/><success/>
   TCP XMPP1 TLS XMPP2 XMPP3 <stream><features/><iq><bind><jid/></bind></iq>

I have not treated SASL in detail above. In particular I haven't examined
challenge/response mechanisms. In the last trace above, the XMPP2 layer
startup and the SASL negotiation get interleaved. I think this is be OK
since SASL is framed by XMPP2, not layered on top like TLS.

Tony.
- --
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
VIKING NORTH UTSIRE: NORTHWEST 5 OR 6, DECREASING 4. MODERATE OR ROUGH.
OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqoIzQACgkQNL8k5A2w/vw1owCdEfu5Nwl1dPfkKGdBUHwwiB1w
ZwYAn3pMcAezRgpUlIPKU1jpDGimyIPS
=Z5ru
-----END PGP SIGNATURE-----