**Session Date/Time:** 22 Jul 2026 14:00

[00:00:11] **Chairperson**: While we're waiting, does anybody want to volunteer to help the AI take notes? Otherwise, we will just probably rely on it. Could someone also close the back door so we aren't hearing the general hallway roar? Instead, we'll hear doors closing and opening occasionally. Okay. Welcome to the quick working group meeting at the at-ietf-one twenty six. If you have not already, please log in with the MeetEcho tool, the on-site tool. At this point in the week, you may have already seen this. But just as a reminder, we operate under the note well here. Please review it. If you have not, and even if you have and haven't looked at it in a while, please also review it. The meeting tips. As I said, please do use the on-site tool. This is how you will queue for the mic. Both and remote participants, you already know because you're there. But, also, state your name before speaking in the queue. This is especially helpful for the, notetaker, the AI notetaker in this case. And these are just your links. Okay. Admin, I already said, listening what he hear is really enthusiastic. It sounds like we're going to reply on the AI notetaker. The chat is in MeetEcho and Zulip. We will manage the queue. You can remove yourself, but if you don't, I will kick you out anyway. Okay. So working group doc status. It's a little bit leaner this time. The main thing is that reliable stream resets is now in last call through August 3. So woohoo. And everything else, there's updates to various working group documents that we will be covering in this meeting. Otherwise, we have a bunch of documents that are awaiting various things like Shepard write ups. So our agenda is a little long in terms of, number of items, the number of things in the working group, that are related to adopted work. We're gonna spend some time on QMux, extended key updates, accuracy of timestamps, and then Q log. And then we have a relatively substantial portion of time dedicated to, as time permits, topics. I will not read them all. They are there. Some of them are interesting, of course. Does anybody want to bash this agenda or reorder things, anything like that? No. Okay. And then with that, I guess we will go to our first present presentation or discussion, which is on QMux. Yeah.

[00:03:49] **Lucas Pardue**: Hi, folks. I'm Lucas taking my chair hat off and presenting on behalf of the QMux authors today, and I'll have Eric helping me towards the end of that session. Wherever you are, I can't see you. You not here, am worried. So yes, that is that. Since the last IETF, if my math is correct, we have published two drafts, the draft-one and the-two, being that we had adopted QMux-zero-zero into the working group. We had a lot of issues that Kazuho presented at one twenty five, so we've discussed those previously. Those are wire breaking changes from zero zero to zero one. And then from zero one to zero two, just trying to close out remaining issues. I'd say that no wire breaking changes. There were behavioral changes in, say, tightening of text about how a peer should respond to some kind of frame or some something. So behaviorally, slightly different, but effectively same wire image. Some of those key changes briefly are to use QMux records. So this was the kind of two layer encoding question that we discussed last time. I'm not going to go into all of the details. It's not a good use of the working group time. I'd I encourage you to read the latest draft if you haven't, and you can go and look at section 3.2 about how those QMux records work. I had some kind of issues relating to how to define to use QMux over TLS. We all agreed that we'd want to do that, but required use of ALPN, which helps in somewhat for people who are developing application layers to decide how they want to use QMux. Some text on the guidance there, which I'll touch on before the end of this session. A lot of the use of reset stream at very straightforward and just general hardening, cleanup, and clarification. So I want to take some time to look

[00:05:51] **Max Franken**: at the

[00:05:51] **Lucas Pardue**: implementations before we get into some of the problems, just in case people haven't been tracking. There's been a lot of activity in various statuses. We had some of the kind of early adopters of the work, people who are interested or enthusiastic about QMux prior to adoption. So we got Quickly, HAProxy. Anything on this slide was my quick survey. If there's any inaccuracies, that's my fault, and people can correct me or incorrect in the chat. But from what I understand, we've had various levels of implementation from projects like Move Fast, Pico Quick. There's a QMux MSQuic fork, but I think the MSQuic folks are interested in doing it their own way. So there is some work going on there. I had a fork of Clarify its quiche that I then went on and Vibe coded a curl back end for to do hp3 over QMux, so demonstrating the composability of the libraries and the layers. There's a quick go fork, I've said, but I believe now it's a PR to quick go. Although we've had some of the work in the space of kind of libraries that are being developed within the web transport mock world, both a Rust crate and a NPM thing, whatever they're called, node thing. Then the final one was tooling around this thought experiment of how easy or hard it would be to do a Wireshark dissector. So I put up an MR for that that I haven't linked. It still needs a little bit of polish up, but it was kind of easier than you might anticipate due to the reuse of the existing quick handling, which is part of the value proposition that QMux suggests it has. So implementations on their own are not great. The question has kind of been in group of folks in this slide. What is a good driver for interop? You can have a client that's civil, but what should they do to connect and exchange some application data? Some of us have been using HTTPthree over QMux. QUIC, in general, has used a form of HTTP to drive drive, like, a request response echo client server to drive streams. So Kazuho and I updated a non adopted document that defined how to do h p three over QMux, very short draft. It defines the ALPN token, which is important for the negotiation of using QMux. Although this text is taken from the draft and says it uses QMux version o one, because o two is wire compatible, there's no need for another ALPN right now. I presume once we do a breaking change, we'd probably want to do a different one and rev that, but that's not something the working group needs to worry about too much itself. We've also heard that MOQ over QMux is a popular target amongst that group of people. I can't speak much for that myself, but there's these kind of different subpopulations of people who want to do some things. There has been interrupt success between those people. I was just trying to capture that back in the Slack, and unfortunately, the history didn't go back far enough for me to make that comprehensive. So the results of capturing those results has not been so great, and I'll try better to do that in the future, so I can present a matrix of things like we're used to in the past. But in addition to that, Marco has been doing a work in progress, interrupt runner thing for QMux. I think that would be another thing for us to explore. Also, just to highlight that some of the implementations have been doing more than just QMux over TLS, so looking about how we can do this over things like unit sockets or web sockets, changing the substrate underneath. This is just a quick view of the Wireshark Disactor to show you that it did actually work, and it presents the information a way you might be familiar with if you did TLS dissection ever. You can see that it's a TCP running over Oh, sorry. TLS 1.3 running over TCP with a client and server hello. They've negotiated this ALPN I just mentioned, highlighted in the red box. I'm not going to go into this in too much detail, but you can see it's changing the QMux transport parameters, including the match record size, which relates to the change to the two layer encoding that we did, and then it's changing HTTPthree data over the top. What was cool is the HTTP three dissect that just needed some glue to be able to pick up and hook into QMux with no other changes. Now, onto the meat of the issues. We only have four issues, which is kind of surprising. We thought we might have more at this stage, given how many we closed out previously. Just in summary, could QMux optionally leverage this existing TLS quick TLS negotiation? Should we require TCP, which is more of an editorial issue about how we frame some of the discussion about the substrates, something about QMux and the provided ALPN, and a more recent issue about revisiting some of the newer text about graceful close and some of the requirements we put on endpoints, or suggestions we made to those endpoints to do anything.

[00:11:36] **Eric Kinnear**: The first one is more of a a larger question of do we wanna have this document be talking about just QMux over TLS over TCP? Do we want to include the current discussion, which is already in the draft, about HP Connect and Unix domain sockets and all that kind of stuff? Right now, we have ALPN for TLS. We don't have that for Unix domain sockets, etcetera. Do we wanna allow any transport that's suitable? What's the plan there? Do people have any thoughts, opinions? We can also take that same discussion to the issue. Marco, I see you're in the queue.

[00:12:23] **Marco Forte**: Yeah. I mean, I I would want this to work over any suitable substrate, But I'm curious to hear if anyone has the opinion on why you would only want to constrain this in TLS over TCP.

[00:12:38] **Eric Kinnear**: I think some of the subsequent issues we'll talk about, what do we do for insecure substrates, which I think was a large part of the motivation. But mechanically, I don't think it's that different. Kazuho.

[00:12:57] **Kazuho Oku**: So I think one of the problems of talking about other I mean, talking about substrate other than TCP is that they could have different ways of closing. I mean, TCP has a very specific way. I mean, things are unidirectional, whereas the RSTs are bidirectional. So at least in the QMux draft, we have to say exactly when using TCP how the connection should be toned down. But for other underlying transports, we cannot really say anything without specifying which ones do we want to support. So I'd probably say that the best direction is specify what we would do be doing when using GCP, and maybe other sections saying that if you are using something else, then it's up to you or something like that.

[00:13:48] **Eric Kinnear**: Yeah. I think that's kind of a a reasonable middle ground where we say, these are the properties that we need. Right? Like, we need some kind of application layer protocol thing, not to finish the acronym. We need some way to say this is closed and this is done. And then this is the distinct mapping of that to TLS over TCP. And if you want to define a document that is your own mapping, then, like, you should probably write down how you chose to do that if you want anybody else to talk to you. In a very similar vein, the next issue is about what do we do if one of those non TLS things isn't secure. And so the the question came up, hey, we kind of banned these crypto frame things that quic- has from q mux and said, nope. You get all of that from TLS. However, if you were running this over some other substrate that didn't have TLS already or where the claim is that it is challenging to add TLS, why not just use quic- crypto? I think based on the discussion on the issue and kind of where I'm personally ending up without any hats on is that we probably don't want to add yet more combinations of ways you could run this. It'd be nice if there was just one thing, and if you needed security and it was easy enough to add QMux, then it's not totally clear to me why it's hard to add TLS and then QMux. So if if anybody feels strongly or feels differently, it would be great to to hear more about that. And we have a queue.

[00:15:29] **Speaker 6**: Hi. So I'm one of the people that was asking for could we get TLS frames or quick crypto frames directly in QMux. The main motivation is most quick implementation already come with all the TLS machinery implemented in. And so in terms of implementation simplicity, if we can just simply say, keep it in, do the same as is already implemented, and get cryptography and security for free. It is simpler for some use cases. It is possible to get TLS or TLS layer implemented below. That's something that is doable technically. We are talking about code. Everything's possible. It just seems more complicated. But there might be additional challenges with making it work inside of QMux when looking at the details. That's a part I haven't explored yet. So Yeah. That's a just a big question, a suggestion. I would like to see if we can do something there. It's not something that I have solutions for.

[00:16:30] **Eric Kinnear**: Yeah. I think I think it's also a complexity trade off with having multiple modes for QMux. And and one of the benefits here is the the thing that you'd be running outside as TLS is the same TLS as you're running inside inside of QUIC. So if if you have it well enough to operate inside your QUIC implementation, there's a good chance that you at least have some of the support for running it outside. Two more.

[00:16:52] **Lucas Pardue**: Lucas speaking as an individual, I I commented on some of the issue. I'd I'd really like to keep the current design and and to avoid some of the the complexities there. So I'd love to punt on this for the time being.

