[{"author": "Martin Thomson", "text": "

I'm enjoying the disco

", "time": "2025-06-02T21:06:03Z"}, {"author": "Martin Thomson", "text": "

fooQ, right?

", "time": "2025-06-02T21:16:54Z"}, {"author": "Marco Munizaga", "text": "

echo

", "time": "2025-06-02T21:17:06Z"}, {"author": "Piotr Sikora", "text": "

IMHO, address migration would be very useful for migrating between QUIC-over-UDP and QUIC-over-TCP when moving to a network that blocks UDP.

", "time": "2025-06-02T21:17:08Z"}, {"author": "Guillaume Hetier", "text": "

Can you clarify if the bullet point about TLS being \"optional\" means that QMux would provide TLS if needed, or if it means the underlying transport would be responsible for providing encryption/authentication if the app needs it?

", "time": "2025-06-02T21:18:53Z"}, {"author": "Guillaume Hetier", "text": "

IMO, it would be interesting if QMux could bring TLS on top of a reliable but not encrypted / authenticated transport.

", "time": "2025-06-02T21:19:40Z"}, {"author": "Marco Munizaga", "text": "

My understanding is that it's the latter. The transport needs to add the TLS layer.

", "time": "2025-06-02T21:20:06Z"}, {"author": "Willy Tarreau", "text": "

ALPN could still be \"h3\" for H3 over QMUX as it's still possible to distinguish between ALPN from QUIC and ALPN in TLS over TCP.

", "time": "2025-06-02T21:22:34Z"}, {"author": "Matt Joras", "text": "

Could there be an argument to having a Qmux and Qmux-TLS as separate documents?

", "time": "2025-06-02T21:22:42Z"}, {"author": "Matt Joras", "text": "

i.e., like how RFC 9001 specifies how TLS works, you could have a document that specifies how to do Qmux over TLS1.3 over blah

", "time": "2025-06-02T21:23:29Z"}, {"author": "Nick Banks", "text": "

I think having separate docs would be ok, but then, I think we'd need to do both together, like we did with QUIC.

", "time": "2025-06-02T21:24:12Z"}, {"author": "Matt Joras", "text": "

yeah I agree that would make the most sense

", "time": "2025-06-02T21:25:22Z"}, {"author": "Martin Thomson", "text": "

we have an early implementation of webtransport over h2, I believe

", "time": "2025-06-02T21:26:15Z"}, {"author": "Alan Frindell", "text": "

we're working on it!

", "time": "2025-06-02T21:26:24Z"}, {"author": "Matt Joras", "text": "

If qmux is successful then an implementation deleting webtransport over HTTP/2 would be \"fine\" if then WebTransport-over-qmux became a thing?

", "time": "2025-06-02T21:27:28Z"}, {"author": "Alan Frindell", "text": "

FWIW our moq implementation is the same as Victor's -- it's written against our C++ WebTransport API with an H3 and native QUIC implementations

", "time": "2025-06-02T21:27:51Z"}, {"author": "Martin Thomson", "text": "

If that's a question, the answer is probably \"no\". Or at least it isn't that simple.

", "time": "2025-06-02T21:27:57Z"}, {"author": "Will Hawkins", "text": "

Not to sound needy, but if someone could help notetaking, I would appreciate it -- my $DAYJOB is still asking for my eyes and I am worried about missing things!

", "time": "2025-06-02T21:28:36Z"}, {"author": "Will Hawkins", "text": "

THANK YOU!

", "time": "2025-06-02T21:29:39Z"}, {"author": "Marco Munizaga", "text": "

I can help as well

", "time": "2025-06-02T21:29:46Z"}, {"author": "Will Hawkins", "text": "

THANK YOU ALAN!

", "time": "2025-06-02T21:29:49Z"}, {"author": "Will Hawkins", "text": "

and MARCO.

", "time": "2025-06-02T21:29:52Z"}, {"author": "Martin Thomson", "text": "

It was Matt's

", "time": "2025-06-02T21:30:52Z"}, {"author": "Martin Thomson", "text": "

Migration is hard

", "time": "2025-06-02T21:30:57Z"}, {"author": "Victor Vasiliev", "text": "

@matt I would personally not object conceptually to rebasing WT/H2 to QMux, but the problem is, WT/H2 draft is further along than QMux is

", "time": "2025-06-02T21:31:08Z"}, {"author": "Matt Joras", "text": "

Chrome deleted PUSH

", "time": "2025-06-02T21:31:09Z"}, {"author": "Martin Thomson", "text": "

Right. We're probably OK to remove webtransport today given the relative amount of adoption. At some point, that's not an option.

", "time": "2025-06-02T21:31:32Z"}, {"author": "Kazuho Oku", "text": "

and we deprecated the old prioritization

", "time": "2025-06-02T21:31:36Z"}, {"author": "Martin Thomson", "text": "

Again, prioritization was relatively easy to remove because no one really used it (Alan being the only one)

", "time": "2025-06-02T21:32:01Z"}, {"author": "Victor Vasiliev", "text": "

Again, if we (=Google QUICHE) were to implement QMux, it would most likely just expose WebTransport API

", "time": "2025-06-02T21:32:02Z"}, {"author": "Alan Frindell", "text": "

I'm in my new room and can handle notes starting with the next speaker

", "time": "2025-06-02T21:32:35Z"}, {"author": "Lucas Pardue", "text": "

MT are you saying that qmux should work to an aggresive shcedule

", "time": "2025-06-02T21:33:45Z"}, {"author": "Matt Joras", "text": "

Yeah I was more thinking what would happen if we theoretically got a qmux document out within a year?

", "time": "2025-06-02T21:34:14Z"}, {"author": "Willy Tarreau", "text": "

I implemented H2 in haproxy and still maintain it, and IMHO it is a rushed design with lots of flaws. I would love to be able to get rid of it!

", "time": "2025-06-02T21:36:44Z"}, {"author": "Martin Thomson", "text": "

yes, webtransport over h2 relies on the stream semantics

", "time": "2025-06-02T21:37:04Z"}, {"author": "Martin Thomson", "text": "

webtransport over h2 works over HTTP/1.1 as well, as far as I can see

", "time": "2025-06-02T21:37:40Z"}, {"author": "Alan Frindell", "text": "

Are we haggling about the differences between qmux frame definitions and wt/h2 capsules?

", "time": "2025-06-02T21:38:42Z"}, {"author": "Martin Thomson", "text": "

Ian's point is interesting. Can someone perhaps look at what the difference between the two would be and see if the gap isn't compatible?

", "time": "2025-06-02T21:41:28Z"}, {"author": "Victor Vasiliev", "text": "

I will note that MoQ added length on control streams because it simplifies parsting

", "time": "2025-06-02T21:41:52Z"}, {"author": "Alan Frindell", "text": "

The length field is one difference, the code points are different, and I think RESET_STREAM always has a reliable offset

", "time": "2025-06-02T21:41:59Z"}, {"author": "Victor Vasiliev", "text": "

(parsing QUIC is easier than parsing varints from stream since QUIC packets are finite)

", "time": "2025-06-02T21:42:12Z"}, {"author": "Victor Vasiliev", "text": "

s/finite/received all-at-once/

", "time": "2025-06-02T21:42:26Z"}, {"author": "Mirja K\u00fchlewind", "text": "

It sounds like webtransport over H2 is more overhead not only in term of bits but also implementation complexity but yes it would be interesting to understand the differences in more detail.

", "time": "2025-06-02T21:44:12Z"}, {"author": "Martin Thomson", "text": "

Is there any real difference between what webtransport and qmux need?

", "time": "2025-06-02T21:44:57Z"}, {"author": "Kazuho Oku", "text": "

webtransport needs HTTP?

", "time": "2025-06-02T21:45:11Z"}, {"author": "Martin Thomson", "text": "

that's on the outside

", "time": "2025-06-02T21:45:18Z"}, {"author": "Matt Joras", "text": "

yeah, HTTP is the main thing

", "time": "2025-06-02T21:45:18Z"}, {"author": "Willy Tarreau", "text": "

I think WT provides to H2 what QMux already provides without having to go over HTTP.

", "time": "2025-06-02T21:45:41Z"}, {"author": "Martin Thomson", "text": "

the webtransport-h2 has two parts: the negotiation of what happens in the stream; and, what happens to negotiate the stream

", "time": "2025-06-02T21:45:49Z"}, {"author": "Marco Munizaga", "text": "

@Kazuho Oku Can you repeat the last point you made around a transport built over h2? I missed this in the notes.

", "time": "2025-06-02T21:46:05Z"}, {"author": "Kazuho Oku", "text": "

@Marco Thank you for taking notes. Did I answer verbally?

", "time": "2025-06-02T21:48:09Z"}, {"author": "Nick Banks", "text": "

Are there any transports that people are looking to use QMUX over that already have encryption/authentication that aren't TLS?

", "time": "2025-06-02T21:48:41Z"}, {"author": "Marco Munizaga", "text": "

yes, thanks

", "time": "2025-06-02T21:49:02Z"}, {"author": "Marco Munizaga", "text": "

@Nick Banks yes. I would use it over a Noise encrypted TCP connection.

", "time": "2025-06-02T21:50:11Z"}, {"author": "Nick Banks", "text": "

@Marco thanks for the feedback. The reason I asked is because it seems simpler to leverage what QUIC already has for TLS.

", "time": "2025-06-02T21:51:59Z"}, {"author": "Nick Banks", "text": "

Maybe a follow up question for you @Marco: Are you interested in a QUIC w/ Noise?

", "time": "2025-06-02T21:52:41Z"}, {"author": "Victor Vasiliev", "text": "

We support webtransport over raw QUIC to support MoQ over raw QUIC

", "time": "2025-06-02T21:53:57Z"}, {"author": "Alan Frindell", "text": "

The old \"QuicTransport\" draft defined a frame for sending PATH etc. MoQ has its own \"SETUP\" messages that convey this

", "time": "2025-06-02T21:55:04Z"}, {"author": "Marco Munizaga", "text": "

Yes, I think it makes sense for the QUIC wg to work on this.

", "time": "2025-06-02T21:56:45Z"}, {"author": "Nick Banks", "text": "

I think this is a good use of the WG's time

", "time": "2025-06-02T21:56:59Z"}, {"author": "Ian Swett", "text": "

+1

", "time": "2025-06-02T21:57:13Z"}, {"author": "Guillaume Hetier", "text": "

+1

", "time": "2025-06-02T21:57:26Z"}, {"author": "Marco Munizaga", "text": "

Nick Banks said:

\n
\n

Maybe a follow up question for you @Marco: Are you interested in a QUIC w/ Noise?

\n
\n

Not particularly.

", "time": "2025-06-02T21:57:30Z"}, {"author": "Will Hawkins", "text": "

+1

", "time": "2025-06-02T21:57:42Z"}, {"author": "Willy Tarreau", "text": "

+1

", "time": "2025-06-02T21:57:49Z"}, {"author": "Martin Thomson", "text": "

:wave:

", "time": "2025-06-02T22:00:19Z"}, {"author": "Willy Tarreau", "text": "

Maybe when the original charter was written, it was not yet very clear that there were two QUIC layers: transport and multiplexing. It's possible that simply clarifying this point makes any change to the multiplexing layer applicable to any of these two areas after all.

", "time": "2025-06-02T22:08:24Z"}, {"author": "Alan Frindell", "text": "

I like that Willy

", "time": "2025-06-02T22:09:15Z"}, {"author": "Martin Duke", "text": "

I think #1 is good

", "time": "2025-06-02T22:09:58Z"}, {"author": "Kazuho Oku", "text": "

+1 to Willy

", "time": "2025-06-02T22:10:25Z"}, {"author": "Victor Vasiliev", "text": "

I wouldn't say it wasn't clear (I suggested splitting RFC 9000 into two docs along those lines), but there wasn't enough appetite at that point

", "time": "2025-06-02T22:10:34Z"}, {"author": "Victor Vasiliev", "text": "

I feel like 4 would be a bit of putting a cart before the horse given the discussion we had during the previous hour

", "time": "2025-06-02T22:13:24Z"}, {"author": "Lucas Pardue", "text": "

I tend to agree victor

", "time": "2025-06-02T22:13:39Z"}, {"author": "Ian Swett", "text": "

What is QUIC?

", "time": "2025-06-02T22:14:40Z"}, {"author": "Ian Swett", "text": "

+1 to Willy's comments that a driving use case might be helpful

", "time": "2025-06-02T22:15:47Z"}, {"author": "Alan Frindell", "text": "

Willy's comment sounds somewhat like #2? compatibility of QUIC in different deployment scenarios?

", "time": "2025-06-02T22:16:16Z"}, {"author": "Alan Frindell", "text": "

There's value in QMux even if the HTTP over QMux effort drags on. I don't want to couple them

", "time": "2025-06-02T22:17:06Z"}, {"author": "Kazuho Oku", "text": "

Re charter, maybe something like \"Provide substrate compatible with QUIC to applications running on other transport protocols\"

", "time": "2025-06-02T22:17:11Z"}, {"author": "Ian Swett", "text": "

I have more appetite now than I did then

", "time": "2025-06-02T22:17:27Z"}, {"author": "Victor Vasiliev", "text": "

To follow up a bit on what I've said before, the problem here is \"bridge applications that are written against QUIC API with TCP\", but QUIC intentionally does not define the API

", "time": "2025-06-02T22:18:20Z"}, {"author": "Kazuho Oku", "text": "

Yes, it's the semantics to application that QUIC provides

", "time": "2025-06-02T22:18:59Z"}, {"author": "Ian Swett", "text": "

In theory, yes

", "time": "2025-06-02T22:20:35Z"}, {"author": "Willy Tarreau", "text": "

UNIX sockets

", "time": "2025-06-02T22:20:39Z"}, {"author": "Gorry Fairhurst", "text": "

I love Ian's not too vague ... not too specific :-)

", "time": "2025-06-02T22:20:41Z"}, {"author": "Matt Joras", "text": "

also RDMA is hot again

", "time": "2025-06-02T22:20:49Z"}, {"author": "Ian Swett", "text": "

+1 to Unix Sockets for sure

", "time": "2025-06-02T22:20:58Z"}, {"author": "Ian Swett", "text": "

To be not vague

", "time": "2025-06-02T22:21:06Z"}, {"author": "Ian Swett", "text": "

But there are other options that might be relevant

", "time": "2025-06-02T22:21:22Z"}, {"author": "Will Hawkins", "text": "

I've been implementing over RDMA

", "time": "2025-06-02T22:21:22Z"}, {"author": "Will Hawkins", "text": "

In particular, RDMA over WAN.

", "time": "2025-06-02T22:21:35Z"}, {"author": "Victor Vasiliev", "text": "

I may or may not want to put QUIC over QUIC streams

", "time": "2025-06-02T22:21:51Z"}, {"author": "Alan Frindell", "text": "

Victor's MTU rapidly approaching 2

", "time": "2025-06-02T22:22:17Z"}, {"author": "Matt Joras", "text": "

I would hope no one would \"want\" to do that :)

", "time": "2025-06-02T22:22:22Z"}, {"author": "Willy Tarreau", "text": "

+1 to forward QUIC frames, that clearly explains the current limitation, where QUIC remains as the door and everything else is done over HTTP.

", "time": "2025-06-02T22:22:39Z"}, {"author": "Nick Banks", "text": "

RDMA+QMUX is very interesting to us

", "time": "2025-06-02T22:22:56Z"}, {"author": "Victor Vasiliev", "text": "

Why not? That's perfectly reasonable if you want to terminate QUIC at the edge but have backend do stream-level semantics

", "time": "2025-06-02T22:23:03Z"}, {"author": "Marco Munizaga", "text": "

Victor Vasiliev said:

\n
\n

I may or may not want to put QUIC over QUIC streams

\n
\n

Maybe a way of implementing Stream groups? https://datatracker.ietf.org/doc/html/draft-seemann-quic-stream-groups. Seems interesting

", "time": "2025-06-02T22:23:16Z"}, {"author": "Victor Vasiliev", "text": "

(other designs run into nested flow control pains)

", "time": "2025-06-02T22:23:19Z"}, {"author": "Ian Swett", "text": "

Again, +1 to the idea that QUIC is a lot of functionality

", "time": "2025-06-02T22:23:45Z"}, {"author": "Matt Joras", "text": "

Victor: to be clear I'm just saying that doing Thing-over-Thing when the things are the same thing is often a thing that is unpleasant to do

", "time": "2025-06-02T22:23:53Z"}, {"author": "Matt Joras", "text": "

not that it isn't the best thing to do given other alternatives :)

", "time": "2025-06-02T22:24:09Z"}, {"author": "Ian Swett", "text": "

Yes

", "time": "2025-06-02T22:24:58Z"}, {"author": "Alan Frindell", "text": "

HTTP over QMux is clearly in scope for http wg not quic I would assume

", "time": "2025-06-02T22:25:59Z"}, {"author": "Kazuho Oku", "text": "

+1

", "time": "2025-06-02T22:26:08Z"}, {"author": "Alan Frindell", "text": "

+1 Martin

", "time": "2025-06-02T22:27:02Z"}, {"author": "Ian Swett", "text": "

SGTm

", "time": "2025-06-02T22:27:13Z"}, {"author": "Ian Swett", "text": "

Agreed. The more HTTP versions, the more risk

", "time": "2025-06-02T22:28:24Z"}, {"author": "Alan Frindell", "text": "

Have we tried 0 HTTP versions?

", "time": "2025-06-02T22:28:48Z"}, {"author": "Kazuho Oku", "text": "

we've tried 0.9

", "time": "2025-06-02T22:29:10Z"}, {"author": "Alan Frindell", "text": "

haha

", "time": "2025-06-02T22:29:16Z"}, {"author": "Willy Tarreau", "text": "

Thanks Lucas for better explaining than me :-)

", "time": "2025-06-02T22:30:36Z"}, {"author": "Marco Munizaga", "text": "

Context helped me. Thanks

", "time": "2025-06-02T22:30:50Z"}, {"author": "Kazuho Oku", "text": "

\"byte stream substrate\" SG

", "time": "2025-06-02T22:34:26Z"}, {"author": "Alan Frindell", "text": "

reliable bidirectional byte stream substrate?

", "time": "2025-06-02T22:34:28Z"}, {"author": "Kazuho Oku", "text": "

either ways

", "time": "2025-06-02T22:35:03Z"}, {"author": "Willy Tarreau", "text": "

Maybe in 3rd bullet we should change \"Adapting QUIC such...\" to \"Adapting the QUIC multiplexing layer such...\" as we're not touching the transport layer.

", "time": "2025-06-02T22:35:35Z"}, {"author": "Matt Joras", "text": "

we never defined the difference between those though, as discussed above. Which makes putting that in the charter complicated

", "time": "2025-06-02T22:36:25Z"}, {"author": "Alan Frindell", "text": "

I'm not getting what you are asking Ian

", "time": "2025-06-02T22:37:04Z"}, {"author": "Lucas Pardue", "text": "

QUIC without streams?

", "time": "2025-06-02T22:37:13Z"}, {"author": "Ian Swett", "text": "

Handshake + loss detection + congestion conrol, but the payload is just raw bytes. No streams, no flow control.

", "time": "2025-06-02T22:37:33Z"}, {"author": "Ian Swett", "text": "

DTLS++

", "time": "2025-06-02T22:37:38Z"}, {"author": "Matt Joras", "text": "

Isn't that just not using streams?

", "time": "2025-06-02T22:37:46Z"}, {"author": "Ian Swett", "text": "

Yes, very true. And so maybe it's not worth thinking of separately

", "time": "2025-06-02T22:38:17Z"}, {"author": "Alan Frindell", "text": "

We need API compatibility and datagrams are effectively part of the API

", "time": "2025-06-02T22:39:10Z"}, {"author": "Victor Vasiliev", "text": "

API compatibility is a funny thing

", "time": "2025-06-02T22:39:24Z"}, {"author": "Alan Frindell", "text": "

When there's no defined API :D

", "time": "2025-06-02T22:39:40Z"}, {"author": "Victor Vasiliev", "text": "

If my QUIC API provides me with information about when individual stream chunks get acked, will QMux provide that functionality?

", "time": "2025-06-02T22:39:52Z"}, {"author": "Matt Joras", "text": "

vacuous API compatibility

", "time": "2025-06-02T22:39:55Z"}, {"author": "Marco Munizaga", "text": "

If it's not encrypted the protocol police will get them!

", "time": "2025-06-02T22:40:05Z"}, {"author": "Alan Frindell", "text": "

If we want to converge WT/H2 with QMux, then it wouldn't be QMux over TLS/TCP, but QMux over H2 over TLS/TCP

", "time": "2025-06-02T22:40:29Z"}, {"author": "Martin Duke", "text": "

Well if you make ALPN part of negotiation, etc, it's hard to do without it

", "time": "2025-06-02T22:40:43Z"}, {"author": "Willy Tarreau", "text": "

Yes but it drops UNIX socket and loopback usage which are pretty valid use cases.

", "time": "2025-06-02T22:41:08Z"}, {"author": "Nick Banks", "text": "

To be clear, my doc defines a way to securely negotiate removal of encryption post-handshake. Still requires TLS :)

