On Fri, 15 Feb 2008, Dave Cridland wrote: > > 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.
3920bis already has some nice examples which provide a great starting point for round-trip optimization. XMPP's connection setup is very similar to SMTP's, so I don't think it would be all that difficult to adapt quickstart. There are a few significant differences, though: (1) In XMPP the client speaks first. This is a win for XMPP compared to SMTP, since it allows the client to piggyback useful information in the first data-carrying packet of the TCP connection. SMTP requires evil hacks to persuade paranoid servers not to reject clients that want to speak earlier than is traditional. (2) The XMPP server includes the stream features in its first utterance, which is again a win for XMPP compared to SMTP - no wasted round trip for EHLO. (3) XMPP has resource binding, which is a lose compared to SMTP - an extra round trip. More about this below. The essence of my quickstart extension was to work out a safe way of pipelining as much of the initial protocol negotiation as possible. I'm not so familiar with XMPP as SMTP, but I don't remember RFC 3920 saying much about pipelining. Is there anything to prevent a connection startup along the following lines? C: <stream> <starttls/> <!-- hope for the best --> S: <stream> <features/> <proceed/> <!-- the bet paid off --> C: TLS hello S: TLS stuff C: TLS again <!-- with a TLS session cache the client could even start talking now --> S: TLS finish <stream> <!-- hey that's a bit presumptuous --> <features/> C: <stream> <!-- but the client always asks for a stream --> <auth mechanism="PLAIN">BASE64</auth> <stream> <!-- really sure that password is right --> <iq><bind/></iq> <!-- keen as mustard --> <presence/> <!-- if all goes well ... --> S: <stream> <!-- ... the man from del monte says yes --> <features/> <success/> <stream> <features/> <iq><bind><jid/></bind></iq> For really tight optimisation, I expect the trickiest part will be dealing with the stream restart after SASL negotiation, especially when there is a failure. The simplest solution is to require a round trip at that point. Otherwise you'd have to introduce a new error response to deal gracefully with what looks to the server like an attempt to nest streams after a SASL failure, when the client expected a stream restart after a SASL success. Resource binding is interesting because either end can choose the resource. It's much easier to pipeline if the client specifies it, since that means it doesn't have to wait for information from the server. How common is it for clients to let servers choose their resource? Latency-sensitive clients should be encouraged not to. The pipelined session above is 4 round trips, compared to 8 in 3920bis section 10. It could be reduced to 3 with a TLS session cache. If you are willing to specify some stunt buffer handling then it is possible to shift the TLS hello into the client's first packet and save another round trip. However this requires some really quite tricky juggling of the XML and TLS layering which might not even be possible on many platforms. I'm not going to the devcon, I'm afraid, nor am I planning to go to any IETFs in the near future. (Dublin would have been tempting if the location weren't nearly as far away from the city centre as Cork.) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ GERMAN BIGHT: EAST VEERING SOUTHWEST 3 OR 4, OCCASIONALLY 5 LATER. MODERATE. FAIR. GOOD.