**Session Date/Time:** 21 Jul 2026 09:00

[00:00:17] **Gorry Fairhurst**: Okay. It's 11AM. Welcome to t s v w g. If somebody in the back could close the door, I would appreciate it. The noise is quite extensive. Thank you, Martin. This is the ITF Notewell. It covers a lot of the expectations regarding participant behavior and legal obligations, IP obligations, etcetera. If you have not read the note well, please scan the QR code or type IETf-note well into your favorite search engine and learn all about it. We're on day two, so I think most of us are familiar with how MeetEco works. If you are remote, we strongly advise you use a headphone head headset of some kind to avoid any echo cancellation problems. If you have not done so already, please scan the QR code that's posted in the back of the room or on the mic stands to join the session so that we have a record of your presence here as well as enabling you to participate in the queue, shows of hands, etcetera. Here are links for kind of the standard resources at IETf. And for those of you in the back, appreciate you your support. The doors do not close themselves, and it's quite noisy out there. So if you can just monitor that and help us keep the room audible keep proceedings audible, that would be very helpful. Thank you. Here's today's agenda. We're focused on a number of adopted drafts that we have in retrospect. We we based on what happened in Shenzhen, we asked for ninety minute session. That was a mistake. We're we're overloaded, but hopefully, we'll get to at least one or two of the the, if time permits, topics. Would anyone like to bash this agenda? Okay. Hearing nothing. We'll move on. It's a pretty spicy interval on regarding drafts. A couple RFCs published. Congratulations to the authors of those drafts of those RFCs. We have one document sitting at the RFC editor, and we're gonna talk about u s p user EXP today. This is our routine pitch for viewers. T s v w g is a collection of different interest groups. It doesn't work if everyone stays in their silo. I ask you each and every one of you to come out of your comfort zone, maybe review some documents that are not in your particular area of interest so we can get good review of the work that working group is doing. At this at the moment, nothing is in working group last call. We recently updated the working group milestones because they were slipping. Actually, all of these documents, we're gonna discuss the milestones today. There might be reasons to have them slip considerably. We will talk about that as we get to them.

[00:03:43] **David Black**: Just to comment, the red on the dumb thing, milestone, is because the

[00:03:49] **Zaheduzzaman Sarker**: way we say dumb, like when you submit something to the ISG, we say, like, it's done. But then that document got re returned back. So I think today, we'll we're gonna have some discussion and say, like, what to do with it. Then we'll change the up to the milestones.

[00:04:03] **Gorry Fairhurst**: Right. That document will presumably have a new milestone, so we'll have four active ones. Do you want to talk about this?

[00:04:14] **Zaheduzzaman Sarker**: Yeah. So we have published RFC nine thousand nine fifty six, which actually updates RFC 8,325. And while we're doing so, we say, like, hey, need to send an LS to IEEE 802.11 and WFA. Perhaps WBA also we should send. Greg, thankfully, proposed some text. Thanks for doing that. And right now, we have sent it to the I believe liaison coordination, because we actually didn't figure it out who would how to send it to these working groups for us. So hopefully, this will be processed from the IAB coordination liaison coordination. So this is an outgoing LS from us too, those two groups.

[00:05:01] **Gorry Fairhurst**: Okay. That was our last chair slide, so let's jump right into the presentation starting with Wes.

[00:05:09] **Wes Eddy**: Hello. Can you hear me okay?

[00:05:12] **David Black**: Yes.

[00:05:13] **Wes Eddy**: Alright. Well, I'm Wes Eddie, and, I'm gonna talk about this draft on user ports and port identifiers for experiments. Joe Touch is actually the, editor of this document at the moment, and, he can't make it today. So I'm gonna be talking about the status and, next steps. We've actually been working on the document in the working group for several years. It's been mature. It went to the IESG for balloting, and the IESG put their ballots in on it. There are several discussed positions that I will discuss on the next chart, and those haven't been addressed yet. The document is currently expired. So in case you weren't paying attention in the last few years that's been worked on, this document is defining a couple of new ports that can be used for experiments. What that really means, in my opinion, is it's intended for use cases where there are applicants to IANA for port numbers, and they may not qualify completely for a normal port assignment. But this provides them a way to get stable port numbers that they can use while testing and otherwise maturing their protocol or their implementations. Sometimes these type of applicants aren't happy with being told that they should just use a dynamic range port. And sometimes there have historically been problems using the existing ports ten twenty one and ten twenty two that are allocated for experience because they're in the system range. And I guess also not mentioned on the slide, there's no way to deal with conflicts in that ten twenty one and ten twenty two port range if there were, for instance, multiple protocols trying to make use of them. So this draft fixes all those things. I have a interest in it. I'm one of the report reviewers with Joe. And so, I think because of those years of experience dealing with, many applicants and seeing that there's a need for this. That's why this draft was originally brought to the t s v w g. So at the moment, there are actually five discussed ballots from the ISG, and there are even two no objections supporting those discusses and one abstains. So it's not a great situation from the standpoint of ISG support to publish this. And to to move forward, we have to address those ballots. Some of those comments that are embedded in the ballots have been addressed in revisions, though they're not. Those parts of, the discussion aren't really cleared out of the ballots yet, I noticed. There are a lot of, remaining issues, though, and they fall into, well, the main ones fall into a couple of classes. Corey sent a nice summary to the mailing list last month, and my even more compressed version of those remaining issues is that there's quite a bit of concern or I would even say confusion about firewall traversal and how these ports work with regard to that and whether this creates new security concerns. So we have to work through that. There's also questions on the what what's called PEXIDs in the draft, which are identifiers that help to separate multiple experiments that might use the same port. There's question about whether those are necessary and how they would work with all transport protocols. I think people agree they can envision how it works with TCP or UDP, but they're not sure about other things. So working on those discussed ballots and addressing the points that the ISG wants to discuss is something we have to do to move forward. My implicit assumption, but I think the chairs want to discuss if the working group still wants to pursue this. I assume we do, but I'm a little bit biased being one of the ports team members that wants to use this draft. So, I think that's something the chairs would like to hear some feedback from the working group on. My proposed next steps are that, we should engage with the ISG members on really what a typical use case for this looks like and explain, better maybe what a potential, port number application looks like that wouldn't normally qualify for a regular port assignment and so would be recommended to make use of these experimental ports and walk through how that applicant's code would make use of, these ports, how different types of firewalls would need to be configured in order to allow their usage, and, even work through how the PEXID would work for them. I think by working through an example, it makes some things more clear that are muddied in the the current ISG discuss comments. So that's how I'm thinking to move forward and address those discusses. Curious if there are any other thoughts or concerns. And, I think, chairs, this would be a good time to open up mic on this because I can maybe win you back some time for the other presentations.

[00:11:35] **Gorry Fairhurst**: Yes. So I I do wanna thank Wes for Joe was really unable to continue and bring this document to completion, and so I I appreciate Wes stepping up to lead the effort here. So if anyone has any comments on this course of action or wants to help Wes, now would be a good time to approach the mic. Gory?

[00:11:58] **Gorry Fairhurst**: Got it first. Just a small clarification. The ballots closed for this document. We returned it to the working group. Really good to get these discussed topics solved, then it'll have to be reballoted afterwards if we decide to proceed. The other thing is this looks like super good to me. If it had examples and people contributed to those examples, I think that would make things much clearer.

[00:12:22] **Zaheduzzaman Sarker**: You're right. I think I think, anyway, this is the return back to the working group. So whatever we do with WES, this need to be, like, worked through during the during the its lifetime now. And in the new renewed lifetime in the working group before you can introduce to the IHG. But I think, from my point of view, most of these things are editorial, except the PX ID. I think there might be a couple of way up to fix that one. I think that's where the working group should work on. And keeping that mind, like, ISG might change when we submit it again. And