", "time": "2025-06-02T22:41:56Z"}, {"author": "Matt Joras", "text": "

TLS security theater

", "time": "2025-06-02T22:42:20Z"}, {"author": "Nick Banks", "text": "

I think it's still a good idea to always require TLS for QUIC

", "time": "2025-06-02T22:42:25Z"}, {"author": "Kazuho Oku", "text": "

@Alan I'm not actually sure, IMO WT/H2 is HTTP headers + capsule-encoded QUIC frames.
\nWe have options like split the part on HTTP headers, or stop using capsules. Not saying that's a good idea but

", "time": "2025-06-02T22:42:43Z"}, {"author": "Alan Frindell", "text": "

What I mean is if we rewrote what goes on the H2 stream as QMux

", "time": "2025-06-02T22:43:06Z"}, {"author": "Kazuho Oku", "text": "

ah I see

", "time": "2025-06-02T22:43:27Z"}, {"author": "Willy Tarreau", "text": "

I don't think so, for me it's not just the crypto cost but the complexity of inter-component communication (containers, local applications etc) where people end up doing wrong just to be able to connect (e.g. use the same cert everywhere).

", "time": "2025-06-02T22:43:33Z"}, {"author": "Alan Frindell", "text": "

\"totally secure bytestream\"

", "time": "2025-06-02T22:43:39Z"}, {"author": "Lucas Pardue", "text": "

