Session Date/Time: 24 Jul 2026 12:00
[00:00:41] Dominique Barthel: So it's it's time I propose that we start. So welcome to this SCHC the meeting of the SCHC working group for IETf-one hundred one hundred and twenty six. So, begin with the note well. So, this is an official meeting of the IETF and by participating in this meeting, you agree to follow IETF processes and policies. So, this note well is a reminder of those policies. For example, the code of conduct, participants are expected to behave in a professional manner and the extent we expect and courtesy to people at all times. So, you can go check these guidelines with scanning the QR code. And if you have any question or need advice, please ask the chair or the the AD. So the quick reminders of meeting tips. So for in person participants, make sure you've signed in to the the session using data tracker, using the QR code or whatever, and use the live client. And please, if you want to ask questions, join the the mic queue and participate in show of hands if any. If you're using the phone client, please keep the audio off. And for remote participants, make sure your audio and video are off unless you are speaking or unless you are presenting, and the use of a headset is strongly recommended. So we'll be presenting the agenda. You can find the tips on your use of on this using these links. And if you have issues, don't hesitate to report them. We have two note takers today. Thanks, Marco and Alejandro. This is the agenda batching. Today, we'll have a quite large number of presentations. We'll start with the introduction and the quick status of the working group documents. Then we'll have a thirty minute presentation of the chic architecture document. Alexander will be the presenter in order to present the outcomes of the the design team and sort of debrief the side meeting we had yesterday. Then Marco will present the updates in version nine of the the document on CoAP. And, of course, we'll have a presentation of the new contribution from Magnus about compressing dynamically assigned IP addresses. We'll continue with a second new contribution about by Lorenzo Cornell about SCHC context management extensions. Then we'll have a presentation on VOICI which is a link multiplexer for sessions. And then we'll have two quick presentations on the first one by Samar on the compression of quick frame metadata. And finally, Laurent Toutang will present private SIDs. Any comments?
[00:04:29] Alexander Pelov: And as we are starting this meeting, first of all, we would like to introduce the new co chair, Marion, who has been co chairing SCHC for a couple of weeks now and Quentin, who was appointed as technical advisor. So we are very happy that they are joining the team in this way. And yes, this follows a long period of contribution. And thank you for this. And as you may have seen probably in the list of people that have joined, there is a special uninvited speaker. So that is none other than our big friend, Pascal Thubert. Pascal Thubert, has been with this working group since its creation, even before it was created. And actually, it is exactly ten years now. It was on the 07/18/2016 that we had our meeting in that that was the first meeting. And then we had so many interesting and very productive meetings. And here I'm just going to show a couple of photos. So for the people that don't remember, at that time, LPWAN was almost like a war zone. So there were four different technologies. And at the IETf- and this working group was the only place the first place that they started talking and in a very constructive way. And here on the table, can see many people from from LoRa Alliance, from Sigfox, from from Wi-SUN, from many, many places. And Pascal was one of the founding fathers of this. So Pascal is is stepping down now. And Pascal, maybe Eric wants to say something. Yes. And that's it. That's so I just wanted to say thank you very much Pascal for everything that you have done for us, for SCHC. And not only, but yes, thank you.
[00:06:45] Éric Vyncke: And thank you again, Pascal, for the work you have done, and welcome, Marion. But Pascal, double thanks for LPWAN, SCHC, and so many contribution about talking about you as well in 6lo this morning. So thank you.
[00:07:02] Pascal Thubert: Thank you all. This is very, very emotional. I look forward to seeing you all again. I don't know where. I don't know when. And best luck to Marion, obviously. She will be doing a great job, and I'm very confident that the group will move on very swiftly. So thank you all for all those years. Deep happiness with you guys.
[00:07:29] Alexander Pelov: Yes. Well, we do hope to see you again. You know, you're the door is always open for reviews, contributions. And there is actually a draft of your name, the PPP draft. So you're not going to get away as easy with that. Right? But yes, it was an amazing time. And all the people that you see around the table and even not everyone, these were the photos that I found. Everyone spent a huge amount of work and in a very, very constructive way. So thank you all. That has been an amazing run of ten years. I hope we will have a good Now
[00:08:16] Dominique Barthel: let's back to usual business. It. So, yeah, this this is a quick overview of the status of the working group of the SCHC-related documents. So those are the active working group Internet drafts. So they are making progress. So, as I said in the agenda, the the the work on the on the SCHC for CoAP document is almost ready, and Marco is going to give some updates about this. You have also a new version of the architecture document we were going to present also. And then there is a newly adopted document by the working group, which is about SCHC payload compression or structured formats. And there's still the the documents will advance soon. We also have some expired drafts, so we invite the authors to continue their this valuable work. So, I reached out to some of them, and thank you for your replies. And so we'd expected that Laurent will update the ICMP, the document on ICMP basics. Some other documents related to the SCHC data model, for example, the solutions and also access control, are sort of on hold, but will be resumed. And as Alexander said, there is the PPP document, and Pascal will count on you to to help us finish this work. And we have a lots of related sheet documents and also new contributions. Some of them will be presented today. And so thank you all for your active contribution, advancing the work of this working group.
[00:10:19] Alexander Pelov: Laurent, you have
[00:10:23] Laurent Toutang: Yes. Few few comments on on the IPv6 and and IPv6 and ICMPv6 and the universal options. So there is there was a lot of work on the data model, the new data model. And I think it's something we we should start to work on now. So the evolution of all the SCHC compression. So maybe I will write a draft for the next interims showing the evolution of the data model that include the universal option and some passing of ICMP.
[00:11:04] Alexander Pelov: Okay. Thank you very much, Laurent.
[00:11:08] Dominique Barthel: So we can proceed with the first presentation. So Alexander.
[00:11:13] Alexander Pelov: Thank you very much. So I it's it's been some time since we've been working on the architecture document. I'll try to be brief also in the interest of of the time here, but please don't hesitate to to to ask questions. So the work here is that I'm going to be presenting is, of course, starts with what is SCHC and what is what does the architecture document do? So this is a small attempt to actually provide all the list of types of documents that we have in SCHC. So we have something which we can call, like, the the core, like the SCHC framework core plus the extensions. And it's basically RFC eighty seven twenty four plus other documents that add core functionality, such as Compound ACK, universal option and so forth. So that's the first part. Then we have another part, which we can roughly say interoperability. And that's basically how we can represent the context in an interoperable way with RFC 9363 and all the other drafts that you see in this category. So some of these are still just individual submissions, and none of these documents is promised to become a working room item. Right? It's it's are just put there so that we have them in our minds. Then we have documents that are SCHC adapted to some technologies, like LoRaWAN and the IT six folks and networks prone to disruptions and TPP. Or also, SCHC applied to some technologies, like to CoAP, to the ITSP, and so forth. Right? And so all these documents, like, it it can it can be some a little bit daunting for someone that comes to the group and says, hey. We would like to use that technology, and how do we do that? Right? And so one of this is one of the points that the SCHC architecture needs to to to answer to that question, like the entry point, which says, well, these are the rough these are the the this does the terminology. These are the concepts, and this is how you proceed with some base basic and some more advanced use cases. It is an informational document, so act the actual work needs to happen elsewhere. The the other technology needs to be defined in standard track documents elsewhere. And we have been working in the design team. So there was a design team formed after I after last IETF. And the point was to converge to a document that corresponds to these principles that is also simple to understand. And today so we had we had a side meeting on that. And basically, our point is that the work of the design team is over now. We want to give back the work to the to the working group, and we present the the work as it is today. So you'll see that it is a very small document. It is around 18 pages. There are some examples, and some of them may be integrated in later in in the body. But, yet, the the idea is that when someone comes to the working group, they don't have to read a 100 page document just to make sense of everything. Right? There is a part that starts with, like, the basic architecture, like very simple principles, then focus on some core components and deployment profiles. And the point is to have a clear and unambiguous terminology. The work is ongoing, of course. So nothing is it it's not perfect, but we feel that we have really made a huge progress in that direction. And also, normally, is animation here, but I think that the tool actually like the PDF is confounding everything. So anyways, so here we have like, this is the basic architecture in which we have, like, two endpoints that are communicating. And these two endpoints, like, what's an endpoint? It's a logical entity that provides SCHC functionality. And one or more of these endpoints can be present on a physical device. In this endpoint, there can be one or more instances. And each instance so the the the instance is actually the component that executes the actual operations, this the compression, the compression fragmentation, and and and the composition. And then we have, of course, the the cut the context or the static context as as discussed yesterday. Some local parameters to that instance. And all that, of course, is living in this on these two endpoints in that example. Communication between two instances is happening over a session. And we can have dynamic sessions, like opening a session and so forth, or implicit communication sessions, as in, for example, LoRaWAN, where the thing is there. Like, there is not like an opening session event as such. The unit exchange between Cheek instances, actually, yesterday during the discussion, it was reminded to us. So we will call it Datagram in the document, but it was reminded that actually we had converged on data units in the past discussion. Right? So we will replace that in in the o seven version. And we have, of course, the notion of stratum, which is a background concept which identifies the portion of the network protocol stack on which operates SCHC. And it is a continuous set of layers. So it's a continuous thing. So this is the baseline scenario. Then here is, as an illustration, we have an example of a multi tenant scenario. So here we have two domains. We introduced the notion of a domain. So a domain is like a logical grouping of instances that share a common context. So that's something that's used mostly for for management purposes. Right? If you have if you're an operator, want to be able to to say to name the things that you that are in your domain and to manage them. And then you have the thing that's called a domain manager. And all these things, of course, that can be something very simple. Now, doesn't need to be some kind of enterprise level software. It can be a super simple thing. It's just named like this. And here, the example is where we have, like, one of the domains is, let's say, a smart city domain. The other domain is a utility domain. And actually, they're reusing an infrastructure that is provided by the by the operator. That's just an example. Right? So the operator will be having these two domains in which they will be managing their their their their instances. So that's the the case. So that was the definition of a domain, the the example of multi domains. And then here is an example of how we manage things when there are multiple instances which live on the same endpoint. So here we have two notions that are present. One is the dispatcher and the discriminator. The discriminator is that's an optional informational element, which is used by the dispatcher throughout the SCHC data units. Sorry. So the SCHC data units to the appropriate instance. And from the discussion yesterday, it became clear that actually the the dispatcher, which is the the thing that the logical component that actually does this dispatching, it should not need to know the actual strict rules in order to be able to dispatch the thing. Right? And typical examples of these are, for example, dev UI in LoRaWAN, or if you have, yeah, so an MPLS tag or something. Well, so typically, it's going to be outside of the chic part. So these are the two elements here. And just to to move a little bit further, that that was the correction from the from yesterday's discussion. So it's not chic datagram, chic data unit. So that will be corrected in the o seven version. So the data unit format is fairly straightforward. There is the rule ID followed by things that depend on the on the type of the rule. Like, if it's a compression and decompression, if it's a data unit that comes from a compression operation, then that will be the residue, and then we'll have the SCHC payload. Thank you very much, Carlos, for actually pointing out that the SCHC payload was not was not actually in the definition, but it is presented. We use it. I mean, it it it's in the text. So this is the the basic thing. That's the data unit. Now, optionally, in some advanced use cases, we may have a control header. Right? And that's not a must. In some cases, can have it. And, actually, in the o six version, there were two versions of that, because we were under the impression that compatibility with the previous version required that. But after the discussion yesterday, it was actually underlying that, no, that's not necessary. So the only type of thing will be, like, we have the control header followed by the rule ID the control header followed by the format that you have here. Now, just to give an example of how we see things is to say that the control header actually needs to be specified by the standard track document by a standard track document. So one such example is the draft VOICI, which can be is a candidate for a control header. Right? We expect that there to be potentially several types of control headers. For example, for the eight zero two dot 15 dot four, over eight zero two dot 15 dot four, There, Carlos and Anna, you know, and and the 6lo working group, they need a different format. And so they just need to specify how that how that format works. And that's in a standard track document. And two definitions that are not there in the o six version is a SCHC header. So basically, that's the portion of the sheet data unit, which is not like the which is the rule ID and, like, and plus the the information that's necessary for processing. And the remaining part is the the SCHC payload. And then we have also the notion of a SCHC header format, which is not there yet today, but we just say it, like, the this is the the type of format that we see, like the sizes of the rules, that is necessary to be specified in some cases. And there is an example of how this can be achieved. Right? But this is not yet on the six version. We will provide, after this discussion next week, we'll provide the seven version. And we would really like to continue the work over that document and the evolution as a standard working group document. Now, we did a study of how this o six version of the architecture impacts the existing drafts. And so we used so, of course, we wrote the draft with our own brains, but, we used AI to go actually over all drafts that are in the working group here today, plus all RFCs that were produced by the LPN working group to see if there are any, conflicts there. And so normally, there are green check boxes here. So everything is the so all RFCs are compliant. The architecture is compliant of with all RFCs. And from the 70 drafts that were actually studied, the translation for 14 of the draft is easy. So that's just a simple search and replace. And there are three that we need to just look a little bit more in into them. One of them is six low. So she covers 15 o four, and we will be working, of course, with Carlos and Anna if they want to to help them with that. And the other one is the delay tolerance. So she covered delay tolerance networks because there is the notion of a proxy and so forth. So we didn't want actually to go and and and and and overdo the whole thing. We have generated diff files for each of these drafts with suggestions to the to the authors to say, okay. Look. Look how your draft will look like with the new terminology, with the new architecture. And everything is on the GitHub of the the working group. And you can go there. You can see the the analysis. You can see the verdicts from Claude and Gemini. You can like, you can see all that. And the work continues. It is not a finished document yet, but we would really like to finish that document. So first of all, we would like for this terminology to be fixed and don't so for it to not change again and to finish the work pretty soon, I would say, by by the end of the year. And with that, I give the floor to you if you have any questions or any comments. Yes, Laurent?
[00:24:54] Laurent Toutang: Yes. Thank you for this great job. I I really appreciate when you and the architecture when you separate the plan and the functionality like compression or or fragmentation. This is something very useful. But I had some I I yesterday, when I saw the things, I I was a little bit trouble and I so I didn't sleep that night. And for for me, there is a confusion. You say at the beginning that what you want is to document SCHC for people that comes. And so you have one part that is what exist, and you introduce also in the document new things like domains that are never been talked before. And so it's quite confusing. Maybe it will be better to have two documents, one document that documents the architecture as it is right now, and another one that define where we wanna go and what are the new things that we we want to study.
[00:26:01] Alexander Pelov: Okay. So thank you thank you, Laurent, for for this. There are a couple of of new notions, but they they were discussed. I think they were discussed at the last IETf when we were discussing, should we call that domain? Should we call that I mean, there were a couple of of of alternatives, and I think that we converged on the notion of domain. So in that aspect, we actually followed the discussions from from Morale. Then we went maybe a little bit too far because we said, okay. Well, there is something inside that will manage the endpoints, something inside that will manage the context and so forth. And and we called one of them endpoint manager, the other one context manager, and so forth. These were a little bit we developed things that were, some way, we felt they were already present, but were not named. And from what we have until now, I think that we were basically documenting how we use SCHC for 6LoWPAN, so for SCHC for 15.4, how we use it for CoAP and OSCORE and how we use it for LP1s. And it's not a perfect document. Are things we're missing as yesterday during the side meeting we said. So we need to add that, right? But it will be with a pleasure to work on that with you.
[00:27:22] Laurent Toutang: You.
[00:27:24] Éric Vyncke: Eric Wang, responsibility for SCHC. While I understand the motivation of having two draft or two documents, one for the new stuff and one for the architecture itself, honestly, if you consider the load of already the working group with so many documents and then after last call and so on in the AIG, I am you do whatever you want. Right? You are the working group. It's not up to me. But it would be way, way simpler if there was one document explaining clearly all the terms. Just a small request. The UK group decide, right?
[00:28:02] Alexander Pelov: Thank you. And yes, we hope to get the documents finalized soon. Well, we have a very busy agenda. This is one of the reasons I didn't want to go in super lot of details. Please read the draft. All of the draft authors that have already they can go and consult the the LP or the the Git. And we'll be reaching out also individually to help them do the migration, which in most cases is going to be just search and replace. But of course, we cannot just let an AI output decide for us. Right? So we saw that it's not always as straightforward. So thank you all. We'll be publishing a seven version next week. And then we hope to be able to produce all the suspended drafts that we're waiting for this work. Thank you.
[00:29:02] Dominique Barthel: Thank you, Alex. So Marco is next.
[00:29:22] Marco Tiloca: Hello. I'm Marco. This is an update on the document describing how to use SHIC for compressing comp headers now in version nine. Yeah. As a recap, the goal is always the same, obsoleting RFC, eighty eight twenty four originally describing this compression. The scope is the same, no change at all in the innermost core mechanics of at all. Of course, we're still being on 8724. I'm not going through through all the points here. They haven't changed with the caveat that the last point about the the YANG data model is planned to be removed consistent with the early review we got from the YANG Doctor for which we have a PR already. Yeah. What happened relatively recently? Last time we saw this was November 2025 in in Montreal. After that, version six went in working request call. There were positive feedback from participants and especially a review from Alexander. Thank you very much. And also another review from the YANG Doctor that was very good to have actually. Putting this together, we addressed the review from Alexander and the review from the YANG Doctor. And I'll say partially, you'll see why some plus two narrowly scoped fixes that I realized the document needed. And all of this mentioned here is already in the version nine, the latest one available in the data tracker. After the cutoff, we had one more PR from the RAM. PR four still open. Of course, I didn't want to rush anything before this session, but it's basically ready to be merged. I'll try to give you an overview in the next slides. Yeah. On Alexander's review, that became PR number one to address it. Again, it's it's merged after checking on the mailing list with the working group. No objections raised. Its content is all into the latest version nine. Other than some editorial fixes, it was, of course, about to be more precise about the list of updates made compared to 8824 as to the covered exotic or most exotic coefficients. And being a bit clear about using the function length like var or generalizes var x, and that ended up even giving an an inline example when using specifically var bit, yeah, in a particular situation that is not revealed. So I think that helped a lot. More, there was some two paragraphs, I think, claimed as editors note that became real text. And Alexander already, even before the yang.org review, had some comments on on the YANG data model. That was all addressed in version nine, although this is practically moved now because of what we plan to do for addressing the angle to review. But right now, it is in version nine. On the narrowest code fixes I mentioned that ended ended up up in PR two, advertised to working group, no objection already in version nine in the data tracker. I just noted that the description of the use of the field descriptors in the rule were overly strict and really expecting each descriptor to be corresponding exactly to one instance of an option while we had already instead an example at least where multiple instances of the same option adjacent could actually be mapped into a single field descriptor in a rule. And, well, the text was relaxed to practically admit something that we were doing anyway. Conversely, other texts that had to be shrink to admit the only thing that is really possible to do in a particular situation where normally you may have no idea of how many instances of the same option are present in the message like your Uri-Path. And if you really have no idea, the best thing you can do is creating different rules to be prepared to handle all the possible situations that can happen. On the YANG Doctor early review, it had comments on the YANG module itself, and those were addressed on top of Alexander's and ended up in version nine. But the main point of the review was you don't need the YANG module here. It's an incremental update to the module defined in 9363, and 8824 didn't have one. In fact, it came later with ninety three sixty three. So I just just to remove it from here, and you can better have altogether a new year module wherever you produce a base of 9363. And, yeah, I I I fully agree the moment I read the review, essentially. So I prepared the PR that I didn't merge. So this is not yet in in the document in data tracker, but the PR has been open for a while. And it's basically about removing the module and very little portions of text about the draft that point or talk about the module and references that become not used anymore. Of course, the module in itself can stay on the GitHub repo, and it's, I believe, very useful material for a later revision of the main module. So this will be APR still open to merge. I mentioned one more a bit after the cutoff. Lauren thanks, Lauren. Noted that we were doing something not a 100% appropriate when specifically using CDA not sent or mapping sent in the rules. We were saying FL can just say not set. It's actually better to put something there. And as expected, it can be, well, a constant number expressing the size in bits of the field if that's just unknown or a function to indicate it's variable or to compute essentially at runtime from previous field, the length of that present field. So Laurent started the PR to put something appropriate in FL in the example rules. Of course, it doesn't change anything in the example of compressed messages because those are still the rules we were meant to use. We work also together on the PR during the hackathon days. And after having fixed the the FL content, of course, we got to the text of the drugs that was talking about this topic that was essentially inconsistent, and we made it consistent to describe what we actually want and what is now in the FL of the examples. And, And, again, this PR is currently open. This is not in the draft yet. So what's left? Well, I think we are almost done, but we need a version 10 where the two PRs I just mentioned are merged. And last but not least, I have to go through the diff Alexander talked about and we discussed yesterday to align some terminology and sentences with with the architecture draft. It's almost a matter of search and replace only. I noticed that the diff yeah. Of of course, it is biased by the input of the architecture, and it just point to mention or refer to the architecture sometimes threshing away something that should be kept as well. For example, references to eighty seven twenty four. So not the pure search and replace. You need to be careful and possibly do a merge of the two things. I'll try to produce version 10 soon. I think there's some final step remained in the shepherding, but then I believe that versions should be ready to be sent to it. That's all I have. Thank you.
[00:36:53] Alexander Pelov: Thank you very much, Marco. So I'm the shepherd of the document and basically I have all the information to write the shepherding write up. I'll do that next week. And I mean, the moment that you like aligned it to the terminology, then we'll press the button.
[00:37:15] Marco Tiloca: I'll drop a mail to the list when version 10 is out anyway at this week, we all think. Thank you.
[00:37:22] Alexander Pelov: Thank you very much, Marco, and thank you for always being super active with the document. It is a big piece and yes, it is a significant amount of work that we are pushing out of the working group now with this document. Thank you very much and thank you to all the authors for this. Is Magnus.
[00:38:11] Magnus Westerlund: Okay. So I'm Magnus Westland, McFrijksen. So we wrote the draft on me and my co author Lorenzo wrote the draft here on trying to deal with the problem of dynamic addresses in there and see if we can get good, SCHC compression of them. There are IPR disclosures on this draft. So the problem we see here is we're looking at into applying SCHC to mobile network traffic. And we have a lot of dynamically allocated addresses, both v4 and v six. So and looking at the rule stability and the possibility of rules applying to multiple devices without having them custom made for each device would simplify the management of the rules. So that's the kind of core problem we see here. So how do we achieve good compression efficiency? Because either you're specifying very little about the addresses and then you send the whole address as they are. So we're looking at that, okay, can we do something better here? Can we actually use, for example, the interface state and the shared address allocation between the gateway and the device to as a way of compressing this and keep the rules independent of the actual device and its exact device allocations. So we also have in the mobile network a number of challenges. Like
[00:40:13] Alexander Pelov: first
[00:40:13] Magnus Westerlund: of all, we don't actually have a Layer two address field the protocol. It's abstracted away, especially over the radio, to other identifiers. So we don't have, like, the device ID or an app ID for IPv6 used in IPv6 rules doesn't work here because there's no v six layer two header to use as a basis to create this IID. Instead, fairly common use for stable IDs use RFC 7217 variants or the temporary privacy address generated. So far, I will come back to these details if you don't know them, but basically, hashed addresses based on a number of input information. So the IP addresses are assigned on a per PDU session, and mobile endpoint can have multiple PDU sessions and have multiple set of addresses. But we like looking for this from a single PDU session context, which is also where we expect the header compression to work on within that state. We also have cases where we have the candidate more addresses. For example, if you have tethered devices and you have, like, for example, a Wi Fi subnet, you can have an additional prefix for IPv6 even to that tethered network or use IPv4 NATs, which later might be simpler. And in practice, in mobile terms, the address allocations is controlled by the SMF, the session management function. So when you create the PDU session, the v4 will come over the control plane. The v six will come in Slack messages or DHCP prefix delegation sent over the PDU session by the and interacted between the SMF and UPF to send this, yes, so you understand how the addresses gets there. But they are based on, okay, when you turn on your phone, you will get an address allocation. The SMS might remember what it gave you that device before or it might actually ask to sign something new. That's all depending on situations, etcetera. So the actual kind of proposals starting proposal we have was to actually look into defining a new CDA and the new matching operation. So basically, collect the addresses you have on the interfaces, remove those that aren't actually being used over the interface between the so we would remove local loopback addresses and things like that. But then basically, just sort them so you can index them efficiently. And then match like, okay, because you don't know what's this is a kind of side table in the implementation, it would end up being something that's preprocessed or regularly checked and put in some type of compressor adjacent state, which is shared and or actually, it's not shared, but it's known by both sides because the allocations is known how they're done. You would have the same index, and you could reference this index by saying, Hey, in this packet, it's this address field, for example, prefix, it's index one. And you would get those 64 bits. And then that way, you could define efficient rules that's not device specific for both v four and v six. So for v four, we would say the whole addresses use this algorithm. And for IPv6 prefixes, this basic would work fine. And I think these are the simpler part. Then we looked into IIDs. They are more difficult, I would say, and has impact. So here, you see on the how we actually generate the ID is to basically has a hash function that takes the prefix, the network interface, the network ID, collision counter and the secret key to generate stable address for which, for the same interface, when you redo this, you would get the same stable identifier the next time you do it. And the DID, that counter is used here. If you actually get a collision against something that already exists, you just increment it to one and rerun the hashing. So and this makes it possible to it may make it possible. The problem here is saying, okay, you need to actually have a joint understanding of both the secret key, what identities, etcetera, for the network interface are to be able to compress it in a similar matter. And then we have a version also for the privacy IDs, which basically just say, let's quantize the clock. So you actually can reference which quant of the clock. So any at any time in if independent when you generate an ID, private side ID, even between, for example, six and seven, if you do it like the Red Cross is, you would use the time for start six. And then you would just reference that this is address which was generated in slot six and have this data counter to really try to compress this. But yes, these have downsides as we noticed about we needed to share all this information, but it would be potential. So just to get higher efficiency. So yes, I'm here to hear interest to see what if there exists interest in trying to solve this problem and what you think of these ideas. I know they are pushing a bit to the boundaries for what's static being based on potentially available information, but it should be so. Yes, Erik?
[00:46:57] Éric Vyncke: Erik, this time, individual contributor on the V six front. Nice to see you, Magnus, in this room, by the way. Regarding the table, right, the two endpoints are building the same table, sort in the same order so we can compress. Got it. Now are we sure that the two table are synchronized correctly? Because they are synchronized because the SMS said, hey, I send you this array, right? And I said, you did a CP. But
[00:47:26] Magnus Westerlund: Yes. You might want to we will think of it that if you need a little bit of version or a little bit of a small, small, small hash that just to verify that you're agreeing on that you have the same input.
[00:47:39] Éric Vyncke: Yeah. If you can lose arrays I mean, again, I don't know the radio. When you say radio, it's not Wi Fi. I know the Wi Fi, you can lose them. Yeah. Right? Or you can send a new one. I'm a little bit uncomfortable on the p v six side. The same thing for the privacy extension. So I was I mean, I like the idea, by the way. I forgot to say this. You may want to run this at six months as well at some point of time.
[00:48:02] Magnus Westerlund: Okay. Yes. For the mobile network, I think we have fairly good reliability, etcetera, to get this. And you need to get the address before you start using them. And at least for the prefix, etcetera, you will maintain this as long as you have the PDU session. So you will have little changes in most cases there. But yes, you do need a solution at least to handle changes. And the other part is, I guess,
[00:48:28] Éric Vyncke: when you should do the HTTP PD and you receive a slash 60, you need to fill the table with the 16, if I'm
[00:48:35] Magnus Westerlund: not Yeah. Yeah.
[00:48:35] Éric Vyncke: This kind of stuff. Right?
[00:48:36] Magnus Westerlund: Yes. Yeah. You need to adopt your how many bits you give this based on what address allocation plans you have for.
[00:48:45] Alexander Pelov: Yes. Thank you very much for the presentation and for the document. I'll go a little bit fast here. So the iid, I like very much that idea because I think it fits of what we have been done already, like, in the state list. I mean, there are good things there. On the address table, I I think the risk here is, like, we have the static description of the rules on the on side of the context, and then we have something outside that can be much more much less static, let's say. So probably a way to think about it is for your document to explicitly specify what are the requirements to the interfaces to the to this address table. Mhmm. So I don't think you need to to to actually specify how the updates and synchronization of that address table will work in that document. Right? Of course. Mhmm. But you may say, well, the the requirement is that whenever there is an update, this and this and this needs to happen. And Yep. And this and this and this needs to happen so that we don't end with any of the the the cases as as Eric said that, you know, like, there is some desynchronization. So then suddenly nothing works anymore and your device is unjoinable. Like, you cannot even connect it because, you know, they think of different things. So there is this subtle risk, and I think the interface needs to be really strictly defined so that we are still in the static.
[00:50:06] Magnus Westerlund: Yeah. Okay. Yeah. And maybe then it means that you could use one or two bits for versions so you know that you're referencing this particular agreed on or generated information. Thank you. Yes. Anything else or? Laurent? We have yes, we have more in queue.
[00:50:26] Laurent Toutang: Yes. So I will try to be quick as possible. Thank you for this work because we we have to work on on addresses on on the whole, so that's very important. And what you have done right now is very, very basic. One point I I didn't understand, it's that why don't you use a matching list for your addresses and put them directly on on the table, on the rules, knowing also that we are working on management, which means that we have a standard way to push information from one world to the other. And I encourage you to talk with Samar who is on the room and made some prototype where we can exchange rules between two entity using co conf management. Another point, it's but you the prefix length, in fact, we never talk about that. But in the rule, you have the length. So if you want, you can put a prefix of sixty and nine service ID bigger. Yes. It fits with what we have in Czech.
[00:51:31] Quentin Lampin: Yeah.
[00:51:32] Laurent Toutang: And but we we have no time, but I think it's good to talk more in in terms and your on the meeting list on that. That.
[00:51:44] Alexander Pelov: UNIDENTIFIED you very much. Lorenzo?
[00:51:58] Lorenzo Cornell: Hi, everyone. Lorenzo here from Ericsson. And this is joint work together with my colleague, Magnus Vestalund. Yeah. So this work is about providing proposing SCHC context management extension to the current framework. So there are there is an API disclosure on this on this item. So if you want to know more, please follow the links. And let's get into the the problem that we are facing. So, as soon as we will start using and deploying Sheikh for scenarios far from from IoT, we might face some scalability issues for when it comes to deployment. For example, we can have a context growth as more devices are added to the the network. And also, if you are considering the payload compression extension that we're also bringing on in this working group, this might generate many new rules because of the dynamic nature of the of the payload, for example. And this might lead to duplicate field descriptions and also frequent updates between the sheet nodes. As the set of rules grow, also the time for matching the rules might also increase as there might be combinatorial explosions. For example, now that we don't have the addressing extension that Magnus just mentioned, we might need to replicate the same rule for every different IP addresses, as a matter of fact. And then also, just to add more complexity, we also could be dealing with IPv6 extension headers, which they're variable and add more complexity. And so the solution that we propose here are actually two. And one is about providing referencing rules to create static compositions among rules. And for this one, we propose two CDAs. The first one is RefN that just references another rule unconditionally. And the other CTA that we propose is RefN M that allows to reference rule N but by modifying adjacent M fields. This is just for tweaking without repeating the rules. And then for providing more dynamicity when it comes to rule definition, we proposed this branch CDA that allows to point to other fragments according to certain conditions. And here we have two cases. The first one is to use the match mapping operator that is already defined in Sheikh. And basically, we would do the branching based on explicit header fields. And then we have the match rule, which we which is newly proposed in in this draft that is about branching by probing the next the next rule based on the payload in the packet. Let's get to the to to see how this work in practice. So here we have RefN and then you see the on on the on the left side, there is the, our Sheik rule. And, basically, with the Rev two, we are telling the Sheik node that we are referencing rule two in that specific case is, an IPv6 rule definition. And therefore, we can also continue to other field identifiers if that matches. Otherwise, if it doesn't, it it just breaks it. It goes to the next rule. And and, yeah, this this eliminates duplication for shared protocol layers. For example, we don't need to define again the same IP rule both for UDP and TCP and for all the other combinations for what it matters. But then, you know, we might have this problem where, okay, we have just defined an IPv6 rule and and in that one, we are saying that the next header here is UDP. But now we want TCP and we don't want to rewrite yet another rule for that. So we can say ref edit to one, like in this example. And then we are specifying that the next error this time is six, which is TCP. Right? So the Sheet node will point to rule two and will just look out for the target value six this time. This is a neat way for just doing a small tweak to an existing rule without redefining the rule. And let's get to the more dynamic part of the draft, which is about defining the branch CDA. And here, at the moment, we thought about encoding some semantics in in the field length field. Here, when the field length is major than zero, then we perform the match mapping. So we do the we branch on the actual header. I'll I'll show it shortly. And then when field length is equal zero, the branch is performed on on the payload and probing the existing defined branch alternative and see whether there is a match or not. And if there is no match, we should remember to terminate it with a branch new statement. So this is how the match mapping works. So, you see here we have the IPv6 next header field and there is an array of values in the TV, in the target value. And it just works that when we define this mapping and branch three, for example, on the target value 17, which is UDP, if there is a match, then that specific branch is matched and put into the residue with the value there the cent, which is an index similar to what Magnus just showed in his presentation. And once there's no match, there is the branch null that basically makes the matching operation failing. And then, you can just move on to the next rule. Yeah. And then, this is how the match rule works. This is the newly proposed matching operation. Match or matching operator, by the way. And here, we have the fill length equals zero. So when that is zero, we know that we need to basically check the payload and see if it matches any of the branches there. And and yeah. So and and and in this case, order on which they are the branches are defined matters, because the first one that matches is also the one that goes to the residue, always using this sent column, which is an index based on a mapping table. Yeah. And once again, if there is no match, basically we terminate the compression with null operator. Yes. A few security considerations. So, by providing this new CDAs, we technically introduce some issues when it comes to circular dependencies. So an error in defining the rules and using these new CDAs or a malicious context manager might want to inject cycles and and loops. So this way, once we are trying to do the matching, well then well, it doesn't resolve, basically. Of course, that and and we need methods for mitigating this. Another thing could be resource exhaustion. Again, not so careful. A context manager on a malicious one can architect the rules in such a way to waste resources. Therefore, for example, increasing the latency for doing the matching. And also, we we need to to think about context integrity because we must be sure that the context are exactly the same and they are synchronized. And I know that there are already some works on on trying trying to fix this issue. Yeah. So this concludes my presentation. Thank you everyone. And I'd love to hear from from you some some feedback. Thanks.
[01:00:42] Alexander Pelov: Thank you, Lorenzo. Very interesting work. And I think it it points into a place that, you know, how to represent the context in a in in a compact way, like in a three way. From what I understand, if you have, like, the a context expressed with the CDAs and the matching operators that you have, The exact same thing can be represented with the CDAs and the matching operators that we have today. It's just that it's going to be much more verbose. Right? Because maybe you'll have, I don't know, 10,000 rules to represent the same the same thing that you can represent in a much more compact way. Right? So my question for you would be, isn't this more like a new data model that needs to be defined that basically says, well, in your implementation, your local device, like, you represent that, you know, with this branching structure and where you have, like, the references inside and so forth. And the software actually also implements that in this way. But from the outside world, it can be seen as RFC eighty seven twenty four compliant and so forth. Right? Yeah. That is that
[01:01:56] Lorenzo Cornell: is a very good point. And I think that would work especially well in the static case where when we where we have proposed the RF and RFN. So that would work. Of course, you still have the problem that you have this rule explosion and and therefore, you get all the side effects of that. And then, of course, you don't need to modify too much the existing framework. I'm not sure that approach would work on the on the on the branching because there is dynamic and there are certain things that you can only get to know at runtime. So but, yeah, that's a great feedback, and we can work it out in the in the working group and see what makes the most most sense.
[01:02:36] Alexander Pelov: I I think it could be interesting to have maybe two data models. Like, one is, like, compact one, but a ship compliant device needs to be able to expose the non compact one, right? And then Yes, this
[01:02:50] Lorenzo Cornell: is something that we should definitely investigate. Magnus
[01:02:54] Magnus Westerlund: Wesselen. Yes, I mean, the point with the branch is very much to try to cover cases where you start seeing extension headers, things like that, where or dynamic structures. If you try to, for example, compress RTP that location has CSRC fields or header extensions, you would run into these type of problems.
[01:03:19] Alexander Pelov: You very much. And I'd like to see the work continue. And yes, if it's to see how it goes. Thank you. Oh, we had okay. There was Alejandro, you wanted to see, but it was locked. Okay. Okay. Yeah. Please.
[01:03:40] Magnus Westerlund: Just a quick question because we I mean, how is this is this very different from hierarchical role parsing? Have you seen this? Okay. I will send you an email. We we can check together. Yeah. Thank you.
[01:03:57] Alexander Pelov: So next is Conte remotely. Conte, are you there?
[01:04:04] Quentin Lampin: Yes. Can you hear me?
[01:04:06] Alexander Pelov: Yes. Okay. Cool. So we are starting the timer. Ten minutes with the questions.
[01:04:12] Quentin Lampin: Yes. So this presentation is about Voisey. It has been discussed a bit on the mailing list, and this presentation is going to be in two parts. The first part will be a quick recap of what VOICI is, and there is additional information that we cover very fast, which is new since the discussions. So, really, what VOICI is about, this is about the case where we need to have an explicit discriminator to discriminate between sessions. The case is where, for example, you have a sheet that are in it, and you need to hand it over one of the instances that run on an endpoint, and you need to know which one. In most cases, you have the information available in the same packet. For example, it could be a dev UI, and this covers the case where you don't have this information available. So this is the key problem that was the targets. And then the rest is just requirements that arise when reviewing all of the other documents and the charter of the group. So we need something that would work on top of every carrier layer that she is supposed to work on, for example, over Internet, over IP, over UDP, and so on. And then there are cases where we also need to restore some information. For example, when we say this is a sheet that I need, we need to signal that. We need to replace, for example, the original UDP port, and we need to restore that. That is the case where we want to add integrity, and there is the bonus requirements, which is we might want to signal that there are more than chic in the world. So this is what it is about when we talk about content identification. Alright. This is just a slide that shows that we have done our homework. And question was, is there any protocol that would fit the bill, basically? And the answer to my knowledge is no. So what is Voisey? VOICI is mainly a header. The header is formed of two parts, one which is fixed. The fixed part is one byte. In there, you find flags, and those flags are actually telling you if there is an original Internet, it's a type of port that is carried over for reconstruction later. There's a flag that says this is well, there is an integrity. There is a CRC, which is appended. There's a content identifier. And since Schick is the best compression protocol, there's the o one, the number one, flag for it. And then you have a short session ID. And in case we need more than seven values for the session ID, so seven instances running on the device. We can extend that to a larger session ID using the value seven and a an encoding variable integral encoding. And then, obviously, when you have session CRC's and originality type slash port number carried over, you have those appended to the fixed port. In the case where we have a very constrained network, mostly, Voise is going to be one byte, the flags and the short session ID. So, really, what is Voisey and how does it relates to Chic? Chic is proposed as a dispatcher, but mostly the VOICI header is proposed as a sheet controller. And, again, only in cases where we need multiplexing, of course. What's new compared to what we discussed before in the mailing list and the previous presentation during the interim is that one of the benefits of having a specified control header, and in this case, was the header. The interesting part is that we have a specification, so we can construct sheet compression rules for it. And this is just an example on how we can do it. So example with only two sessions. Since it's Voisey using the context of sheet, The CI value is known. Let's consider that we don't have a original letter types to to restore. Let's consider that there is no integrity check, no CRC. In this case, we can build a very simple compression rule for that. And for the cases where we have only two sessions, this is compressed down to one bit in this case. So just to show that even though it might seem I can write an overhead to have all of those fields that do just more than having a session ID. It's just to show that we can still compress it. Alright. So the the rest is just an example that I tried to put up just to show how it could fit into a complex design architecture, and this is taking the example that we have considered a lot when discussing the sheet architecture. So this is considering a six flow network. It's not meant to replace what's available in six flow, but just to show a showcase exam provide an example of of of Voisey and how to compress it. So in this case, we have a very simple network topology. We have a six low node. We have a six low router, border router, and a server on the Internet. On the six low node, we have two applications, one using co op and one using co op s, and that sends traffic to the Internet server that runs the co op and co op s servers. We have two chic session that are multiplex, one for each of those application. And we have a lower layer of stratum for the six low network with a session that is a session zero in this case. And, sorry, the mouse is not working. Yes. Just to show how it could work. So there's a first instance that we'll do the compression of the co op and UDP part. This will generate a data unit. Since we have two cases in this in this scenario, one is going to have the session ID zero and the the other one is going to have the the value zero one. And that with the I p v six header, so voice plus IPv6 header can be compressed using the lower stratum and provided new residue, which is the sheet that you need to. All of that is and transported over the six network and add the six LBR. We restore the voice in IPv6 header, and then this goes to the to the server, which is going to use the reconstructed VOICI header to route to the correct application. So it's a co op over UDP or co op s over UDP. To conclude, so Chic is just a was it just a multiplexing capability? This can be used as a dispatcher and a controller for Chic. The design is modular. The idea is that if we only need multiplexing, we don't have to carry all of the original letter. We don't have to carry a CRC. But if we need them, we can add them. It's adaptive in the sense that we can target very long, smaller numbers of session. In this case, we have only one byte and compressed, but we can go much more if we need them. And since it's specified, at least in this draft, we can compress it using Cheek. That's it. Back to you. I would be glad to have your feedback on that and if it fits the requirement, if there is something that is missing, etcetera. Thank you for your attention. Yes, Laurent?
[01:12:30] Laurent Toutang: Yeah. Thank you, for your presentation. So it's points I raised on the on the mailing list. So for example, on slide eight, if you can go back to to this slide. So you you present here a compression rule and so that's that's very nice. It's and in fact, it's what we have already in in the chicadir. And so and if you, for example, instead of not send, you put ignore and value send, then you you have the serialization of your of your of your header. So I don't see the interest to create something that has some semantics that are more complex and not just keep what we had in before. It's just she can't can't read read And then we define some fields, and the rule gives the serialization of this field. And you can if in compressed environment, you send nothing or one or two by bits. And when you want something straight because you want to be high speed, then here you want that human data rule, and we don't have to go to to a new protocol.
[01:13:42] Quentin Lampin: I'm I'm I'm not exactly sure. I I agree with you that it's very similar to what was in architecture o five in the sense that in architecture o five, you had exactly the same concepts, being able to add a sheet control letter, which in a sense had a session ID in there or an instance ID, if I remember while the the the naming at the time. Really, the the the key point here is that I believe we should have some kind of format that describe for a deployment what is the structure. Yeah. But because if you want to build a a sheet world, you'd been you will need a data model for it. You need to add that to yeah. I I think you we need to to to deploy them, and we need to refer to a data model for this chic header.
[01:14:27] Laurent Toutang: Yes. But here, you need a document, so it's not so. Yeah. But we need a document. It's more flexible because you have to update an RFC if you want to to push something. My other question is on the v, what do you do if the v is not good?
[01:14:44] Quentin Lampin: The v is not good. What do you mean by that?
[01:14:47] Laurent Toutang: For example, you have a version of it. So if the version is not good, what is your reaction?
[01:14:55] Quentin Lampin: You you mean if if the if you receive voice header with v being not zero? Yeah. Is that is that what you mean? Yeah. What it means that this this is a new version of the protocol. I would say it it's basically the same as any protocol. If you have an I p v six only implementation and receive an I p v four value header, then I suppose you you would have to discard it in the same sense that if you receive a voice header with a value of one, probably you're going to say, oh, I don't know this protocol. I'm not going to to act on it. Really, I mean, I I see what this the question that you might have is why having this v outside of the pen of having a header that is Voicy. Really, the idea is that having one bit can have kind of like a future proof property to the protocol. We might not know how this this protocol But
[01:15:50] Laurent Toutang: that's why you you put I think you had pushing complexity because if you have a rule, you agree on the rule, that's the basic definition of chic, and then you put the information you want. And if you go to defining a protocol, it means that, for example, if you are not agree on the version, then we have to send an ICMP message or and so you are opening a lot of complexity in in the architecture and in
[01:16:17] Quentin Lampin: the So so this is not going to be in the architecture. This is not supposed to be part of the architecture. This is a proposal for a format of a sheet controller. And the the point I'd like to react to is that you say, well, we could just have a
[01:16:31] Laurent Toutang: rule
[01:16:31] Quentin Lampin: ID, and then we do whatever we want as as in the the format of the sheet controller. But you still need to to write the the the the the sheet rule that that tells you how the header is formed.
[01:16:47] Laurent Toutang: Yes. That's the point
[01:16:48] Quentin Lampin: you need to do it, and you need to specify it. You need put that in a stronger track, and you're going to have the same kind of problem. And possibly, only difference is that in your case, you're not going to have this v value. It's it's going to be only the session ID, but still, that's needs to be to be written somewhere.
[01:17:06] Laurent Toutang: Yeah. But that's you use all the shake mechanic to do it, so you don't have to define something else.
[01:17:11] Dominique Barthel: Let's continue the discussion
[01:17:13] Lorenzo Cornell: that way.
[01:17:14] Quentin Lampin: Okay. Thank you, Laurent.
[01:17:16] Dominique Barthel: Thank you.
[01:17:16] Alexander Pelov: Yes. Thank you. And here on that point so thank you. Thank you, Contra. Laurent, on your point is, yes, the architecture document is an informational document. It says that there is a control header sometimes. So there may be multiple standard tracks that define how that works. And I would invite you to write a proposal that actually specifies how you can use chic only for a control header. And and then I think that it's up to the working group.
[01:17:48] Laurent Toutang: So content as is, I think it's architecture five.
[01:17:54] Alexander Pelov: Sorry?
[01:17:56] Laurent Toutang: I think it was before in the architecture document.
[01:17:59] Alexander Pelov: Yes. It it was not in the place be in the architecture. In the architecture, we said that there is just a control. There is a control header and there needs to be a a standard track document that says how that works. And I think we'll need that for Ethernet and for others where we'll need to be processing on the line speed and we cannot go in for every individual packet to look up. So we'll need to have some structure in some cases.
[01:18:22] Laurent Toutang: Yes. But you can have the structure with discuss on that on minutes.
[01:18:28] Dominique Barthel: Let's move on to next present let's move on to next presentation, please.
[01:18:43] Samar Abbas: Okay. So hello, everyone. I'm Samur. And this presentation today covers our exploratory draft on how we can use Schick to compress quick frames. And in this, basically try to answer or explore the question of how and then under what circumstances or conditions QUIC can be used to compress the frame metadata for QUIC frames. So most of you already know probably, Quick provides a secure, reliable I can adjust this a bit. Yeah. So it's Quick provides secure, reliable, and multiplexed transport over UDP. And what you might not know, a quick payload usually includes a thing called frames. And these frames include not only the application data, but also transport metadata, including frame types, stream ID, offset, length, and acknowledgement information based on the frame type. And so this is kind of like a frame header, and these fields can introduce an overhead. But for regular Internet traffic, this is very small and negligible. But in certain scenarios, for for example, for very small packets or constrained or expensive links, such as base communications or links where the traffic is very predictable, this traffic, this overhead can be more major. And so in that case, we can use Shake to try to compress it, but there are some problems for this, firstly, which is that any savings that we get should be larger than the rule ID and the registry, which is the usual Shake data unit that introduces, but also any framing that might be used to be more compatible with the, quick processing. And the second one is the more architectural constraint, which is that quick, payload is encrypted. And so we cannot just have shake on the path to compress this frame headers, but it has to be integrated within the quick pipeline itself and decompress after decryption and so on. And we can try to design this compression based on some independent decisions. For example, the compression unit, we could have one rule per frame because there is different types types of frames. And or we could have one rule that describes a sequence of frames in the quick payload. But both have their pros and cons. Like, one rule is more general. But if you have a sequence, we can save on the overhead more. But then it's less general, and the rules can become very large very quickly. The rule context itself can be more basic with most values being values sent, or we can have more traffic specific rules for which can use the dynamic update using CorCom, for example, to update the rules throughout the connection. And then the encoding itself, so we could use, for example, a quick frame extension type for Shake specifically. And even that could be a general frame type, or it could be a more optimized one, which is for each type of frame, which is a compressed version of the original. But then we would need to a lot of frames for each type, and then, again, it would and then then the other one is to introduce an alternative payload syntax, which would change the how the payload is structured or encoded by QUIC. But this would require more deep changes in the QUIC department itself, so more savings maybe, but more complex. The the packets could be the the rules could be defined with the rules that are more packet stateless, so they do not really It does not depend on the one packet or the other. Or it could be based on the one packet's decompression could be based on the last one. And so we could start with a more general profile, which are more traffic specific rules with the rules based on a complete sequence and the packet stateless reconstruction. And based on that general profile, we can look at different encoding mechanisms and how much savings we can get. Should be quick. It's, the the the result, as you can see, is that we do not get a lot of savings. The most we can get is based on this. It is in the draft, detailed in the draft, of course, but this alternative syntax replaces the frames themselves, we use the more generic shake data units how with the with the rule ID and the residue, but then it completely changes how QUIC is transported even if it's on decompression resulted back into the original QUIC packet with the frames. But, yeah, to save more, we would need to have, for example, nine multibyte fields using it could be using rule management like for fields, frames like stream frames for this for the stream ID. It is better to have a more predictable traffic so we can compress these frames within one rule and bundling the multiple frames in one, and of course, try to reduce the overhead as much as possible. But the major conclusion of that, of our exploratory work, is that it is technically feasible. But already quick frames are very compact because, like most of these frame types, they are one byte only. And even the integer values for these frame fields are quick uses, for example, integer, variable integer based encoding. So it's very compact already, and we're trying to optimize something that's already quite optimized. And so the gains that we get are in a very specific scenario and might require deep integration into QUIC itself, which introduces more complexity. And it's not really worth it based on the gains that we might get for, for example, one or a few bytes per packet. And so instead, we think that the next work we should work on is more on the dynamic rule management using core comp for which we could we we will we plan to work on more the rule installation and updates and for that optimize RPCs and other works, for example, private seats that we'll talk about next. And, yeah, that's it. Thank you.
[01:25:05] Éric Vyncke: Eric Link, again, and you're a contributor. And Magnus, you can help me there. As you know, transport better than I do. As far as I know, Quick has got a padding function Sorry. Basically to prevent traffic analysis. Was it part of the draft? Sorry? In Quick? Mhmm. As far as I know, there is a padding function basically, pad the content
[01:25:26] Samar Abbas: Yeah. Yeah.
[01:25:26] Éric Vyncke: Right, to prevent traffic and then traffic line analysis.
[01:25:30] Alexander Pelov: Yes.
[01:25:30] Éric Vyncke: Is it part of the draft?
[01:25:32] Samar Abbas: No. Initially, we just looked at major frames, for example, stream and act based on some perf and bulk runs that were for just upload and downlink scenarios. And we saw that these were the majority of the cases. And first, we just wanted to see, for example, these decisions based, how we could have a context, how we can do the encoding, and based on that, what gains we could get. And then we can generalize it more to the other frame families. But because those were the majority that we witnessed from doing some experimental runs, we focused first on just these frame types.
[01:26:08] Magnus Westerlund: Magnus, West Lund. Yes, I don't think padding is used much for really for it. I mean, it's available for doing concealment. But I don't think it's normally, it's not used that much. My question here was, you said your next step was to do outer. Are you expecting them to compress the SID? Is because that, I think, is the connection ID is the only really unencrypted information. Otherwise, you have one byte of most
[01:26:36] Samar Abbas: Exactly. So for the connection ID, it's what Laurent told talked about before was using CoreConf. So rules are static per packet, but you can dynamically update them through the connect throughout the connections to, for example, have a rule be updated with the now the connection ID in place, which can be learned over the connection, and we can discuss about it later.
[01:27:01] Magnus Westerlund: I just wondered because I see that I could see that's the only field that really you get a chance of compressing. Okay. Thanks.
[01:27:07] Samar Abbas: Okay. Thank you.
[01:27:09] Alexander Pelov: Thank you very much, Senor and Laurent. So we have around three minutes and if you can fit Laurent? We cannot hear you.
[01:27:25] Laurent Toutang: Yes. My mouse has disappeared. So I will compress my my talk. So the goal is to talk about a way to compress core conf. So here, you know the architecture. So we we have chic and we have two point to point association. And so the goal here is to say, if we have a core conf message in the middle, can we compress it to gain things? And it's useful for data plane, but it's mainly useful for us because we will do management and we will have to exchange words. So here we have a chic rule, so that's the new format we have to develop. So what is in the range is the seed as it is, and in yellow, it's the delta encoded seeds. So, what we propose is to move the seed from its space. So, also seed are positive number. And what we propose is to use negative numbers, so make a translation of, the seeds to use very small negative number because this number are smaller in their presentation into CBOR so we can have gains. So here is an example. Here is a rule. It's about 4,000 bytes. And when we do the compression, we have 3,000 bytes. So we divide by one fourth the size of the rule, which is quite quite nice. So we discuss that in the core working group to see if it's possible to get these first negative numbers. And regarding Cheek, it means that we need a new MO and CDA that will be translated where you put the seed files, the description of the young data model, the youngest and the offset we want to to do. And this way, we can have a very generic and strong compression of core of core model. So the other impact on seed allocation, it was a number that has close to minus one or smaller. So it's already what we have done in the young data model for the rules is to put the very frequent identity at the beginning, like equal ignore, and the less frequent far away from the beginning where we have less compression. And this way, so we can have good gains for sheet data model, but also for payload if it's carry cork off. One minute.
[01:30:02] Alexander Pelov: Oh, okay. That that was efficient. So if you have any last questions to Laurent. Other than that, yes, thank you Laurent and thank you for also presenting this to Core. It's an interesting work and we'll be following it. And thank you all for being here.
[01:30:21] Éric Vyncke: Yes.
[01:30:24] Alexander Pelov: Thank you, Mario.
[01:30:25] Dominique Barthel: Thank you.
[01:30:35] Alexander Pelov: Thanks to our minute takers. Thank you, Marco. Thank you, Alejandro.