[00:12:56] **David Black**: so

[00:12:57] **Zaheduzzaman Sarker**: it's more about, like, try again with all our solutions that we think is we are comfortable with and we think it works. Michael?

[00:13:05] **Michael Tuexen**: Michael Dickson. I would also say that I would really like to see this document going forward. Willing to help there. But I mean, I'm also one of the port. So I don't know if this is if you need input from someone else from the work group.

[00:13:29] **Zaheduzzaman Sarker**: Yeah. That's great. Is there anybody else that has some concerns?

[00:13:38] **Tim Chown**: Tim? Hi. Tim Cheyne. Just an observation as someone that co chairs the Interdeer reviewer team. I noticed on the reviews by area, there are six reviews, and they're all ready, ready, ready, ready, ready. So it's a bit I mean, it happens, and then the ISG has five comments. It's just a bit of an unusual situation.

[00:13:58] **Zaheduzzaman Sarker**: I think this is this is a bit unusual situation. It's like when the Eddies were writing so the reviewers, director reviewers has their own view, but the Eddies make their own calls. Right? So I mean, this is the area the reviews are for their aid, but there are some confusions. I think I'm saying confusions because when I read the discusses, I think it's a bit need to be clarified what we're doing in this draft, and Wes find nicely pointed that out too. So I'm hoping, like, Wes, you to be added as a co editor on this document, and you'll work through this one. And thanks for doing that.

[00:14:35] **Wes Eddy**: Yep. No problem.

[00:14:38] **Gorry Fairhurst**: Yeah. So with no other comments, hopefully, Wes, we'll get a report from you in Heard. Oh, yes.

[00:14:45] **Zaheduzzaman Sarker**: In the queue.

[00:14:46] **Gorry Fairhurst**: Centimeters Heard. Mike Heard. I'll contribute to reviews if this effort pops back. Thank you. Great. Thanks. Lovely. Hopefully, Wes, we could hear from you in San Francisco. We're getting up to maybe we'll have some made some progress on this. We don't need to readopt or anything. Right? It's already adopted.

[00:15:06] **Zaheduzzaman Sarker**: It's our document, but we just need to add in my list and know.

[00:15:09] **Gorry Fairhurst**: Yeah. Okay. I'm not hearing any objections to this course of action, so I think we're we're good to go. Yes. Alright.

[00:15:15] **Wes Eddy**: Thank you.

[00:15:16] **Gorry Fairhurst**: Thank you, Wes. Alright. Next up is Magnus to talk about d t l s chunk. If I can change this oh, there we go.

[00:15:37] **David Black**: Okay. So Magnus Vesplund. I represent the coauthors here, Jan Matson, Claudio, and Michael Thaksen. So, the DTLS chunk. Let So bit of reminder where the what this is. It's an SCTP chunk to carry or is encapsulate security encapsulating the rest of the SCTP packet payload. It's encrypted and integrity protected, uses detail as record format as it is inside the chunk. And it's keyed by key management methods that separately specified. So and the key management traffic is transmitted unprotected, the rest requires so we have a process for setting it up, negotiating the key management that's in the chunk, and then the chunk defines how to protect the packets. There's one IPR declaration on this, which is a defensive one.

[00:16:47] **Michael Tuexen**: I can

[00:16:48] **David Black**: go read it. What's happened since last time is that we actually made some changes in the working on this document. So we actually stripped out some fields because the main change that happened with the chunk was that we actually went to specify. We select a single DTLS 1.3 record format configuration, which is one without length fields and with a 16 bit sequence number. That made us the prepadding field to be only one always be one byte, and therefore, we could remove the indicator bits in the chunk header. So that's the change here on the chunk side. We also updated the parameter to once we actually shrunk the space for the key man key management method identifiers to eight to a single byte. But the other thing that was the maybe logic change was that we actually realized it's fairly not too complex to support simultaneous open and that we actually would prefer to have support for it. So we have incorporated support for simultaneous open. And what's happened here is that endpoints, when they're negotiating with this parameter, they will indicate, can I do act as a client, can I act as a server, or can I act as both? So if you support simultaneous open and wants to be able to use it, you need to indicate they can function as both client and server. And in those cases, we will use the tiebreaker field, which we added to, determine who takes the client or server role for the key management. So so this is then you and that also in influence the selection of the key management method depending on the role. So but we have a well defined algorithm. We also clarify that if you haven't another specification defining, which is the mandatory to implement ciphers, we we we included these and say, okay. These should be supported or must be supported if you otherwise, it's not indicated in your application or specifications. We also clarified error indication in the establishment procedures and and how to clarify that you if you require this, etcetera, error message for this. So we made API API updates to match this and a lot of editorial improvements. So the other good news, okay, is the actual, improvement in we actually done interoperability here. We have two independent implementations of the chunk. One was done in by Red Hat in Linux, the in the Linux SCTP stack. The other implementation was done by Ericsson in their our user space stack where we use we use Wolf SSL's DTL as implementation as for the record protection. Linux SCTP uses in built in crypto crypto functions combined with realization of of the actual DTLS record in in the kernel. Ericsson built a test app that's using the socket API on the Linux and implements the key management that I will talk later about, where we actually had two different realizations of TLS stacks for the key management method. So we used WolfSSL on the key management too and OpenSSL on the Linux side. And with this, we actually achieved interoperability between these these two stack exchange data. We actually tested, a number of different things, not just the basic. We didn't first, we validated we could actually have the pre shared key, ensure that we get communication. Then we with the key management methods using the socket API, etcetera, to drive the key and change. We also done multi simple single multiple rekeyings and association restart. We actually tested this with restart. I think the only thing we haven't, which is a little bit trickiest to actually trigger actual simultaneous reconnectivity connections. I think we'll have something we'll have to try to do more tests on later, but the former design teams and the authors group here, we think this has become quite stable. We consider it based on achieving interoperability, etcetera. We don't expect changes really to the wire formats, etcetera, that was actually being sent. And the specification text, I think, is quite clear. And so at this point, I think we do want some more external review if this is ready. We have one minor open issue, and I think we've tried to do a little bit just one more editorial check. But basically, we are at the stage where we could go to working plus call with this from our from the offshore team's perspective. So and the open issues are very minor. Do we actually need both the abstract and socket API? It's currently written there. It's the open The abstract API is quite a lot of text, also the socket API. So there's a lot of text there. It shows that it's clearly to multiple different ways we implemented the API, which in some sense is good. But, yeah, if anyone has an opinion otherwise, yeah, I guess we will probably keep it. It's it's there, but we just have one small change, I think, addition we need to do, and then we're done. So let's see. Yeah. Yeah. So if there's any comments on this, otherwise?

[00:23:37] **Gorry Fairhurst**: So, Magnus, so you have the one issue which is just really an editorial one, right? Whether you have the abstract API? Yeah. Okay. I would be happy to take this to last call as soon as you resolve that one way or the other. Yeah. So just let us know. I I would anticipate working with the last call before San Francisco. Yep. Certainly, as soon as you're ready. Does anyone have any comments about this API issue or anything else?

[00:24:09] **Michael Tuexen**: Michael. I asked that earlier, but do you use the abstract API in your Ericsson implementation?

[00:24:20] **David Black**: I mean, we we in some sense, it's completely realized internally. It's not the actual strict API implementation from that perspective. So

[00:24:30] **Michael Tuexen**: Okay. So for the socket API, we have an implementation. For the abstract API, we don't. I mean Is that a is that a description or is that

[00:24:43] **David Black**: I mean some

[00:24:43] **Michael Tuexen**: some aspects of the abstract API are used in