sorry for misrepresenting you Nick

", "time": "2025-06-02T22:44:14Z"}, {"author": "Nick Banks", "text": "

No problem :)

", "time": "2025-06-02T22:44:23Z"}, {"author": "Kazuho Oku", "text": "

UNIX sockets is a good example on which we want QUIC streams semantics but encryption being pure cost

", "time": "2025-06-02T22:44:24Z"}, {"author": "Ian Swett", "text": "

Efforts will be focusued on QMux over secure transports and no effort will be made to enable QMux over other transports.

", "time": "2025-06-02T22:44:33Z"}, {"author": "Kazuho Oku", "text": "

+1 to Ian

", "time": "2025-06-02T22:44:46Z"}, {"author": "Alan Frindell", "text": "

What do we think the cleartext quic people are doing right now? Maybe living without multiplexing but probably not being more secure

", "time": "2025-06-02T22:44:58Z"}, {"author": "Martin Duke", "text": "

\"encrypted byte stream\" and/or \"authenticated byte stream\"

", "time": "2025-06-02T22:45:38Z"}, {"author": "Alan Frindell", "text": "

private and integrity protected?

", "time": "2025-06-02T22:46:21Z"}, {"author": "Willy Tarreau", "text": "

OK if we consider that a UNIX socket is secure :-)

