Le 29 janv. 2026 à 11:02, Dave Cridland
<dave(a)cridland.net> a écrit :
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low bandwidth.
I'm not sure we'll get to this at the Summit, and there's not many who want to
talk about it so I wondered if this summit topic could have been an email. (Except then we
discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the wire - are
round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation we don't
worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss causes the
stream to stall until the packet is retransmitted, which is at least a round-trip away -
and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending stanzas over UDP
directly) because if we do that we lose the ordering. Out of order messages can be
confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we normally worry
about - normally, we just process everything on a strea, in order, and this does satisfy
the rules. But the rules allow us to process stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such that we
open multiple channels on both C2S and S2S sessions, which would form part of the same
virtual stream, and we can distribute messages such that we maintain ordering within
messages where we need to, but allows us to out-of-order (and avoid HOL Blocking) messages
sent between unrelated jids.
This differs to the existing XEP, where each channel maps to a single XML Stream and XMPP
session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as well,
so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Yes. As Peter St-Andre and I started a thread some time ago, our use case is (deep) space
messaging/chat where latency is significant, but QUIC can be configured to work very well
in this environment. If we have a good spec, I'll have my team implement it using the
Quinn QUIC stack and simulate it on our (deep space) testbed.
Regards, Marc.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org