[00:24:46] **David Black**: Yeah. I would say that it's in some form, but it's an integrated I mean, it's internal in inside the software components because it's it's much more integrated than the clear cut socket API in. Okay. Yeah. So it's more like between modules. Okay. One question

[00:25:09] **Michael Tuexen**: for the chairs is we had a request for early assignments of some error courses. Could you trigger that somehow?

[00:25:20] **Zaheduzzaman Sarker**: You asked for it. It is on the to do list. It will be triggered. Perfect.

[00:25:25] **Michael Tuexen**: Because that that makes all the the protocol assignments to Vienna so this code then could go into releases. Yeah.

[00:25:34] **David Black**: Well, that we can do now. I think the only thing we can't do is the chunk flags on

[00:25:39] **Michael Tuexen**: the The chunk flags. But but then yeah. I mean, we changed the chunk flags later. So that's actually a good thing. Yeah. But on the chunks, on the parameters, and on the error causes, we are pretty sure now that this is what Yeah. Is stable.

[00:25:53] **Zaheduzzaman Sarker**: So Michael, when you bring up the early allocation, it I don't think this is like any dependency, but it would be good to have that. Right?

[00:26:01] **Michael Tuexen**: Yes, exactly. Because we have the early assignments for parameters and chunks. We asked for that at the point of time where we were sure that this is stable now. But at that point of time, the error causes were not stable. So that's why we did this later.

[00:26:16] **Zaheduzzaman Sarker**: Yeah. So this is also why it didn't process. So now it's more clear. Now I'm comfortable in processing that.

[00:26:24] **David Black**: Okay. Perfect. Thank you. Thank you.

[00:26:27] **Gorry Fairhurst**: Gori. Gori Fairhurst, individual person who's read a lot of SCTP documents. And usually, the API is in the appendix as an informative chunk of text. Here, it's in the body. Was that a conscious decision?

[00:26:44] **David Black**: I mean, also in the other cases, the in the extensions, others has to be the extension documents has has the socket API extensions in the same document.

[00:26:56] **Gorry Fairhurst**: Yeah. In the same document, but it I think it was usually in an annex that was declared informative. Oh, it's actually in the text, is it? Yeah. Yeah. Okay. I'm just wondering how other people will read to information only sections in a document which are alternatives. Yeah. Well, okay. And for working group to the cut, fine.

[00:27:17] **Zaheduzzaman Sarker**: So on that one, I mean, I think it would be good to also clarify like whether this API description is informative or is it an

[00:27:25] **David Black**: I think it's very clear in the draft that it's it's it's just representing the assumptions about the API between the key management methods and the actual chunk because that's fairly relevant in these exchanges. There's some kind of general restrictions on on what you need to think about when you do this that's is described in these They and then slightly different realized or combined in some cases between the socket API and the abstract API. So Yep. It's it's from that perspective, I think they're having the two. It's it's good because it more clearly clarifies that, okay. There are things to think about here, but it's it's not set in stone. It's yeah. We have a proposed socket API that's has been implemented in the Linux, and we will have expect to see when Michael gets to the free BSD implementation will also follow. So Yep.

[00:28:24] **Zaheduzzaman Sarker**: On the LS part, Magnus, I think at least my point of view, we're more comfortable after working with LAST 12. So when we're working with LAST 12 done, we're more comfortable like we have done something. Mhmm. Then we can send the LS not before that.

[00:28:38] **David Black**: Okay. I hope that's fine. Yep. Yep.

[00:28:40] **Gorry Fairhurst**: Okay. Don't go anywhere. Yep. We're going to go straight to the DTLS handshake. I see the DTLS handshake slides.

[00:28:50] **David Black**: Yeah. If I

[00:28:51] **Sebastian Premba**: can find them.

[00:28:54] **Zaheduzzaman Sarker**: Say

[00:28:58] **David Black**: again? Yes. So now I'm talking for a slightly different hotel group. It's me, Ilhan and Claudio who's behind this document. It's Ericsson's proposal for SATP, DTLS Chunk Key Management. So now we're trying to realize one of these key management methods that lives on top. And and this is an updated version, and the reason we picked the new draft name was actually to ensure that you don't get confused about the IPR statements because Ericsson has made no IPR declarations and has no we, the authors, do have no knowledge of any IPR we need to declare on this document. The big significant changes here is that we actually switched from DTLS to TLS 1.3 for the key management. We use this for mutual authentication, the ephemeral key exchange, and exporting the keys to DTLS chunk. The goals here in this has been to take existing being able to use existing TLS stacks without any additional implementation needs than it was already exists and being able to use it with the key the DTLS Chunk and be able to support rekeying and re authentication. So

[00:30:33] **Lorenzo Colitti**: as

[00:30:34] **David Black**: I said, we have implemented this in the and with two different TLS stacks, which was useful. What we learned here, for example, was that we actually had to change the procedure slightly because we had problems getting OpenSSL to actually export the server keys at the earliest possible moment from a TLS standpoint. You actually had to wait until the finished message to be able to export it. And that's resulted in the change between zero zero and zero one. And this implementation is try to be as robust as possible while still being not wasting RTTs, but it's driven by messages either through explicit TLS handshake and additional message to ensure that we can enable the protection. So you do the SCTP handshake. The ones that fit the key manager client role starts with the TLS, sends a ClientHello. The server side responds. The client at that point initiate installs write read keys, sends the finish back over to the server. The server installs both set read and write keys and send extra protection established measurements. It's not a TLS message, it's a key message message to tell the other client, yes, I'm fully ready. And it also enables protection is required. This message is sent over to the client side, which then install its right key, and you're also requires protection. And for that point, you're actually ready to send protected data and can tell the upper layer protocol, hey, you have an established connection which is secure. And after that, you also can close the TLS connection. When you rekey, whoever side determines that you need to rekey, either for usage, time limits, whatever you're using, we recommend, like, timer and or data amounts. You basically take on the TLS client role, the key manager client role here, do the TLS handshake. When you know that the other side has the keys in place, you install the keys for the next start using them. So you here, also, you need to do the right key in the right driven by the end messages. So that's why when you're at the stage six here, you will install the right key on the server side, and seven will install when eight is being received, you will install the right key on the other side. And then you have rekeyed. And the TLR handshake itself forms is the basis for mutual re authentication. So there's the working group document, which is a sketch, but I wanted to show what's the differences here. We have if MREL rekeying happening through the TLS handshake instead of extended key updates, which is in the work parent workgroup document. We based the re authentication only on mutual the TLS handshake instead of of the exported authenticators and TLS methods that's specified in. Working document, we have a difference on implementation experience. The current, working document requires details with extended key updates. There exists no yet, to my knowledge, any implementation of that. It's available. And both neither of the solutions have an IPO disclosures on them. So the proposal we have is to actually ask the working group to reconsider our the previous decisions around working group adoption to actually adopt this version this style of solution and work on that. Because if you think it's a quicker way to get something that works and has a lower thresholding for implementation, that's the main motivation here. And with the having no IPR disclosure on this, that should take care of the previous concerns. So I want feedback on this. On the previous version, existing working group documents, it can coexist, continue to exist and be finished if that's desired. Or we can make a later decision to, as a working group, to not do it or not. But that's, I think, is for a future decision. The primary decision I want here is is their interest to adopt this version as a solutions direction. And then the idea we have had in our discussions around the DTLS chunk, author team and with Red Hat has been to iterate on this in a similar fashion. We have biweekly meetings, working through issues and discussion and what we had and basically have something which becomes stable and worked through by the time of the next ITF meeting.