", "time": "2025-06-02T22:47:16Z"}, {"author": "Matt Joras", "text": "

yeah I think this is a situation where we can't really say we're going to prevent people from doing anything.

", "time": "2025-06-02T22:48:04Z"}, {"author": "Willy Tarreau", "text": "

Sounds good to me.

", "time": "2025-06-02T22:48:19Z"}, {"author": "Ian Swett", "text": "

+1

", "time": "2025-06-02T22:48:22Z"}, {"author": "Kazuho Oku", "text": "

sounds right

", "time": "2025-06-02T22:48:22Z"}, {"author": "Matt Joras", "text": "

and so we probably should avoid saying we're going to, unless there's a concern that the WG will adopt \"insecure QUIC\" or something

", "time": "2025-06-02T22:48:26Z"}, {"author": "Martin Duke", "text": "

For example, QUIC puts a lot of effort into path validation. If we \"put no effort\" into that, and you're running with no crypto, your deployment will be essentially unusable on the open intenet

", "time": "2025-06-02T22:48:35Z"}, {"author": "Marco Munizaga", "text": "

+1

", "time": "2025-06-02T22:48:36Z"}, {"author": "Ian Swett", "text": "

Your new text is better than anything on the prior slide

", "time": "2025-06-02T22:49:13Z"}, {"author": "Kazuho Oku", "text": "

