> Le 29 janv. 2026 à 11:02, Dave Cridland <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