[00:36:03] **Michael Tuexen**: So Michael Tuexen, one of the co authors of the current working group document, I support taking that back as a working group document and using that because as far as I can see from a security perspective, they both are good enough. And that document has no external dependencies. It can use existing TLS implementations. So I don't see any reasons why not do that work. Whether we need in the future a key management method using extended key update, I don't know. We can see in the future, I mean. When some requirements come up for that, we can always do that work at that point of time. But we don't need to work concurrently on two documents for the same thing.

[00:36:53] **Gorry Fairhurst**: Okay. Yeah. That was actually my question since you two probably care more than anyone else. You say what can continue independently. Would you like to continue it independently, or would you rather just let it

[00:37:04] **David Black**: I I I prefer this proposal as as the basis for for a working group published document. It's up to you and if anyone else has an interest, it's

[00:37:17] **Gorry Fairhurst**: So, Michael, you're also not particularly excited to pursue the the current draft?

[00:37:22] **Michael Tuexen**: No. I I don't see any reason. I mean, my point was we we need some some open source implementable way of of doing this. This does fulfill these requirements. It's simpler than waiting on external dependencies. So I would say go with that.

[00:37:43] **Zaheduzzaman Sarker**: I already did. Okay. So I mean, I do see a good point here to work on this as base. But I think that also like reversing the decision that the design team made too, right? So my suggestion would be like, Okay, let's evaluate this one as well and come back whether we want to do it as a base or as a parallel one. Later on, people try to say, like, compare that those two and then make it one as a base rather than right now reversing the design team's decision right now.

[00:38:23] **David Black**: Yeah. I mean, yeah, our plan is to work on this so we can delay wait a little bit longer until we make the some type of consensus call on this. Yeah.

[00:38:33] **Gorry Fairhurst**: K. I'm gonna do a quick show of hands to see if anyone has read this thing. Always love no opinion on these questions.

[00:39:34] **Zaheduzzaman Sarker**: So someone need to click on it.

[00:39:37] **Gorry Fairhurst**: Does anyone need more time?

[00:39:40] **David Black**: I haven't gotten in, but it's fine. Okay. I think you can think you can see why I read it.

[00:39:47] **Gorry Fairhurst**: Yeah. I I presumed you have. Okay. Not many people, which is not surprising. So, Ahid, are you comfortable with doing a adoption call on this before San Francisco?

[00:40:00] **Zaheduzzaman Sarker**: I think we should we should have a look at it. We should have more discussion on the mailing list. And people would like to read, and perhaps they have some concerns. But as I said, like, for for now, from the technical point of view, this gives them, like, a chance for open source to implement without doing quite a lot of work on extended key. But I think the extended key is also progressing really well. So let's give it more time and come back and transfer us to see, like, what to

[00:40:27] **Gorry Fairhurst**: do. So you want to do the adoption call after San Francisco? Yeah. Okay.

[00:40:31] **David Black**: Yeah. I will send out an email for on the list to for anyone to respond to if they want to join the work on evolving this so so you can get the invites to our meetings.

[00:40:44] **Zaheduzzaman Sarker**: So, Magnus, can you clarify what you mean by involve? Like, is it like editing the draft or real implementation?

[00:40:52] **David Black**: I mean, I so this the the focus is to get the draft in in improved shift. But, mean, if you ever want the implementation, have yeah. So I mean, we do have one implementation currently, which

[00:41:06] **Gorry Fairhurst**: Okay. So I'm gonna terminate a show of hands. I'll let the record show that five people said to have read or reviewed the the new draft, the porphyry draft, and 43 people said no, one had no opinion. Would anyone like to suggest that we should move faster, that we need to have an adoption call prior, like, prior to 01/27? Okay, nobody is in that much of a hurry, I think that's the course of action we're gonna have. So please take a look before 01/27, and we're gonna have another talk about it then and probably initiate an adoption call soon after that meeting. We'll start during the meeting and finish it after. Thanks, Magnus. Yep. Next up is Mohit.

[00:42:27] **Mohit P. Tahiliani**: Alright. Hello, everyone. I'm Mohit. I'll be giving an update on the Internet draft on FQ-PIE. It's a hybrid packet scheduling and active queue management algorithm. For those who have not received a chance to actually look at the draft, here is a quick overview. It basically combines flow queuing with the PIE algorithm. Flow queuing is pretty much similar to what we do in FQ codel in RFC eight two nine zero, and it it uses pi, which is already described in eight zero three three. So the functioning of FQ is pretty similar. Incoming packets are hashed into buckets, each having its own queue, and then the packets are dequeued using a modified DRR based scheduler. The functioning of pi is pretty much similar to eight zero three three, except that we suggested to use timestamps to calculate queue delay instead of using the little slot. And then there are three implementations of FQ-PIE currently available. We have one which is in Linux supported in multiple Linux distributions like upon WRT and others. We also have an implementation in free BSD.

[00:43:39] **Gorry Fairhurst**: Thanks

[00:43:39] **Mohit P. Tahiliani**: to Greenville's team who worked on it. And we have it implemented in n s three as well. The status of the draft is that it was adopted in ITF-one hundred twenty four, and then there were some comments on the mailing list which were addressed. These were the discussions that we have had on the draft on the mailing list so far. There was a feedback from Greg about in I mean, trying to see if we can do some performance evaluation of the fact when we use timestamps versus when we use Little's Law, do we get any impact on the latency? So that work was done, and the results were presented at ITF-one hundred twenty four. We also had feedback from Chris and other members on the mailing list with some minor changes, which we adopt which we already incorporated in the draft. There was a feedback on also including the l four s support for FQ-PIE through which we had a separate line of discussion, and we thought that it will be better to have a separate draft to talk about not just l four s and FQ-PIE, pi, but l four s with any FQ based, Q disciplines. And we already started putting an effort in that. In this ITF on Sunday, I presented an hot RFC talk wherein I mentioned about the problems or rather the issues that we foresee when you try to integrate l four s with FQ based mechanisms and why it requires a separate line of thought and why it can be a separate draft. So we already have started discussion. The hot RFC talk talk was mainly to collect the initial feedback and whether somebody would be interested to work with us. Craig and Chris are already here. We are working on three of us are working. Please feel free to come and talk to us if you would be interested in talking more about l four s in FQ based mechanisms. The performance evaluation of FQ-PIE and FQ-Codel is something that we have been doing from last four ITFs now in hackathon. Every hackathon, we have participated and tried comparing FQ by FQ codel with different kind of scenarios and different tools, different setups. We also have a company back in India. The name is Quantum Networks. Just a disclaimer, they don't work anything on Quantum. It's just a brand called Quantum Networks, and they have a line of products. And they have given us couple of products to test, which also I brought it for this hackathon and the previous ones. But most interestingly, they have deployed FQ-PIE in one of the client site in India. Three of their access points, which are in a room like this size, have deployed FQ-PIE, and they have been continuously running experimentations with the help of the LibreQoS advanced buffer bloat test, which also gives QO metrics. So they have done some experiments on f q I mean, they have done some testing on f q codel at random times of the day and at the same time they did FQ-PIE. We see some minor improvements from c grade to b grade, but then it will also vary depending on the load. So we sometimes have QPY may also give c as opposed to b. During this hackathon, we did two more kinds of tests. So first of all, thanks to the team in India from Samsung r and d. They have deployed FQ-PIE and given it in their phones to us for testing. This is primarily when we configure it as a mobile hotspot. So in during this hackathon, with the help of my student, Abhayode, who is here and one another student who is remote, Vishal, we were able to run FQ-Codel versus FQ-PIE experiments using the flexible network tester tool, and we ran the standard R rule tests along with TCP download test for this particular experiment. One observation that has stood out in all the ITF hackathon results that we have had is the ninetieth percentile latency results. The tail latency that we see with FQ-PIE has always turned out to be much better as far as as far as all the experiments that we have seen. We also brought in one access point from the quantum networks team. This is their tiny room sized access point. And, again, we had FQ-PIE configured on this. This is based on OpenWRT 23.04, which already has FQ-PIE. We just had to turn on the knob. We conducted some experiments, and our observations, again, were in line with the same thing with as low as 10 TCP download or 400 TCP download. We saw that the tail latency was definitely something that FQ-PIE was able to control better. That's primarily because FQQ FQ-PIE uses packet drops during the enqueue time as opposed to portal that does during the dequeue time. So it probabilistically drops the packet during the enqueue time itself. So if the probability is increasing, you see more packets being dropped at the enqueue time. That helps in a way to control the daily latency even there are too many packets coming in. Another thing that we did from the last ITF to this ITF is that we did not have a per flow stats collection feature in the FQ-PIE implementation of Linux. I believe that per flow stats are important for diagnostics purposes. So we looked at the reference implementation of FQ codel in which Perflow statistics feature was implemented. So our team of students has also implemented the same feature, and we have already sent across the patch to the NetNEXT. We got a review today. There are some minor indentation and typing mistakes that they have identified, but, otherwise, the patch seems to be good enough and should go into the next version of the kernel. So, these are the updates that we had from the last, ITF till now. Next steps, I would like to request, the the community to help us, do more review of this particular Internet draft and let us know if there is something else, that we could improve. And we'd also like to request the chairs to see if there is interest and if there are no more further, corrections, maybe this could be taken for our working group last call.