\"over a secure byte stream substrate.\"

", "time": "2025-06-02T22:49:53Z"}, {"author": "Alan Frindell", "text": "

I still like reliable + bidirectional byte stream

", "time": "2025-06-02T22:49:59Z"}, {"author": "Matt Joras", "text": "

reliable is basically in there to say no ACKs

", "time": "2025-06-02T22:50:46Z"}, {"author": "Gorry Fairhurst", "text": "

Do you want to do more than document? ...

", "time": "2025-06-02T22:50:50Z"}, {"author": "Alan Frindell", "text": "

+1 gorry - specify?

", "time": "2025-06-02T22:51:08Z"}, {"author": "Matt Joras", "text": "

Ian: is it reliable \"packages\"?

", "time": "2025-06-02T22:51:34Z"}, {"author": "Gorry Fairhurst", "text": "

i.e. PS or INFO RFC?

", "time": "2025-06-02T22:51:39Z"}, {"author": "Martin Duke", "text": "

QUIC over SCTP :smile:

", "time": "2025-06-02T22:51:45Z"}, {"author": "Kazuho Oku", "text": "

SOCK_SEQPACKET!

", "time": "2025-06-02T22:51:54Z"}, {"author": "Martin Duke", "text": "

I endorse those 3 adjectives

", "time": "2025-06-02T22:52:31Z"}, {"author": "Martin Duke", "text": "