[00:17:06] **Alan Frindell**: Alan Van Del Meta. I I also think we should not do this now, but I think maybe there's if somebody is really interested in running this mode, can't they just write another document that you would shim between your substrate and QMux in the future. So it doesn't close if we if we lock it out now, it's not for closing that door forever if that's how you want your stack to work.

[00:17:28] **Eric Kinnear**: Yeah. That's fair. That's that's not a hard no forever. That's a that's a this is an extension that could work. Now it like Marco's last, and then we'll keep going.

[00:17:36] **Marco Forte**: Just a quick note from the implementer's perspective. I thought doing as what we have right now with QMux sitting on top of a TLS stream was very straightforward and simple.

[00:17:49] **Eric Kinnear**: Gotcha. Thank you. There we go. We talked in the previous slides about do we restrict QMux to only TLS versus not. This one is hopefully fairly straightforward. We're saying if not running over TLS, one of the things, think, Kazuho framed this nicely, like this is one of those things that we need something for, and the draft currently talks through how you do that for TLS. I put some options here of kind of things that people had brainstormed in the issue of ways to negotiate the application protocol. One of them is say that's a you problem. Go figure it out. Enjoy. One of them is to say you have ports. That's what ports were for once upon a time. We could also build in a QMux transport parameters or ALPNs thing. And let's build a queue and maybe close a queue because I see we are at time, but I believe this is the end. Almost the end.

[00:18:53] **Christian Huitema**: Christian, I'm all for the u problem solution because, I mean, you're you're not going to do everything. And the the obvious candidate that that we've heard after TLS or TCP TLS is Unixocket. So if people really want to run QMix over Unixocket, maybe they should write the draft and put the Unix socket stuff there.

[00:19:21] **Ian Swett**: That's it. Gotcha.

[00:19:23] **Alan Frindell**: Yep. Alan Fendel, I'm I'm a little sad to lose this piece, but I maybe don't have a maybe Christian's point is right. Like, somebody who wants to run this over something else can go think about it. I wonder, was it in the issue, like, with their, with the use case or why they were what was the substrate they were thinking?

[00:19:43] **Magnus Westerlund**: Yeah. Like, say so

[00:19:44] **Eric Kinnear**: you wanted to run this over Unix domain.

[00:19:45] **Alan Frindell**: It was Unix domain. Yeah.

[00:19:46] **Speaker 11**: I mean, the

[00:19:46] **Alan Frindell**: thing about ALPN is you you actually it's not or or or ports, for example, you have combinatorial explosion. Like, right now, you know, some of us support five different versions of the mock trends the mock draft. And so Yep. The negotiation piece is, like, useful.

[00:20:03] **Lucas Pardue**: Cool. So, Lucas, again, speaking as an individual that commented on the issue. My concern is if we did something like the third option here of providing another negotiation mechanism, we end up with considerations of, well, we we wanna use TLS and one, what if we sent these additional messages, whatever they would be, that would try and negotiate a different protocol, and you end up having threat models about project protocol mismatches, etcetera. So I I personally, I'd love to punt on this for now. If people wanna go away and and think about it harder, again, not shutting the door to it, but just let the authors focus on the most minimal solution for stuff.

[00:20:43] **Eric Kinnear**: If we have an easy enough extension model with the transport parameters, it's not super hard to add what actually is useful in real

[00:20:49] **Lucas Pardue**: life. Mhmm.

[00:20:51] **Eric Kinnear**: Okay. This one, I don't think we have a ton of time to talk about, so I will simply say go read the issue. I think it was Corey did a very nice write up in the issue of why, especially mobile devices that are powered by batteries, care hugely about not being woken up to be told that the connection you had that was idle is gone now. It's kind of like knocking on someone's door to tell them that they should be asleep. So go comment on the issue. There's a little bit of complexity there around can we make silent close happen for idle connections? But otherwise, my take is it seems like a pretty good idea. And that's it.

[00:21:25] **Lucas Pardue**: Yep. So thanks. Yarosav, do you wanna come up your next, yeah, next step? So close the issues on QMux, keep iterating and implementing.

[00:21:40] **Florentin Rochet**: Hello.

[00:21:44] **Yaroslav Rosomakho**: It's been a while since we spoke about extended key update. As a reminder, idea of extended key update is to introduce post compromised security in QUIC. Compromise is always a bad thing. And if you know that you are compromised, then you should do something about it, not just do some kind of remediation and and keep going. But quite often, don't know that you are compromised, and that's a problem. So in with regular TLS and quick key update, you get fresh keys for AID that are derived from the very same shared secret that you got during the initial handshake. So it does not help with compromise. So if somehow somebody stole traffic keys from their application memory, your session is compromised forever and ever until you terminate it. With extended key update, your blast radius is reduced. You'd make a fresh extended key update that includes doing a fresh key exchange, and that minimizes or reduces amount of traffic that attacker could steal if they manage to steal your session keys. Now what happened to the draft? So QUIC extended key update draft depends on TLS extended key update draft. We decided not to create a completely new mechanism for for QUIC. There are a few differences that I'll cover in

[00:23:15] **Lucas Pardue**: a moment.

[00:23:27] **Yaroslav Rosomakho**: Once we get initial implementations of quick extended key update, I suppose we will also be asking for a working group last call for a quick extended key update. There is a chance that as a result of formal analysis, we might have to make some changes to TLS extended key update, so we will we really have to wait for for that. For TLS extended key update, we have two implementations, one that is based on embed TLS and another on Rust TLS. I am working on quick extended key update implementation based on Rust TLS Quinn. So if anybody wants to participate in interoperability testing, please reach out. Would be would be great to do that. As a recap in recent changes in TLS extended key update that are also relevant for QUIC. So in the past, when I presented it last time, we had separate messages, separate TLS handshake messages for extended key update request response and new key update that was deemed to be wasteful. TLS messages are very scarce resource. It's a single byte type, so they they have to be allocated very, very carefully. Now we're asking for a single extended key update message type with three subtypes, key update request, key update response, and new key update. So we're staying consistent. New key update cannot be used mustn't be used in QUIC because QUIC has a a key update of bit flag that we are rotating in the very same way as key update the standard key update works. IANA registry will be requested for potential future extensions, and I suppose we will have a separate column if this subtype applicable to QUIC or not. Other change, there are no more failures in TLS extended key updates, so it's always expected to succeed, not necessarily instantaneously. So you could potentially delay before, if you if you really feel like it. But there are no more error codes, which significantly simplifies the specification. So if responder is too busy, it might delay the response. And if you're a requester and you didn't receive response in timely fashion and you're not happy with that, you can, well, terminate the connection. Another recent change based on initial results of fat formal analysis feedback is we are mixing in initial transcript in TLS extended key update. So TLS extended key update now carries continuous transcript of all handshake messages. Previously, it started fresh transcript every time. So formalizes people told us that it would be much better to for the security properties to keep the same transcript, which we are doing now. And our prototype implementation software updated accordingly, and it was not really a big deal from implementation perspective. So right now, we are again hopefully, soon, we will be doing working group last call in TLS working group, getting few more quick implementations. And if nothing dramatic happens, we'll be asking for a quick working group last call as well.

[00:26:49] **Lucas Pardue**: Cool. Thanks, and thanks for giving back some time. There anyone who wants to ask anything or say anything on this topic? Magnus?

[00:27:01] **Magnus Westerlund**: Magnus Wesclod, Ericsson. Yes. I should review the draft better, but I mean, this overrides the no further TLS crypto frames after handshake complete, doesn't it?

[00:27:17] **Yaroslav Rosomakho**: It uses TLS crypto frames after handshake is complete. Actually, you can and should be using TLS crypto frames after the handshake is complete today to pass new new session tickets.

[00:27:29] **Magnus Westerlund**: Yeah. I think that's the only message that was allowed. So, I mean, you're writing, you're actually using this extension to replace some of the

[00:27:37] **Yaroslav Rosomakho**: Yeah. So so it will be leveraging crypto Yeah. Streams with this special stream in the very same way as new session tickets is using that.

[00:27:44] **Floris van Dijk**: Yeah.

[00:27:44] **Magnus Westerlund**: But no, it's good. I will review this better and

[00:27:49] **Lucas Pardue**: hopefully provide some comments because

[00:27:50] **David Schinazi**: Awesome.

[00:27:51] **Magnus Westerlund**: But I think because it really is needed in a number of use cases, I think I talked to Alvaro about the potential use of BGP over QUIC, and they have really long decision. They're gonna need it.

[00:28:03] **Yaroslav Rosomakho**: Yes. Again, the the motivating use case is all sorts of long lasting connections over QUIC, such as VPNs and IoTs and perhaps BGP, where you do want some form of post compromised security. Great. Thanks again. And, yes, we are very much looking for volunteers for interoperability testing who would like to do implementations, and, of course, reviewers. We need more of those. Thank you.

[00:28:33] **Lucas Pardue**: Thank you. Next up, we have received timestamps.

[00:28:40] **Joseph Touma**: Okay. Can you hear me in the room?

[00:28:43] **Lucas Pardue**: Yes. We can hear you.

[00:28:44] **Joseph Touma**: Okay. Well, good morning. Good evening, everyone. I will be I'll also have a short presentation on the quick package received time stamps draft. And this is, I'm Joseph. This is a joint draft with Ian from Google. So in case you haven't seen the draft recently, this is just a quick overview. The draft enables the peer to report accuracy time stamps for some or all ACK packets. The time stamp is connection local and not intended to be absolute. And the current version of the draft uses a new act frame types that extend the existing act and path act frames with received timestamp information. And where we are right now is, version three of the draft. We've only had editorial changes since the last IETF to clarify some details about, what it means to have max received timestamps not be sent at all or if it's sent with zero. We clarified that zero means that you cannot send the frames, and we added the security considerations section. There were some, suggestions that were raised in in an issue, so we used these to add the section. And we currently have one open issue that, Victor and Ian suggested, like, they opened while adding implementation for Quiche. And this is the issue is do we need specific guidelines for rejecting implausible time stamps? We say that the the time stamps are best effort anyway for the for the sender side, but this adds like, for the receiver side, when we currently already say the draft says you should do plausibility checks and you may ignore implausible time stamps, but we don't provide concrete heuristics. Victor Victor and Ian suggested two specific heuristics. So just soliciting more feedback, do you think we should include, guidance on heuristics to reject implausible time stamps, and are there any others besides the two that Ian and Victor suggested? So I'll leave that up for discussion in in a minute. But the the quick, like, implementation update, move fast supports the latest draft version. It's not enabled in the Internet, but it's in the code, and you can we can set it up on one of our interop endpoints if you want to test against it. Google Quiche has support for the latest draft, but the transport program negotiation is still, planned. And what we really are looking at at this point is more eyes on the draft. Is there anything, you would like to see added fixed in the draft? Any editorial or clarification suggestions? And if anyone wants to do it on. So with that, I will just leave it at the issue that we have open and if anyone has any questions, comments, clarifications on on the draft.

