Just under 7 years ago, I wrote Slow Data. In it, we explored how XMPP on ridiculously slow links had been, and in some cases could be, improved.
This is the follow-up. It's taken 7 years for me to get around to this.
Fitting, I thought.
The Story So Far
Baseline XMPP - which, as we'll show, hardly anyone uses anymore - takes about 12 round-trips to set up the connection:
But, thanks to a whole bunch of work in the community, we had designs, but not implementations, to reduce that to merely three, at least on reconnection:
But this required lots of people to write code for a couple of key extensions - SASL2, specified in XEP-0388 and ISR, specified in XEP-0397.
One of these took, and the other did not.
What happened next
The community picked up SASL2 - which if you read the previous post should put us at 5 round-trips - but didn't pick up any 1-RTT authentication mechanisms, preferring to use SCRAM's better security, which includes Channel Binding.
Channel Binding is a technique for ensuring that the ends of the SASL authentication match the ends of the TLS session. Given that CAs get compromised occasionally, and we've had the occasional state-level attacker target specific XMPP servers, the community understandably prefers to rely on such things.
So we end up with this:
6 round-trips isn't bad, but the community didn't stop there.
First, it invented "Bind2", XEP-0386, which collapsed that last resource binding part into SASL2, wrecking my colour scheme, but saving a round-trip at the end:
Next came FAST, XEP-0484. FAST is a system for issuing short-lived tokens we can then safely use with single-round-trip authentication mechanisms. It adds no round-trips for setup, but reduces reauthentication to a single round-trip:
Finally, we made IAP, XEP-0509, which allows us to entirely safely skip over the first round-trip:
This is now 3 round-trips, which is as good as ISR got us - but it's more general, because ISR relied on session resumption whereas FAST is just token use.
We cannot improve on just a single application-level round-trip, either - that step not only authenticates the client to the server, but the server to the client, too, so we cannot start sending messages until it's complete.
Zero RTT
However, we can look at the round-trips before.
TLSv1.3 has a nifty, but complicated, feature called "Early Data". Usually known as 0RTT, this allows us in principle to jam our one remaining application-level round-trip into the TLS exchange, saving us yet another round-trip.
This is complex, and has ramifications on the security of authentication, so is still in the "research" phase.
Slow, but QUIC
The community now has two distinct experiments inprogress about running XMPP over QUIC. In terms of session establishment, these are identical. QUIC combines the connection setup with TLSv1.3's handshake, meaning we shave a round-trip then, too.
This can be combined with early data, too - meaning that we can open a session and have it ready for use in just a single round-trip - if, of course, we can get it working safely.
I'd do a diagram, but honestly it's just noise with overlapping arrows at this point.
Still Slow
Session establishment is, of course, only one part of the picture. I ended the last part nearly 7 years ago by noting that a 250k JPEG is still a 250k JPEG no matter how much you try.
And even when the session is established, XMPP has to deal with packet loss and reordering, both of which are extra painful under high latency.
But, once established, XMPP is remarkably tolerant to high latency and barely uses bandwidth. And the loss/reordering problems can be mitigated heavily by multi-stream QUIC.
Next year, XMPP turns 25 years old, and remains widely implemented by several open source projects and companies, and used heavily especially when getting the message through is of critical importance.
If you're interested, the conversation is still going strong at the XSF!
Top comments (0)