Re: QUIC(ker)

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 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 <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]