[00:31:54] **Magnus Westerlund**: Yeah. Ian.

[00:31:58] **Ian Swett**: Ian's by Google. I I just wanted to add that, I have spent too little time thinking about what their objection criteria should be. And so, like, these are, like, the definition of, like, me thinking for, like, ten minutes. Unfortunately, Victor did come up with a case where you you could basically persistently, like, just move time. I think it was, like, what, more slowly, like, the half the rate of actual time. And if you persistently do that, you end up getting persistently two x the bandwidth measurement, that you would expect for something like BBR, unless admittedly, we do other things in our BBR implementation, like, limit by, like, the send rate and stuff. But, like, the point is you it's fairly trivial without some sort of rejection to end up with, like, extremely large misestimation in bed width. So my inclination is to say we probably need a recommendation that I should or something with, like, a plausible, heuristic. And so, but I'm I'm not an expert in this area, and, like, you know, I would really appreciate anyone who is to suggest something. So

[00:33:09] **Alessandro Ghedini**: Alessandro Goudini, Cloudflare. I think, regardless of the specific heuristics here that might need more thinking or or review, It would be useful to include guidance if we think that you like, an implementation would, for sure, like, need to implement this. And even if you leave room for an implementation to do something else, having, like, a specific guidance that, you know, by default, you probably should do this, but then maybe if you have a reason to not do this, then whatever. So if it it it makes it easier for an implementation to not have to think through too much if it's, like, common logic that most people should probably implement anyway.

[00:33:56] **Joseph Touma**: Yeah. That makes sense.

[00:34:00] **Gorry Fairhurst**: Got it. No hats. I'm now confused. So, yeah. I I think we need to write down good rules for this, and we need to kind of do some sanity checking for really strange paths and see what happens. And I don't understand the rules at the moment, but that's probably just because I can't squint at it properly.

[00:34:32] **Jonathan Lennox**: Jonathan Lennox. Maybe this is just because I'm old, but I remember the days when you couldn't rely on your peers' clock crystal being within 20% of yours. I mean, it's probably not that bad anymore, but the things could legitimately have a clock that's running fast or slow. I also mentioned on the chat that Tip Top is gonna have to worry about cases where time runs faster or slower at your peer than it does for you because, you know, they're on Mars and you're on

[00:34:52] **Lucas Pardue**: Earth. But

[00:34:55] **David Schinazi**: so

[00:34:58] **Jonathan Lennox**: yeah. I mean, I think you just you're gonna have any time stamp based thing is going to have to be robust to the peer behaving oddly just because they're weird even if they're not actively hostile. So I think maybe there should just be general guidance of when you write and then maybe this should be not specifically for this, but, you know, something in c CCWG for time stamp based congestion control algorithms. I don't know.

[00:35:26] **Joseph Touma**: Yeah. Sounds good. Ian and I will try to put this in a PR and see I can share it with everyone to get more feedback.

[00:35:34] **Lucas Pardue**: Yep. Everyone who's commented, review that and engage in the discussion on the issue.

[00:35:42] **Joseph Touma**: Okay. Thank you very much.

[00:36:09] **Lucas Pardue**: Q log is up next. Typically, we might just do this as a quick chair update, but I wanted to put some slides up for some visualizations, presenting on behalf of the four authors, Robin, Luca, Martin, and myself. Since IETf-one hundred twenty five, we have published some new drafts. The key changes are numerous design changes I'm not gonna go into, individual events, fields within events, optionality, consistency, numerous editorial improvements, not including my misspelling of numerous there, but to to keep going through and refining text, taking text out, things like that. I expect some of that to continue as we drive towards working group last call, but some of the key nonchanges are that the the fundamental design of foundations are not changing. We've sorted the extensibility model out that we're fairly happy with, which I'll touch on in a couple slides, We closed out the JSONSEC versus JSON issue that had been rumbling on a little while and deciding to close with no action, so we've kept the JSONSEC serialization. I'm sorry if that makes you feel sad, but it helps unblock us as one of the fundamental serialization design challenges that could have affected progressing this draft. It means the authors don't have to do any work, and we can focus on other things. So to go back to implementations and interop again, there are varying levels of support of QLOG versions across implementations because we have been iterating. I'd say now is a really good time to update to the latest draft. We're gonna keep touching a few things, no doubt. That's just the process. But fundamentally, if you're on a very early version of the Q log drafts, now would be a great time to to switch to this one. AI and LLM does a really good job of of taking these structured definitions of things and looking at your existing code. If you have code or if you're just regexing and print it effing, it could probably figure it all out. So it might not even be too much work. In addition to that, we have a new parser tool. This is a logging and analysis observability kind of thing. So while I had a lot of loggers, the parsers were fewer, far between. So a chap called Pat Meenan, who people might know from the web performance world, has developed something called waterfall tools. This is coming from the world of kind of web perf analysis, web page test, if you may have heard of that or ever used it yourself, but trying to abstract the visualization of things like page loads that do multiple h t p three or h t t p requests on the connection and making this a more reusable library, again, in Node. Js, I believe. And I opened an issue in May. It'd be like it'd be really nice if it could also do Qlog. It can analyze files, if you're familiar with those, or Chrome NetLog files, saying the time's over, but I just forgot to reset the timer for myself, but I'll try and be brief. This is an example of what what I mean by the waterfall example. So this is a request on local host loading five different resources. They've all got different color depending on the phase of the the connection. This maybe resonates with some of the stuff going on in HAPI, try to identify what the user agent was doing in the time that wasn't just about something active on a single transport layer connection. The interesting thing there as well, I tried to highlight in the red box, is you have kind of these banding of colors that shows the data delivery for that resource. So beyond the when did it start and when did it finish, you know, TTFB, TTLB, you get a better sense of when were key elements or bytes of that resource delivered on the wire, which could indicate things like prioritization, head of line blocking, loss retransmission, etcetera. In addition, Pat kept iterating, and he's taken qvis and somehow embedded it into this tool. So, we've got the familiar sequence diagram from Robin Marx's qvis tool there that we're familiar with. Then in addition to that, he's taken Chrome's NetLog viewer kind of view of the events that were happening and a way to go through them and extract render some of the details on the right hand side. So anyone who's filming with Outworld, that's that too. That's pretty cool, I thought. Now, for open issues, we've only got four of them. Unlike previous set, we're not going go into these issues. I don't think it's a good use of time other than one of them. Again, we might run out of time for that one, but these are the four two related to zero RTT and session tickets and settings. If people feel passionate about those topics, it'd be really nice to get some input on the tickets to drive them to closure. We have one issue five zero one that the editors and authors can probably figure out amongst ourselves. And then this last one that's the most recent about frames process, I wanted to go into because it's new. So this is a consistency issue. And a brief history was that quick frame, the traditional logging of those was in packets sent and packet received events. You have an array of frames that you say, oh, I received this packet, and the frames are in it, say. But when I was trying to use Qlog for QMux, because I love both, we don't send packets, and therefore, visibility of frames was trickier until I realized we have this existing frames processed event, which got me thinking if we could repurpose it in some way to indicate if if the frames were processed because they'd been received or sent. After some discussion in an editor's call, we figured it would be better to have separate frames created, frames parsed, and frames processed events, which are effectively similar to the existing frame created and frame parsed events in HTTP three. So we've added two events, frames created, frames parsed, and left frames processed there. So now, we end up in this kind of similar but different mode, and that's where the inconsistency is coming. We wondered if we what we should do, and I'll present three options on the next slide. But for context, this frames process event is kind of a bit of a weird thing. It's part of the use case was that it can be used to signal internal state change, not resulting directly from the actual parsing of a frame, I. E. You could have parsed the frame and then buffered it to action later and then action it later. You could, but I don't know any implementations that would operate that way, or even if they did, if they need a standard event for doing this kind of thing. So I can imagine three proposals here. We remove that frames processed event. The original purpose to separate out packet handling and frame handling is now achieved by frames parsed, say, or frames created, etcetera. For the overall consistency of these drafts, we add a frames processed like event to h3, or we just do nothing and leave it as it currently is specified in the document. I don't want to spend too long on this, so maybe if we lock the queue map, that'd be good. But, yeah, Kazuha, go ahead.

[00:43:32] **Kazuho Oku**: Kazuha, I prefer removing it, because we we will be having other problems if we try to fix these things. For example, QMux allows streamed processing of frames. So if you have received partial frame, then it can still be processed. So there, these can be this is that keep coming also. Let's keep it simple, close it, and then if we find anything in the future, then we can change things.

[00:44:00] **Lucas Pardue**: Yep. Thank you. Who's next? Christian.

[00:44:05] **Christian Huitema**: Yeah. Kind of. Let's let's not do that in this quick frame process. There are events of a legit in quick frames. For example, it says you'll receive an extension of flow control.

[00:44:23] **Max Fillinger**: Okay.

[00:44:24] **Christian Huitema**: And and and but they can be treated at their own events.

[00:44:28] **Lucas Pardue**: Cool. That's that's a good signal for me. It's easier to add things later than try and deprecate or take them out later. That's the kind of school I'm subscribing to. So great. That's a clear input to the authors. Next steps, please help us. We've got the session tickets, zero RTT stuff. Beyond that, I think we're really, really ready for working group last call even though we said this a 100 times before. And just to flag that we wanna be able to support new animating QLOG drafts or or schemas that are building on top of this work. It's really important that we can get the foundations done to unblock some other work that's been happening, such as careful resume. Has got a draft for happy support happy-three, and there's some other things that are going on now. So things are progressing well, and it feels like we're very nearly done, which is exciting. Florentine, Reverso for QUIC. Oh, and, yeah, that is the end of the adopted working group items. So in the, as time permits, bucket now.

