Re: QUIC(ker)

Dave Cridland <[email protected]> Sat, 4 Apr 2026 22:23:40 +0100
Newsgroups gmane.network.jabber.standards-jig
Message-ID <CAKHUCzx=sT9vW0sydPx=h=fsS4pTrwBx1kroehtu8z=uVes3hA@mail.gmail.com>
On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <[email protected]> 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.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]