[00:49:57] **Gorry Fairhurst**: Chris?

[00:50:00] **Chris Box**: Hi. Chris Box, BT. Oh, here. Would you mind going back to the slide where you showed the CDF curves of FQ-PIE versus FQCodel?

[00:50:11] **Mohit P. Tahiliani**: So This one?

[00:50:12] **Chris Box**: Yeah. Because I just wanted to because you went quite quickly through that. I'm just not sure. I wanted to stress the the differences that this showing. So essentially, you've got the two they're they're fairly small on the screen there, but the the two CDF curves, and you can see the the overall takeaway that I think we're concluding from that is that, as you were mentioning, the tail latency of FQ-PIE is a lot better performance than FQ coggle. And you had some theories as to why that was. I'm just also curious to know whether anyone else in the in the working group what what what you think of that difference in the performance and whether you think there are particular network characteristics that should be explored, for example, in n s three Yeah. To to explore whether with different networks, those lines would look differently.

[00:51:17] **Mohit P. Tahiliani**: Right. So I could not hear part of the thing, but are you asking about the evaluation of this using NS3?

[00:51:29] **Chris Box**: Well, evaluation of it in both in reality and in simulations. So you're identifying that there are performance differences. That's good to know. It's good to help people to choose what they want to put in their networks. I'm just wondering, because it's a little are results from one particular network configuration, and with all the network configurations, would the results be the same, or would they be different?

[00:51:58] **Mohit P. Tahiliani**: Oh, okay. So you are asking about the fact that if the network configurations are different, do we have any observations on that? So, yes. So we have tested both these algorithms, and also there's a paper out that got published last year in CNSM. We did n s three based evaluations in those papers in totally different network conditions. There was no Wi Fi in those network configurations, whereas in these ones, you can see the one which we have used with mobile hotspot and the quantum networks access point. Are mainly with Wi Fi networks. We have done we haven't done yet any testing on cellular networks. But apart from that, we have tried in several other configurations, and those are well documented. Yes.

[00:52:40] **Chris Box**: Yeah. So it's it

[00:52:42] **Sebastian Premba**: seems consistent. Yeah. Thank you.

[00:52:44] **Mohit P. Tahiliani**: Thank you, Chris.

[00:52:48] **Gorry Fairhurst**: Briefly, please.

[00:52:50] **Greg White**: Greg White. I can't answer Chris' question directly, but I can say we did an evaluation of the Codel algorithm and the Py algorithm in consideration for the active queue management mechanism that we standardized in the DOCSIS protocol. And we did see significant benefits to the PIE algorithm as compared to coddle and documented that. And it's been ten years ago, so I don't recall all the details. But there was a white paper we put out which had that information

[00:53:20] **David Black**: as well.

[00:53:21] **Mohit P. Tahiliani**: So Sure. Thanks for mentioning

[00:53:22] **Michael Tuexen**: that, Greg. Yeah.

[00:53:23] **Gorry Fairhurst**: Okay. GitHub is has no issues. So if you have an issue with this draft, please file an issue very, very soon. I would anticipate us initiating a working last call certainly before San Francisco and maybe right after this meeting, depending on how things go.

[00:53:41] **Zaheduzzaman Sarker**: Sure.

[00:53:41] **Michael Tuexen**: Okay. Thanks.

[00:53:42] **Gorry Fairhurst**: Thanks, Mohit.

[00:54:04] **Greg White**: Alright. Greg White, CableLabs. Actually, before I get into the l four s ops draft, let me just very briefly mention the l four s interop events. We did have another iteration of the l four s interop at the hackathon this past weekend. Time was pretty short, we didn't get a lot done. But there was a continued testing of the screen integration into Libweb RTC, continued testing of the Netflix NDTC ingestion controller, some testing with the Apple responsiveness tool, the l four s functionality there. And we got a start on testing this SRM, static rate management functionality, which I'll talk about a little bit more in a minute, and and also the iPerf-two update, which supports additional features for testing L4s functionality. There are some upcoming opportunities for further interop testing at Cable Labs in Denver coming up in October as well as at the next IETF meeting in San Francisco. And then the other public service announcement, for those who are interested in the reordering draft, which was something we discussed at IETF one twenty four in this group, It's a draft in the interior. Well, it's a individual draft at this point, but being discussed in the interior. There's been an update to that draft, and there's some slides, and a link is there if you're interested. Okay. Alright. So l four s ops, we're at draft 10. This is a draft that really, the work was done, I think, almost five years ago on this draft. And we as a working working group decided to keep it as an open document to document any experiences that network operators and application developers have in the initial deployments of L4s. The goal of this draft is to talk about one specific issue that was discussed quite heavily during the standardization of L4s, That was concerns about rate imbalance in shared RFC 3168 bottlenecks. So we held the draft open for several years, and then and there really was only light modifications to the draft, just editorial changes really during that time. And IATF-one hundred twenty four, I proposed that we carry this forward to working group last call and and work on wrapping it up as an RFC. When you know it, as soon as we do that, we actually got a proposal for a new section in the document to describe a new technical method that a network operator can utilize in order to implement L4S functionality. That's this TRTCM, so two rate, three color marker mechanism. And that mechanism is not specific to solving this problem of rate imbalance. It's really a more general mechanism that can be used to implement l four s in a core network switch. And so rather than just documenting that in the l four s ops draft, I had an offline discussion with Kun DeSkepper from Nokia and agreed that it'd be better that that be written up as a separate draft on its own. And so that has happened. That draft was posted maybe a month ago or at least a couple weeks ago. And then I updated the l four s ops draft to include a new section that that discusses this two-rate three color marker option and includes a reference to this new draft from Kuhn. So a brief overview of what this mechanism is. So a two rate three color marker defined in RFC twenty six ninety eight. As I understand, it's fairly widely supported in core network switches, may not be heavily utilized in switches today, but but is available in a lot of equipment. What this mechanism describes in the in the draft is a way to utilize a two rate three color marker to implement l four s in a way that's scalable on high speed switches. It works apparently well when you've got a stable egress link rate, so you're not dealing with, like, a wireless link that may have variable egress rate, and in situations where you've got quite a bit of flow aggregation. So you're not super concerned about, say, a single flow or or a small number of flows utilizing the entire egress link rate. The configuration of it is you set up two queues, but there's no coupled AQMs, so it's not RFC ninety three thirty two. But you have basically a standard queue for classic graphic. You have a high priority queue, think generally strict priority queue for the l four s traffic. And that queue is configured with this two rate three color marker. And there's we have two rates that you configure, a committed information rate above which the packets would be congestion marked and then a higher peak rate above which packets would be dropped. And there's some recommendations in the draft about how that rate should be configured. The end result of this is L4s traffic sees zero queuing delay and gets the appropriate congestion marks so that the senders can adjust their sending rate.