[00:45:40] **Florentin Rochet**: So hi, everyone. I'm Florentine Rochef from the University of NamUs in Belgium. So I'm here today to talk about memory copies in networking implementations. So usually, when I do some netcode, I can end up with having to copy information. So you're copying data, and this is usually expensive. I'm trying to avoid doing that as much as I can. And in the case of of quick version one, there is still one memory copy that cannot I can't really avoid. So let's take, for example so we we receive one megabyte of of of data from the network. So this megabyte is encrypted. So we have to this has to go through the QuickStack. And in any QuickStack, it's going to decrypt this megabytes as many different packets. And then we have a stream frame inside the packet that we would want to extract and give to the applications. And there's usually two kind of way to extract that. So either we copy inside some kind of buffer that the application is providing, or we just give the the stream frame as is to the applications, and the application has to do the rebuffering itself if it wants to. What I want to do to have is have some kind of contiguous zero copy in which from the network layer to the application layer, there will be no copy happening. And the applications can have is can have this one megabyte of contiguous data if it wants to. To do that, we need to actually refactor the protocol, and that's the the proposal today. So there is actually three changes that are necessary from quick version one. The first change is to add two elements in the quick short header. These elements will be a stream ID and an offset. They will be used to select the buffer into for the decryptions and and to locate where to decrypt. Second change will be the stream frame. The stream frame should be the first elements inside the packets. And then any other, of course, control frame can be after the stream frame. And a third change will be the ordering of frame elements that will need to be reversed. So this change is a bit uncanny, certainly. But, yeah, with these three chance, we can have this contiguous zero copy property. So we can have this this situation in which we have no copying between the network stack the network layer and the application layer. So how does it work? So, basically, you can see here in the in the middle. So we have a buffer containing multiple quick packets, so two quick packets. And when we decrypt, we are actually using the decryption hidden copy. So the the put of place decryptions to combine the stream frame. So we end up to a contiguous stream of data, and there is no copy anymore that is needed to recombine the information. So we can recombine because we have information in the quick short header to to do that. There are different solutions to than than than reversing all the frames. But these solutions for reversing is interesting, my opinion, because it minimized information in the short header. And we can come up with a nice abstraction in the code because reversing give us asymmetry with the quick version one. So we can actually write something like this, for example, which we are here. We have one frame. If we want to pass the frame or to write the frame on the wire, we can actually use the same code because the relative order of all elements is the same. So we have this buffer here that is an object that is hidden the fact that the buffer can be from left to right or from right to left, so in the case where it's reversed. So basically, we can have the same code for the two versions. With that, of course, this proposal has some benefits and and some drawbacks. So I would suggest just to to leave this slide up, and I'm just going to take any feedbacks, comments, or questions for this ID. Thank you.

[00:50:36] **Lucas Pardue**: Questions? No one.

[00:50:50] **Kazuho Oku**: Kazuho Oku, thank you for presenting this. I think this is an interesting idea. I like the fact that when you actually encode it, you don't need to calculate the I mean, one of the complexities that we have in quick version one is when you encode it, you don't know the size of the frame header. So the the position from where the data starts changes, and it's kind of hard for us. So I think, I mean, if this was proposed during the development phase of quick version one, I I would have preferred this approach. Okay. Though, honestly, I'm not sure if we really want to do this now that the UI has ownership. But other than that, I I like this idea.

[00:51:32] **Florentin Rochet**: Yeah. I mean, I think it's it's a good good point. Thank you. We can also think about the new protocols that are being designed today, like QMux, for example. So if we have this kind of reverse frames or designs, then QMux will inherit this this property as well. So it can still be useful for ongoing and new designs in the future. Yeah.

[00:51:56] **Lucas Pardue**: Brian? I took myself out of the queue, so don't come up.

[00:52:09] **Brian Trammell**: Hi. Brian Trammell. Clarifying question. This is a new this would be quick v three. It would be wire format and uninteroperable with one. So if you have one endpoint that wants to do the zero copy, that would only happen if the other endpoint also negotiates.

[00:52:23] **Florentin Rochet**: Correct. Okay. Cool. Thanks.

[00:52:31] **Lucas Pardue**: Kyle?

[00:52:34] **Kyle Rose**: So making sure I understand, this is achieving zero copy only if you already have a copy during decryption?

[00:52:43] **Florentin Rochet**: So decryption also is always copies. So when we when you decrypt, you have to put the data somewhere. Usually, it's in place decryptions, but most cryptographic libraries let you choose the destinations. So in this case, you choose the destination as being the stream buffers. And you are going to override the previous control control packets of the previous the previous control frame of of the previous packets. So it's it's the same cryptography code that is being used. I don't know if that answer your questions.

[00:53:22] **Kyle Rose**: But you're you're assuming you have to copy from some memory that you can't decrypt in place from?

[00:53:28] **Florentin Rochet**: So it's the point is you have to have out of place descriptions. So most cryptographic libraries have out of place descriptions. Even in place description is a copy, but it's a copy aliasing on the same destination, right, than the source.

[00:53:47] **Christian Huitema**: Okay.

[00:53:50] **Lars Eggert**: Hi. Lars. So I think I read the paper a while ago. I don't remember the details, but I'm assuming you're presenting the same thing. So I'm I think it's a clever hack. You get some performance. You avoid memory copies, which is nice, but I'm kind of wondering how many deployments have that as their remaining bottleneck.

[00:54:11] **Florentin Rochet**: Yeah. I don't know.

[00:54:15] **Lars Eggert**: Okay. That's a fair answer. Thank you.

[00:54:23] **Christian Huitema**: The wait a minute. On the main bottleneck, just put that in the shot. The mem copy is not the remaining bottleneck that we have in PicoQUIC. The the main bottleneck is basically complexity, and so adding more complexity is kind of debatable. The question I have is that the scenarios that require that tend to be served today by RDMA. So have you done a comparison of a a quick enhanced to do this zero copy and receive stuff at RDMA? Because I I don't know. But, I mean, it's not clear to me that people who are really, really performance constrained would use QUIC with extension versus RDMA.

[00:55:28] **Florentin Rochet**: Okay. It's not necessarily clear for me as well. So I suppose that if someone has a use case that will benefit from the copy, this is this can be useful for them. But, yeah, I don't know whether RDMA is going to be benefit from benefit from that.

[00:55:47] **Lucas Pardue**: Chair interrupt. We're we're just at time. So, Ian, if you wanna make a quick comment, we'll take that.

[00:55:53] **Joseph Touma**: But yeah.

[00:55:54] **Ian Swett**: Ian's about Google. I I think to echo Christian's comment, I think this is an interesting idea. I like the fact that you're experimenting in this space. If you're gonna break the wiring format or, like, make it different, go for it. Like, go way farther. Like like, way, way farther. Like, think about, like, think about RDMA. Think about, like, all the things they do, and think about things like, do I need even need to put control messages in the same packet as a data packet at all? Like, go farther.

[00:56:24] **Florentin Rochet**: Okay. Thank you.

[00:56:25] **Lucas Pardue**: And and, yeah, just to close out that talk, thank you for the presentation. These these are not adopted work items. We could get into them. If there are people who feel really inspired or enthused about this, do communicate and do keep doing the work on this, because performance is a complicated story, but important. Yes. Thank you. Up next, we have CTAPs. If you want to come up, finger prick.

[00:56:57] **Presenter**: Yeah. Hi, guys. My name is I'm I'm I'll be talking about CTAPS. This is based on a paper we submitted to ANRW, and it's also been my master thesis for the last year. So transport services in general, it's a layer between essentially layer between the application and sockets and other network settings. So it allows you to not have to bind tightly to specific APIs, but instead helps you state your intentions and and communicate over the network in a, yeah, in an intention based way. So the vision of transport services in general is to have a single interface for more than just automatically or, like, more than just selecting translated protocols, but you also have common policies, which you can use to set things like DSCP. For this example, there's no way to directly set DSP DSCP through transport services, but instead, you can state that you want low latency interactive connection, and then the library itself is supposed to do whatever it can to actually achieve that. And it's also supposed to transport service in general is supposed to help ease protocol adoption, thanks to a happy eyeball style raising of protocols. CTAPS in itself is a CE implementation of transport services, and it's the first open source transport services implementation which supports QUIC. This comes with certain gaps that are more or less inherent in transport services as it stands now, and this is what I'll be focusing on. First of all, there's a slight gap in exactly how connections are closed in transport services. So a quick connection maps to this TAP's concept of a connection group, while a stream maps to a TAP's connection. This mapping doesn't necessarily fit that well for TCP. So when you're closing a TAP's connection, it makes sense for TCP to initiate graceful teardown, while for QUIC, it makes the most sense to send the FIN, but the RAIN open for receiving data. Isn't inherently problematic, but it's an example of this is supposed to be a generic API where you don't actually notice which transport protocol you are using, but here it's bleeding through to the actual application. There's also examples where you lose granularity through transport services. For example, if you're aborting a stream in Qwic, you can both you can send stop sending, you can send reset stream, while for taps, you can only you have a single abort implementation, so you lose this directionality that you have if you use QUIC directly. There's also no way to establish directional streams as of now in transport services. So for taps, directionality of a connection is stated before the connection is established. And cloning, which is the concept that is used to later create streams on an established connection, doesn't have any, yeah, equivalent way to set the directionality of the resulting stream. So there are several mitigations that can be made in transport services to better support Qwic and to fix, these gaps. For the granularity problems, it's naturally that you would update the TAP's API. You could add optional flags and your parameters. This is something that would, for example, be easy to do in CTAPS, but then you would deviate from the actual transfer services spec as as it stands now. For the closing semantics I talked about earlier, this is perhaps a bit more complicated. What I've found is useful, at least when writing applications using CTAPS, is to assume that you're using QUIC all the time and then only interacting with the connection group, and then you will get this consistent behavior no matter what. But this is an example of the underlying library actually forcing the applications to be written in a certain way, which is not ideal. Yeah. So to conclude, I think transport services is useful, and it could help for wider protocol adoption. Application level protocols can be written on top of it and used quick, and then receive TCP with more or less free fallback, But there are some gaps that exist, but they can be mitigated through new careful design, and it could be all this is fairly relevant for later work. There's been some discussion for having taps as the basis for networking in the plus plus standard library, things like that, and that's And it would have to take this into account. If you're especially interested, you can find the source code and my thesis on my GitHub.

[01:02:18] **Max Fillinger**: Thank you.

[01:02:20] **Lucas Pardue**: Yep, and thank you. As a reminder to people, we're not the TATS working group. We can't necessarily talk about those things, but personally, what I found quite interesting on this was the powerful feature set of quick streams and how the APIs to those are maybe not necessarily there from from this layer, at least. Some applications don't need that at all, but where they are critical to those apps, it's something for us to consider. Let's get to the queue. Ted? No Ted? Ted is Todd. Jonathan?

[01:03:07] **Jonathan Lennox**: Yeah. Jonathan Linux. I mean, this is maybe a little bit cynical, but given how much taps is a generalization of Apple's network framework, I would say do whatever Apple did. And, also, I think they'd be useful I think taps working group is closed. They're probably useful to have a d guidance of where things like this should go. Maybe it's TSVWG, but it's probably not here.

[01:03:34] **Brian Trammell**: So hi, Brian. Yep. Brian Trammell. I think it's very interesting that you did a thing that was not just what Apple did. Right? Like, so the this is another sort of way at the the implementation. So really, really excited about this work. It's pretty cool stuff. I find it really interesting that when we were doing taps, we pointedly did not include QUIC as one of the protocols that we were targeting because QUIC was in flight at the same time. Right? We're these things took a while, and it's like, no. No. We're in scope only to do IETF protocols, and Quic was not yet an IETF protocol. And then, you know, I said this, I think, at the the mic in in Wood area that I I think there is a gap in having sort of, like, standards or standard ish APIs on top of QUIC in order to actually drive adoption beyond where we are right now. So this is this is really cool stuff. I will be taking a closer look at it. Thank you.

