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.
I'm interested in implementing this multiple channels for one xml stream thing in Monal. -tmolitor Am Donnerstag, 29. Januar 2026, 17:02:05 CET schrieb Dave Cridland:
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.
Le 29 janv. 2026 à 11:02, Dave Cridland <dave@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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.
I think we have, with "WebTransport" a real opportunity to specify a proper XMPP-native transport mechanism (no extra framing or use case specific hacks like WebSocket or BOSH, full normal TLS support possible when implemented in a normal client, etc) that happens to also work from browsers (and other things like transit through HTTP proxies and HTTP reverse proxies... at least if they support http3 smelling things). I'm not sure what the "raw" QUIC advantages could be, but I would be strongly in favour of making this a special case MAY with WebTransport handshake support as at least a SHOULD level thing.
On Fri, 30 Jan 2026 at 02:13, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I think we have, with "WebTransport" a real opportunity to specify a proper XMPP-native transport mechanism (no extra framing or use case specific hacks like WebSocket or BOSH, full normal TLS support possible when implemented in a normal client, etc) that happens to also work from browsers (and other things like transit through HTTP proxies and HTTP reverse proxies... at least if they support http3 smelling things).
I'm not sure what the "raw" QUIC advantages could be, but I would be strongly in favour of making this a special case MAY with WebTransport handshake support as at least a SHOULD level thing.
For all the purposes I need QUIC for (and Marc Blanchet, too), having full control over congestion control, keep alives, idle timeouts etc is important. Web Transport doesn't let you tinker in this way. Also, Web Transport adds the HTTP/3 handshake, which is breaking the 0-RTT desire. I think Web Transport might well be great for many cases, but I'm currently focused on low-bandwidth, high-latency, high-loss networks, so for my purposes at least I'm only interested in QUIC itself at this stage. But, solving QUIC should mean that Web Transport is very easy. Dave.
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.
https://xmpp.org/extensions/xep-0487.html is how both QUIC and WebTransport can be discovered, and both are implemented in https://github.com/moparisthebest/xmpp-proxy already, stop by the muc if you want, you can even connect with webtransport or quic now ;) xmpp:xmpp-proxy@code.moparisthe.best?join On January 29, 2026 11:02:05 AM EST, Dave Cridland <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.
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <travis@burtrum.org> wrote:
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So clients can open multiple bi-directional reliable streams, they must be treated as seperate connections but with the same security and authentication? What does "separate connections" mean if they're authenticated the same? Are they the same resource on a C2S? Does the S2S mention suggest that each domain pair MUST (MIGHT?) be on a different stream, and that we SHOULDN'T mix them? I think this needs a massive amount more detail. What I'm working toward is where we want to send to 5 different entities, we can - as a trivial degenerate case - connect via C2S, pass through SASL, open up 4 additional QUIC streams, and then send to each remote entity over a different QUIC stream, so that if a packet is lost the HoL blocking only affects the one stream. The more generalised idea is that given any stanza, if we take the bare jids of both to and from, then this pair must map to only a single stream at a time (and you actually need XEP-0198 in effect to switch streams reliably without messing up the ordering on the switch). I'm going to get some `tc` stuff up and running and experiment, but I think this is roughly the algorithm that'll work best on the low-bandwidth, high-latency, high-loss networks I'm targeting. Dave.
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave@cridland.net> wrote:
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <travis@burtrum.org> wrote:
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So clients can open multiple bi-directional reliable streams, they must be treated as seperate connections but with the same security and authentication? What does "separate connections" mean if they're authenticated the same? Are they the same resource on a C2S? Does the S2S mention suggest that each domain pair MUST (MIGHT?) be on a different stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
The same security and authentication of the TLS negotiation, so if you are a client with a connection to a server with a cert you trust that is good for bob.com and tom.com you can open new quic streams for any number of accounts on those domains. But not google.com. tl;dr only trust your TLS auth when deciding if you can use the connection for this domain. (different XEPs and RFCs might change the way you trust of course) The server just treats them as entirely seperate connections. so you are free to log in for a session per domain with smacks each if you want.
On Sun, 5 Apr 2026 at 04:49, Travis Burtrum <travis@burtrum.org> wrote:
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave@cridland.net> wrote:
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <travis@burtrum.org> wrote:
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So clients can open multiple bi-directional reliable streams, they must be treated as seperate connections but with the same security and authentication? What does "separate connections" mean if they're authenticated the same? Are they the same resource on a C2S? Does the S2S mention suggest that each domain pair MUST (MIGHT?) be on a different stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
The same security and authentication of the TLS negotiation, so if you are a client with a connection to a server with a cert you trust that is good for bob.com and tom.com you can open new quic streams for any number of accounts on those domains. But not google.com. tl;dr only trust your TLS auth when deciding if you can use the connection for this domain. (different XEPs and RFCs might change the way you trust of course)
So they go through SASL etc and form a complete XMLStream on each connection, under your model? For client sessions, this would mean multiple resources? This seems very wasteful. Dave.
On April 5, 2026 3:50:36 AM EDT, Dave Cridland <dave@cridland.net> wrote:
On Sun, 5 Apr 2026 at 04:49, Travis Burtrum <travis@burtrum.org> wrote:
On April 4, 2026 5:23:40 PM EDT, Dave Cridland <dave@cridland.net> wrote:
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <travis@burtrum.org> wrote:
Nothing in the current XEP https://xmpp.org/extensions/xep-0467.html forbids multiple streams, in fact it mentions it directly
Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.
I took this to mean ... well, actually I'm not sure what this means. So clients can open multiple bi-directional reliable streams, they must be treated as seperate connections but with the same security and authentication? What does "separate connections" mean if they're authenticated the same? Are they the same resource on a C2S? Does the S2S mention suggest that each domain pair MUST (MIGHT?) be on a different stream, and that we SHOULDN'T mix them?
I think this needs a massive amount more detail.
The same security and authentication of the TLS negotiation, so if you are a client with a connection to a server with a cert you trust that is good for bob.com and tom.com you can open new quic streams for any number of accounts on those domains. But not google.com. tl;dr only trust your TLS auth when deciding if you can use the connection for this domain. (different XEPs and RFCs might change the way you trust of course)
So they go through SASL etc and form a complete XMLStream on each connection, under your model? For client sessions, this would mean multiple resources? This seems very wasteful.
Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
On Sun, 5 Apr 2026 at 13:19, Travis Burtrum <travis@burtrum.org> wrote:
Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119? Let me give you a concrete case: I have a client that has some 1:1, but primarily it has several chatrooms. The network is what I'll describe as "dodgy" - it's low bandwidth, high latency, and has high degrees of packet loss occurring in bursts. When I send to a chatroom - or receive from one - the packet might therefore be lost, and need retransmission. When this occurs, all other stanzas occurring afterward need to wait for the missing packet to be retransmitted successfully. QUIC addresses this by allowing multiple streams, so by following this architecture and sending stanzas which are order-independent on different streams, I could change the last sentence to be qualified: "... all other stanzas to the same chatroom ...", which is much better. On networks which are not "dodgy", it's still useful to any C2S connection. But the only way to accomplish this in the XEP is to open multiple independent client streams within the same connection, which gives little to no advantage over simply opening multiple connections, and - at least in C2S - seems very niche. Introduce Carbons (and we must introduce Carbons) and it's actively harmful. In S2S, we could open multiple streams, one for each domain pair, as long as the TLS certs hold. But we can already do that via piggybacking and bidi, anyway - the advantage to S2S here is to avoid the HoL blocking, and that's very useful indeed. But, it could easily be made better by splitting channels based on bare-jid pair instead of simply at the domain-pair level, which is what I want to do at the C2S level as well. To my mind, HoL blocking is the primary use-case for multiple streams, and supporting multiple authenticated entities via the same connection seems problematic, and gets wildly complicated when we want to (for example) use additional streams for media, or file transfer, or ... So, summary: Authentication should be tied to a QUIC connection, not a QUIC stream, and we should be using streams to reduce HoL blocking. I'd appreciate other people's view here. Dave.
I appreciate this use case, but another one is you have N accounts served by the same server and can connect all of them over the same QUIC connection. Another is 1 stream for 1:1 with carbons and another per MUC where you don't even send an account presence. So I'd for sure like to keep those available, for yours I'd suggest something like a new XEP where the server sends a long random token on login you can send on new streams to shortcut normal login dance and request a filter for stanza JIDs or so. On April 7, 2026 6:40:46 AM EDT, Dave Cridland <dave@cridland.net> wrote:
On Sun, 5 Apr 2026 at 13:19, Travis Burtrum <travis@burtrum.org> wrote:
Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119?
Let me give you a concrete case:
I have a client that has some 1:1, but primarily it has several chatrooms. The network is what I'll describe as "dodgy" - it's low bandwidth, high latency, and has high degrees of packet loss occurring in bursts.
When I send to a chatroom - or receive from one - the packet might therefore be lost, and need retransmission. When this occurs, all other stanzas occurring afterward need to wait for the missing packet to be retransmitted successfully.
QUIC addresses this by allowing multiple streams, so by following this architecture and sending stanzas which are order-independent on different streams, I could change the last sentence to be qualified: "... all other stanzas to the same chatroom ...", which is much better. On networks which are not "dodgy", it's still useful to any C2S connection.
But the only way to accomplish this in the XEP is to open multiple independent client streams within the same connection, which gives little to no advantage over simply opening multiple connections, and - at least in C2S - seems very niche. Introduce Carbons (and we must introduce Carbons) and it's actively harmful. In S2S, we could open multiple streams, one for each domain pair, as long as the TLS certs hold. But we can already do that via piggybacking and bidi, anyway - the advantage to S2S here is to avoid the HoL blocking, and that's very useful indeed. But, it could easily be made better by splitting channels based on bare-jid pair instead of simply at the domain-pair level, which is what I want to do at the C2S level as well.
To my mind, HoL blocking is the primary use-case for multiple streams, and supporting multiple authenticated entities via the same connection seems problematic, and gets wildly complicated when we want to (for example) use additional streams for media, or file transfer, or ...
So, summary: Authentication should be tied to a QUIC connection, not a QUIC stream, and we should be using streams to reduce HoL blocking.
I'd appreciate other people's view here.
Dave.
The use case of multiple accounts served by the same server doesn't feel common at all for c2s, and it is not clear to me why a client couldn't just initiate multiple QUIC connections instead. If we indeed get to 0-RT reconnects, that should be just fine. Binding (bare JID) identity to the QUIC connections seems extremely desirable to me for your other use case and the ones that Dave mentioned. It also makes it much easier to have "oob" data streams (calls or file transfer or whatever) authenticated, without requiring tokens. I think the latter would be more common use cases than multiple accounts, so I'd rather optimize for this. -- ralphm On 11 April 2026 00:14:47 CEST, Travis Burtrum <travis@burtrum.org> wrote:
I appreciate this use case, but another one is you have N accounts served by the same server and can connect all of them over the same QUIC connection.
Another is 1 stream for 1:1 with carbons and another per MUC where you don't even send an account presence.
So I'd for sure like to keep those available, for yours I'd suggest something like a new XEP where the server sends a long random token on login you can send on new streams to shortcut normal login dance and request a filter for stanza JIDs or so.
On April 7, 2026 6:40:46 AM EDT, Dave Cridland <dave@cridland.net> wrote:
On Sun, 5 Apr 2026 at 13:19, Travis Burtrum <travis@burtrum.org> wrote:
Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119?
Let me give you a concrete case:
I have a client that has some 1:1, but primarily it has several chatrooms. The network is what I'll describe as "dodgy" - it's low bandwidth, high latency, and has high degrees of packet loss occurring in bursts.
When I send to a chatroom - or receive from one - the packet might therefore be lost, and need retransmission. When this occurs, all other stanzas occurring afterward need to wait for the missing packet to be retransmitted successfully.
QUIC addresses this by allowing multiple streams, so by following this architecture and sending stanzas which are order-independent on different streams, I could change the last sentence to be qualified: "... all other stanzas to the same chatroom ...", which is much better. On networks which are not "dodgy", it's still useful to any C2S connection.
But the only way to accomplish this in the XEP is to open multiple independent client streams within the same connection, which gives little to no advantage over simply opening multiple connections, and - at least in C2S - seems very niche. Introduce Carbons (and we must introduce Carbons) and it's actively harmful. In S2S, we could open multiple streams, one for each domain pair, as long as the TLS certs hold. But we can already do that via piggybacking and bidi, anyway - the advantage to S2S here is to avoid the HoL blocking, and that's very useful indeed. But, it could easily be made better by splitting channels based on bare-jid pair instead of simply at the domain-pair level, which is what I want to do at the C2S level as well.
To my mind, HoL blocking is the primary use-case for multiple streams, and supporting multiple authenticated entities via the same connection seems problematic, and gets wildly complicated when we want to (for example) use additional streams for media, or file transfer, or ...
So, summary: Authentication should be tied to a QUIC connection, not a QUIC stream, and we should be using streams to reduce HoL blocking.
I'd appreciate other people's view here.
Dave.
Multiple accounts on the same server is common, eg for people with more than one phone number from jmp.chat You need protocol to have bare JID bound to the quic connection anyway, so we can have both. Though the only thing spec'd and implemented now is each stream is independent which doesn't need protocol. On April 11, 2026 1:52:00 AM EDT, Ralph Meijer <ralphm@ik.nu> wrote:
The use case of multiple accounts served by the same server doesn't feel common at all for c2s, and it is not clear to me why a client couldn't just initiate multiple QUIC connections instead. If we indeed get to 0-RT reconnects, that should be just fine.
Binding (bare JID) identity to the QUIC connections seems extremely desirable to me for your other use case and the ones that Dave mentioned. It also makes it much easier to have "oob" data streams (calls or file transfer or whatever) authenticated, without requiring tokens.
I think the latter would be more common use cases than multiple accounts, so I'd rather optimize for this.
-- ralphm
On 11 April 2026 00:14:47 CEST, Travis Burtrum <travis@burtrum.org> wrote:
I appreciate this use case, but another one is you have N accounts served by the same server and can connect all of them over the same QUIC connection.
Another is 1 stream for 1:1 with carbons and another per MUC where you don't even send an account presence.
So I'd for sure like to keep those available, for yours I'd suggest something like a new XEP where the server sends a long random token on login you can send on new streams to shortcut normal login dance and request a filter for stanza JIDs or so.
On April 7, 2026 6:40:46 AM EDT, Dave Cridland <dave@cridland.net> wrote:
On Sun, 5 Apr 2026 at 13:19, Travis Burtrum <travis@burtrum.org> wrote:
Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119?
Let me give you a concrete case:
I have a client that has some 1:1, but primarily it has several chatrooms. The network is what I'll describe as "dodgy" - it's low bandwidth, high latency, and has high degrees of packet loss occurring in bursts.
When I send to a chatroom - or receive from one - the packet might therefore be lost, and need retransmission. When this occurs, all other stanzas occurring afterward need to wait for the missing packet to be retransmitted successfully.
QUIC addresses this by allowing multiple streams, so by following this architecture and sending stanzas which are order-independent on different streams, I could change the last sentence to be qualified: "... all other stanzas to the same chatroom ...", which is much better. On networks which are not "dodgy", it's still useful to any C2S connection.
But the only way to accomplish this in the XEP is to open multiple independent client streams within the same connection, which gives little to no advantage over simply opening multiple connections, and - at least in C2S - seems very niche. Introduce Carbons (and we must introduce Carbons) and it's actively harmful. In S2S, we could open multiple streams, one for each domain pair, as long as the TLS certs hold. But we can already do that via piggybacking and bidi, anyway - the advantage to S2S here is to avoid the HoL blocking, and that's very useful indeed. But, it could easily be made better by splitting channels based on bare-jid pair instead of simply at the domain-pair level, which is what I want to do at the C2S level as well.
To my mind, HoL blocking is the primary use-case for multiple streams, and supporting multiple authenticated entities via the same connection seems problematic, and gets wildly complicated when we want to (for example) use additional streams for media, or file transfer, or ...
So, summary: Authentication should be tied to a QUIC connection, not a QUIC stream, and we should be using streams to reduce HoL blocking.
I'd appreciate other people's view here.
Dave.
On Sat, 25 Apr 2026 at 19:35, Travis Burtrum <travis@burtrum.org> wrote:
Multiple accounts on the same server is common, eg for people with more than one phone number from jmp.chat
I'm sure it happens, but I imagine it happens considerably less than a single account talking to multiple people.
You need protocol to have bare JID bound to the quic connection anyway, so we can have both. Though the only thing spec'd and implemented now is each stream is independent which doesn't need protocol.
As noted elsewhere, I've implemented a PoC for multi-stream QUIC, and a PR against XEP-0467 for it. Would appreciate your comments/feedback. I would note that I'm actually running discovery via SRV records; I'm not keen on the idea of using an HTTP call to get the connection details, and haven't revisited SVCB for XMPP yet - though I probably should. I've deliberately not included this SRV discovery in the spec, I think that's entirely orthogonal. Dave.
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 <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.
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@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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Sat, 4 Apr 2026 at 14:10, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
Coooool!
Which QUIC stack(s) are you using?
Quiche in Netty - this is Openfire.
I'll be interested in testing it out first under normal conditions and then see how it behaves in high delay environments (space)
I've not yet pushed it, but will do hopefully today. Dave.
Le 4 avr. 2026 à 09:12, Dave Cridland <dave@cridland.net> a écrit :
On Sat, 4 Apr 2026 at 14:10, Marc Blanchet <marc.blanchet@viagenie.ca <mailto:marc.blanchet@viagenie.ca>> wrote:
Coooool!
Which QUIC stack(s) are you using?
Quiche in Netty - this is Openfire.
Good. Quiche has been updated to expose the hooks necessary for space, with only one exception: a new congestion controller can not be added when using Quiche as a library, so one has to do a fork. (Quinn on the other hand enables adding a new congestion controller without having to do a fork). In space, standard congestion controllers don't work well when there is intermittence. Regards, Marc.
I'll be interested in testing it out first under normal conditions and then see how it behaves in high delay environments (space)
I've not yet pushed it, but will do hopefully today.
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (6)
-
Dave Cridland -
Marc Blanchet -
Ralph Meijer -
Stephen Paul Weber -
Thilo Molitor -
Travis Burtrum