[01:00:17] **Gorry Fairhurst**: Hey, Greg. I just wanna say you've used six minutes of your 10, and you've only gotten through three slides. And I would like that for the discussion time. So good pick up the text, please.

[01:00:28] **David Black**: Okay.

[01:00:29] **Greg White**: Yeah. Last point is the only downside, I think, is that l four s traffic aggregate won't exceed the CIR.

[01:00:38] **Gorry Fairhurst**: Okay. So

[01:00:41] **Greg White**: what are our paths forward? So we had this draft through working group last call. We sort of decided to move on with publication of it. We have this new suggestion for significant addition of technical information. What do we wanna do? I listed a couple of paths forward. There are probably more paths forward for this document. One would be we we published effectively L4s ops version nine. We say that new functionality was too late. Another option is we keep this draft in kind of a a holding pattern and hope to move forward with the SRM draft and get that matured and approved, and then finalize L4Sops once that's done. So that's it.

[01:01:36] **Gorry Fairhurst**: Oh, there's backup slides. Great. I'll just say that the third option is that we go ahead and submit after adopting the SRM draft, and then it would just sit in the RFC end queue, but it would be out of the working group at least. But we wouldn't wanna do that before it's adopted.

[01:02:00] **David Black**: Okay. Yep.

[01:02:01] **Gorry Fairhurst**: Miro.

[01:02:05] **Miroslav Kovac**: Hello, everyone. Can you hear me? I am the one of the author of the SRM, so I am the guilty party for this a little bit late, yeah, submission. Yeah. What I would like to say is that we really kind of have a very good results with with with this algorithm. So we would that's why we have kind of decided to submit it as a separate method because usually the the l four s was very much related to the AQM and so on. And it's okay in some parts of the networks, but in some of the parts of the network, especially when you are talking about the the gateway devices between high speed links shaping to the user case user access line speeds. Yeah. The extra delay which you which you get by because you have to absorb the burst is a little bit too high. So that's why we think this algorithm is is kind of a good alternative to the to the this part of the network. I don't want to hold you longer.

[01:03:19] **Greg White**: Yeah. Yeah. Thanks. I yeah.

[01:03:20] **Stuart Cheshire**: I think

[01:03:20] **Greg White**: it's a pretty interesting concept and and, in my opinion, worthwhile for the working group to consider.

[01:03:30] **Gorry Fairhurst**: Martin Duke, Google as an individual. I guess what what's not clear to me from your discussion, and maybe I just got lost in the weeds there, but is SRM specifically about thirty one sixty eight coexistence?

[01:03:45] **Greg White**: No. Okay. Which is why we decided that it would be better to not just document it in the l four s ops draft, but to have it be a standalone draft on its own that could go to RFC, and we would just include a reference in l four s ops.

[01:04:01] **Gorry Fairhurst**: I mean, I've had to continue to remind myself that in spite of the the shorthand for the draft being L4Sops, it's not a general of for us operations document. It's a thirty one sixty eight Correct. Document. The quick close distance document. That is the deliverable. And if this is not germane to that, maybe this I'm not I I don't object to someday having another l four s ops document that is actually about l four s ops, but this is not that document. And and just like general l four s advice is probably not in scope for it for what you're working on. Well, this but this is

[01:04:40] **Greg White**: is also a a an option for a network operator that may already have deployed 3,168 in their network in gear that may support, say, red with with classic ECN marking, they could migrate to using this two-rate three color marker mechanism. Sorry if I if I was gave a confusing answer earlier. It's not only for RFC thirty one sixty eight coexistence. It's a has a broader applicability. Okay. Thanks.

[01:05:20] **Gorry Fairhurst**: So Garry Fairhurst does a d two chairs in working group generally. I guess this document hasn't really surfaced and been subject to critical review, to analysis, etcetera. So I guess no. I do think that the most important thing here is to decide what the working group wants to do about the existing document and whether they wish to effectively part the working group last call and then spend some time considering this because until people have read it and looked at it, got analysis of it, thought about it, commented on it, We can't really talk about whether it's part of this document or not. So the question really is, is the working group wanting to wait to see what this looks like?

[01:06:05] **Zaheduzzaman Sarker**: Yeah. So, I mean, we have been working on this sale for us for a long time. But that also means we're in no hurry on publishing it. So maybe we should ask the question that you were asking, Gori, whether we need to park this one and get this match return SRM, and then decide whether we need to include it or cross reference or whatnot. So that might be something we can ask. Yeah.

[01:06:40] **Gorry Fairhurst**: I don't know that the outside world is crying for this document to be published immediately, but it is always nice to to clear things off the to do list. So why don't we just take a quick poll? Let me do that. So if you just want to be done with this, vote no. If you would like to consider the other thing first. Does anyone need more time? Okay. I'm gonna stop the show of hands. Eight people think we should wait. 14 said we should just ship it. I think we gotta take this to the list. It's it's a little it's too close.

[01:08:23] **Zaheduzzaman Sarker**: So there is also in part, like, whether if you ship it without because the ship it with the path forward one or not, that's not clear. So I think let's discuss it in our main use. So the yep. So you can ship it with with SRM, like, not talk about SRM at all.

[01:08:44] **Gorry Fairhurst**: No. That those are the two options. Yes, Corey.

[01:08:48] **Gorry Fairhurst**: I suggest the chairs have some input. There's obviously some interest, so we should just talk about it further. Going to delay it for a short period while we can do that consideration.

[01:08:59] **Gorry Fairhurst**: Yeah. Yeah. I think I think we have a I'm to take it to the list, frankly, but but I I do see a lot of interest in in maybe holding things up a little bit until we have a good look at it. So that seems to be the outcome. Thanks, Greg. Yeah. Thanks. Okay. Next up is Philip.

[01:09:20] **Michael Tuexen**: Okay.

[01:09:25] **Philipp Hancke**: Does audio work? Can you folks hear

[01:09:32] **Gorry Fairhurst**: me? Yes.

[01:09:39] **Philipp Hancke**: Okay. Waiting for the slides.

[01:09:50] **Zaheduzzaman Sarker**: Did

[01:09:54] **Gorry Fairhurst**: you post the slides?

[01:09:55] **Zaheduzzaman Sarker**: It should be refresh it.

[01:09:58] **Gorry Fairhurst**: Oh, it's too late, probably. When you post slides at the last minute, they don't often show up in the tool. Nope. Gotta do it before the meeting starts. Alright.

[01:10:15] **Philipp Hancke**: I can share the screen if that helps.

[01:10:18] **Gorry Fairhurst**: Yeah. Do that. Do that.

[01:10:33] **Philipp Hancke**: Okay. Sorry about that. Philip, I am presenting here on behalf

[01:10:38] **Gorry Fairhurst**: of go into presentation mode so your slides aren't tiny?