[01:04:23] **Max Fillinger**: Thank you.

[01:04:24] **Lucas Pardue**: And and just as a quick reminder, there was a draft for for QUIC taps that was floated around a while, but we it it didn't progress.

[01:04:36] **Eric Kinnear**: Eric Kinnear, Apple. This is really cool work. I would also suggest you not do what Apple did. Not because I think there's anything wrong with it, but because I think we benefit from having a diversity of the different ideas and experimenting with different things. So I think doing other things is great, and then let's look at what works the best, and we'll all move in that direction together. So this is this is very cool work. Thank you for doing it.

[01:05:03] **Joseph Touma**: Thank you.

[01:05:05] **Lucas Pardue**: So so just as a clarification question, if there are people that wanna discuss this more, like, we we don't think this this working group's a good venue. Is is TSV w I'm getting a nod and a thumbs up from our responsible AD, Gauri. So, yep, folks, please take it there.

[01:05:23] **François Michel**: Thank you. Alright.

[01:05:24] **Max Fillinger**: Thank you.

[01:05:29] **Lucas Pardue**: Next up, we have Magnus.

[01:05:35] **Magnus Westerlund**: Yes, Magnus Westland, and now for something different. Now we get into ciphers. If I get some slides. So the shares did an interesting interpretation of my title, but it's about the talking about trying to introduce GCM SSTs in QUIC. Thank you. So this is a draft in actually towards TLS currently because it's registered both TLS and quick and details, me and John coauthors. So a bit of a primary between GCM-SSTs. SSTs goes for strong secure tags. It's an AEAB algorithm. It's documented in a CFR draft, individual currently. It has been standardized by and three d p p. There's two independent security proofs. It uses basically the same cryptographic construct as AES-GCM. The main difference here is really how it derives, and it derives new authentication keys for each AAD invocation. So for each packet in quick terms, you will derive new keys before you do the authentic calculating the authentications. And this, addresses a weakness in normal AS DCM, which use the same authentication key for all communication. So if you ever and if you ever crack that key, which becomes fairly simple, which is why in this table in DCM, for sure, where you say, forger probability of the first forger is basically going towards one. You almost you get most bit of the key with one single forger. So in a few forger, you will have definitely have the key. So and that makes it hard to truncate this, tag and with with maintain security properties. So GCM SST is defined for a s 128. So with a 120 bits, a s two fifty six with 256 bit keys and 120 blocks. And also, Rijndael with 250 bits keys and 256 bit block sizes. So And looking here at the strength, you can see that an GCMSST 12 byte tag, so basically saving four bytes, we would have still have five bits better strength in the authentication than Poly thirteen oh five. GCM is a bit more difficult to make a very straight comparison, but it's I it's roughly the same at least roughly the same sync level if you take into consideration that you if you ever would have a forger. In this case, you would have one forger and only one forger. With GSM, AES-GCM, you would if you ever have a forgery, you can have multiple fordies. And we will come into where these properties might matter in QUIC further into this presentation. So how do we use this in QUIC? We are proposing now the 12 byte tag and 112 byte tag. And the 14 byte tag is considered definitely stronger. We are using the same AES ECB as AES-GCM for the header protection. And one thing that happens when you go to 256 block is that you actually need to extend the sample extension for deriving the input for this AES ECB. So we do that basically by just padding out it. But that ensures that even also short, quick packets can be authenticated with Rijndael. So this is the currently proposed cipher suite names and and their parameters. So but, yeah, it's this is the current proposals. They are definitely up to be changed if people have ideas about what should be most appropriate. So the benefits here is really that we can truncate the tags, and this MSST truncated tags behaves ideal when you're using them in Unicast and with replay protection. Yeah. Then you get the four d probability of approximately one divided by two up to by the power of t, where t is the tag length of bits. And as I said, the kind of big difference here is that with SSTs, you get one single forgery if you ever manage to do a forgery. You have no further information into the next packet or so to be able to ford. If you have AES-GCM, you basically get to collapse and can forge do additional forgery afterwards until a rekey happens. With the 12 byte tag, we would say four bytes per packet. And you also if you would go with Rijndael, you would get a significantly larger parameter space. It's basically removes all limitation practical limitations around invocations, decryption invocations. The other limits are not that restrictive in quick usage. You're gonna be restricted by other usage before anyway. Where it might be matter more actually is in multipath and multicast. Maybe take multipath first. For AES-GCM, you use the same each path in multipath uses different uses slightly different nonce construction than normal QUIC, which means that the path is part of the nonce, which means that you can actually, in your attack here, use all the paths, which these had individual replay windows kind of behavior because you have different packet number spaces for each path. And you have multiple different paths to spread your attack load over. So it's enables a bit of this scaling of the attack with the number of paths you're using. For GSM SST, you need to target one specific nonces. So if you you can't actually send the same attack traffic to multiple different paths. You will have to attack different keys if you send a different on different paths. So you maintain an ideal behavior in multipath with replay protection, etcetera. So multicast, we have a multicast extension proposals. It might something happen. But if people goes in this, they might have to consider this behavior for AES-GCM because basically, you can get an attack surface improvement by trying to send different attack packets if you have enough capability in the network to send different traffic to different multicast receivers. You can try significantly more packets. So you basically get to this probability to forge something, it becomes v times r divided by two to three. So how much traffic you send to an individual and how many individuals you can send. You can scale up the attack. So And after you made the forger with a s AES-GCM, you could actually tailor packets to particular receivers. So we are going to try to now push this with the security proofs in place, the standardization happened in its GDP, etcetera. We will work in CFRG for getting that process forward. But it would be helped to see what the interest is here in QUIC for the Cypher Suite, our Cypher Suites, I would say.

[01:14:34] **Max Franken**: And

[01:14:37] **Magnus Westerlund**: is there other authentication tag? Are there interest, etcetera? You can think a little bit about what it's implicate try to think about what the implications are with and how much if you have a need for saving more, etcetera, but considering what attack surface and attack probabilities you're after. But the advantage here is really that, yes, you will have different properties in SST because you get 140 only means 140. That can, of course, have substantial damage to a quick connection if it's if you can actually flip the bit rate. Like, for example, you can reset streams probably, if you know things like that. So it might have implications. So but, yeah, I think I'm done. So if any feedback to this?

[01:15:29] **Lucas Pardue**: Speaking as a chair, some of the the kind of off lift's feedback was whether, you know, if if this kind of work should be discussed in the quick working group, not this talk. Obviously, this is a FYI to kind of the folks in the room of of of some work that might be happening. But if if there is interest, then what would an appropriate venue be? And if people have thoughts on that, that would be interesting to hear.

[01:15:55] **Lars Eggert**: Hi. Larsa here at Mozilla. I'm not a security person even when I'm more awake than I'm now. So wouldn't this need to go into TLS? And Yes. Okay. And once TLS thinks this is the hot cheese, we just do it?

[01:16:12] **Magnus Westerlund**: Yes. Okay. I mean, basically, we did the draft in which is currently targeted TLS, would register the necessary TLS Cypher identifiers, the parameters, etcetera, and it also defines the header protection for QUIC, so you can use it for QUIC too.

[01:16:29] **Floris van Dijk**: So Okay.

[01:16:30] **Lars Eggert**: That that sounds like what I thought would happen.

[01:16:33] **Joseph Touma**: Yes.

[01:16:33] **Lars Eggert**: And I I mean, I'm not qualified to evaluate any of this, to be sure. I'm not not, like, saying this is bad or this is good. It's just like No. I want TLS to tell me we should implement this. Thank you.

[01:16:44] **Magnus Westerlund**: But trade is a little bit slightly different in TLS versus maybe QUIC for certain aspects. So that's what the why I'm bringing this up here. I will talk in ABT core where we have a completely different set of traders also. So but there we're gonna talk even shorter tags than this because

[01:17:03] **Martin Duke**: so Martin, you're cool. This is cool. And, yes, like, most of the work is in TLS, but I'm intrigued by the fact that I think there's some weird rough edges in doing like, if you just have a TLS implementation and just one day starts negotiating this thing, like, all our quick implementations will break because we because the tag lengths will be wrong. Right?

[01:17:27] **Magnus Westerlund**: Why why would that? I mean, they've the tag length follows the ciphers. Yeah. But, like, the sample

[01:17:36] **Martin Duke**: but you mentioned the sampling has to change for eight like like, minimum packet size, for instance, changes.

[01:17:42] **Magnus Westerlund**: No, it doesn't. That's the thing that's this by doing what we've done doing this draft, we ensure that it's not changing. We're using for for the shorter for AES 128 and AES two fifty six that use 128 bit blocks. It has the same property as current AES-GCM. We need the same amount of sampling to create the for ECB there. And and we basically fix the 256 block sampling by padding it out so that it will not break.

[01:18:19] **Martin Duke**: So Oh, so you you are gonna tag 16 bytes onto the end of the packet even though you don't need that.

[01:18:26] **Magnus Westerlund**: We we sample what's currently defined as a sample, and then we expand it with an additional 28 bytes of zeros just to make it ensure that it works.

[01:18:35] **Martin Duke**: Alright. But never mind. Yeah. Easier than I thought.

[01:18:38] **Magnus Westerlund**: So this is yeah. We're trying to fix these kind of which were otherwise would be rough Okay. Problems.

[01:18:44] **Martin Duke**: That said, there's, like, probably a minor editorial change, like, thousand one to authorize this cipher, but thanks. We

[01:18:50] **Lucas Pardue**: got two minutes, so please be brief, Christian.

[01:18:55] **Christian Huitema**: Yeah. I mean, I I love these things. I mean, we we should have a crypto agility and if TLS allocate the cut point to say, hey. Use GCM-SST, and we negotiate that, it should just work. And should. Yeah. Because in theory, all the code pass say, hey. The size of the checksum varies. It's a function of the algorithm. In practice, it's always 16. So there's a tension between what you should do and the fact that 16 actually works quite fine today. And I predict that there'll be a couple of bugs to fix.

[01:19:38] **Magnus Westerlund**: Yeah. It might be. I have I have to check this again, but yeah. Thank you.