specify

", "time": "2025-06-02T22:53:00Z"}, {"author": "Marco Munizaga", "text": "

+1 specify

", "time": "2025-06-02T22:53:09Z"}, {"author": "Victor Vasiliev", "text": "

I prefer document to specify

", "time": "2025-06-02T22:53:09Z"}, {"author": "Guillaume Hetier", "text": "

I think it would be interesting to keep the possibility of an unsecure substrate, with QUIC bringing the encryption through TLS - if only for how an existing QUIC stack could implement it.

", "time": "2025-06-02T22:53:21Z"}, {"author": "Victor Vasiliev", "text": "

(see my objection to milestone)

", "time": "2025-06-02T22:53:27Z"}, {"author": "Alan Frindell", "text": "

Document sounds like BCP to me, but we need to write down some protocol bits right?

", "time": "2025-06-02T22:54:07Z"}, {"author": "Gorry Fairhurst", "text": "

Great job all at designing text on line - let's talk more on the list!

", "time": "2025-06-02T22:54:15Z"}, {"author": "Matt Joras", "text": "

I think Guillaume wants to _add_ more crypto

", "time": "2025-06-02T22:55:25Z"}, {"author": "Victor Vasiliev", "text": "

I still would like to see the list of use cases written down

", "time": "2025-06-02T22:55:56Z"}, {"author": "Marco Munizaga", "text": "