[01:10:44] **Philipp Hancke**: Yep. Perfect. Okay. I'm Philip. I'm presenting here on behalf of my draft co authors, Justin Huberti and Victor Boivi. And this is something that was presented at the last IETF in the AVTCORE working group. It is mostly a SAP topic, but let me give you some background on the ways this is going to be used in WebRTC. WebRTC uses STTP for data channels. This is using the data channel establishment protocol, r c eight eight three two. This runs over details after ICE is done. And the problem is that this needs a lot of time to establish a connection open data channel. We have two things for reducing that. One is combining ICE and DTLS, so it's called SPET. It's basically merging together ISO DTLS, and we have the draft the snap draft, which is basically putting the STTP in it and the STTP handshake into the STP, which is what I'm talking about today. And then we have DSEP, which already allows sending data without waiting for an acknowledgment, so it's pretty fast. We also have negotiated channels, which don't need any inbound negotiation. So if you look at it on the wire, basically, the flow is between a SDP offer and the SDP answer. You have an SDP offer. You get back an SDP answer. Then ICE does its connectivity checks, establishes a UDP connection. Then we have the DTLS handshake, which is DTLS ClientHello, server hello, and to finish messages, basically. And then we have these two round trip times for the s c t p in it. Gets answered with an INIT-ACK, cookie, and COOKIE-ACK. And then after six round trip times, the offer data channel is ready to send. That's WebRTC one point o. It has been there for a decade plus. And what we're proposing is the thing on the right, basically, skipping the entire STTP handshake. This removes two rounded times. And, basically, it takes the s t p s exchange the in it and INIT-ACK as well as cookie and COOKIE-ACK. That means one or two round trip times without considering packet loss. In theory, it's one RTT because that can be a cookie can be bundled with the actual data. What we've seen in the practice is two RTT. In WebRTC, we do all this after the SDP exchange and after ISO DTLS, so lots of latency. And the proposed solution is to piggyback the SCTP INIT chunk into the SDP exchange, which always has to happen before. It is a base 64 of the chunks that would usually go onto the network. An example is below the s a equals s c t p in it and then base 64. This allows us to skip the whole cookie exchange, and we can jump straight to the data channel establishment protocol or negotiated channels. One thing we found out is that you run into troubles if you negotiate this at in on a connection where you already have detail established. That means we have a race condition between the STTP packets and the STTP signaling handshake. Hopefully, not that relevant in practice, but can be solved by caching some packets. We do have at least three implementations right now. It is in the RPC and Chromium behind a flag. We have it in the Pyon STTP package and the WebRTC implementation. It's a go implementation of WebRTC. Firefox also has two work in progress changes, one by me, one by one of the Mozilla's engineers. What we've seen is that OpenAI has deployed this in their mobile apps, and that shows that this promised improvement of reducing the time to open the data channel is actually delivered in practice. So they saw two RTTs p 50 improvement, which is what everyone expected, six RTT in p 95, which is probably due to no packets that can be lost anymore, and that was previously affecting the handshake. Not surprising, but a good result. We also have an argentile in Chromium based browsers, which runs until November 15. This is very clearly stating that this is experimental participants of the origin trial aware that there can be changes. So we're not shipping this without expecting any changes yet. Okay. The question I have is basically what are the next steps? Where should this work happen? A b t core or t s v w g? And, obviously, the draft just expired last week, so we need a new draft version.

[01:16:17] **Gorry Fairhurst**: So clarifying question. So the the only change to the SCDP protocol is the cookie exchange is gone. Is that correct?

[01:16:27] **Philipp Hancke**: The cookie exchange and the STDP, it moves basically to the STP and is no longer exchanged over the network.

[01:16:37] **Gorry Fairhurst**: Okay. Are you adding a mechanism to s d b SDP, or are you taking the or are you using something that already exists in SDP?

[01:16:48] **Philipp Hancke**: It is it doesn't exist in the SDP, so it defines a new attribute to put the base 64 encoded chunk into the STP.

[01:16:57] **Gorry Fairhurst**: Okay. Thanks. Michael?

[01:17:02] **Michael Tuexen**: On the email, you you stated that you wanna reduce the delay of the initial handshake and also brought up that you might want to save 12 bytes the sdt command header which basically has no use in the WebRTC context. So my suggestion would be if you want to do these kind of optimizations, do them once and not once in a while we do the checksum to zero, we remove the checksum, we optimize the handshake, whatever. The second is, I'm not sure exactly why, but I don't like to put the chunk in in the STP. So for example, when I read the document, are you actually using it in network byte order or in host byte order? And if we remove the common header, then you actually don't need a lot of fields of the unit. So you basically need the advertise receiver window. You might need the streams. And you can put this explicitly in some STP stuff. So don't use this network format, but just stay that. And then change the sttp implementations to have an API call which says move move an endpoint create an endpoint in established state with these parameters. And that should simplify things. And if you do it that way, you can just remove the the common header in the same way.

[01:18:37] **Philipp Hancke**: Yeah. That's good feedback. Basically, the reason for using a base 64 encoded in a chunk is that it's opaque, and it doesn't require any IANA registrations for mapping all the STTP parameters to STTP, which would be a lot of overhead.

[01:18:55] **Michael Tuexen**: No. You need you just you just need one number, the advertised receiver window. You need maybe stream numbers, but as far as I know, the default in WebRTC is 64 k, so you don't need to negotiate that. And you might wanna negotiate the extensions, which would be a list of numbers. So it's it's a couple of numbers in STP, which is I think simpler than putting something into a byte thing and then convert everything to network byte order, which is missing in the spec. And so that that complicates things. Mhmm. And you don't need an initiate tech if you don't use the the common the the thing. So so it really simplifies if you focus on the WebRTC use case.

[01:19:43] **Philipp Hancke**: I'll definitely look into that, in particular, if you can avoid the IANA registration for the fields. That makes it much simpler indeed.

[01:19:51] **Michael Tuexen**: Yeah. So happy to help, and I can't help on the question whether it should

[01:19:55] **Gorry Fairhurst**: go

[01:19:55] **Michael Tuexen**: here or maybe the SAP staff. I mean, happy to help wherever this ends up.

[01:20:04] **Philipp Hancke**: You.

[01:20:07] **Martin Thomson**: Martin Thompson. You you say that the current handshake is six round trips at least, and that seems pretty spot on to me. That's a lot. What if I said that you could reduce it to one rather than four?

[01:20:25] **Philipp Hancke**: That's the spec work.

[01:20:29] **Martin Thomson**: I think spec work no spec work work required. No working in this working group. No hacks for SATP. Use web transport. Obviously. I'm absolutely serious here. This this seems like, I think, completely the wrong way to solve a problem that's already being solved.

[01:20:47] **Philipp Hancke**: Well, the thing is we have a lot of web proceed deployments, and porting them all to web transport is going to be tricky.

[01:20:56] **Martin Thomson**: I think you'll find you'll get better results. And it turns out that the companies involved here have access to things called LLMs, which will do a lot of the heavy lifting for you.

[01:21:08] **Sebastian Premba**: Mhmm. True. True.

[01:21:12] **Martin Thomson**: That's all. I'm just tying this thing up.

[01:21:14] **Gorry Fairhurst**: Okay. Time time is up. Gory, would you like to say anything about the working group venue for this?

[01:21:27] **Gorry Fairhurst**: Gory Fairhurst as a d. I think we need to choose a mailing list, not a venue because there's already been some discussion here on topics that weren't discussed in AVT core. So I'd love to continue the discussion on this mailing list on these topics to see if we can get some resolution. Where it's finally adopted depends on what the solution looks like. Would encourage discussion on the tfvwg list and we finally choose which working group to go to.

[01:21:54] **Gorry Fairhurst**: Okay. Thank you. Yes. Clearly, there's some discussion that will happen in this group regarding SCTV and and some of the other things that that Martin brought up. Alright. Thank you, Philip. If you're interested in this topic, please go to the list. I think set to have a pretty lively discussion about it. And last up today is gonna be Sebastian.

[01:22:31] **Sebastian Premba**: Alright. Everyone, Sebastian Premba, Apple Apple Google. Sorry. Co authored with Lorenzo and Sandeep from Google and Samsung respectively.