[01:19:45] **David Schinazi**: David, Google. Just to respond to the last two comments, that's not how the interaction between TLS and QUIC works. We very much cannot just grab something, a code point from TLS, put it in QUIC. And I'm not I know you're not suggesting that, to be clear. I'm just responding to Martin and Christian. If you take AES-CBC and put it in QUIC, the wire format will work, but it'll be completely unsafe because your sequel your counter keeps increasing. So explicitly in all the QUIC implementations, we have a specific allow list of the TLS ciphers that we allow with QUIC along with whatever the parameters, like the min packet size and all of this. So that makes sense. Like, we'll have to add them one at a time. That's how we'll get agility in QUIC. I think, like Lars said, we'll wanna see what the cryptographers really think. Yeah. But they'll need a bit of input from us, and by us, I mean quick, because I think the innovation here is multicast. With TLS, you can't really do multicast TCP, and I think this is where it matters more, and that's the input that they need to know that this matters for them, that then they can bring it back to

[01:20:53] **Speaker 27**: us. Yep.

[01:20:55] **Speaker 28**: Yep. Okay.

[01:20:57] **Lucas Pardue**: We're we're out of time. I think there's clearly a a subset of people that'll get really excited about this stuff, but the rest of the people are just staring at the floor. So I'd encourage, like, encourage those folks to to get together. You know, if if there are inputs we can give to other groups that are considering this work, that's gonna be valuable even if it's something we don't do here or maybe we don't do here right now. So good stuff, Max. Please come up.

[01:21:34] **Max Fillinger**: Hi, everyone. I'm Max from Mozilla. I wanna give a quick, client side perspective on the adoption of HTTPS RRs and QuickV two, and this is based on Firefox's telemetry set. You can download the slides, and there you find links to the public telemetry as in all of this data is public. Yeah. For a browser, there are two ways to upgrade to h t p three slash quick, which is one out service HBS headers and then two, HTTPS RRs via DNS. Today, the majority of h three upgrades Firefox does is over out service HP headers. What this means is that Firefox always has to do or any browser has to do an h one or h two connection and then learns, the out out service h three signal on that connection, and then only on consecutive connections can it do h b three. And the alternative is HTTPS RR where we do a lookup in DNS before even establishing the first connection, and that way we have the h three signal right away and can connect over h e p three. Now we, as a browser, are obviously very eager to see more h e p three and are very sad when we can't do h e p three even though the origin would support h e p three. So why is this relevant? Here, again, as a diagram, either via service. First connection is definitely not h three. Later on, consecutive connections can be h three. HTTPS records, on the other hand, we fetch them via DNS right away, and the very first connection can be h u three. And so we reap all the benefits of h u p three on our connections. Where do I click? Okay. Second interesting perspective from Firefox's telemetry, we enabled Quick v two recently. For those that don't know, Quick v two is functionally identical to Quick v one. It just greases a couple of values, so we don't ossify the protocol long term. After having it rolled out, we see exactly well, close to 0% of Quick v two and a 100% of v one still. That matches other measurements. Why is that? A couple of implementations implement QuickV two, a couple don't, but, really, the, the drawback, the main drawback is that most deployments don't deploy v two. Yeah. Now I understand, that there is not much value in deploying v two, but if we wanna prevent as a working group that QUIC does not get notified, I think this is a good step forward. So I encourage everyone, to implement and deploy QUIC v two. Now to push all these efforts, forward, I built a little website. It's called safearoundtrip.com. You can, you can learn, what HBSR is all about in QuickV two, And then you have a little check where you can input your domain, check whether it does HTTPS RRs, what those are, how you could if you don't have them, and it will do a quick handshake to that endpoint. And we'll do it both of v one, offering v one and v two only. And that way, check whether the domain offers either or both. So with this small slot here, I wanna encourage you to check your domain, then publish HPS Rs so browsers can do h p three on the very first connection, and to please turn on quick v two or implement it.

[01:25:23] **Florentin Rochet**: Thank you.

[01:25:25] **Lucas Pardue**: Thanks, Max. This is just a short kind of snippet of some of the the work that you've been doing and presenting in in a more fuller format elsewhere. Right?

[01:25:33] **Max Fillinger**: Mhmm.

[01:25:33] **Lucas Pardue**: Yep. So folks are really, really keen on learning more. Do reach out to Max because he's got it. David?

[01:25:40] **David Schinazi**: Thanks, Max, for doing this. This is really cool work. Just David Schinazi, Google briefly. We've implemented QUIC v two, but we didn't deploy it because QUIC v two does not help with ossification. There is no way to know a priority using the HTTPS record or alt service that a server supports QUIC v two, so you're still stuck using QUIC v one for the handshake. You could do a compatible version handshake to v two, but that's actually doesn't help with ossification because that's you're still sending a quick v one initial. My understanding from chatting with you recently is that Firefox remembers the support for v two and can use it later, but that's still gonna be really, really small numbers. If we wanted v two to be useful for ossification, we would need a way to discover support through the HTTPS record. Well, I guess so currently,

[01:26:30] **Max Fillinger**: we offer, I guess, v one and v two as a client, and then we do grease the download path, right, as in the offer then decides for v two. So that would already work here. Firefox today does not remember that the server spoke quickly to.

[01:26:43] **David Schinazi**: Ah, okay. Then I blame Martin Thompson for lying to me. The ossification is on the upwards path because that contains the SNI and other parts of the client hello that are kinda hashed into the j a three and all that by all these kinda boxes that prevent DDoS. I don't I'm not aware of anyone looking at the downward path, so I don't think that'll help us much. Like, it's really the upward path that we need to grease and prevent ossification on.

[01:27:11] **Max Fillinger**: That's a good point. Okay. Cool. Thank you. Thanks.

[01:27:31] **Lucas Pardue**: Okay. I'm back again. Hopefully, my last time. So this is an individual talking about an individual draft not adopted or anything. This came out of a discussion back in Montreal around lunch. Can't remember who was there. Sorry. But it was like, oh, it would be like, you could do all this stupid stuff with Quic- and you would never want to do this. Although, so I wrote a draft about how you could do it, thinking it was a good idea at the time. The more I consider it, the more I'm talking myself out of the idea. But then other people are like, oh, no. Like, that makes sense now. So this is why there's a question mark. I I'm not presenting this because I think it's good or it's valuable, but that I I would I would love to capture the discussion about some of the stuff this relates to in case it helps inform other similar discussions about mutating any of the transport parameters in QUIC. Maybe if I can take you through the thought process, we can capture this in the recording, and next time somebody comes with a similar kind of idea, we can point them at me failing. I see Brian's already in the queue. I mean, give me a break, man. Yeah? Okay. So we start with a quote. This is Eric Idle. We're talking about idle timeouts. You're here and then you're not. The quick connections, maybe if you use Magnus' draft, they're gonna last forever. But realistically, they they're intended to be created and then closed at some point. Quic- goes into the details about how we can open and close connections. One of the ways of doing this is via the idle timeout. So this is just text taken from the RFC. Each endpoint advertises this max idle timeout, and then the effective idle timeout for the connection is the minimum of those two, kind of. Not precisely. Depends how you like doing maths. But the things I've boldened emboldened here to focus on on some of the things that kind of stick out to me. You have the prompt to name, but you got either endpoint can do things. The the outcome of if you do negotiate the idle timeout is that the connection is silently closed, is one of the good features of Qwic- that helps save things like radios from needing to wake up to send a message to say, I'm going away. Both endpoints can agree that at the moment in time, based on some of the maths, that they will just blow the connection away and move on and do their own things. But that if you do agree on a max idle timeout or an idle timeout for the connection, the endpoints commits to initiating an immediate close if it intends to abandon the connection prior to that effective timeout, which I don't remember ever reading that. It does make sense, but it gives you a slight pause for thought sometimes. Just to illustrate how this thing works in practice, say we have both the client and the server just there. They're configured however they are, maybe in static configuration or browser default behavior that end users cannot modify themselves. Client here is advertising thirty thousand milliseconds. That's what the units of the transport parameter. The server would say 60, and in this case, the effective idle time out would be 30,000, so thirty seconds. If the server had advertised max idle timeout zero, I. E, it didn't want to use idle timeouts as described, the client still trumps in this case. So it's not always the min. It's the min, but zero is special case, which is okay. Zero can also be represented as not sending that transport parameter at all, so omission would have equated to the same thing. This kind of makes the transport parameter a bit weird when you look at it in the light of some others, which I'll come on to on the next slide, but just doing a very quick AI powered survey of what different implementations tend to have as defaults. This is not exhaustive. Some of these are libraries that are then used by their respective applications on the top and set different values. Do not put too much stock in what is put here. I'll probably make mistakes. But interestingly, there's lots of folks picking thirty seconds discussing some of this surrounding the corridors. Some of that seems to be inspired by the whole nap timeouts being around thirty seconds and trying to keep connections kind of alive or something. Maybe one of the comments is you shouldn't be using idle time out to try and get around NAT issues, but I think that's probably its own research topic. We've then got to kind of step up to sixty seconds, and then this kind of cluster of people setting much larger values or indeed just setting no default whatsoever. I can't talk to those other than Cloudflare's quiche, and our approach was, well, the library itself shouldn't be having an opinion on this. It's an application matter. Any default we pick is probably not gonna be the right value, like a Goldilocks y problem. So by setting none, maybe that helps. It gives the initiative to the peer who also has a say in this discussion. So to kind of try and frame all of this mess together, I'll make some assertions that I don't necessarily believe hold anymore. But the the max idle timeout is unique across all of the the transport parameters that quick defines and that it is an actual negotiation. A lot of parameters are defining things you're willing to receive or at least the initial value of things you're willing to receive. Then at runtime, you're going to keep modifying that, say, the initial flow control for a stream, and then giving back more stream flow control credits. Or other properties to do with the connection that would maybe hold once and be used by the peer to continue speaking to you in the future, but they are not negotiated. They're just more statements. The other assertion is that a client could advertise multiple ALPNs and that the same idle timeout would apply to all of them. Why? This needs to be there is probably not going to have time to get to, but it was important in some of my reasoning around the problem statement for the draft. A single application protocol can have multiple use cases. So something like HTTPthree, you're gonna use ALPN to negotiate that, but the use of HTTP on any given connection could be wild and varying. You could have standard request response coupled with mask tunneling, coupled with web transport. You don't necessarily know precisely what's going to happen on a single connection until you've made that connection and start to see what's happening. Therefore, coming up with a static declaration at the start of the connection is maybe not ideal. You can have different lifecycle events within a connection. Although QUIC doesn't define a graceful close mechanism itself, HTTP does. That, in addition to things like TLS, either server authentication or client and or client authentication, application protocols might have their own models, and it's good that they do. So moving on from that, I'm not gonna ask people to prove them right or wrong again. We don't have the time. But to go into some of the details of this h three go away, effectively, if the server sent one, it's telling the endpoint not to initiate or the client endpoint not to initiate any new requests. The connection is kind of going unidirectional at that point. The thing that's going to keep driving the connection, we ignore pings but focus on application data, is the responses coming from the server, which limits it slightly. One of the open questions is that if you know you're going to go away and you send the data, do you then send an immediate close as required by RFC-nine thousand, or do you stop sending responses and then wait for your thirty seconds idle time out that the client negotiated? If that's the case, perhaps, just perhaps, renegotiating an idle timeout at the moment you sent the go away to something shorter would allow you to, from an application, push some of the timeout management you might be doing in your layer into the quick connection, Just let the idle timer look at exchanges of packets and data, maybe. If you wanted to negotiate, which I don't think you probably do, but if you wanted to, here is a way you could do this. Either endpoint could request an update to the idle timer for the connection, and the peer would then accept or reject that. You would lock this with some sequence numbers, and you'd have to have some DOS considerations about not changing the timer too often and not going forwards and backwards in time. You end up with actually a lot of complication here for what should be something that would maybe be a simplification. You could also disable the timer altogether, so you could grow or you could shrink the timer depending on the kind of use cases you've got, which leads me to thinking, would this cool thing you can do as an extension to Quic actually solve any real concrete problem? I don't know. Which then leads on to other any other transport parameters that you might want to change to solve other problems too. And therefore, if there's more than one to do, then we should have a generic way, maybe, or probably definitely not. And I'll finish that. Brian?