@Kazuho Oku I think I misheard you at the beginning. Do you remember what you were saying around ack-frequency and qmux at the beginning?

", "time": "2025-06-02T22:56:07Z"}, {"author": "Marco Munizaga", "text": "

Happy to help @Lucas Pardue

", "time": "2025-06-02T22:56:29Z"}, {"author": "Marco Munizaga", "text": "

Will Hawkins also volunteered help here.

", "time": "2025-06-02T22:56:49Z"}, {"author": "Alan Frindell", "text": "

Victor: you mean like \"fallback when UDP is not available, environments that are not suitable to QUIC transport\" ?

", "time": "2025-06-02T22:56:50Z"}, {"author": "Kazuho Oku", "text": "

@Marco I said ack-frequency is an example of an extension that we might _not_ want to use on QMux

", "time": "2025-06-02T22:56:50Z"}, {"author": "Victor Vasiliev", "text": "

Probably?

", "time": "2025-06-02T22:57:05Z"}, {"author": "Guillaume Hetier", "text": "

To be clear, I think it would be good to have QMux be able to bring encryption to an insecure substrate, rather than having to build by hand a \"insecure substrate + TLS + QMux\" stack. QUIC already defines a lot of how to integrate with TLS and it would be interesting to leverage it.

", "time": "2025-06-02T22:57:11Z"}, {"author": "Ian Swett", "text": "

That last use case is interesting, but I'm not sure how to proceed

", "time": "2025-06-02T22:57:47Z"}, {"author": "Kazuho Oku", "text": "

In QUIC v1, we had to split (d)TLS into two parts only because we had to run handshake fast.

", "time": "2025-06-02T22:58:35Z"}]