[01:22:43] **Wes Eddy**: This is

[01:22:43] **Sebastian Premba**: mobile L4s draft zero. So a lot of the documents and presentations I've seen start with this preface of L4s happens when there is a collaboration between multiple layers and components of the system. We observe the same thing. In mobile ecosystem, we have a large concern with applications time to first request. There are a lot of network changes. There are a lot of cold starts. And we also know that applications at median will make between zero and a few requests per connection depending on the use case. So we really care about how long an actual handshake takes and how we can accelerate that. We also have complex link layer subsystems. You know, Wi Fi is complex. Modem is very complex. And we thought it is useful to both provide some guidance on how to tune the thresholds and behaviors to make sure the latency is as expected and also to reiterate the relevant parts of the other RFCs for the link layer portions of the system to highlight the overlap with what they already have implemented. So we start with self imposed recommendations, what the system should do. The document talks about what should be the capabilities offered to UDP socket, but also the behaviors of TCP side. But I think an interesting portion is where we talk about what our colleagues from Apple have also mentioned. How do you provide heuristics that let you turn on or off L4s support on networks that are known to have some firewalls involved in them. So we do provide the recommendation to run the detection and to back off from a network that does not that is known to filter out L4s traffic to not trigger the retransmit path on the handshake. To be clear, this is not a case where a network is L4s not aware. This is the case where a network is filtering, which adds extra round trips to the handshake. We also propose doing some form of caching per IP or per host and to cache these for a number of days. I want to be clear. We are early in deployment, so this is the section where I expect to iterate the most in future drafts. We provide some recommendation to the link layer. There is already existing language in nine three three one and nine three three two that talks about how do you mix L4s traffic with non L4s traffic and L4s traffic with classic. This has an unfortunate overlap with preexisting conceptions, especially in the modern subsystems where high priority queue and low priority queue already exist, and we find that it's too easy to conflate these two. And, you know, I think it's a very important observation of LFS that latency is not a natural property of the network. It is a property of how restrained an application is. So just creating priority around L4S traffic will not necessarily result in better latency. We do recommend in these systems to have a strictly distinct L4S queue that would guarantee there is no queue building in it. There is also overlapping work and an area around packet reordering. We will probably decide whether the scope of the documents should cover that or just wait for this document to land, but I just want to express that we we support this work. And lastly, we have network recommendations. I think similarly, there is a lot of conflating ideas around how Prote could result in latency improvement because that historically has been the case. We have observed some networks talking about L4s deployment, allocating a slice of traffic to EC and mark traffic, which is good, but then actually not doing anything about ECN markings or introducing any low latency queues, which obviously leads to, you know, these queues not doing anything. It just creates a slice of a traffic which is attractive. And our concern is that applications will end up marking ECT one without actually doing anything about CE markings and the traffic. We are implementing any congestion control based on this just to get in this new attractive slice of the traffic. So we are mentioning some language around how this can be mitigated. And we also try to intentionally avoid some overlap with Comcast's living good document because it treats a lot of the same concerns. And I wanted to invite some comments. There has been a lot of good discussion in the mailing list. Thank you for that. So I wanted to scope this a little bit to whether the scope of the document that's presented sounds right. There were proposals to extend it into mobile networks in more detail or into application space or to shrink it to avoid other documents I know are in the queue. And, also, finally, is this of interest to TSV? There's not a call for adoption yet, but we want to iterate on this so it eventually is.

[01:28:23] **Gorry Fairhurst**: Go ahead, Stuart.

[01:28:25] **Stuart Cheshire**: Stuart Church from Apple. Thanks for a great presentation. I agree with lots of the things that you said. You you talk about applications setting ECT one to get preferential treatment, And I think you're absolutely right. There is a risk that people will think that. It's misguided because the preferential treatment that L4s gives you is not more bandwidth or lower latency or lower loss or any other special treatment.

[01:28:55] **David Black**: Mhmm. The

[01:28:56] **Stuart Cheshire**: preference the the treatment you get is being given the information so that you can be a good citizen and avoid shooting yourself in the foot. So if you ask for the information and then ignore the information, you haven't helped yourself. That said, I think there will be misguided people who think they can do this, and that's why we need the queue protection function. We talk about in dual queue to statistically monitor badly behaving flows, and then punish them in some way that makes the disincentive strong enough that implementers know that it's self destructive to try that trick. But, yes, I I I think you you said some really key things here, that l four s is not about preferential treatment. It's about more information to make a better client. Thank you.

[01:29:48] **Sebastian Premba**: Thank you.

[01:29:52] **Zaheduzzaman Sarker**: Shahid, as an individual. So I think this drafts really talks about a couple of things that we have observed, especially when deploying these things, mobile networks. But here I came up with a question like, is this really mobile network specific? We have some issues here. It's more like kind of like what is our scope. Because it's very unlikely, like in IT, if we can tell the 3GPP or mobile networks operators what to do. And they do their own stuff, right? So it would be more useful for IT to do something on this ground. It is more like a kind of generic internet kind of case, right? But I think a lot of things that you were talking about actually applied for more generic kind of things. You take mobile network as an example, but that's one deployment use case, not like the only deployment use case. So I think if we work on this at tsvwg, we need to make sure we have this scoped right. Otherwise, I mean, we can't publish something and nobody will read. Then you need to go to 3GPP and then do something about it. Right?

[01:31:10] **Lorenzo Colitti**: Actually, I can maybe speak to that directly. I think one of the issues that we're seeing is that we we see a lot of interest in deploying L4s. And there is a huge amount of confusion about what that might even mean. Like, you know, I lead the Android IP networking team and, you know, the the people in the the device section is like, what do we need to do for L4s? Can we just turn on this feature? And then, like, are we done? And I'm like, no. Absolutely not. Right? Like, the modem needs to, like like, marquee CN bits and, like, all of this other stuff needs to be done. And they're like, cool. How do we find out? And I'm like, well, you can read these 15 RFCs that total, like, whatever, a 100 hundreds of pages. And so one of the things that we're trying to do, and I don't know if we can, but one of the reasons was to say, okay. Here's some set of things that you absolutely must do. Otherwise, you're not really gonna achieve the benefits. I think there's a lot of confusion. So and, also, one of the reasons we're here is, like, we we wanted to, you know, come up here and, you know, get told everything that we got wrong so that we can actually do the right thing because we don't even know right. So any the experts are in this room. But I think as to your concern, will I wanna read this? I promise you, I will make them read it. Right? But, like, the people here are the ones that need to tell us or need to, like, tell the ecosystem what to write and what to do. But, yes, they will read it because I will make them read it before before they could touch my code. So in that sense, it will be useful. I can't really promise anything about nonmobile devices, though. So that's where the scoping came in. That was where the the intention was.

[01:32:45] **Gorry Fairhurst**: Okay. We're we're out of time. Alright. So thanks for the new draft. Has already had a pretty active discussion. Please join that discussion, and we'll talk further about what to what to do with this draft. I do want to call everyone's attention to the two documents that we did not have time for today. In Shenzhen, there was initial presentation of the IPFIX ECN draft, which got pretty good reception. Work has continued. Please engage on the lists on that work. And we had a new there's a new draft out about TCP and UDP checksums and ILMP. You can look at the slides that are posted for today's meeting. You can look at the draft. Check some enthusiasts, please have a look. It's in a different working group, but here at t c w g, we should probably have a peek at what's happening over there. Have a good lunch and have a good rest of your week.

[01:33:42] **Zaheduzzaman Sarker**: See. Okay. So how do I get

[01:33:48] **Gorry Fairhurst**: out of this?

[01:33:52] **David Black**: A milestone for