[01:37:20] **Brian Trammell**: Yeah. So I'll be honest. I put myself in queue primarily just to argue against whatever you were wherever you landed. But I think the answer to these now I have a serious comment. Right? No. Maybe yes. In that order.

[01:37:37] **Lucas Pardue**: To to these questions.

[01:37:39] **Brian Trammell**: To these questions. Well, no asterisk. Right? Like, so depending on how complicated your multi path situation is or whatever is going along along your path or you get, like, renatted onto a thing where you the big use case that I think is useful is if you were trying to maintain a long running connection without doing a reset and you get renatted onto a different path and you notice it. Not sure how you'd notice that. Right? Like, that's and then magic occurs. But I really like the mechanism that you came up with in trying to solve this problem that might not exist. So I think that's worth talking about. Okay. Thank you.

[01:38:16] **Lucas Pardue**: We are at time, so if you could be very brief, folks.

[01:38:20] **Ian Swett**: Okay. Ian's by Google. I think a number of comments that came up. One, and we've had bugs with this ourselves. The most important thing is that if you idle time out early, tell the peer. Because it turns out if you don't and we've had this bug. Like, it really does cause tail latency problems you don't wanna deal with. So, like, fixing your implementation is probably, like, the, like, you know, step zero in this. Chrome's also implementing or experimenting with the three hundred second idle timeout. It is plausible that might happen in the next few months. And so, like, you know, that's not quite so ossified maybe as we thought. How much of this is, like, the lack of a go away at the quick layer and instead of putting and then the other question was oh, settings make me sad in h p two. So, like, making any any of the stuff updatable makes me gives me, like, trauma. And I don't know. I'm not really sure if you actually need if you negotiate this extension, do you need to be able to reject it? I mean

[01:39:22] **Lucas Pardue**: That that was a reject at the idle timeout. You already said that you'd negotiate like,

[01:39:27] **Ian Swett**: you support the extension. Like, you get what you get. You don't get upset. Like, now it was just, like, a go away or, like, close the connection. Anyway.

[01:39:34] **Lucas Pardue**: Okay. Cool.

[01:39:38] **Speaker 29**: Do you have any data how often you close on idle timeout or on regular close?

[01:39:45] **Lucas Pardue**: I don't know.

[01:39:47] **Speaker 29**: Would be nice to have some data. There might be a problem.

[01:39:49] **Lucas Pardue**: It would, and if anyone would like to volunteer data too, I think that would maybe help this kind of discussion.

[01:39:54] **Speaker 29**: And on the other questions, actually, yeah, maybe there's a general case for it, probably not for our parameters. I tried to just look at the RC, but the data tracker didn't load, so I don't know.

[01:40:03] **Max Fillinger**: Okay. Thanks.

[01:40:05] **Speaker 27**: So I kind of went the opposite way. When I first read your draft, I totally disliked it, I'm starting to like it more and more. The the reasons are, like, I'm I like I like hole punching. I like connection migration and having different timeouts for different path that you're using seems very useful. I also like mask protocols, they have very different properties than H3, as you said, and being able to act upon that seems very useful. Would updating other transfer parameters also be useful? Probably, but I am kind of scared of doing this, so I would like to not do that in this draft.

[01:40:47] **Lucas Pardue**: Okay, thanks. It does remind me, I forgot to put on the slides, I think multipath does change some of the design rationale we had for the initial approach to idle timeout, But I'm going to try and get people in the corridor and discuss this some more. So thank you, everyone. Who's up next? Yes.

[01:41:15] **Max Fillinger**: Hi, folks. Max Fillinger from Theo Berlin with your favorite topic, multicast. Actually mentioned for the second time today, thanks to Magnus. So, yes, we talked about multicast in Qwic-quic before, but today, we want to talk about it again because some things changed. A lot of external things changed, and today, we want to talk about real world use cases. We want to talk about actually running codes and some of the implementations we now have and why it might now be finally the right time to add multicast to the quick toolkit. What we will not talk about today is any technical details on the drafts, test two, any implementation details, anything like that. Right? Nothing about adoption, nothing about the inherent trade offs you get with multicast, right, which are about privacy, security, and so on, but we just want to show what we actually did here and how this might be a good thing for Quic- have. Right? But we're, of course, happy to discuss all of these issues offline or on the list. Okay. So really briefly, multicast, many people might not in this room. I mean, most of you will know this, but multicast is actually used today on the Internet. Right? There was in mobs yesterday, there was this panel discussion from some operators. And Broadpeak, they used multicast ABR to stream some of the games of the last World Cup. Right? So there are legitimate use cases, and there's legitimate use of multicast today. The problem is that deliver the delivery path is quite complicated. The solutions that are out there are are all very, very much proprietary, and they're also not that secure. But even though these issues exist, right, it is still being used on the Internet today in the domain. Okay. So why do we want multicast in QUIC? Well, QUIC runs over UDP, so it's a very, very natural fit for multicast. Right? QUIC gives us a path into browsers through web transport and so on. So we can actually have a realistic path, I will show you we will show you with one of the implementations that is actually there now to have multicast natively play in the browser. Right? Again, this has security and privacy implications. Not gonna discuss these today, but it's a feasible path. With QUIC, we get provided get security and reliability, which, again, if you do it with UDP, regular multicast, you have to add a lot of stuff on top of the UDP multicast to have things like fallback and reliability and security encryption and so on. Right? But also very importantly, quic gives us a full end to end solution for this multicast, and we don't need a 100 different delivery paths. We don't need a 100 different options and middle boxes and whatever to get multicast working. We can just get it with QUIC end to end completely. And, of course, QUIC is designed in a way that it allows for extensions to fit cleanly, so getting multicast into QUIC is actually kind of elegant. Right? And it's not bending TCP or whatever making it somehow work, but you can just quite naturally get it in. Okay. So to the running code, we now have three implementations, and they are basically on various different levels of complexity at the hackathon on the weekend, and Louis will talk about this in a second. We got a very minimal implementation. Then we have the Flexicast implementation that was presented before, And then now we also have a running media over QUIC multicast implementation that I will talk about afterwards.

[01:45:10] **Speaker 11**: Thank you. So, yes, I'm Louis. So this one comes from the hackathon we made this year. So the idea was to start from QUIC and see what we have to change to have a minimal working multicast in QUIC. So we had this hackathon. We modified six implementations with not that much line of codes. And as we can see here, the basic idea was just to announce the multicast tree where we can receive the multicast data, so that is one change. The second one is to be able to open a multicast sockets, and then finally, to receive the data. So we made this during the Rakuten. I promise that at least one of the six implementation was written by a human, we can do this in a single day. And then as a use case, we use RTP, and as you can see, we managed to make an RTP stream over this implementation running on the laptop and also even on iPhones. So just to show that it works. This one? Okay. And then that was a previous work where we used multi pass to do this more cleanly. So it's a complete design, a complete implementation, but it's much more it's it's much heavier because we require multi pass and modify multiple things inside QUIC, but we could show that we can scale to a lot of traffic.

[01:46:36] **Jonathan Lennox**: Alright.

[01:46:38] **Max Fillinger**: Thanks. And now for the the media over-quic multicast extension. Right? So this is on based on the the one of the two drafts, and it basically uses the existing mock architecture to, again, relatively naturally fit in multicast. Right? Because in mock, just very briefly, you have the the relays. Right? And what we did with this implementation is basically that your mock relays, they would just emit multicast. Right? And in addition to the regular unicast channels. So what happens is that the client just connects to the mock relay like it would do any other way. It will get the traffic over unicast, but at the same time, it will negotiate multicast support through through the extension we implemented. And, again, we implemented this. This is in a browser. Right? It's an extended or modified browser based on Firefox. And we negotiate it, and if multicast works, right, you will exchange some frames. You will announce some multicast channels. The client, the browser in this case, will try to join this multicast. If it succeeds, then we're gonna get the the data over multicast, and the unicast transmission will stop. And for this, we use reliable stream frames, right, because that's what mock uses, and, basically, you get the scaling benefits. Right? And for this implementation, we also used integrity frames as an additional layer of security, right, to make sure that you can't inject traffic. So, yes, this this is basically the model really quickly. Again, if the multicast doesn't work, the only thing you actually lose is that you add a few frames at the beginning of the connection, and after that, it's just a regular, normal, quick mock web transport connection. So there's no additional overhead. It's there's no issue if the client doesn't support it or anything. Right? You don't have to jump through any hoops to get this working. It just fits again very naturally in there, and it's like this opportunistic approach to multicast where you get the benefits of it without having too many of the drawbacks. So if the clicker works right. So as I mentioned, seamless for clients. Right? We tested it again in the browser of a couple 100 of clients, and if the multicast traffic stops for some reason, you don't see it in the video. If you if if you switch from unicast to multicast, you don't notice it as a client as as a user watching the video, And I think on the this plot, you can tell when I so this is the egress, right, of of one of the the servers for this. And, again, this is running on the Internet today. Right? You can just go to our demo website and build the demo version of Firefox to just use this. And you can probably tell when I turn multicast on and off, right, just based on the egress. So even with this very naive implementation that is not optimized in any way, shape, or form, including integrity, including all the overhead, you can still get a egress traffic reduction of over 80% already. And the added latency you have for the multicast authentication and everything is around sixty milliseconds. Right? So it's, again, even in this naive implementation, you already have quite significant benefits. Okay. Yeah. This is a QR code to the the repo where you can try it and to and to website. And, again, what we want or what we would like from the quick working group is discussion on these implementations, discussions on the use cases. Right? Also, with the perspective of discussion that happened yesterday on how you can get more quick adoption, right, and maybe adding features to the quick toolkit that can't be done with TCP and old h two and so on, you know, could be one option to extend the quick the quick landscape with yes. Okay. Thanks. As I

