Session Date/Time: 31 Mar 2026 14:00
Laurent Toutain: Good afternoon, everyone. Nice to see you here.
Éric Vyncke: Good evening, Alex.
Laurent Toutain: As usual, we're waiting for five minutes after the hour to start.
Laurent Toutain: Yes. And thank you, Marco, for putting the links of the notes in the chat. So, it is five minutes past the hour, and we can start. So, as I said, hello, everyone. So, this is our first interim meeting after IETF 118. We did not meet there, so this is the first opportunity we have to discuss. So, this is an official IETF meeting, and as such, you agree to follow the IETF processes and policies. So, this is only a reminder of some of these policies, and a full version, a linked version of this text is given in that web address. All IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues at all times. If you have any concerns about behavior, please contact the ombuds team, who have duty of confidentiality. If you are aware of any IETF contribution is covered by patents or patent applications that are owned or controlled by you, your employer, or your sponsor, you must disclose that fact or not participate in the discussion. And for detailed process information, consult RFC 2026 and the rest of this meeting and the rest of this Note Well.
Laurent Toutain: So, for today, we have two items. So, the first one is first we are going to review the status of the documents of the working group. And then we have the first presentation, which is FEC mechanisms for SCHC and an update on the SCHC architecture. So, the work is still ongoing, but we wanted to give you some information of where we are. And of course, if you would like to join at some point, you're happy to do so. We'll be happy to do so.
Laurent Toutain: So, the documents are advancing well. So, we have actually two documents in Working Group Last Call, one document and two documents which only need to be... we wait for a new version to be submitted by the authors so that we can start a Working Group Last Call. We have a couple of documents, one of them that are expired and we'll need for them to be updated by the authors. But of course, our most important point right now is to get the architecture document advancing. Yes, Marco?
Marco Tiloca: Hi Alex. On the document 8824 update, the Working Group Last Call finished on February 10th but was never closed formally. There was some feedback on the list, more on the line of "this is ready," not really actionable comments. You may want to have a look and then we can make the document progress.
Laurent Toutain: So, actually... oh, okay. I forgot to erase one of the slides. So, this was what I prepared. Thank you, Marco. This was exactly the point I wanted to make here. So, the first one is about the SCHC protocol numbers and the SCHC 8824. So, we had two votes that said they agree with the document as it is by Ricard and by Carles. I remember there were people that during the last meeting said that the document is ready. I'm not sure we actually if we need a shepherd for this... I think we will need a shepherd for this one as well. But in any case, what I'll do is I'll provide at least one review so that we're able to close... like to... to call the Working Group Last Call like officially terminated. Right. I had this on my to-do list and I just didn't get to it. And yes, Marco, I mean, you've done your work on your side on this one. Right. So, I'm taking the point for this one and we'll need to find a shepherd for this document. I have a couple of ideas about that and I think we'll be able to close this maybe not in the next two weeks but in the next month because I'll be a little bit away for the next two weeks. But yes, Marco, I mean, you've done your work on your side on this one. Right.
Laurent Toutain: On the document SCHC protocol numbers, so there were a couple of reviews. I did a review and there are some changes to be some modifications to be made. I sent that to the mailing list and now the authors would need to provide some update of that document. The security section will need to be revised and there are like... I proposed some text on how the UDP port objections must be addressed. So all that is on the mailing list. And yes, we'll see like how it goes and we'll need to find a shepherd for this document as well.
Laurent Toutain: And there are two documents that are remaining basically that are that will be ready for Working Group Last Call. So it's ICMPv6, the document on ICMPv6, and the other one is on SCHC over networks prone to disruptions. So, hello, Laurent. I'm not sure if you can hear me. Can you hear me? Um, I maybe... oh, yes. Yes, but I'm not sure if Laurent can hear me because he has like an icon like... in anyway, like so I would really like for the authors of these two drafts to be able to submit... yeah, there was some problem trouble connecting... to submit like an updated version for the SCHC ICMPv6 compression so that we can call... like it's an expired draft for this one. And SCHC over networks prone to disruption, I think the point was just to submit a new version and we can start the Working Group Last Call. So that was my understanding and we'll need to find a shepherd for this document as well. I don't think it had a shepherd.
Laurent Toutain: So with this, that's the overview of the status of the drafts for the moment. Yes, okay, that's the... oh, no, that was from the last slide. And with this, I'm going to give the word to Javier, to Alejandro. So, Alejandro, do you want me to... okay, I'll pass you the control of the slides. So here you go.
Javier FERNANDEZ: Yes. Okay. Can you hear me well?
Laurent Toutain: Yes.
Javier FERNANDEZ: Cool. Okay. So we're going to present the last update to this draft called draft-munoz-schc-over-dts-iot initially. So this was to propose a solution for networks prone to disruptions, specifically how to make SCHC more reliable over these networks by including a FEC mechanism. So the thing was that previously we proposed a very simple XOR mechanism, which was kind of like just airbags for SCHC. And later there was like a bit more developed draft, so this one, where you know there's like it's very robust and so it's like it uses a matrix to to organize tiles and so. So I'm just... so we have actually merged both concepts under the same framework. So now it's unified and I think this is ready for for adoption.
Javier FERNANDEZ: So just yeah, just a recap. So basically when there are long delays or losses or errors, well, we just need some sort of reliability method for SCHC because right now there's none. So what we propose is basically a new fragmentation mode called ARQ-FEC. So it works more or less like ACK-on-Error with Compound ACK, except there's there are two main processes. Instead of only being fragmentation-reassembly, there's a encoding and decoding process. And there's this concept of coded structure that interacts between the the two subprocesses within the mechanism. So we receive the SCHC packet from the compression layer and now the fragmentation layer becomes this box.
Javier FERNANDEZ: So what we have introduced is the concept of encoding geometry. We have allowed by including encoding geometry, we define a C-stream, a coded stream, which allows simpler FEC schemes such as XOR, which was our our concern. And we have improved some wording. So more in detail, what we have coming back taking again the the architecture from the previous slide, we have the encoding process which applies the FEC scheme to the compressed SCHC packet. And in the version in the previous version of the document, there was only this matrix-based encoding structure. So this is actually kind of complex. Our concern was that it might involve too much memory, yeah, like thinking forward into implementations we have like a strong a big memory footprint. And so we've added the stream, which is just a linear thingy, and we work under the same concept. So we basically fit XOR into this very cool framework. And finally the fragmentation-reassembly process is just cutting up into tiles and transmitting. So that didn't change much. So I think that's it. I hope it was comprehensive. It was really short.
Javier FERNANDEZ: And so now this unifies the... so my main concern was that we had the like the XOR solution and this matrix-based solution, which is like it's a super cool framework because it's very reliable. We can use very complex FEC mechanisms to provide like extreme reliability. And now we allow some some very simple like minimal memory footprint thingies. So yeah, if please if you have questions let me know and we would like this to be adopted soon.
Laurent Toutain: Yes, Alex. Yes. Um, yeah, thank you very much for the presentation. So yeah, I wanted to know a little bit about the concept, the new concept of streams that you that you added. So in terms of implementation, I think that you have implemented this mechanism, right?
Javier FERNANDEZ: Not fully. We have we have some implementation on the matrix-based. And on the stream we have an example in included in the draft, so you can you can go ahead and check it out there.
Laurent Toutain: Mhm. Yeah, yes. I mean, I have not read the latest draft, so I need to do that for for this part. So what I was probably was interested in in knowing like the memory footprint of of the stream method. So if I understand correctly, this is... can you go back like on the previous slide? Yes, maybe this one. Yeah. Yes, let's say it's this one. Yes. So when you have like the SCHC packet, so then how much memory does it takes with... so you can have like if the SCHC packet is very small, let's say it's it's smaller than the MTU, right? So you don't need to basically to fragment it. So how would that work with the stream approach?
Javier FERNANDEZ: I'm not sure I understood your question. But so talking on memory footprint right now it's a draft, I we don't have any data. So but I encourage you to look at the the example included in I think it's Appendix C. Okay. And I don't know how if I can showcase it or share my screen somehow. But otherwise we just apply the... so for example one a FEC scheme that is allowed now by the stream is just to do XOR between within each encoded block. And and so then it depends on your XOR configuration, you could add one XOR symbol per every two symbols.
Laurent Toutain: Yes, I mean, that was... that was the point of for my question, right? Because I like this lightweight approach and the point is to see like if you have like a small device where memory is an issue, like could be an issue, like if you have a lot of if you need a lot of memory to calculate the FEC, that could be like in some cases you know, it could be an issue. So having a way to have a low memory footprint for the buffers, that could be that could be interesting important for exactly.
Javier FERNANDEZ: And so the here the main thing is that I specifically chosen the stream word to define this linear thingy because since it's a very simple FEC scheme, we can just calculate on the fly and not necessarily store things in memory. Just thinking forward, you know, I know this doesn't really concern implementations, it's just a future thing. So I hope this answers your question. We're going to go on to the next question. Rodrigo, I think you have some comment.
Rodrigo Munoz-Lara: No, is is answer to to Alexander because Alexander question is if we are implement the solution. But I implement the solution, I already implemented the matrix-based solution in my code and I have tested my code and I'm able to recover the SCHC packet even when fragments are lost. Then right now in my code is working.
Laurent Toutain: Yeah, cool, thank you. Yes, I mean, my my question was because I know that I remember that you have implemented the matrix-based approach and I was curious if you have implemented the stream-based approach for for the question of like the memory footprint.
Rodrigo Munoz-Lara: Yeah, this is the next step: implement the stream solution.
Laurent Toutain: Okay, perfect. Thank you.
Javier FERNANDEZ: So once we implement this, we might have some data, like footprint data comparison. And so, would you think this would be a requirement to call the adoption of the draft, of the solution? We can of course discuss.
Laurent Toutain: Well, no, I mean for... no, it's a good question. It's I mean, implementing it's not a hard requirement, but the point would be at least to be able to say "hey well, like the memory footprint of that thing, it is not is not going to eat all the available memory of some IoT device." Right. and in like the example that you gave probably like just writing that in in... so I need to read the text, right? But probably writing it in in some clear form would be beneficial, right? Because that typically that could be a consideration for some IoT devices, for for some LPWAN technologies and even though we are making SCHC like it's more generic, like I think that one of the big use cases could be for IoT communications. And you know that I think if we standardize a document then you know, we we should be aware if it's if it is applicable or not. So that would be the only the only point, right? I mean, even if you can like from an analytical point of view say, "hey, well, that would work," then that's sufficient, right? But yeah, I mean, I think it is great and we have it in the charter to have a working group item on on FEC. So so yes, I think that the moment that we have this answer, we can start a Working Group Adoption Call. Oh, sorry, Working Group Adoption Call.
Laurent Toutain: So with this, okay. Let me now take back the control so that I can go to the next presentation. So actually we wanted to... our our initial objective was to present the full document of the architecture as it was as we've been working in the design team for for a month now. But there are still... so we have done a considerable amount of work, but the document is like it's in the oven, it's not it's not fully baked. So we've been doing like a lot of discussions with Marion, Quentin, Pascal has joined also in the discussions a couple of times. And basically the we have I think we have converged to a very to a very interesting point.
Laurent Toutain: So just small reminder of the mandate and the scope. So the point was that we had like the baseline draft, the SCHC architecture which was at a at a good stage, but needed some revision. And a lot of the inputs came from the last discussion that we had in Montreal and the minimal architecture draft. So we had a call for participation by in the design team and of course, like Marion and Quentin answered to to that call. And our the way of operation is, of course, so we have regular meetings one or two times per week. So the normal course would have been like one time per week, but we have intensified. And the goal is to have a consensus, to have an information... so the we have it's an informational document and we're targeting a light document so ideally I would say 20 to 30 pages, but pages is not the like the the size of the document is not the the only criteria, of course. The point is that this document is like an entry point for someone that doesn't know SCHC so that they can understand how things work and yes, and so the point is to have like a document around like I said 20, 30, maximum 40 pages and then have annexes and in these annexes, well, we can have like use cases and deployment examples where, you know, things can be developed in much more detailed manner and where like the interested reader can like go understand the architecture and then go to the specific deployment if that that they care about.
Laurent Toutain: So it's not a standard track document and we are seeing right now that probably we'll need a couple of standard track documents afterwards. For example, we think that SCHC over Ethernet, so that that's possible, right, that SCHC over Ethernet would require a standard track document. And so we have the EtherType that is being requested by in the SCHC protocol numbers. And when that EtherType is allocated, then you know for processing in the on the Ethernet level, well, I think that at least that's my personal opinion that should be discussed in the working group, like we will need to fix some rule sizes, right? We would not be I think that it will not work really very fast, let's say, or I don't know that that it could there could be issues if we don't standardize at least part like the size of the rule IDs, how over how many bits they are so that this could be processed on on switches and intermediate elements, right? So that I think would require standard a separate standard track document. Probably also if we decide like with the control header, we'll we'll need to have some part on standardizing this this format and it's actually in our charter to have a SCHC header standard track document.
Laurent Toutain: And of course the difficulty of of having like a very clean, a very small, a very neat architecture document is that it needs to cover like a wide a wide spectrum of use cases, going from the tiny SCHClet on on an LPWAN device to the multi-instance gateway over Ethernet. And the implementer or like the the people working on tiny SCHClets on LPWAN devices, like maybe they can be overwhelmed by if they have to digest the entire architecture that that also serves a multi-instance gateway over Ethernet. And of course the the key is like one of the examples is diet-ESP where like we would like typically that that to be SCHC to be the architecture to provide enough resources for diet-ESP to use it without like the authors being lost.
Laurent Toutain: So for the moment, where where we are, so we're working on we have actually produced multiple internal documents in which we we iterate over the different over the different core concepts and how that impacts the full like the full text of of everything. So we have a couple of core concepts around which we agree. So these are the approximate definitions, right? It's not the these are not the final final final fixed definitions because like they're a little bit richer in the document. So basically one of the points was that we as it was pinpointed by during the discussion that there were already the examples of like SCHC instance being used as actually the logical component, like the software, the process that executes SCHC, like the compression, decompression, and fragmentation like that physically does that. So so that's the instance that that performs these operations and it uses like it works on a context and it has its instance configuration. So that's part of the equation.
Laurent Toutain: Then we have the notion of an endpoint. So here like it's really shortened down, but it's something it's also like a logical elements, the SCHC peer, it's the container for one or more instances. So typically we'll have like only one in a lot of the a lot of the deployments we'll have one instance there, so the endpoint, the SCHC endpoint will almost be synonymous with SCHC instance. And it has an optional dispatcher, like it's the dispatcher that is doing the dispatching between the different instances if there are several. And like we're not going to go into the like the full discussion, but basically like we have the endpoint, on the endpoint we have instances one or more instances.
Laurent Toutain: So we have the session. So the session is the communication relationship between so the communication session, right, between two or more instances that share the same the shared common context. So compared to what we have seen until now like in the past in the architecture in the document in the past document, instance the session what we call a session here, it was called an instance. And and that that was in contradiction with some of the uses in RFC 8724. And it was a little bit ambiguous, right? So basically these are the three pillar definitions. And I have shortened them down and I hope I I took the latest version that we had in our discussion. So Marion and Quentin if if if you see anything to add, please don't hesitate. And of course the context doesn't change, right?
Laurent Toutain: And currently our discussion is to see to what extent actually so we understand the importance of of the notion of this of the point of to set to tell the scope of where the portion of the stack where SCHC operates. And the we find this in many cases how the the notion of stratum actually simplifies the language and simplifies the way we use it in when we have multi-instance, multi-hop, or dispatching scenarios like we see that in many cases. And the alternative is actually to say, "well, actually, you know, we can have you know, this notion of a stratum, it's really interesting, but maybe we can call it just like the scope of where SCHC operates." And for more advanced and more I'm going to say for for for more complex deployments, you know, there will probably will be a bit more cumbersome to use it without stratum.
Laurent Toutain: So this is our current discussion. We're trying to produce actually two documents so it takes a little bit of time to see how things change among the two. And one of the things that we were saying is and and I think it's it's important is to have like we are basically always covering, okay, how would that look for for this kind of scenario, for this other scenario, for this other scenario. And basically we have we see that if we're able to cover 6Lo, so 802.15.4 deployments, PPP and diet-ESP, Ethernet deployments and OSCORE, and LPWAN, of course. So maybe we can say they're five. So if we're able to cover all these five different very different ways of looking at SCHC, then the architecture will be like sufficiently rich and not overly complex. Right.
Laurent Toutain: And so probably at and here like I would like maybe to so this is the the last slide. I would like maybe to at some point we'll come to ask people like maybe it'll be on some interim or it could be before that, to say like how you feel about the this evolution and when we probably will have maybe two different versions of the architecture and have a vote in the working group to see which one seems like the minimalistic or the richer one to to see which corresponds more to the feeling in the working group. So I don't know if you have any questions, any remarks about how things are going on the work.
Laurent Toutain: Carles, I'm not sure if during the IETF in in Shanghai... I didn't I didn't have time to read the minutes yet. I'm not sure if if you have any if you had any discussions on the 6Lo over... SCHC over 6Lo. Your draft is like a very important use case for the architecture and I think it will be one of the driving documents to see like on whenever we have questions how to orchestrate this or that decision like to so that it can fit your your document. Yes, Carles.
Carles Gomez: Yeah, yeah well, not sure if you still wanted to make a question or I mean about discussions in the last meeting.
Laurent Toutain: Yes, I was like I'm not sure if SCHC over 6Lo was discussed at the last meeting.
Carles Gomez: Yeah, so it was discussed and at this point it's like the document is quite stable and well there's a couple of things we need to sort out about one of the route-over modes. But then one main point right now is to basically precisely monitor the evolution of the SCHC architecture document and we align a little bit some of the terminology. At least some of the terms that you may recall, I think you made a comment in Montreal about this, that some of the terms were now actually more stable, like SCHC control header, SCHC data and so on. But yeah, other than that we actually as you said need to monitor the evolution, the progress of this initiative about the SCHC architecture. And yeah, we are basically looking forward to to see okay, uh this work and how we might need to adapt the existing content in the 6Lo draft so that it can fit the architecture or whether we may find any issues with that. Let's see.
Laurent Toutain: Okay, okay, yes, perfect. I mean, yeah, we were we are also and thank you, Sandra, for comment as well. Yes, as I said, it has been a little bit which is not surprising, right? It was been it has been like a little bit more time-consuming because we really are always testing all the different architectures and we're saying, "okay, how do we minimize the entire the architecture and in the same time to to keep a rich a voc- a richer voc- a vocabulary."
Laurent Toutain: So I think that we will be it will take a couple of more weeks so until we we get to a point where we'll be able to actually show to the working group a document where we can say, "hey, like you can go and read this one. It's we're really happy with the text, so you can go really comment on it." But in any case, if you are interested and willing to to join at some point the discussions, don't hesitate. It's quite open and you'll see that it is it is something quite enriching.
Laurent Toutain: Thank you very much, Carles. And just maybe I'll I'll try asking the people that are here on your opinion, your take. We are discussing the stratum right now, as I said, and we're basically having two takes on it. On one take with the stratum, the architecture like as a first-class citizen where the stratum is we have a good definition right now, right. It's basically the scope of SCHC so where it star- where it lies on the protocol stack, where it star- at what where it starts, where it stops, the ingress and the egress interfaces. So basically we can go to to that extent. And so it makes the architecture document a little bit heavier on terms of okay, we introduce stratum and we use it extensively during the document. And that actually helps precise language for multi-instance, multi-hop, dispatching scenarios and so forth, and that helps for example the 802.15.4 document, right.
Laurent Toutain: So what we if you have any intuition about this, would you prefer to have a lighter language where we avoid the use of introducing the notion of stratum, but maybe it's a little bit more cumbersome where describing some of the more advanced use cases? So that's basically option A. And option B is well we introduce stratum and we use it everywhere even for let's say more simple deployments where some people could be a little bit like people from Diet-ESP, for example, they need to understand what stratum is and why do we talking why are we talking about it. Maybe we can find some work-around some work-around, but what would be your take? Would you like having a simpler language a little bit less expressive or a richer language, but maybe a little bit more difficult for newcomers? Yes, Carles.
Carles Gomez: So yeah, this is definitely a difficult question, I guess. I think it depends on the actual customers of of the architecture. Some might prefer more simplicity. Some others might prefer the other way round, especially if we consider some protocol stack where we may have several strata of of SCHC. Yeah, then the notion of SCHC stratum is really useful, right? So I don't have like a clear answer right now, but for example in the 6Lo draft we provide the vision of the protocol stack and we and the notion that that SCHC could be used maybe in just as a single stratum, but maybe in several strata in different places in the protocol stack and I think that helps to have this notion of stratum. And I think that the idea that it's called stratum and not layer is also a very good one. And yeah because then it allows some flexibility in what SCHC is doing and what other sort of layers cover by SCHC. So at least in the 6Lo draft so far, I think it's good to have this notion of stratum as a well-defined term. But I understand that perhaps in other cases maybe when there's a single stratum in any case, maybe more simplicity could be good. So I guess it would depend referring to the table you showed before whether the different scenarios... one of them was 6Lo, but then there were a few others. Yeah, it may have different different answer when considering different rows in that table.
Laurent Toutain: Thank you very much, Carles. And yes, as I see also Edgar, he says "I vote for richer language because we want to extend the use of SCHC in more areas." Thank you, Edgar. Thank you, Carles, very much, thank you for for your feedback. It's it's really precious. Quentin?
Quentin Lampin: Yes, just providing just a bit of context about that discussion. One of the work that we are doing in in the design team is also trying to define if a stratum is a functional element or just a concept that that we can use to talk about SCHC. So the so really the question is is it a first-class citizen such as for example the instance, the session? If we were to define a functional architecture, is there any kind of like interface between this and for example an instance or is it just something that we use to describe an instance? Because behind the idea of stratum and every time we talk about stratum, there is the the idea that this is the fraction of the stack that the an instance is actually compressing or working on. And so so the question is it is it for example an attribute, a property of an instance or is it something else that lives outside of the instance? And for example in the discussions we had consideration about having the stratum as being an architecture element in which multiple instances can live. So it's just not a terminology or a definition that we use to to talk about SCHC, it could also be a part of the SCHC architecture in terms of like the function. And so this is the ongoing discussion and if anyone has feedback on that, that would be much appreciated as well.
Laurent Toutain: Yes, it's it's as we say, it's very easy... so thank you, Edgar, and thank you, Marco, for the feedback. And one of the points is of course when we define this notion, then everything seems to to flow from it and it starts it tends to become a very central notion where for minimal use case it we want to avoid people to go like to extreme lengths to to get like a full spectrum of yes. And as Marion said, we'll be able to do both.
Laurent Toutain: So, in any case, I mean as you know, it's like we're really taking our time to to define very clearly in unambiguous way and clear way all the definitions. So this is... I don't think we should be like... we'll present the full solution like the full definition, the full proposal, one or two proposals even that we can discuss here. And I would like we have the feedback at least we have a very and excellent feedback here. Thank you very much for for that. I would suggest that we stop here because otherwise we can diverge and go into more into less well-defined areas and then we'll just spend our time like discussing. And these are things we are doing at the at the design team.
Laurent Toutain: So, if you would like to join any of the meetings, you are more than welcome. We do everything on GitHub on the GitHub where the the LPWAN architecture document is living. It's a little bit like we have like several internal documents right now, but we'll be publishing that very soon. So in case anyone wants to join, don't hesitate. With this, I think that we can end our meeting here. Marco, huge thanks for taking the minutes. And yes, very happy to see you all and we'll meet in two weeks' time in our regular slot. Thank you, all. Bye.
Carles Gomez: Thank you. Bye-bye.
Laurent Toutain: Bye.