Session Date/Time: 26 May 2026 14:00
Here is the complete verbatim transcript of the audio recording.
Javier FERNANDEZ: Hello, Alex.
Alexander Pelov: Hello, everyone. Nice to see you here.
As always, we'll be waiting five minutes after the hour for a start.
Hello, hello. We'll be starting in just a two minutes.
Thank you, Marco.
Thank you, Marco, for for the pointer to the meetings, and thank you for, as always, being here for for that. So, let's start. Hello, everyone. So, you uh we will start with the Note Well. So, this is the uh a meeting, official meeting of the SCHC Working Group, and uh this is an official IETF meeting, and by participating in the IETF, you agree to follow IETF processes and policies. This Note Well is a reminder of some of these policies, and you have the full text, which is displayed here, and the QR code. IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues at all times, and you can see all the uh relative um all the relative documents. If you are aware that any IETF contribution is covered by patents or patent applications, you must disclose the fact or not participate in the discussion, and there are some pointers here for the process information and about the privacy statement. And of course, this is but an extra- but an extract of this information, so we have the full documents here. And if you- if you have any questions, don't hesitate to talk to working group chairs or AD directors.
Um, so, with this being said, for today we have um a busy and interesting agenda. So, we have uh a short discussion about the status of the documents. Then, Alejandro is going to present us his work on streaming coding using XOR for uh the draft uh that is under uh as an individual submission for the moment. Uh, then probably we'll have a short discussion about the um what we what we presented last time, what Marion and Quentin presented last time just, you know, to to see if everyone is on the same page. And at some point, we'll be discussing of course the IETF- the upcoming IETF and some interesting announcement uh about- but for that, we'll wait uh our AD to connect and he will be joining between two meetings uh around um 4:30. So, we'll be waiting for that moment. Um, and of course, with that we'll discuss the- the IETF 126.
A short overview of the document status. So, things are generally advancing well. Uh, so, we wait for uh some updated input about the SCHC over networks prone to disruptions so that we can now start a working group adoption call. And uh we have a shepherd now for the protocol numbers and a shepherd for the uh update of 8824. Um, so, the shepherd of 8824 update is me. Um, so, Marco, I started my work on this. Uh, yes, it is uh how can I say, uh uh it is not one of the shortest documents on- on which I've- I've been working. Uh, there have been some days off in the month of May, so I'm I'm still working on it, and I hope to be able to uh- so, I will definitely finish all the shepherding work before our next- before the next IETF, but I hope it will be in- in June. Um, but the work has started, and it looks really solid as a document, so I'll- I'll provide some feedback, but it's- it's really good. And if you can update uh if you can probably just uh uh upload a new version just so that we keep the document alive. Um, we will- we'll talk a little bit about the SCHC architecture draft, but we also probably have to uh we will submit a new version before IETF 126 because the document has expired. There are several documents that are working group documents and that are in expired uh uh in expired state, so with the chairs, we will have to uh uh uh reach out to the authors to of these documents to see what are their- their intentions. Um, some of them are just ready to start the working group last call. Uh, others, the working group last call has finished, and, you know, we just we need to- to see what- what is- what is the intention there and how we can move on from there.
And with this being said, I think that was uh everything um from from me for the moment, and I'm going to give the uh I'm going to give the hand to Alejandro, or Javier. Javier Alejandro, who can um share uh who- who will talk- talk to us about the performance that he uh he saw with- with streaming XOR solution. Alejandro?
Javier FERNANDEZ: Uh, yes. Hello. Just uh figuring this out uh. Uh, but I'm not sure if this is the right interface. Request screen share. I think there should be one. Okay, I think you see my screen now.
Alexander Pelov: Yes, we see it.
Javier FERNANDEZ: Cool. Um, okay, so hello everyone. Um, I'm Alejandro. I've been working a bit with uh Rodrigo Muñoz. I'm not sure if he's online. Uh, so he wrote uh so actually, for context, we wrote uh back then with um Alexander Pelov, the uh a draft to include a FEC mechanism for SCHC. It was more like it was very simple XOR and uh it was really like uh just error bags for SCHC. Um, so we weren't really sure if just it was that simple if it worked, and some people were not very uh keen on adding a SCHC rule specific for this, so it was kind of a mess. It didn't comply really with the data model, I think. Anyway, uh then some researchers from um anyway, some researchers made some progress on it for satellite, specifically for satellite communications. And they uh wrote the draft called Muñoz. It's called, wait, I have it here. Sorry. Um, it's here. So, it's this one. I think we've presented it uh sometime sometime ago. And oh, there we go. So, it's called uh ARC FEC Mode. It's a new fragmentation mode, and it includes uh an encoding process and then a fragmentation process. So, this is the fragmentation uh process, but it has two subprocesses now. So, first, it's- it's encoded, then we fragment it and send it, and then we just reassemble the stuff. And then we attempt to recover uh recover uh data using parity symbols. So, just for a reminder how this works, I'm going to jump to the example. Uh, how this works is we set two different- yeah, here it is. So, we set two different um encoding geometries, we call it. So, we can arrange the data into a matrix or a buffer. And so the matrix would allow more complex and more like row-based and complete uh FEC algorithms such as Reed-Solomon, and the buffer one would allow much simpler algorithms like XOR. And then the transport subprocess just uh sends data as usual. Um, and so you can check out the draft. I'm not sure if you had time to check this before. So, so what I've done since is I wrote uh a proof of concept, so it's uh this one, this project. You can find it uh yeah, I'm going to put the link in the discussion uh second. So, I have the main branch, I have also stats branch. I'll check it out in a bit. So, basically we have um a device, which is the sender, and we have a server, which is the receiver, excuse me. And, uh well, this is just uh so here I implement just really simply the stream encoder and the fragmenter process and also in the server I implement uh the decoder and the reassembler. And then I just run a basic scenario where I do like- so, I'll show it to you. Here we can run uh the server and here we can run the device. I'm going to make this a bit larger. Okay, and then we can check what goes on. So, first, the device here, I'm going to make this larger. Here we're on the device, and I just input a SCHC packet, so we can see it's rule 8, etc. It's 39 bytes in total. Now, in the configuration, I'm setting the MTU to be uh 11 bytes. So then, we would do the fragmentation process as defined in the draft. And here, a cool thing to notice is that uh because we were worried about the um memory efficiency, I've managed to implement it without duplicating uh having to duplicate buffers. So, it's very memory efficient. So, of course, we have to have a memory buffer for the SCHC packet, so here we have uh 8F, F8, etc., basically divided into symbols. And then we produce the parity symbols. So, right now I'm doing a 2-out-of-3 XOR. So, this one is exactly this one, this one is exactly this one, but here, the third one is now the XOR of these two previous ones. And then I continue, 5F, 2F, and so on. Um, so then we divide this into tiles and into windows, as usual. Um, so here, for simplicity, I'm saying that a symbol is one tile. And we divide this, so window 0, so our main- my fragments end up like this. Um, and then I apply an interleaving pattern, so this will make it more robust against uh burst errors. Uh, so here I do, so the pattern itself is defined in the draft. It's very simple. Uh, I take the first element, and then I skip 3, so 4-2, as you want to say it. 1, 2, 3, I take tile number 3, and then I skip 3 more, 1, 2, 3, tile number 6. So, what this does essentially is uh it reorders, if I go to the example in the draft is, so here it is. So, I have my data, I divide into tiles and windows. And the interleaving pattern, where is it? Yeah, so basically, if I have symbols uh A, B, then parity between A, B, C, D, then parity between C and D. So, this produces an encoded- encoded block, what we call it, and um we organize the data like so, so we have all the parity symbols at the end, basically. Um, anyway, we apply interleaving, then we divide again into fragments, so we just put the fragments as- so, with this data. And so here, we have uh the reference for each fragment, and because we have static context, we know that this is an interleaving 3, so fragment 0 window 0 uh FCN 6 begins here, but then the next tile is going to be FCN - 3. So, we know that this is going to be uh FCN, so we are going to skip two places in the buffer. So, here's my data, this is what I send, and this is what I transmit. And, well, in this case, I don't have any losses. I've set up the scenario to have 10% losses, as you can see here, loss probability, so this is a config file, you can modify. And then the server, what it does, it's just receives data. It puts uh- let me put it here. It puts uh the data into a buffer called as C stream, so coded stream. And here, for example, we can see how the interleaving works. So, we receive the first- so, this is the header actually, window 0, FCN 6, and then we have the data. So, I'm putting the first tile in the first place, and here I have the bitmap. So, I've received this, but I haven't received these two. And the next one, 5F, uh I put it here because we have an interleaving pattern. And so, I fill in this uh buffer with the bitmap. And I can see that at some point, even if I am still missing these two fragments, uh I already I can already decode. I'm just missing the all 1 fragment. And we can see that it's correct. So, I'm going to try to get a simulation where I have some losses. Okay, here, for example, we lost one fragment, 05, and we still got uh ACK C1. And it was still good. So, you know, I can run it multiple times. Here I have- I lost one of them as well. Okay, here, for example, I've lost two fragments and the all 1. So, I can retransmit, and uh yeah. So, yeah, it's working like this. However, I've done a runner script that writes uh creates uh some statistics. So, here, for every run, I can uh automate each run and create some statistics. So, I have the configured loss probability, I have the- if I allow the loss of all 1 packet, how many regular fragments were sent, uh, etc., etc. And then some data on the server side as well. Uh, so, I've created, with this data, I've created a Jupyter Notebook. Let me close this. So, I've created a Jupyter Notebook, this is really rough, and uh, it's not by all means finished or complete. So, here we- I'm using some basic data analysis. I'm loading the CSV files I just showed you, so these ones. Oh, oops. These ones. Uh, you can see them here in the project. Um, yeah, analysis. And so, for example, here I can see some derived columns, here I see if uh FEC mechanism sufficed or if actually the retransmissions uh rescued uh the transmission. Here, I have some summary, so now I did the- I loaded all of these CSV files I did previously, and I have uh 72 total iterations. I've tried uh this uh loss probabilities. So, 10%, 15%, until 50%. Uh, this, right now, it's a bit misleading because I'm considering all of these different probabilities, but we can see that even with uh- so, what it would be like, the average of this, I think. I get failure rate of 20% and still success rate of 80%, which is really good. I mean, it- I guess it will depend on the use case. So, here is where it gets a bit more interesting. Uh, so, with all those uh probability loss mixed into the data, um, I mean, you can filter out if you want, this is just for demonstration purposes. So, here, for example, I see that I sent 72 iterations, 49 + 8, so 49 uh the FEC worked, 15 I didn't manage to uh to recover. Here, I'm just doing one retransmission, by the way. So, in theory, it would be like three retransmissions or something. And, uh, here I can see that in 8 cases, the- the retransmissions actually recovered anyway. Here, I have breakdown by loss probability. So, this table is not super cool, but this graph I really liked. So, we can see the success rate uh going down, like getting worse for every loss probability uh in the link. Uh, this is how close the actual loss probability was. So, it's called uh loss simulation fidelity. So, here, for example, even though I said 15%, in reality we lost like 20% of the packets. Uh, but it's cool, so here, for example, we can see that even if we have 50- so like, relatively bad- relatively bad link, uh, we can still manage to recover like 80% of- of the times. So, this requires a bit more work. I was doing this 20 minutes ago. Uh, and here I have also, if I lose the all 1 packet, like, what happens if I do it? So, most of the times it fails, you see, because I only have one retry. Uh, Alejandro, I have- I have uh two- I mean, okay, several questions. There is just one point. I see that Eric just joined us. So, Eric, I know that you are here for a short time. Um, if- is it okay, Alejandro, if we treat your questions just after uh after Eric tells us what he has to say?
Javier FERNANDEZ: Um, I think yes, it should be- well, I'm not sure if I have to go to another meeting.
Alexander Pelov: Yeah, yeah, yeah, but keep- keep keep the window open here, because it's- uh, it's really interesting exactly here what you're showing. So, um, uh, so, yeah. And I mean- I spoke to Eric, and he has a very short slot, and it's important that we- that we discuss it with him. Okay?
Javier FERNANDEZ: So, so I can just stop sharing. But, overall, I think I'm done. It's just you can check out the project. I'm going to put the link in the- in the- in the conversation, and you can check it out. That's- that's all what I wanted to say.
Alexander Pelov: Okay, thank you. Thank you, Alejandro. Um, so, Eric, are you hearing us well? Or maybe I um uh interrupted a little bit uh earlier, Alejandro, than what I should have, but uh uh in any case, Eric, the moment that you are available and connected, the floor is yours. Um. Okay, so uh and then I would really like to come to what Alejandro was presenting, because it's super interesting. Um, yes. Thank you, thank you, Alejandro. Um, so, ah, yeah. Ah, but because you were- you were going to leave at 30, yes, because you had another meeting. That's why I also put you in the- in the- in the- in the chat, in the list. So, Eric, ah. Yes.
Éric Vyncke: Yes, I think I'll stay. I'll just be like not very attentive.
Alexander Pelov: Yes, I actually wanted to ask you one question, but um um okay, so let me then uh go with uh with the IETF uh the organization of IETF 126. Uh, so, uh yes, in uh in IETF 123, uh or maybe it even- it was also in 122. We didn't meet only on 124- 124, so we met at 124 as well. And we had a uh- a 1-hour-30 uh request, um so I scheduled a meeting, like, published a slot just so that we have- we don't forget, right, to be- to be on time. Uh, I just wanted to make sure that, you know, we are all okay with this. It's- it's our regular duration. Uh, during the discussions from what I have observed, at least, it seems that we are always like just on time, uh but I think it gives the right- uh, the right tempo. So, do you have any objections or any suggestions to go more or less? I think we can keep it as it is for the moment then. I mean, of course, if you feel anything that- that we should discuss, definitely just send an email or- or the chat. Um, yes. Yes, yes, yes. Yes. Yes, it is running. It is running. We are waiting for you. Uh, yes, yes, yes. We are waiting for you. Eric, can you hear us? Can you hear us? 1, 2, 3, can you hear us? Can you hear us?
Éric Vyncke: I'm not sure whether my audio is working.
Alexander Pelov: Yes, yes. It is working. It is working.
Éric Vyncke: Yeah, looks like I don't hear you, Alex. But, uh, for whatever reason, I just came off of a call where everything was working fine. So, can not hear you again, but, uh, as many of you knows, right, there's been some thinking by the current uh working group chairs and myself, basically to partly renew the chairing, to- the chairs, uh simply because Pascal Thubert uh is retired from Cisco, uh and will be enjoying life, but still interested of course in SCHC. Uh, and we want to get new, fresh people coming on board, so I have decided to select uh Marion Dumay as the third working group chair for SCHC. And most probably, around the Vienna time frame, uh Pascal will be stepping down. In the same shot, I am also selecting Quentin Lampin as what we call a technical advisor, which is no chairing, so no decision-making, but can still provide uh technical information to the working group, like he has been doing for a long-long time. So, thank you, Marion. Thank you, Quentin, for joining the- the leadership. Uh, I know this is a new role for both of you. Uh, you have- you've never been chair or leaders in the IETF working group, so that's a first step and I hope it's not the last one, because after working group chair, you can become an AD, right? And then why not the IETF chair? And the same message for you, Alexander, right? So, uh, the stairs are open. Again, I don't hear you, so I hope the message went okay. Uh, Alexander, okay, you put your thumbs up. Yes. And I'm afraid I joined late in the meeting mainly for this, and I need to leave to get to another one, so sorry about that. But, Marion and Quentin, thank you so much. And, Alexander, I'm pretty sure you will be drilling them and managing them and set the expectation right, and you can count on me of course, as- as usual there. Okay, looks like we'll be meeting at IETF 126, which is even better when I see the slide. Uh, and sorry for the audio, and thank you, Marion. Thank you, Quentin. And see you in Vienna, if not before. Bye-bye. I need to run. Sorry.
Alexander Pelov: Yes. Thank you. Bye. Bye, Eric. Okay, yes, so that was directly from our AD, who jumped in for five minutes without having the- the feedback of what he's saying. So, we could not say anything more uh on- on- on, like, live. Uh, but it- it was important that we- that we get the- the dynamic running. So, yes, as in- as in the chat, was saying, congratulations to Marion and- and also to Quentin. And, it's being a real pleasure to work with you for the past many-many years now, many-many months in a very-very active way, and also in the past years. And, it is uh very refreshing and very-very good thing to see uh a new co-chair uh uh of the working group, and I think it will give us a very good dynamic for uh for the- for the next years, right? So, that's really great. And also thank you, Quentin, for agreeing also to be as a- a technical advisor, uh so that, you know, we can always solicit your advices and your help, uh as- as Eric said. Um, so, thank you for that.
And, with this, we we can go back to the- to the organization of the IETF 126. So, I just wanted to see if- if any working group that you would like to include in this list that would otherwise, uh, you know, make uh that you would not be able to attend the meeting. I added Carsten and Marco, I added your names explicitly as people that have to be present in the SCHC Working Group. Uh, there will be really interesting and important discussions uh this time, and um uh also, of course, we don't want to have uh conflicts with your agenda, which I know is very- uh, is packed. So, for the moment, I propose that we- we stop here with- with this item. Uh, Alejandro, is it okay for you to go back to the slides that you- to the- to the- to the screen that you showed with the- because I- we ended up very fast, uh, very abruptly. I- I want- I had a couple of questions for you, if it's okay for you. If you are able to to interact. Yes, I know that Alejandro also had another meeting just uh that he has to attend uh just after uh 4:30. So, um uh, probably it- it will be um uh, not the right time for him. Um, but one thing I saw that was really interesting, and I think that we have to go back to this one, is that there was the FEC part, when, like, if you see the graph with the green, blue, and red, where- where the green part was the part that was saved by FEC, the blue was the part- the part was saved by- by RQ, and the red one was the one that was not saved at all, that we could not recover from. And it seems that the green part was really like- in the majority of cases, the- the part that provided most- uh uh, most of the cases got recovered with the- with the FEC part. So, that will be interesting to look uh more, maybe- maybe next time as well.
Um, so um, with this, probably I just wanted to- to give a short um, uh, okay, let me look. A short update of the discussions that we had last time. So, uh, one thing that's really important is um, Quentin uh made a brilliant presentation, I think, very good presentation. Uh, last- during- during our last meeting, which really put a lot of uh- a good, an excellent recap of of the things we've been working on during the SCHC architecture in the- in the design team. Um, you can actually see the whole thing on YouTube. Uh, it's not very long, it's, I think, 20 or 30 minutes, and it was really well done, so we're not going to repeat the exact same thing here. Uh, I just wanted to say that we had a very uh uh interesting discussion also with uh, with Marco, and with, like, the people that were in the call. So, uh, if you go to the- to the- to the presentation, well, we had the definitions of, like, endpoint, instances, context, domain, um, the- the baseline scenarios, uh, a session. So, all- all- everything is defined there, and I- I really think it's- we're on a very-very strong um, uh, start there. And, we had a couple of questions uh, that we discussed last time uh, with Marco. We have not yet uh updated, uh, like, provided a new version of the draft. There was- there has been a lot of holidays in France. So, um, uh, that's, among other things, was like the- the vacation time. It- it's- it's not the- the most uh preferred time to advance uh on the document, but we have uh- uh, really converged on many topics. So, we'll produce a new document in- in the next- in the next two weeks. Um, in any case, the design team is open to new participants, um, and uh, please, if you- if you want to pay- take part of the discussion, don't hesitate to send an email, right? So, Marion, Quentin, do you want to- do you have anything to add?
Quentin Lampin: It's better with the mic on. Um, no, really, the- the feedback from the working group would be great. Uh, we know that there is a discussion that we need to have soon, we'll probably provide uh talk about it uh in a coming interim. This is about uh this encapsulation/multiplexing/transport placeholder that we have discussed. Um, in short, the- the question is how do we multiplex uh multiple sessions uh on the same link. Um, yes. So, there- there's- there's a pending issue. Uh, we are working on it. We are actually uh describing the issue and- and- and trying to- to find in the IETF portfolio of protocols if there is anything that- that works well. Uh, I believe that you propose an interesting way for this uh to solve, uh this is the placeholder. So, yes, a lot of interesting stuff and you're absolutely right, uh to put up that slide, that particular slide, uh the design team is open. So, if anyone has uh ideas on how to multiplex uh different SCHC session uh well, well, you're welcome in joining us as well. I think that's- that's pretty much it.
Alexander Pelov: Thank you, thank you very much, Quentin. Um, so, uh I think that Javier is actually being- uh he needed to jump- to- to jump between this- the end of this session and the another session, and I think he's- he'll- he's a little bit too busy with the other one. So, I propose that we have the discussion of the performance of- of of his uh software, and like, the performance between FEC and ARC and uh during the next session, uh and to also ask him to make some slides for that. Um, so, in that case, I wanted to say again, um welcome Marion to the family of- of chairs at- at IETF. Um, so, I think uh Eric is going to do the configuration today or, I mean, whenever he- he can. And, yes, it will be a pleasure to work with you and it is a pleasure to work with you, and it will be a pleasure to work with you as co-chair.
Marion Dumay: Thank you very much, Alexander. And I'm with Quentin, this is why the- Quentin's name is displaying instead of mine, but- Well, I'm very- I'm very happy to join the- here. Um, and thank you. That- that's a real pleasure.
Alexander Pelov: Thank you. We, the- the- yeah, I'm very happy, and I think people- people from the working group are also very happy with this choice. Uh, and uh also, Quentin, thank you for- for your significant and important implication in the working group as well, and for being a technical advisor. Um, and so, we will meet in Vienna. And, uh then, I propose you that we stop here, and we will uh get back, we'll meet again, two weeks from now. Um, see you. Have a nice day. Bye.
Marion Dumay: Bye-bye.
Alexander Pelov: Thank you, Marco, once again, for taking the notes.