[01:50:44] **Lucas Pardue**: see there's quite a lot of chant that the speakers wouldn't have been able to benefit from. So if you made a comment, I'd like to invite you to the mic as well just to perhaps verbalize that if you'd be comfortable.

[01:50:57] **Gorry Fairhurst**: Gorry Fairhurst, what about congestion control? Because that's where Jake left the thing, I think.

[01:51:02] **Max Franken**: I mean, we we wanted to discuss multicast congestion control, I think, in two ITFs ago and CCWG, and nobody really cared there because there was no application for multicast. So chicken and egg problem. Right? But we have solutions. We have solutions on how to deal with this flow control as well. Right? We we can do a lot of things. We have it in mind. Yes.

[01:51:22] **Florentin Rochet**: That's good.

[01:51:23] **Gorry Fairhurst**: I'll not take the floor in a

[01:51:24] **Kazuho Oku**: moment. Thanks.

[01:51:38] **François Michel**: François Michel, Apple. Thank you very much. I was at the hackathon. I implemented the minimal example that you two came up with. So I would like to thank you for that. Thank you for agreeing on the design on a minimal solution. What I would suggest is to continue on that path and continue to agree on parts of the the protocol you would like to, you would like us to to implement to do interrupt with you. There are currently two drafts. Most of the draft are pretty similar, actually. There are several differences. One is the use of multipath. The other is how you handle authentication and integrity. But I think there's a good common ground between the two drafts, so I think it would be helpful if we if we if you could agree on some part so that we could move forward and continue interrupt.

[01:52:35] **Max Franken**: Thanks. Yeah. Also, to maybe add to this briefly is that we actually got public funding also for at least the next year. We will work on this, have multiple people work on multicast quick full time on my own.

[01:52:48] **Magnus Westerlund**: Magnus Westerlund, Ericsson. I do think having a multicast extension for QUIC would be something very useful in the toolbox. I think there's a number of use cases. There's clearly problems to work through to give robust, secure, and reliable behavior in a number of cases, including congestion control, ensuring that you have the right security properties, etcetera. But I think it's time that's working. Roop maybe steps up to start doing working on this.

[01:53:22] **Max Franken**: Yes. Thank you.

[01:53:31] **Speaker 28**: Hello. I'm also interested in the multicast use case. I had a question, though, about the end to end security, guarantees that you had touched on. It seems like if you're going to do a multicast where you're having a relay be one of the endpoints in in which you're sending, the unicast connection and into multicast through that end to endness is actually going to apply from the source to that relay and not necessarily the multicast ends. Can you touch upon that a little bit?

[01:54:07] **Max Franken**: So so, yes, the the the how the design works is basically you have the unicast connection as the secure anchor. Right? And through that, you exchange all the security relevant bits. The trade off you have is that you chain share the keying material between all the receivers. Right? But then the connections, everything is still encrypted. It's just all the receivers share the key, so you get all the the trade offs you get from that. One of them is, of course, that you could do packet injection. Right? Like, of the receivers could construct a packet that confirms of the AAD, but for that, we have the the integrity frames, which are basically hashes against the packets. Right? And they allow you to uniquely verify that the packet was actually sent by the source itself and not injected by somebody someone in the middle. But that's, yeah, that's that's how far we got so far, right, or what's what we have so far.

[01:54:55] **Speaker 28**: Right. So I guess stronger notions of authenticity are not necessarily going to be, covered in that, key sharing sort of, way of doing this. Right?

[01:55:07] **Max Franken**: Exactly. For authenticity, you need you need the integrity frames. Yeah.

[01:55:10] **Speaker 28**: Yeah. Okay. Thank you.

[01:55:14] **Etienne**: Hey. Etienne. There's something that I find very intriguing with the idea of using Quic as a control channel here is and especially the fallback from Unicas to MultiCas is you could for some use cases, are you considering having retransmissions on the quick channel so that I'm getting a multicast stream, but then I missed just one packet? And I can ask the on the quick channel, please give me that single packet so that I can Yes.

[01:55:42] **Max Franken**: Exactly. That's that's I mean, again, we could talk about this for three hours, but the the the the point is, yes, you can do retransmissions. Right? This is reliable data through multicast, and you can even go as fast and say, okay. I noticed a lot of receivers have lost this packet, and I can retransmit it through a different multicast channel to get it to multiple receivers at once, or I can retransmit it through the unicast channel individually to the single receivers to get it fully. Right? But for things like five trans or whatever, it's yeah. You can do it.

[01:56:08] **Etienne**: Thank you. I'll be quick. No pun intended. Did you say that you have a different security framework for the content than from what you use for Quik itself for the individual legs?

[01:56:21] **Max Franken**: Sorry. Can you repeat? Sorry.

[01:56:22] **Joseph Touma**: Did did

[01:56:22] **Etienne**: you say that you have a different security framework for the content end to end?

[01:56:29] **Max Franken**: No. We we used it we used the the same key mechanisms that Qwic uses, but because the keys are shared for all the receivers. Right? Yeah. You have this integrity frames in addition to that to prevent forgery and injection. Right? That's that's

[01:56:43] **Etienne**: Oh, additional integrity frames?

[01:56:44] **Max Franken**: Yes. Yes. Yes.

[01:56:45] **Etienne**: And and those are end to end encrypted between the source and the receiver?

[01:56:49] **Max Franken**: Yes. You can. There's different ways to do this, but you can send those on the unicast connection. Right? And so they are

[01:56:55] **Alessandro Ghedini**: encrypted fully.

[01:56:56] **Magnus Westerlund**: Yeah. Got it.

[01:56:56] **Speaker 28**: Thank you. Yep.

[01:56:57] **Lucas Pardue**: Thanks. K. So kind of trying to summarize that discussion. I might get this wrong. That that seems like a a sense of people are interested and that there is potential driving use case maybe in the mock space, but both well, the mock working group's very busy. There's a suggestion in the chat that maybe this is a topic that would benefit from a of some kind. I I don't know. I think we should probably get together the some of the chairs in the ADs and and talk about this topic. It's been presented in the past. There was a lot of interest back then. It would feel sad if we just did nothing and and made these folks wait and come back again in a year's time when their funding had just run out. So, Maybe we can find some time this week to do that. Thank you. Thank you, Max. Flores, we have a few minutes, so you have all of the rest of the agenda to yourself.

[01:57:56] **Floris van Dijk**: Alright. Hello. So, yeah, I'm Floris from Number Zero. And together with my colleague, Deva, I have been spending a little while implementing multipath and hooking it up to NAT traversal. This started out as a fork of Quinn. You can find it's there. And I also wrote up a little bit how we do the natural reversal. Does it move? Oh, yeah. So a very quick overview of how we get this to work is like we essentially assume that the connection gets established via relay path. The quick stack just sees this as another IPv6 unique local address, so it's just a normal path. So we establish path zero over that essentially, and then we do the hole punching coordination of that. Usually, the IP parts, the direct parts are not immediately there, and we need to hole punch those. So once we start whole bunching, we do this with normal path validation, so part challenge, part response frames from RFC 9,000. And once the parts once the prod succeeds, then we open that as a new path. We base this on the draft from Marten Seemann, a quick NAT traversal, and we bear some familiarities with this. So just like in multipath, the client actually drives the whole thing. So the server can only advertise its address candidates. It does this in these add address, remove address frames. And then whenever the client wants to actually initiate NAT traversal, then it sends out in our case, this is where we differ from from the other draft. We send out the reach out frames. The reach out frames, basically, each contains an IP address and usually send those in a bunch. Once at the same time as we do that, basically, that's like traversal initiation. So the client will, at the same time, send part challenges to all the address candidates that it received from from the server at this point. And the server, when it reaches a bunch of reach out frames, will do the same. It sends part challenges to all the addresses in the reach out frames from the client. If you do that, if you retry those a few times, hopefully, you will punch some holes. So we don't follow the ICE pairing kind of thing. This is kind of not necessarily because we don't like ice pairing, but it was a way of keeping this kind of very close to what we already had. The probing is kind of our path. Yeah. I have to go fairly quick, I think. Does it move? Yeah. We initially so we initially abandoned we we initially tried to do the probing at least on the client side using the correct path ID already of of a new path. We had to abandon this because this just created too much path churn. The problem with the path churn was that, basically, each path, like, every time you have to abandon a round, you had to you had to consume a lot of a lot of CIDs. You had to wait till till the peer increases the max path ID and until the peer issues new CIDs. And only then could you start kind of probing them. This does mean that we had to kind of introduce the notion, like, if this extension is negotiated together with multipath, we do bring back the notion of probing frames because otherwise you cannot do off path probing on multipath because every packet is is a migration. The benefit of that is that it's actually completely orthogonal to to to multipath in a way. You could actually do this with with normal without multipath as well, which is kind of elegant. As I sort of already hinted, issuance CRDs was was a big problem for us. We kind of skirted around this by currently, all our paths are linked. That's very bad. We need to solve this. But we we really like what in in in early our earlier attempts, we had, like, a couple of kilobytes of CIDs at the beginning of a connection, and that was just not workable. So we will try kind of interleaving these with reach out frames probably. Otherwise, completely more radical is like, can we negotiate some sort of shared key and an algorithm to generate CIDs and then you have just CIDs as many as you want? That's quite unlikely. That would not be the ideal outcome, but that was just an attempt at, like, trying to think of what can we do. Probing packets in multipath, I I I already mentioned. It was kind of makes sense for us to bring that back, and it made it, like, much nicer. So that's kind of an interesting outcome for us. And the last point, I haven't really talked much yet, but yeah. Ideally, we kind of want to establish one connection across multiple paths, and we don't know which of the remote endpoints will be alive, and we would like that to be a single path, a single connection, sorry, with multiple paths. We were thinking of, like, can we open this directly on different path IDs? Speaking to other people already here, maybe it makes more sense to actually give this, you know, separate connection attempts and then on the client, throw one away. There, yeah, there are some trails there as well. Yeah. That that's all I have.

[02:03:17] **Lucas Pardue**: Yeah. We're out of time. So thank you. This is Floris's first IETF. The peer to peer kind of use cases are not strict. I don't even know if they're in charter, but extensions and building blocks to Quic that could enable such use cases potentially are. So I encourage anyone interested in this space to to reach out or you to reach out to them and and maybe, you know, quite early right now, but this is something we could discuss on the list and maybe bring back in the future once we figure out some of these open questions. So and with that, I'd like to thank all of our speakers and the AI minute taker, and we'll see you on the list. Thank you, everyone.