Coooool!
Which QUIC stack(s) are you using?
I'll be interested in testing it out first under normal conditions and then see how it
behaves in high delay environments (space)
Regards, Marc.
Le 4 avr. 2026 à 08:52, Dave Cridland
<dave(a)cridland.net> a écrit :
A little update:
I've implemented a very rough bit of support for single-channel, C2S only, QUIC in
Openfire, and similar in Wimsy so I can actually use it.
It... works? But it also does very little of any interest, so is probably not interesting
to anyone outside of implementers. If you are one, ping me for a test account.
I've added a SRV to
_xmpp-client._quic.dave.cridland.net
<http://quic.dave.cridland.net/> for discovery; while XEP-0487 is an option that
still feels very ikky.
I'll go reply to all the messages on this thread now with specifics, sorry!
Dave.
On Thu, 29 Jan 2026 at 16:02, Dave Cridland <dave(a)cridland.net
<mailto:dave@cridland.net>> wrote:
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?
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org