Session Date/Time: 22 Jul 2026 07:00
[00:00:44] Marc Blanchet: Yep. Can we start? Shall we?
[00:00:51] Padma Pillay-Esnault: Yeah. Hello?
[00:00:57] Marc Blanchet: Okay. So it's top of the hour, and they're ready. Eric? Yeah. We should start now. So welcome to this TIPTOP meeting, everybody here in the room and the remote. And thanks for closing the door. That's that's what I was going to say. Thanks a lot. We're going to start. If you are not intend to be in a TIPTOP meeting and not intend to send IP in Deep Space, maybe it's not the room for you. Otherwise, you're most welcome to participate in this meeting. Me and my colleague will be Padma will be running this meeting for you. Padma, you'll go through the slides. Yep.
[00:01:50] Padma Pillay-Esnault: So so we have a full agenda today. So we'll go quickly over the note well. You've been here since the beginning of the week, so, you know, that idea of participants are supposed to behave in a professional manner. You're aware that our ETF contribution is covered. Whatever you present here is you should actually have the RFC and the detailed process information consult, RFC twenty twenty six. Meeting tips, you know, release already. I'm going to go fast over these these are resources for this meeting. And so we'll start with the agenda bashing and the working group status update. So for the working group, today, we have almost all the documents on the agenda. And there is two documents that are out two different proposals that we're going to discuss. We had a call for adoption, but was not conclusive. So we'll present those two proposals today. And so there it is, the working group documents, the use case and requirements by Marc, and then followed by the IP, the architecture for IP in Deep Space. And then we'll have the nonworking group documents, and these are the two I was talking about addressing. So we will have an interesting discussions on this. Next, we will be talking about quick profiling. Mark and Jonas have been doing a lot of work on this, and they will present their work followed by CoAP in Space. And if time permits, we'll go over Interplanetary hops. So without further ado, let's start with our first presenter.
[00:04:01] Marc Blanchet: Yeah. So if you are here and haven't yet logged in, so please do that because that's we don't run the blue sheet again. This also helps us to, like, dimension the next meeting room and all these things. So please join scan the QR code and join the meeting even if you are here in the room.
[00:04:26] Padma Pillay-Esnault: Okay. Marc?
[00:04:36] Marc Blanchet: The slides.
[00:04:38] Padma Pillay-Esnault: You can check the
[00:04:41] Marc Blanchet: slide. No. No. You're not sharing. You're not sharing the agendas.
[00:04:49] Marc Blanchet: Good morning.
[00:04:52] Padma Pillay-Esnault: So
[00:04:54] Marc Blanchet: this is an update of the TIPTOP working group usecase document. I'm presenting on behalf of the three authors, myself, Wes, and Marshall.
[00:05:15] Padma Pillay-Esnault: There you go.
[00:05:17] Marc Blanchet: Now you put the PDF. Now you you shared this thing.
[00:05:22] Padma Pillay-Esnault: Yeah. I will. Yeah. I haven't done it yet. There.
[00:05:31] Marc Blanchet: Okay. So, again, the discussion, the position is about differences, the changes from zero one to zero two. We went the use case document went through, you know, a lot of comments a while ago, and we kinda gone through the mailing list again to make sure that everything was covered and also the GitHub issues. So we actually put the changes in the text regarding those two. We have a new section on scenarios and some key exchange discussion or text. So one by one, we have now a new connectivity scenario section, which uses two letter acronyms. And the the idea here is that we were starting to describe various scenarios in other documents and then repeating ourselves all the time. So instead of of having the other documents repeating them, all those together, we decided to create one in the use case, which is the right place to be. And then we would be able to refer to them without repeating ourselves in the other documents, such as the protocol profiles documents. So there are a of connectivity scenarios. You can we could you know, the working group could add more as we find useful. So first is Earth to deep space cruising spacecraft, you know, Voyager. Moon Earth to Moon with full connectivity or intermittent connectivity, so LF and LI, L for Lunar. A full connectivity essentially means that for all the assets that are moon, you could reach them directly without any intermittent. That that's kind of scenario where you have a constellation of satellites that are providing, you know, full connectivity. That may happen sooner than what was planned years ago. We have Mars Earth to Mars full connectivity and inter intermittent, so a few orbiters or one or a few. And then we have solar conjunction, which is, for example, for Earth and Mars where two weeks every twenty six months, there is completely no communications possible unless going through some relays or something else. So, obviously, this one is the last one is kind of obvious, but at the same time needs to be covered by some mean. Those, this slide describes the comments that we we may not have taken into account in the previous versions. There were comments about a synchronous operation. And, obviously, asynchronous does has a different means for us where the one way delay could be minutes compared to asynchronous when we say something, you know, on Earth on the Internet. So, for example, you know, from the time a source sends a packet or, you know, whatever, some data, and then the the destination node may not be up or maybe asleep, transmitter or receiver off, or they could be at the same time in different modes. But still, with the store and forward and the time the packet comes to the destination, the destination may be up. So the the way to think about asynchronous is different here. Energy, I think that was, anyway, someone. So energy in the protocols may need a a synchronous asymmetrical behavior, meaning that there might be a constraint site which is may need to minimize transmissions with the costs being more old by the the well resourced side, and that's obviously things that are already happening in space where rovers are more constraints than the ground systems. And soar and forward, more about I think that was in our review about, you know, denial of service guards again again against the store and forward, the the actual buffers. There were comments about scope and 3GPP and TN and is it when or without scope. So we added some text about this surface networks. There were a lot of discussions in the few meetings and on mailing this about security considerations, so we added some text about this, you know, keeping in mind what I just described about the synchronous, what means asynchronous in our case. So, essentially, saying, you know, these properties are are essentially interesting. Forward secrecy, postcard compromised security, for example. So we described them, but we didn't put a strong requirement to it. They're more described. And I think that's okay. The last one. Yeah. We updated the use cases, more a little bit more, information about this. For example, moon, we cite now the moon based program, which is from NASA, who has been described recently. Yeah. Solid conjunction impacts what what that means. And we updated the acknowledgements and references for the the draft. So almost 10 slides, but, you know, not not big changes of text, but more precise text and based on comments. So that's it for me. Any questions? Comments? Nobody in
[00:12:53] Marc Blanchet: the queue. Okay. Well, they're coming up. Okay. So
[00:13:02] Marc Blanchet: Delay tolerance. Come here.
[00:13:18] Erik Kline: I'm sorry. I haven't clocked Erik Kline, I haven't I haven't clocked the the store and forward text yet, but there was some effort when crafting the charter around store and forward to say, you know, don't stray too close to bundles store and forward work. But but but as I said, I haven't clocked the the the text about your short and forward requirements. I just yeah. I don't know if you could comment.
[00:13:59] Marc Blanchet: Oh, well, please reread, but we made an effort in the previous version to actually clear that out. So please please review and send comments if I I think it should be okay. But
[00:14:16] Marc Blanchet: Thanks, Marc. I think it's very important for us to review this document. This document really gives us the requirements and the use cases. So it's very important that we read it and we actually agree with all the terminologies used there so that we can speak the same language when further discussed. So, please review the two version and help, especially the requirement framing. Thanks. Thanks. Next. So next is Wes who We'll be talking about architecture. Wes, you're there?
[00:14:58] Wes Eddy: Do I sound okay?
[00:15:01] Marc Blanchet: Yeah. Sound great.
[00:15:02] Wes Eddy: Alright. Great. I'm Wes Eddie, and I'm gonna present on our architecture for IP in Deep Space. Marc and Tony are the other editors. And you could go to the oh, I can go to the next chart. So this is a working group adopted document. It goes towards the charter item we have on, producing, basically, a description of how the IP architecture differs when applied in a DeepSpace case versus the normal terrestrial IP usage that we're all familiar with. And this been adopted for a couple ITF cycles now. We had a number of comments on the mailing list between, now and the prior meeting, and I think we addressed those for the most part. Some of the changes that we made between the last IETF meeting and this one, I split here between technical and editorial. And, actually, I think it's erring on the side of considering some more things, technical that, really, if you look at them, they're probably editorial. So first, there has been a good amount of discussion about what exactly to say on address space here. And, there's a lot more planned in the agenda on that today, so I won't be labored on this chart. But I have a a specific, chart coming up that shows the change in text we made there to represent the situation. There were some clarifications on what we said specifically on use of path computation element, PCE architecture, and there were some changes made in the security considerations to be more clear on the terminology we were using there and better describe the types of attacks that this architecture may be more subject to or affected differently than, in normal Internet cases. And then there was a number of editorial changes mainly that came from Padma's review, And so we made those fixes as well. One to talk about a bit is the RIR policy guidance, and, that has probably generated the most discussion on the list in this time frame. There were, also discussions with, some of the RIRs, RIPE and ARIN, at least, I know of. And, so, an additional proposal popped up. So draft-kumari joined draft-li on the topic of tiptop address space. And, in this architecture document, the editor position we took was, we don't need to say or repeat what the specific policy should be. But instead, we wanted to focus on what the area of agreement was between those drafts, which is that, basically, there should be some address space for, space, and that that address space should be managed in a way, that the policies encourage aggregation. So we tried to say just that and then leave it to the future, outside this document to determine whether one of those or some other proposal or no proposal. It doesn't really matter to the architecture what actually sticks, but, we thought it would be good to, present at least the common areas of agreement. Next, we clarified, what we meant when we said that a PCE like approach was encouraged, centralizing the routing decisions within a domain. And, that's just a result in a small expansion of the text based on some conversation between Tony and and Padma on the list. And nothing else really notable. So I think next steps here are to keep the reviews coming. We like getting them. And even if you just have drive by comments or questions, that's useful too. But, specifically, I think from the editor standpoint, we think the document's maturing well, and we need your feedback to know what else more would be needed in order to consider a work complete on the document. That's all I've got.
[00:20:12] Eric Vyncke: Erik Vyncke. Well, thank you. Can you go to Slide four, please? I would be way more happy if the active draft remove the sentence just to help to maximize aggregation, the Internet real and blah blah blah blah. So you keep the first part, which is the actual requirement. You remove the middle, which is a suggesting thing, and you keep, of course, potential approach I discussed. I would be way more happy. And this one, both an individual contributor as responsible AD. I got two heads on my head. Two heads on my head.
[00:20:54] Wes Eddy: That doesn't seem like a big deal to me. That seems doable.
[00:20:58] Eric Vyncke: Thank you.
[00:21:01] Marc Blanchet: Thanks, Wes. I I don't see anybody here, but I think this is this also, like, a document that needs reviews. And please don't wait for next IATF meeting to come here and send the reviews. Please send your reviews in the email mailing list. And to encourage that, I would like to get an raise of hand, like, if anybody volunteering to review this document next coming two week two weeks. Is there anybody that I can I can I can see? That that yeah. Eric, yes? Is there anybody else? Yeah. Yeah. You should do it. Good. Any anybody else? I need another one. Just another one volunteer. Anybody on the remote? I think Jorge was very active in the chat. I think he'll also review the document. So, thanks for that. And with that, we're going to the next section, talking about space. So, have chairs decided to do a more structured discussion on this one, so we invited Tony and Warren to quickly go through the basic philosophy of their two approaches. And then we'll have discussions. And during the discussion, I think Warren and Tony will be standing here so we can have more lively conversations. So, Tony?
[00:22:30] Alexander Pelov: Thank you.
[00:22:31] Tony Li: So this is an update on our draft. Not that much has changed. Just as a reminder, the goal of this draft is to optimize routing. And we would very much like to have routing aggregate as much as possible. Having routing table you know, we we currently carry a million routing table entries right now in default fib, and we'd really like to not do that in space. So we kinda like to have things aggregate well. But to do that, we kind of want to have address space allocated in contiguous blocks. And so what we're recommending are particular prefixes per celestial body. And then to make sure that that happens nicely and cleanly, we are recommending that this is done through an RIR. In my draft, I am recommending that we use a single RIR. This keeps the confusion to a minimum. And we actually have a very low rate of address space requests for address space anyway. So this is pretty straightforward. I believe I have now addressed everybody's comments. I think everybody's happy with the exception of Warren. We've added reference to the architecture draft. There was a request that we remove a prefix for the Asteroid Belt because we don't know how that's gonna aggregate. Fair enough. Pulled that. We explicitly said prefix sizing and timing. That's up to the managing RIR. Those are the changes that went in. Any questions?
[00:24:14] Alexander Pelov: Cool.
[00:24:19] Marc Blanchet: I think we have some questions for you, Tony. Rick is in the queue.
[00:24:24] Rick Taylor: Sorry. I was I was very slow clicking the raise hand button. What happens as I travel from the moon's orbit out to the asteroid belt?
[00:24:39] Tony Li: Address space wise, it doesn't matter.
[00:24:41] Rick Taylor: It doesn't matter.
[00:24:42] Tony Li: In case you'll probably end up with a host route for your spacecraft.
[00:24:46] Rick Taylor: Okay. And my second question is who I completely understand how the technology works. I can see how an RAR you know, we know how this works. I do not understand how the geopolitics is gonna work here, and I think that's the blocker.
[00:25:05] Tony Li: I'm trying to keep the geopolitics out of this.
[00:25:08] Rick Taylor: I think we have to be rational.
[00:25:10] Hans Peter Holen: It's I
[00:25:11] Rick Taylor: I and that's my concern is purely geopolitical.
[00:25:15] Alexander Pelov: Okay.
[00:25:15] Rick Taylor: And I therefore, I think this whole thing is a nonstarter. Sorry. Yeah. So Yeah.
[00:25:23] Marc Blanchet: So So if there's some clarification questions, I'd like to take it now. Otherwise, we have the discussion part where we can discuss such things.
[00:25:32] Tony Li: The simple situation is that we've got people coming from all over making requests, and, you know, we just wouldn't need a neutral third party to take care of things. I don't care who it is.
[00:25:46] Marc Blanchet: Now Warren will say
[00:25:51] Warren Kumari: Yep. So I think people okay. I guess, Jim, are you on line for this or clarification for that?
[00:25:59] Jim Reid: Yes. Not you, Warren. Okay. Let me just talk. Sorry. Jim Reid speaking for myself. Have you given any thought to how an RIR would authenticate requests for address space and validate them somehow? Would imagine if there's a chunk of address space opening up, that this could be exploited for all sorts of nefarious purposes, variety exercises, and so on. And how would, for example, an interact, say, with a space agency or whatever and know who's the right person to talk to in that space agency. Has anyone given any thought to that kind of thing yet?
[00:26:33] Tony Li: Our IRs are very, very good at that already. They get requests all the time from various people for address space, and they have to validate that right now.
[00:26:42] Jim Reid: I I beg to differ. We had a system a few years ago called, is to do with telephone numbers. And it was difficult finding who is the national authority to speak for range of telephone numbers for a country and then get them delegated.
[00:26:57] Padma Pillay-Esnault: We're going to have clarification questions and discussions later. Let Warren present his. Okay?
[00:27:09] Tony Li: Numbers are not allocated by our IRS.
[00:27:15] Carlos Gomez:: So
[00:27:17] Warren Kumari:: first off, thank you, Tony. I think people might be thinking that there is a lot bigger distance between Tony and my proposal here. So basically, it would be nice if we could have, you know, a single prefix and it could be managed by a single RAR. That's a nice, easy, pretty system to manage. Unfortunately, I think, you know, the world is a little bit uglier and trickier than that. There is likely to be competing nations, competing private entities, NGOs, etcetera, all having space missions for the foreseeable future. And the internet sadly isn't a sort of disconnected from politics place. We already see politics making its way into terrestrial stuff, and I think that that's going to be happening in the space frontier even more because it's more of a strategic asset. And if an organization isn't able to get address space, it's not that they're not going to fly their space mission. They will simply use terrestrial address spaces in space. So I think that means that we really want to make it easy for people who have space missions to be able to get addresses. As I say, sadly, geopolitics exists. This is U. S. Executive Order 14,024 which imposes economic sanctions on Russia, especially for aerospace, electronics, and marine sectors. Right? Politics has already entered the internet. Things like this make it so that an RIR in, for example, The US can't realistically service Russia. And cases like this and a bunch of others are why we have the RAR system. LACNIC handles Latin America. AFRINIC surprisingly handles Africa. APNIC does Asia Pacific. RIPE NCC does Europe, and ARIN does North America and technically rest of the world. And because of the fact that we have this RIR system, we have and because of sanctions, we have entities like RIPE, for example, the RAR for Europe, has special dispensation to deal with certain sanctioned entities. For example, RIPE has special dispensation from the Dutch government, where they're based, so that they can service Iran. There are, I think, around six fifty or six eighty local internet registries, are basically sort of sub registries from RIPE in Iran. And Iran has, when this slide was made, around 3,006 hundredthirty two's of IPv6 base, and the graph's going up and to the right. Russia is the bottom graph. That graph unfortunately ends in 2019. But Russia has around 2,000 LIRs under RIPE. And again, the only reason that they were able to get address space is because there's special sort of systems in place to allow right to deal with certain sanctioned entities. I'm not saying that that means that right is the obvious place for there to be a single RAR. What I'm saying is geopolitics influences a lot of this sort of stuff. So what I think is likely to happen or works up reasonably is if you are, for example, NASA or SpaceX and you're based in the North America region, you go to your local RIR and you say, I would like some address space. By the way, I'm going to be using this in space. And they allocate from a special pool set aside for space use, and you use that. If you're a Rust Cosmos affiliated entity, you go to your Oracle RIR and you say I need some address space and they say sure, here you go. I can actually skip that slide. This is actually the older slide deck, so I'll skip those. So what I think we do is we ask AYANA to set aside a big block, size to be determined, and then RIRs draw from that pool. The way that this big block could be broken up is in one of two ways. One, we first divide it by celestial body and then further down by RIRs, or we break it up by RIRs and they break it up into different celestial bodies. One way we get one prefix per body, the other way we get number of RIRs times number of celestial bodies. If we do it by celestial body and then RIR, we end up with something like this. Note, these are only example addresses. I'm not actually proposing we use them. But I chose a big block because the numbers look pretty on a slide. Ayana gets a really big block. They subdivide it by celestial body. For example, Jupiter gets 4,000 slash eight. They subdivide that by RIR. Mars gets, let's say, 4,200 slash eight. They subdivide that by RIR. When NASA needs some address space for Mars, they go to their local RAR, Aaron, they get address space for Mars. SpaceX, they need address space for Mars, they go to their local RAR, they get address space. This still aggregates by celestial body. Roscosmos, they can't go to ARIN, sanctioned entity. They go to RIPE. RIPE gives them address space. It still aggregates by celestial body. NASA needs some more. They go back to there. It does potentially use more address space. Also I suspect it's not actually, you know, you take the celestial body, break it all up and give it to all of the RRs, you break it up into an allocation size, like for example, you know, slash 12, but you still do it based upon the body first. You still get aggregation, You just make it so that people are able to go to their RIR and get address space. And we have people in the queue, and I think this is basically open mic. Let's have a chat time. And I suspect you're going to point out I worded something poorly with the RIR and Russia and sanctions and special dispensation. Please correct me.
[00:33:37] Marc Blanchet: So before we start the discussion part, I just wanted to set some goals here. We have two different approaches to solve, kind of similar, and we think that it's possible to actually combine those two different ideas, two different philosophies. So, have the discussion interactive. And at the end of the discussion, we might want to come to a solution. Or, if we don't have a solution, we're going to form a design team where you can further discuss this one. But I'm really hoping this is a quick, straightforward discussion here that at the end of this discussion, the end of this meeting, we have a simple way forward. Thank you. Please go ahead.
[00:34:18] Hans Peter Holen: Hans Peter Holen, CEO of RIPE NCC and RIR for not only Europe, but Middle East and Central Asia. So thank you, Warren, for for putting this up. I think you're closer to the political reality than the other proposal. My my engineering mind, and that was back in the nineties when I actually did implement, you know, CIDR and that new stuff, is is closer to, you know, let's try to get some aggregation here. It's unfortunately not true that we have any dispensation from the Dutch Minister Foreign Affair. We have a common understanding of how to interpret the sanctions. The the the entities that are sanctioned are not countries, but it's individuals and countries. So it's not only a company, but it's also their owners or their board members and then go up the ladder. So while I think, you know, your proposal may be closer to the political reality, it's not without problems. And and currently, we do publish a sanctions report, you can go in there and see how many entities that we have to, you know, limit our services to. But this is also something that's current, you know, at any point under development, under our political forces in the EU that makes the sanctions, and then it's the Dutch pragmatic government that implements them. But how this will turn out, I don't know. And whether whatever we decide will make it practically possible for a space agency in your favorite or least favorite country to get addresses, yeah, this is this is not simple. So, you know, I commend the the the initiative here to make something simple, and, you know, single registry would indeed be simple, but I do fear that you're right, Warren, that we need to, you know, align it with the existing structure. Although the principle in the new RIR government is that the RIR for an area should be located in the area it serves, so I kind of wonder how that would would fly.
[00:36:20] Warren Kumari: Hans is looking for his the right to have his next right meeting on the moon.
[00:36:33] Kim Davies: Hi, Kim Davies, IANA. I think that there's a lot of interesting things to dissect here. I think my biggest takeaway from from learning about a lot of this for the first time this week is that there's a lot of conflation between technical requirements and sort of designs of a operational reality. And I I think back to the division of responsibilities between IETF and ICANN. So global address policy sort of implementation sort of is on the ICANN side of the fence. And I think I'd like to see a better distinction between what is the technical requirements for this allocation scheme versus proposals or suggestions on how it might be implemented because it feels a little conflated with these proposals. I have no opinion on whether one RAR, five RARs is appropriate or whether the RAR model even is appropriate. Maybe there's a third option where it is structured in some other way. But I'm not sure that this working group is the right place to come to that conclusion. So it would be useful. Think Ryan is probably going to be somewhat of an intermediary between the specification and the solution. But what what how do we define what success looks like? What is the set of implementation criteria that we can test a proposed implementation against? And if it hits all those marks, we know we have something that would be successful.
[00:38:07] Warren Kumari: And yeah, I think whatever gets decided, having a lot of input from the IANA to help make sure that advice is correctly provided to you and what we would like this to look like is provided to the RIR or the RIRs. And again, this is all based on the assumption that we really want a prefix for space and that aggregation is important. If that is the case, then it's one versus many versus possibly, you know, there had also been talk of a new RIR for space or seeing as for the foreseeable future, there are not likely to be that many requests. Maybe just the IANA does it. But, you know.
[00:38:49] Padma Pillay-Esnault: Padma, Kim, this is exactly the kind of participation and feedback we need to have. Because as we bring a design team on or whether we don't bring a design team, we need to have this discussion on the areas because that brings different perspective. And definitely, I encourage everyone here who may not have enough time today to talk to actually participate on the alias and tell us their perspective from their operational standpoint, their experience.
[00:39:19] Tony Li: So I'd like to invoke Occam's razor here. We need the simplest solution that solves the problem. We really need to be doing something as simple as possible. The number of requests that we're expecting here are in the order of about 10 per year. There's not a lot of work here and really does not need to be all that fancy.
[00:39:41] Martin Duke: Martin Duke, Google. This is a clarifying question, I guess, for certainly for Warren, maybe for both of you. How do you think about the hierarchical hierarchical nature of these locations? And what I mean by that is I'm told that Jupiter is quite big. There are many moons around Jupiter. It itself is quite big. So, I mean, you know, god knows what we're gonna do on the the the speed of light, you know, matters if you're going from one of Jupiter to the other. So how would you handle further subdividing the space? Well, because we don't we don't we don't wanna be in a situation where, like, the Jupiter block is I mean, this is taking way in the future, but Jupiter is big, so it's a good example. The Jupiter route is is, like, treated as undifferentiated. Now we're stuck with all these addresses that fragment hopelessly over the enormous geography of the Jupiter system. That seems bad. So, like, I think this is a harder problem for Warren because he's got, like, two axes on how he's separating and maybe a little bit easier for Tony. But, anyway, how do you think about that? And if you haven't, let's please do that so you don't end up with a system that falls apart in in the future.
[00:41:01] Tony Li: It's it's actually very simple. We have a very simple axiom in routing. Addressing must follow topology. Okay? Now, we don't know what the topology is going to be like in the future. Nobody's decided that. So we can't tell you exactly what it's going to fall out, but we want the addressing to map to whatever that topology is going to be. And we need the flexibility to decide what that addressing is going to be in the future.
[00:41:28] Padma Pillay-Esnault: Okay.
[00:41:30] Warren Kumari: Yeah. I mean, I spent some time playing yesterday, and it looks like the round trip time around what likely an orbit around Jupiter is is on many, many seconds, like a hundred and twenty seconds, hundred and thirty seconds. But I think when you're building that, you know, things are moving back and forth. We're clearly not gonna renumber spacecraft as they change different places in orbit. So I think that that's a thing that you figure out. Like, maybe it's not a single route. Right? The Internet routing table has a 100 sorry, has a million routes in it, substantially over a million routes. A single route or five routes, I don't think we need that quite level of perfect aggregation. Would it be cool if you could? Yes. Are you sometimes gonna have like I'm adding and removing this route as things get closer and further away? Possibly. But that's gonna have to happen whatever you do. I think that maybe I didn't describe that well because
[00:42:26] Martin Duke: No.
[00:42:26] Marc Blanchet: I mean,
[00:42:26] Martin Duke: I I think I think your response is fine. I I'm I'm really running the risk here of going too far into, like, science fiction speculation because I I I agree that it's that it is like, the the problem is very small for the foreseeable future. Yeah. But I think addresses are hard to it's hard to have a flag day. And if you have, like, some sort of IoT scenario where there are devices scattered all over a thing that are pretty all over one of these, you know, celestial systems that have some some sort of fixed geography to them that like, I I don't wanna end up in a blind alley where we've, like, created this huge problem for peep for
[00:43:09] Warren Kumari: Yeah. I mean, I think that this is as with, like, addressing terrestrial addressing. Right? You get your address space in North America.
[00:43:18] Johannes: Yeah.
[00:43:18] Warren Kumari: But, potentially, this actually used to be a problem with planes. It used to be Boeing. When you took off from Los Angeles, you'd have your prefix would be routed to North America you're using Boeing. And when you got to Europe at some point in the ocean, they would route the prefix through Europe because that's where your plane was gonna land. Mhmm. So, like, the route would move. I don't think we can have perfect geographical routing because what do you do when a spacecraft is flying from Mercury to Mars, Yeah. Do you read number stuff as it passes through all the planets along the way? I don't think so. I think it's it would be nice if the addresses are kind of grouped there, but we already have routing processes where you have, you know, multiple routes. Nice to have aggregation. You're gonna have exceptions. You're gonna have more than one route per thing because things are moving. You know? My phone is on a spacecraft that's moving back and forth. It's not gonna renumber all the way. You're gonna carry a route.
[00:44:11] Martin Duke: Right. Thanks. I'm taking enough.
[00:44:13] Padma Pillay-Esnault: If you allow me, there's one thing, though, I'd like to point out is that we won't have a network only for Mars, only for Jupiter, or only for whatever because we have to think about the distance. What will happen? You will have relays. What are where are those relays? They might be serving multiple planets as well. So I think we should actually really put ourselves in this term of this is not a one by one planet. It's going to be over most probably relay serving multiple systems eventually, or even it might be relays serving systems that are in close proximity with them or within line of sight, whatever it is. But it is a little bit more complex. So I just wanted to throw this in. Right.
[00:45:03] Tony Li: We don't know the future topology, and we can't really can't plan for it right now. So we have to have flexibility.
[00:45:09] Padma Pillay-Esnault: Yeah. What I what I mean is that it's going to change over time in the lifetime of a of a vehicle space vehicle.
[00:45:17] Warren Kumari: And and, yeah, I mean, I think, you know, you ask for addresses here, but they're not always going to stay there. Some of them are gonna move around. But, again, I think the sort of guiding principle is if entities affiliated with Roscosmos need address space, they need to be able to get that, and they can't get that from ARIN.
[00:45:35] Tim Churn: Like, just
[00:45:37] Warren Kumari: having a single one, I think, is a mistake because at some point, there is gonna be grumpiness between the US and Russia, or the US and China. And you know, Russia ends up being sanctioned. There will be more tension, and China gets sanctioned. Like, I think a single point of failure is dangerous.
[00:45:55] Tony Li: Solving all of the world's geopolitical problems is not in our charter.
[00:45:59] Warren Kumari: That's exactly my point we thought. Anyway, sorry, Peter. Go. It's fine.
[00:46:04] Peter Gortienig: Yeah. Peter Gortienig: Peter Gortienig. Thank you. I would respectfully suggest to elevate the flight level, no pun, of the discussion. I mean, routing around certain geopolitical, and again, funny observation given given the subject, is is probably too much in the weeds already. The one thing that I believe makes sense here and and would would need to be explored further is the separation of the policy making and the policy execution. And more importantly, the IETF is not so experienced in policy making for the address space. Second point, this is not the address of your youth. This is not what we call globally routed IPv6 address. It's more than that. So that might need a different set of policies from which may derive or not. And I think Kim alluded to that partly that this needs a different type of address distribution mechanism. It could be attached to an IRR, but it will not work if that address space inherited the policy making that is attached individually to any of the IRRs. So what needs to be thought about first is who is the appropriate body to set the distribution policy for this particular flavor of address. And I believe that these people are not well, there might be some of them in the room, but there is a larger community of people who are maybe not in the room. So to do that outreach, one step forward could be, and I'll be beaten for that, you submit a proposal to the Internet Governance Forum. You you invite the appropriate bodies that you assume would be requesting these things together around that and discuss that with them and the wider community to make sure that all the voices have been heard when it comes to architecturing the the policy. What this group needs to do is maybe just saying, we are putting a certain flavor on a part of the I p v six address space that is carved out of the reserve pool, which is not globally routable, but it is. It is dedicated for this purpose, and we hand this over. Just make sure that not the wrong entity is gonna grab this. Right? Build that build that community yourself, and then make sure that the the, the technical parties are in it.
[00:48:32] Warren Kumari: So a clarifying question. You said go and ask somebody at, like, IGF or similar. I was thinking you instead ask NRO slash ASO slash existing RAR people because they already know how to build address policy, and that's what they do. Like, we have a thousand people at Wright meetings and a couple of 100 ARIN meetings and a couple of 100
[00:48:54] Peter Gortienig: How many of them live on different planets? I mean, physically.
[00:48:59] Warren Kumari: None. But they are ready. Some of them, it feels like it. But some of but they've already thought about building policy and allocation stuff, and I suspect I don't know if the people if the IGF participants are going to have enough background knowledge. But again
[00:49:15] Eric Vyncke: Well, you
[00:49:15] Peter Gortienig: need to make you need to make sure that the right you you need to encourage the right people to actually show up. If it's a random participant, that that that's not gonna work. Right? But it could be a forum to do this in a multistakeholder, excuse my French, fashion rather than doing it top down in in different ways. Thank you.
[00:49:35] Tony Li: So we have one address space, and it is, delegated to NRO. So they are the right people to talk to.
[00:49:42] Marc Blanchet: So so, Peter, thanks for having this comment. So I think this is exactly what we are trying to do here, have some technical discussions, architecture discussion in ITF. I'm trying to produce a document which perhaps will be then sent to more multistake holders where we can get more policy kind of discussions. So that's exactly what we're trying to do, and this working group is trying to produce something on a tech based on the technical problem, technical requirements, stuff like that. So thanks for the comment. And, Eric?
[00:50:16] Padma Pillay-Esnault: There's one thing I would like to add about this is that don't forget something. We bought a space vehicle. It has a certain amount of memory, certain amount of processing power, etcetera, etcetera. It's not like on Earth where we can just say, oh, we'll change it and put a bigger router. So part of this discussion of happening now in their ATF and talking about desegregation is the right thing to do because we do not want to overwhelm those vehicles that are already out by lack of planning or lack of idea of how the future will evolve. So I think we cannot we don't have all the answers. We need a bigger forum, but we need to provide at least some guidance for what we need from a technical standpoint. So, that's where we are here. We are not going to take the decisions top down for anyone, but we need to be able to actually articulate for everyone, everybody has what kind of requirements and find a way.
[00:51:18] Erik Kline: A couple of points. I want to agree with everybody that said that there's that leans that that this is there are larger concerns here about, allocation and that, like, the RAR mechanism is maybe the closest thing we have that that's applicable. It may also be that something else is better. Or or and if you wanna talk to space agencies, there's there there are ways to talk to space agencies. They don't have the address allocation policy background that an RIR does, but they could perhaps, yeah, contribute some perspective. So I strongly agree with an RIR or RIR like approach. I'm I'm somewhat skeptical of a single prefix being allocated. I think the operational reality is that there's gonna have to be maybe a couple of prefixes, and so that will be a reality. I'm also skeptical of this geographic aggregation. I feel like aggregation the things you're gonna aggregate are a function of your commercial agreements and not of, like, where things are or or which orbiting body they are. So, again, that's actually probably something that should be determined by the entities they get set up to to manage the the multiple prefixes that will be handed
[00:52:32] Marc Blanchet: out. So
[00:52:36] Padma Pillay-Esnault: Rick, I tend to agree with you because most of the time, the way we talk with satellites are not necessarily up from only one point on Earth. They are in different geographical areas as well. So I think the problem is a little bit more complex than what we think today, but we need to start somewhere, and we need to get the right people at the table. So I encourage everyone to really share those point of views so that whenever we have a discussion or if we have another team or design team that we can actually bring all this together and come up with some set of recommendations and requirements.
[00:53:13] Erik Kline: I agree on starting somewhere. I don't think the start should be, let's allocate a huge chunk and then sort it out later. I think that's that's the wrong order of operations.
[00:53:25] Speaker 18: I'm just a random engineer. Lauren, could you go back go back to this beautiful diagram? So, yes. So my understanding is on the technical pure technical aggregation level, those proposal will give you the same number of routes. Right? Why? Because you aggregate per body. I'm not sure I could use geography term here because it's not on Earth anymore, but whatever. Right? We need a new term for this. So, it's the difference is whom this particular space agency will go to get the block. Right? But number of routes does not change here. You get one for Jupiter, one for Mercury, and so on, right? So, I think from technical perspective, if you forget about geopolitics, it's the same. It's only, and I agree with Tony, makes life simpler because it's not just about this RIR know how to serve the customers. Customers only know also know how to talk to this particular entity already. So it's an interim solution. They will go there anyway. Right? Like, yeah, Russia probably wouldn't go and talk to AFRINIC or ARIN or currently because they don't have mechanism for this. They might have already a mechanism for RIPE or at least like so if you don't make it easier for them, they might just do some shortcuts, which we probably do not want. So, yeah, I think it makes more sense from technical perspective and from short term tactical perspective.
[00:54:56] Tony Li: So we simplify everyone's life if we go through one RIR, and they don't have to go all through all over the place. Right? And we don't have to have the RIRs trying to interoperate, trying to get them to do allocation from the same block. It just makes it very more com
[00:55:12] Speaker 18: For customer customers, your agency, probably, it's not easier for them because they need to introduce new processes to talk to new AIRs. They have not been talking before.
[00:55:28] Padma Pillay-Esnault: We are a little bit over, but we have about five more minutes where we were supposed to discuss about the design team and over. So I'll take those five minutes, but after that, we need to close the discussion and move it to their list.
[00:55:42] Tim Churn: Tim Churn: The architecture document talks about maximizing aggregation. Of what I've heard, I kind of like aspects of both, so hopefully, there can be some working together. This does overlook the fact the architecture also says it supports v four and v six. So potentially, we're gonna even though we aggregate v six, we're gonna have a lot of v four slop out there. Can the architecture be changed just to say v six only, was that ship or spacecraft sailed?
[00:56:06] Tony Li: That's been an open debate. The point here is that v four has some advantages, and spacecraft designers may very well choose something with lower overhead.
[00:56:19] Warren Kumari: And, yeah, I mean, I just wanna clarify. I think what Jen said is exactly right. It's from a technical standpoint, it's there's you know, if we assume that you want a prefix per planetary body, or you know, that you even just need one prefix for space, from a technical standpoint, it's a single block per body, and it's not that the RARs have to do anything different. They get allocation from each. But I think Lars is in queue.
[00:56:45] Lars Eggert: Yeah. Hi. Lars Eggert, Mozilla. So a few points, and I apologize I haven't had enough coffee yet morning. So I I think when when Tim said the word maximize, I think that is you know, as engineers, we always wanna maximize, but I think that is also, like, an an dangerous goal. I would I would prefer if we tried hard to avoid, like, bad solutions rather than, like, trying to, like, maximize the last thing out because they will be operational, for example, reasons why you might not wanna maximize. You might wanna do something else, and and the architecture should allow that. Right? So avoid avoiding stupid outcomes that I think trumps the the getting the the very last possible route eradicated from your routing tables. But that that does that's a small thing. But I think also, if you think about, like, attempts to overload semantics on the the the address space, right, There there's been very many of them and very many of them have been very bad. But maybe one of them, at some point, will become something we will want to do, and it would be nice if if this pretty rigid looking to me at least sort of approach would support that. Right? And so that that, think, argues also for some flexibility here and maybe not, like, coming up with the the perfect thing for what we can see now, and then we it might bite us later when we do need flexibility that we didn't foresee. So segue. The the the other thing that made me come up originally was what what Peter said. I think I disagree with Peter in the sense that I don't think the IGF is the right place or a place like that that is very, very multistakeholder compared to what this is. Is the right place to develop something from scratch. And I I actually don't know if you said that, but but at least that's what I heard. I think it make makes a lot more sense if a group of goofful people, a lot of which are probably in the RIR and related communities, and here come together and we write something down as a proposal that everybody can sort of at least not strongly disagree with, and we can sort of go to places like the IETF and do a road show and explain to people not so tuned in that this is how it's gonna be. It's gonna work fine. We got this covered. Right? The the current Internet governance model extends the space. I think that is, like, the top line message we wanna send politically here, and and I'm gonna leave it at that. Thank you.
[00:59:00] Tony Li: Avoiding stupid arguments is exactly why the I p v four table is at 1,000,000 routes, why the v six table is at a quarter million and headed the same direction. K? It's a really bad idea. We need for an engineering organization to be setting our goals a little bit higher.
[00:59:19] Lars Eggert: I think that's a very detailed argument compared to what I was asking for.
[00:59:25] Warren Kumari: And just following from you said, I think, you know, if we talk to a different group, I think what Padma suggested is really important, we outline the requirements that we have, the sorts of things that we want the shape to be so that people aren't like, oh, have you considered using pigeons?
[00:59:42] Dan York: Dan York, employed by Internet Society. I've been speaking just myself. I think we have to be clear to sort of what you said a moment ago, Tony. What is the IETF's role here? Our role is not to do that chart. Our role is to say with there is a a technical reason why we think that there needs to be an allocation of IP addresses for space, maybe prefix, maybe multiple. Who knows? We think there should be a block for that for these reasons, for aggregation, whatever else. That is what we need to specify in some form of a document. And then we need to hand it over to our friends at the at IANA, at the NRO, and folks and say, here's our understanding or what we would like to see from a technical point of view. This is for them to figure out. Right? The people who are doing going to do that, that is for them. Our role needs to be, here's the technical reasons why we think, you know, why we have this goal in this. And that's it.
[01:00:47] Tony Li: And our goal is maximum aggregation. And as soon as we start doing multiple allocators, we end up with less aggregation.
[01:00:56] Dan York: Yeah. I'm with well, what Eric just said was the goal is operation utility is is is having something in having the best possible routing architecture we could have in We need to outline what we think success looks like, what that is out there, and then we need to leave it to the people who actually know how to do all of this to go and figure out the actual way it gets act it gets done there. We're not the ones who are doing the allocations like this.
[01:01:21] Warren Kumari: And to be clear, my this example is not like I think we should break it up like this. My example is we should say there should be a block, and they figure it out. Yeah. What size, how to do it, how they split it up.
[01:01:32] Dan York: You did make a nice chart, though.
[01:01:33] Warren Kumari: Just point was my concern with a single, whatever it is, is they won't be able to service everyone because of politics. But that's
[01:01:40] Dan York: Well and I think you had the right things at the beginning, Warren, in your charts, which is that when this initially goes up, you can take a view that it's going to be everybody who's first going out there is going to use their own IP address blocks and they're probably going to haul it back to their own networks anyway. So all of this might be a great idea, but in the reality of how it's at least first going to be executed, until we have a very competitive space, literally, then I think a lot of it will be that way anyway. So, again, I think our our role is specify the technical considerations and then leave it to the others to implement.
[01:02:15] Marc Blanchet: So, with that, I think, Dan, you just summarized what I was going to say because that's what I understood from the discussions here. We need to focus on our architectural view, what's efficient. We need to set some goals on the technical level, we need to set some requirements out of those, and then actually write those up into documents to further discuss with other bodies. And that's what we should do. And my question to Tony and Warren is like, is this something that we can do, or do we need to form a design team to do all these things that we talked about? Because we have got very good input in this meeting.
[01:02:54] Tony Li: We don't need a design team. We need to make a choice.
[01:02:59] Warren Kumari: I mean, I think that the architecture document maybe describes what it looks like and my document doesn't you know, or our document isn't needed because maybe the architecture document explains what is what the shape should look like.
[01:03:13] Marc Blanchet: So is it is it
[01:03:14] Warren Kumari: All all these documents could be changed to that. You're looking like don't make me write that.
[01:03:19] Eric Vyncke: So jumping the queue, I would prefer to get the architecture document shipped as an RAC way before we get this addressing resolved. Right? So let's ship the architecture document. Keep it very vague there. Just document like one of my points would be, is it part of the global unicast or not? For instance, I think this critical aggregation is obviously another one. With this, I mean, I I think, in the kitchen document.
[01:03:46] Marc Blanchet: So yeah, I think I agree with that. So my thinking is, like, we should have this kind of space discussion separate from the architecture. Architecture gives the hint, like this is it, but then it refers to this document. So I was thinking, if we take all this input, can you two really summarize these these inputs into a document and perhaps add these different ideas how to do the allocation as examples to that one? Is it possible to do that?
[01:04:21] Padma Pillay-Esnault: May I suggest something? Sure. May I suggest something? I I think there is a lot of people with a lot of point of views here. Would be it would be best to have another side meeting just dedicated to that so that these people can actually attend it long in advance. Advertise that. And actually, take medicine requirements from that work, from that meeting. I think that might be easier for everyone. Yeah.
[01:04:56] Marc Blanchet: Okay. Thank you. I think we had very good discussions there, and we hope I hope at least we have a way for from there. So now is a time to look into some risk books. Right? Okay.
[01:05:18] Johannes: Yeah. Hello from my side. I'm Johannes [Johannes] from Technical University of Darmstadt, and I want to show you some results from my master thesis, evaluation of quick and interplanetary networks. Yeah. Let's first define the scope of my work. I was looking at deep space networks only, so I picked this exemplary Mars Earth topology. You can see in this illustration. And not in the scope of my work where GEO and LEO satellites are also the system domain. Also, I know this is in the charter of this working group, but just wanna make clear my work only focused on the earth mass use case. Yes. Starting point for my work was the Internet draft from Mark and Wes, quick profile for deep space, where they already put a lot of work into considerations, what you need to pay attention to when you wanna use QUIC in such a scenario. And, yeah, my goal was pretty much to validate this profile and run simulations to see if it's actually working as described. So just to give you an overview of what are the challenges, the extreme latencies in space cause timeouts on the transport layer and also create a slow feedback loop. Then you also have a high BDP, which challenges congestion and flow control. You need to adapt your window sizes accordingly. The path loss, of course, requires retransmissions and also impairs all loss based congestion controllers. And you also have highly asymmetric bandwidths typically. The uplink is way more constrained than the downlink due to the size and power constraints on spacecraft, which can lead to air congestion. And last but not least, probably the most challenging characteristic is that you have intermittent connectivity and no continuous end to end path, so some kind of buffering at intermediate nodes is required, which in yeah, this work is then done on layer three by buffering IP packets on intermediate nodes. Quickly go over the methodology I used. So I chose to run discrete event based simulations to just sort of practical reasons. I didn't want to run emulations in real time. That would take hours to simulate, and also the discrete event based approach guarantees deterministic results. First, I defined my topology parameters, so I chose RTTs from one to twenty minutes. You probably noticed that this is not exactly the Mars-Earth RTT, but I had to scale down some of my experiments because just of performance limitations of my laptop I was running them on. Yeah, the bandwidth, packet loss rates, I also tried to choose realistic values and run simulations over different configurations. Thereby, I tested mainly five constraints. So first, I wanted to do a baseline feasibility check if it's even possible to get a quick connection running in space. Yeah, get a successful handshake and a complete transfer. Yeah.
[01:09:00] Rick Taylor: Have a
[01:09:01] Lars Eggert: quick quick clarification question. Your packet loss rate, is that random loss, or did you try to model some space links?
[01:09:10] Johannes: I only estimated random loss. Okay. Yeah. Yeah, next, I looked at how the high BDP challenges the flow control and congestion control, and also what happens when I introduce loss to the scenario. Yeah. In the fourth step, I introduced asymmetric bandwidths and so and looked at how how this influences the performance. And in the last simulation, I looked how intermittent connectivity can be dealt with. Yeah. To implement my simulation, I used a Deep Space IP quick workbench. It's a tool written by Adolfo and Mark to run quick simulations in discrete network simulator. It integrates the Quirin implementation, and you can just describe your topology by JSON files. Whoever who attended the site meeting on Monday already knows that too. It's pretty neat. Yeah. And then extracted the relevant metrics from the generated pcap traces and QLOG files. So let's look at the results. First, baseline feasibility check. So if you just want to set a connection from Earth to Mars without tuning any parameters, you will not get it running. You just run into a timeout because the default idle timeout in QUIC is thirty seconds. And of course, you have to increase that. Yeah, if you increase that, the handshake will complete, but you will still see a lot of spurious retransmissions of this initial packet. This because the initial RTT value, which is the second timer variable in QUIC that you can configure, is, yeah, by default, just set to three thirty three milliseconds. And of course, this is also not appropriate. Yeah. If you tune these two parameters, then you get the connection running. But the next thing you will notice is that the throughput is pretty low. This is mainly because flow control limits the throughput in this scenario because the per default, it only reserves 1.25 megabytes of buffer space. And the sender can always just send this block and then has to wait for the acknowledgments to arrive. So if you are to t, I think in this scenario it was ten minutes. You always just can send a megabyte and then has to wait ten minutes to send the next block. So you would need to configure at least one bdp of flow control limits or better two bdp in case you have loss, so it can continue sending while waiting for retransmission. Yeah, this is like one restriction I found. So of course, you need quite high memory buffers reserved if you want to run quick connections over Deep Space topologies. Next, I was looking into congestion controllers. In Quinn, Cubic, NewReno, and PBR were available. Yeah. To sum it up, all of them don't work as well as on Earth, of course, because the feedback signal is just really slow. You always have to wait one RTG to get any feedback from your receiver if a packet got lost or arrived. So the feedback signal is just really delayed. During the slow start phase, it takes a really long time for Cubic and NewReno to scale up the window, and of course, have quite a high buffer upload. If your intermediate nodes have large buffers implemented, Yeah. This could be tuned a little by setting the initial congestion window more appropriately. BBR ropes a little better. So in this scenario, the bandwidth at the BDP is just 15 megabytes and you can see that the blue line here, the BBR controller can probe this through BDP fairly quickly compared to the other ones. Yeah, but then if you introduce loss to the scenario, PBR is really the only option that's left that can achieve any good performance. So cubic then collapses because it shrinks its window as a reaction to the loss, which is to expect it, honestly, here. Just a note, this is only true to PBR version one, which was currently implemented in Quinn. The later PBR versions also incorporate loss as a signal, so they probably have similar issues. Yeah. Next, I was looking at how asymmetric bandwidths influence the performance. The default configuration of QUIC produces quite a lot of acknowledgement uplink traffic. In the left column in the heatmap here, you can see the default configuration where QUIC produces one acknowledgement for every two data packets it receives. So, yeah, this can quickly lead to saturation of the uplink and therefore a congestion where the sender also starts because it has to wait for the acknowledgments to arrive. I tested different bandwidth asymmetry ratios from one to 20 up to a really high number of one to 640. Which of them is realistic? I couldn't really tell in my in my work because there was not that much data from, yeah, actual deployments out there. But, yeah, even at a ratio of one to 20, you can see how the downlink good port is throttled by a congestion. And to mitigate this problem, I used the ACK frequency extension in Quinn to configure the endpoints to send fewer acknowledgements, only one for every four packets or one for every eight packets, which are the other columns here on the heat map. And you can see how the performance can get restored by using this extension. Yeah. In the last experiment, I looked at the intermittent connectivity. Yeah. This architecture, the outages get bridged by layer three buffering. So I simulated the thirty minute outages in this scenario, yeah, which should reflect the Mars orbiter being behind Mars and out of line of sight from the antenna on earth. So the sending halts when the the the orbiter gets into a blackout. And, yeah, this is due to the congestion window being exhausted because the sender also doesn't get any more acknowledgments. I used BBR here and also a fixed rate or better fixed fixed window controller, so which just has a fixed congestion window size. Yeah, the transmission then halts during the outage and resumes once the sender gets more acknowledgments again. You can also see here that the probing of PPR gets disturbed by the outage. So the blue line here has some weird spikes after the first outages. This can be explained if you look at the RGT measurements, which, are not correct anymore because the packet got buffered for thirty minutes. But overall, you can say that even with outages, the transfer still works.
[01:17:58] Lars Eggert: Yeah. Hey. Lars. BBR models a certain link model. And and have you looked into whether that model actually is suitable for spacings? I know you didn't simulate the spacings, links, but if if you were running over a space link, an actual space link, would BBR actually be a good choice? Question one. Question two is, as far as I understand, and and people who know more about us in the room can correct me if I'm wrong, I thought capacity was sort of scheduled and transmissions were scheduled in space. And so you probably wanna actually run Cubic or something which can really, like, fill that thing because otherwise, you're not really maximizing your send opportunity.
[01:18:40] Johannes: Yeah. If PBR is actually suitable, I would say, as you can see here in this plot, probably not because, yeah, it it mainly depends on the But
[01:18:52] Lars Eggert: you're not you're not simulating a space link. You're you're simulating a link with a lot of random loss and a lot of so so an idealized or or Yeah. Sure. Wanna call it scenarios. Yeah. I think an actual space link has a bunch of other characteristics again that other people in the room know more about than me. So so so even if BBR was suited to the link you're simulating, this is not necessarily saying that BBR will be suited to an actual space link. And I think that is sort of I I understand we need to go in steps, and I also think understand this is a master's thesis and not a PhD thesis. So so don't take this as criticism. Right? I'm I'm just sort of thinking about what what else would I wanna see to to get more out of this sort of investigation. This is a great first step. Thank you.
[01:19:35] Johannes: Yeah. Yeah, thank you. No, sure. I agree that, of course, simulation has a lot of simplifications and can't just be transferred to a real scenario in all cases. Directly Yeah. To that, oh, I have a few more slides. Okay. Then, yeah, I just wanted to sum up the results. Yeah. These are the parameters you pretty much have to pay attention to if you want to run quick in such a scenario. So first, timer values have to be set appropriately. Flow control limits need to be increased. For congestion control, you could use BBL version one from looking at my results or better use just a fixed rate controller, which is also what other space protocols mainly do, like just open loop statically configured sending rate. Yeah, and the accuracy should also be tuned to prevent this congestion issue. All of that, however, is only profiling and doesn't require any underlying protocol modifications. So, yeah, it definitely proves that it's possible to to run IP stake protocols in space. Just quickly, a future work that could be interesting. Forward error correction, I guess this would be highly beneficial in such a scenario. Security would probably need further investigations, especially, yeah, the the certificate management in space is not as easy as in my simulation. Then congestion control, yeah, as I said, for the near future, the flows just statically planned, you can just configure ascending rate. But I think it's interesting to look more in the long term vision where you have an interplanetary network with dynamic flows, then you would also require some kind of dynamic congestion control, which is still not soft yet in this scenario. Yeah, this was just yep, I think that's it.
[01:21:55] Rick Taylor: You're ahead of me.
[01:21:58] Marc Blanchet: Oh, okay.
[01:21:59] Rick Taylor: Sorry. Wasn't checking the length of queue. Rick Taylor, first off, I think this is really good and really valuable work. It was a question. The University of Bologna under professor Carlo Caini is also doing similar work, and I wondered if you had read any of their published papers because they were looking explicitly at alternative congestion control
[01:22:19] Johannes: Yeah.
[01:22:19] Rick Taylor: Algorithms and, again, using some of the ESA source data. So
[01:22:25] Johannes: Yeah. I I saw some of the work. They I think they also, like, developed a quick convergence layer for DTN and stuff like that. And Mhmm. Yeah. So it was only also interesting what they do.
[01:22:36] Rick Taylor: So they're ignoring the DTN piece. Fundamentally, they were still using QUIC.
[01:22:42] Johannes: Yeah. So definitely.
[01:22:46] Jonas [Jonas]: Yeah, thank you. And thank you much. Again, very, very interesting, very relevant. I just have more comment than a question. I wanted to bring up that it's important to look at not just a single quick implementation. So we have been comparing two, and they behaved sometimes similar, sometimes quite differently. And so even even congestion control implementations can have quite a bit of diversity. So this is not concerning you specifically, but in the sense of for the group. When interpreting these results, we need to make sure that we get a broader coverage of different space different quick implementations since they do have their own particularities and their own ways of of coping with things. And, so we should make sure that we get that we don't base our judgments on a particular code base. That's more a general comment. But thanks much for doing this.
[01:23:42] Marc Blanchet: Thanks, Johannes. I think this is this was a good presentation. I know one of the takeaway from my side is, like, when you then simulate the links, you may be thinking about you should think about more about, like, how these celestial links look like. So that would be one thing. Maybe condition control need to be modified. As Lars was saying, maybe some other
[01:24:05] Marc Blanchet: Yeah.
[01:24:05] Marc Blanchet: Way of filling the pipe would be required, all these things. So, hopefully, you'll continue the work. Yeah. Thank you. So with that, Mark.
[01:24:26] Marc Blanchet: Good morning. So this is an update of the for the non working group tiptop-quic-profile document. So this came after the last several months that we've been doing a whole set of quick simulations over various scenarios. And, well, those were done you know, many of them were done over the last few years, but they were now done in more structured and detailed way. The old set of simulations was presented on Monday during the site meeting that was announced on the tip top mailing list. The the GitHub that contains all the results, the input file and the output files are are, I think, at the end of this slide deck. And the presentation also is there on the git. Recording would be available when when the ITF staff will provide the recording of the Webex. So the new version of the draft was updated based on the submission results and additional content. Key topics of those changes, the structure, The document was reorganized. The guidance now tied to the TIPTOP usecase connectivity scenarios that I was describing in the usecase presentation. More sections on topics and some normative language, but it's an so it's an informational, so we may want to, you know, change that again. But we'll see. So we group quick features. So before at zero two and before, it was more like a a flat, long list of of quick features and stuff. So that was not natural to read. So it was a shopping list. Now they are grouped into different larger sections, such as connection establishment, connection maintenance, bandwidth management, path characteristics and state, and, yeah, TLS, and then some applicability of the example scenarios. So, again, I'm not repeating, for the you know, make sure that we're referring to the use case scenarios that were described before. So connection establishment. So the danger here is I'm saying stuff that we're, you know, discussing full length Monday, so please refer to that presentations. But so, essentially, when you have a one way delay of fifteen seconds or more connections time out because the max idle time out is thirty seconds by default. So, essentially, you should always put the initial RTT as must be set in in general. And if you don't do this for a one way delay, for example, of fourteen seconds, then you will end up having a lot of resending the initial packets. So that's not good way of of using the bandwidth. So, really, initial RTT is is is a must to to be set. Yeah. So for example, Earth-Mars direct will will with the defaults will the handshake will never complete. We did try and tested with the, you know, something scaling up to two day RTT voyager, and it works just fine for using the initial RTT. And in this case, you can see from the baseline quick simulation, which is terrestrial case. And then this, if you set the right initial RTT, it's the same number of packets, same number of bandwidth use. It's exact exactly. And to the good point of a of a previous question, this is, well, I'll actually discuss the simulation framework in a few minutes.
[01:29:02] Johannes: Yeah.
[01:29:04] Marc Blanchet: Connection maintenance. So idle timeout is boundary was confirmed. Max idle timeout must exceed the longest contact gap, or you use keep alives. And, well, that's mostly referencing the RFC, the quick RFCs, but, you know, where the quick RFCs that talk about middle box on that are available or used in on the Internet where a typical thirty two thirty seconds UDP mapping timeouts happen, well, we don't want this in space. So congestion control. So this was described by Natalia here on the last previous meeting and then join us here. So we did the cubic versus open loop. And why we're we're not using we haven't tested BBRs because it's not yet in the quick stack that is used for the simulator. Yeah. So cubic with intermittent intermittent path is is really bad in terms of it goes much worse. So rate based open loop congestion control would be the best, especially for intermittent scenarios. And you size the the rate for the slowest down downstream link to avoid filling the buffers. High frequency. So we did some tests. There's findings from Johannes about high frequency and Natalia. So if you make it so that you're you take the eliciting threshold to about 10 packets, that is where you have the most the most advantage for, you know, bandwidth utilization and packets. However, and it's written in the draft is if you if you put the accuracy threshold, higher than the the default, then what that means is the other party, will the source will actually hold a lot more data in their memory. So this is an example where on if your device and asset in on Mars or elsewhere with very limited memory, you may not want to use that because it will hold much more data until receiving the x will because they will happen, it will be received less often. So, you know. Relay buffering. So this is not exactly because of quick, but depending on what happens in terms of really buffering, it has an impact on quick. For example, the blackout duration. So we just put a bit of examples of of the impact of really buffering to QUIC. New TLS section. So TLS typically have a seven days TLS limit for zero RTT reuse. So that means key update needs to be carefully handled. We implemented and test the extended key key update, the quick that is currently being discussed in the quick working group. Essentially, the uptake of this is one update actually costs two RTT, takes two RTT in about three packets. And it was interesting to see because if you take the current, Wireshark dissector, and which is not updated for extended key update, as soon as the first key is refreshed, then you can't you can't decrypt anything else in the connection. So it's kind of a proof that it actually works. Yeah. So we then mapped, and that's kind of a a one key outcome of this, is that we actually mapped the scenarios, the cruising spacecraft, moon, full connectivity, moon, intermittent, all those scenarios that were described in in the use case. Now we actually map those those parameters to be configured for the quick connection to be applied to those scenarios. So that's an example of the use of of the scenarios. Yeah. We actually updated the references. And as I said, the simulations are under this URL on GitHub. You really have everything there in terms of of of input and output files. You could verify all our work. One thing in in the that I said in the side side meeting is that we have done those simulations using different quick stacks, but not this way. So we will redo all of them in in a more interrupt way to make sure that the results hold with different quick stacks. So the o three is
[01:35:27] Marc Blanchet: really
[01:35:27] Marc Blanchet: a major revision of the quick profile. It's backed from a whole set of simulations. And as we have discussed in with the previous discussion, yeah, we could do way more additional simulations, but I think that's a good start. And and we're I think the document is enough made sure to request the working group to adopt this document.
[01:36:01] Johannes: And I think I'm done.
[01:36:05] Lars Eggert: Lars? Lars, I get. I think the so so think this is on track for adoption, and we can certainly talk about this. I think either before or after, it would be good to do a pass to make sure that you're not profiling quick into something profiling space quick into something that isn't compatible with Internet quick anymore. For for example, there's a there's a section about padding. Yes. That is that is sort of simple. That's why I'm using it as an example. It and it says that, you know, padding is overhead, and and maybe you don't want that in space. So I'm I'm paraphrasing. And the thing is it's padding is so even even if you don't want it in space, the QuickSpec says that you must pad certain packets, and and that is also not negotiable in space. And so if you wanna say something about profiling
[01:37:00] Tony Li: Mhmm.
[01:37:00] Lars Eggert: The padding applied to SpaceQuick, I think you need to be more nuanced about where you can do something and where you can't. And so I think the pass with sort of that lens over the document would be helpful. And I think also, like, when you talk about simulations, I think a good sort of baseline test would be, is your profile SpaceQuick implementation still able to talk to Google or Facebook or Mhmm. Somebody, the Cloudflare, out in the Internet? Because if it isn't, that's a pretty strong indication that you you profiled it out of spec compliance.
[01:37:32] Marc Blanchet: Okay. Well, the last one. Yeah. We did that.
[01:37:36] Marc Blanchet: Okay. Good.
[01:37:38] Marc Blanchet: First one. So I don't know if you I think you were using padding as an example. Yes. But I agree with you. Still looking for quick experts to, you know, review and contribute and send text. So so but wanna push back
[01:37:58] Lars Eggert: to you. Right? So the the quick community is paying attention to this, but we're not gonna do the work for you. Okay? We we do quick for the planet, and you wanna do quick in space, and we can talk to each other, but but we're not gonna be the ones who are gonna write the quick and Sure.
[01:38:09] Marc Blanchet: Sure. Well, that's we've been doing a lot of work for the last six months. So padding was put in the context of citing the RFC that for, you know, making sure, you know, to fuzz the the traffic so that, you know, people that are wiretapping or looking at the the the traffic would be
[01:38:35] Lars Eggert: There's there's nothing in the QuickSpec that says you should you should apply padding to, like, make your make make your traffic hard for, like, analysis. There is. I can quote you the text. Okay. Sorry. Anyway, I'm not aware of anybody doing this. But there is text in there that says you must pad your initials to 1200, for example, and stuff like that. And and that is the must part.
[01:38:56] Marc Blanchet: Oh, yeah. Yeah. Yeah. Yeah.
[01:38:57] Lars Eggert: And and so I think more nuance when when you in the padding section, for example Sure. Saying, like, you know, this is the padding that in space you might wanna not apply. But but there's other padding that is actually required for compatibility.
[01:39:11] Marc Blanchet: And and you We discussed in the in the patent to you too. And so
[01:39:15] Lars Eggert: Yes. And and and use padding because it's a simple example, but I think a a pass over the document with sort of that in mind would be helpful. Thank you.
[01:39:25] Marc Blanchet: Okay. So Lars Lars, one one question, clarification question. When you say, like, the space squeak talking with Cloudflare or Google, what's your model there? Because I was thinking, in space, between it talks with ART version of the QUIC, you have a that is translating these things. Because if the Google or Cloudflare doesn't really understand it's talking with this space, the profiling would
[01:39:51] Lars Eggert: I'm not saying that you should talk over a space link to Cloudflare. I'm just saying over a in in quick space quick stack running on the planet should be able to talk to non space quick
[01:40:05] Eric Vyncke: Yes.
[01:40:05] Lars Eggert: Servers or or clients. Right? So the be because, otherwise, you we there's something in the space quick profile that makes it incompatible with the quick spec, and we wanna avoid that. It's a it's a baseline test that you haven't, like, accidentally, like like, went away from what the quick specs.
[01:40:21] Marc Blanchet: I think that's the good model that execs is really the model I have in mind. So thank you.
[01:40:29] Michel [Michel]: Yes, I just wanted to add that we are also working on header compression for quick and in in this environment, and we will present some things on the sheet meeting on on Friday.
[01:40:47] Johannes: Tim?
[01:40:48] Tim Churn: Hi. Tim Churn: I was just looking at the the draft, which is generally like it. In the security considerations, is there anything we should say about, you may remember, you're old like me, attacks like slow Loris, the old slow communication, denial of service attacks. Are we in risk of having that sort of profile in some of this? And is that a concern, that kind of potential security issue?
[01:41:17] Marc Blanchet: Maybe. Frankly, I haven't looked at that angle. I didn't know if sort of sat back with the way the profile was done? But
[01:41:27] Tim Churn: Maybe there'll be no attacks in space and everything. Everyone will behave nicely. Who knows?
[01:41:31] Marc Blanchet: Oh, well well, yeah. That's another
[01:41:35] Tim Churn: Yeah. It's just something to maybe think about.
[01:41:44] Marc Blanchet: So I think that we in the queue has trained. So, I mean, you have a question on, like, requesting working group adoption on this this one. So, I mean, I would like to know first, like, how many of you has read the document? Okay. I see, like, 10 ish on the on the room. Is there anybody in the remote has read? Okay. I didn't. So I think I said there's a quite good number of people who who has read the document. So so maybe can we have the pool? So we're gonna ask for this. This this document has been there for quite a long, and it has been now we have some results coming out also, and this has been also addressed by this document authors. And the ask here is to, like, whether we are okay to adopt this document, the working group doc document. So we have a poll there. So please vote. So, again, just a reminder for everyone who who are in this room, please log in to the system. Otherwise, you'll not be able to vote Also, please do that if you haven't done this. I think the voting has been stabilizing and now again, whenever I say that, this is racist. That's quite generic, actually. But I think now it has a stable so for the Rick I see it's coming. Give it one more minute. Okay. I think we can stop the pool. And for the record, we have 16 yes, two nos, and 22 no opinion. And before we say something, I would like to know, those who have voted no, if there is an obvious reason you can tell us about it so we can think about it. So can you come up to the mic or in the queue if you're remote? Tell us why do you think, like, it should not be adopted. Okay, I don't see anybody in the queue. The reason is not to be able to identify who has said no, but it's about to get the input so that the authors can work on it, the working group can work on it. So with that voting, I think we can say we have a rough consensus to add up this one, but we need to
[01:45:30] Padma Pillay-Esnault: We need to put it to the list.
[01:45:31] Marc Blanchet: Put it to the list for further so that anybody else who has not been in this call could raise their voices.
[01:45:40] Padma Pillay-Esnault: And I would encourage everybody who came up with no opinion, and maybe it's because they didn't have a chance to read the document to actually please do so and make an informed decision from that standpoint.
[01:45:53] Marc Blanchet: So, Mark, we'll take this decision to the mailing list, and then we'll decide on that one. So thank you. Who is on next?
[01:46:02] Padma Pillay-Esnault: Next is.
[01:46:12] Marc Blanchet: So Carlos Gomez:
[01:46:28] Padma Pillay-Esnault: Okay.
[01:46:29] Carlos Gomez: Hello, everyone. So my name is Carlos Gomez. I'm going to present the last update of the draft entitled co op in space. My coauthor is Sergio Aguilar from Sant-Anna. First of all, on the status of the draft, today, I'm presenting revision zero one. Although it's actually the sixth version of the draft since there were four previous versions that were, presented in the deep space side meetings that were the precursor to the formation of the TIPTOP working group. So a bit of motivation for the draft, as this working group knows well and as described in the use cases tiptop draft, Deep Space has characteristics for communication and networking such as long delays, intermittent communication opportunities, lower and asymmetric bandwidth, limited computing and energy resources, and so on. So it is quite interesting to notice that if we take this slide and we replace the term deep space with Internet of Things, the resulting slide is still perfectly valid. So, while deep space and IoT are, of course, different environments, they do share a lot of, commonality in terms of the characteristics, they pose to the protocols that need to run on top. So it makes sense to consider, solutions that have been designed for IoT, such as SCHC that has been discussed right now on a site, discussion on the chat. And in this case, today, I'm talking about the constrained application protocol, CoAP, which is an application layer protocol that has been designed on purpose for constrained networks, which are characteristic of the IoT, which, provides lightweight operation, including a fixed header size of all four bytes, asynchronous asset exchanges, lots of flexibility, and security. And it's based on the REST architecture, which is used on the worldwide web. So the TIPTOP architecture draft, has a section that covers, application layer, and it covers HTTP and CoAP. And for CoAP, it explicitly cites this document that I'm presenting today where, we aim to provide guidance on using CoAP for Deep Space environments. Quickly speaking, in the interest of time, CoAP was designed to run originally on top of UDP, and it can be seen as comprising two sublayers, the upper one dealing with requests and responses, the other one dealing with messages. So that messages yeah. I see the new clock. Thank you. The messages sublayer is a transfer layer like functionality sublayer. It provides optional reliability and simple congestion control, and it defines two types of messages, confirmable con messages, which need to be acknowledged by the destination endpoint, and there's associated stop and wait, behavior and time based retransmission with exponential back off. And there's also nonconformable messages, none, which do not elicit acknowledgments. Subsequently, was provided with support over reliable transport such as TCP, TLS, and so on. However, these entail significant issues in in deep space environments, such as due to the initial handshakes, reliability not being optional in this case, no support for efficient multicast, and so on. So our recommendation is to use CoAP for Deep Space based on the original design, which is running over UDP. Then as an overview of the rest of sections in the draft, we cover several areas about the functionality provided by CoAP, also tailored to operation in this space. Sections four and five discuss caching and proxying, which is quite powerful because then a proxy can provide cached responses so that it's not necessary to contact always the origin servers that's saving energy, bandwidth, and time resources. Also, there's Observe, which allows clients to receive not notifications on resources of interest without the need to to request explicitly every time. Then there's also blockwise transfers, which allow to perform application layer fragmentation of large payloads. And there's also message aggregation, which is being defined currently in another document, which, allows a CoAP entity to aggregate several individual CoAP messages into a larger, aggregate CoAP message, which is then very useful, especially in deep space environments since, we may have intervals without connectivity. Then there's also CoAP group communication, which is suitable for multicast use cases, and there are a few such multicast use cases described in the TIPTOP use cases draft. And, also, CoAP can be secured in different ways. One of them is by using DTLS. However, this would not be recommended generally for Deep Space because it entails, handshakes among others. And, there's an alternative, which is OScore, which is based on object security, where, handshakes can be avoided since the security context that needs to be, shared by the two involved entities communicating can actually be pre shared. So there are a few updates in zero one, the last update of the draft, but, the main one is a new section, which is appendix b, where we aim to provide reference parameters for Earth, Moon, and Earth, Mars communication. The parameters listed here comprise time based parameters, like a retransmission time timeouts, also maximum amounts of time during which a QAP message is expected or could be still alive. And there's also other parameters like maximum number of retries and few others. But for the time based parameters, they have been determined on this table based only on propagation delay components. So this is just for reference, meaning for a specific scenario, if additional delays need to be considered, like storage delays, okay, they will have to be added to these numbers. So the second column from the right provides recommended values for earth, moon communication. Here, aiming to provide safe as but also practical values for the time based parameters, we have considered the maximum distance between Earth and moon. And, however, for Earth Mars communication, that would be the parameters on the rightmost column, we have considered both the minimum and the maximum distances due to the great variability of the related times. And therefore, here, we are providing a range of values. Okay. So considering next steps, okay, we are not asking for adoption because there's not currently an explicit work item, in TIPTOP for CoAP. However, we believe that it fits within the general charter and the general scope of TIPTOP. And we would like to ask the working group, perhaps also the chairs, should TIPTOP consider adding co op as an explicit work item, co op guidance, as part of its future work?
[01:53:58] Padma Pillay-Esnault: Hi. Thanks for the slides. I think we should gauge the interest of the working group this work. Currently, is not in the charter. It is sure that we said we will start with quick, leaving it open to other protocols. But currently, it's not an explicit work item. So I think that one of the things that would be interesting is just my 2¢ here is that as Mark has actually defined very precisely what are the use cases, I think it would be a very good exercise to actually see which use cases CoAP can be used, which use cases and what it brings it plus. For example, the fact that you have multicast might be something or group. Communication might be something interesting. And and then I think that we can gauge the the working group interest on whether this will really make a difference and it would be possibly that some protocols work in better in some use cases than the others. It cover recommendation. That would be my my advice here, but I would like others speak up as well.
[01:55:21] Marc Blanchet: Yeah. The queue is open. So if you have any comment on, like, whether you you see the potential of CoAP in this space, please come to the mic and talk about it. Alex?
[01:55:40] Alexander Pelov: Hello, Alexander Pelov. Yes, so we have done, we have applied CoAP in LPWANs where you have very, very severe delays and very asymmetric links and, you know, like things you can talk you you don't talk during days to the things. So we know that it's really useful work in that aspect. Right? And maybe for the working group here, will be interesting to see if there could be cases where some the control center can talk to a device somewhere, like a very limited or maybe very small data, which would not merit like for a quick session to be opened. Like, can just be just, okay, I want to read that particular sensor, like directly from the center. So that can be a possible traffic pattern to be studied, right? Or having a proxy. So maybe that's a use case. But I know that that could work. And in general, that could be interesting.
[01:56:33] Padma Pillay-Esnault: Personally, I think that maybe, you know, coming back to this use case of having able to have a group communication is that, for example, if you have to update several several devices at the same time, that might be a plus. But I think that you need to define a use case so that it really, you know, fits in some of the use case we have here and actually address those. And maybe I think that will make it easier for the group to see the interest.
[01:57:04] Marc Blanchet: Lauren?
[01:57:07] Michel [Michel]: Yes, and I will add to to Alex that CoAP is also used to carry CORE-CONF messages, and CORE-CONF messages is to use YANG model in a compact way. So it can be also very useful to to control some some element on on other planets.
[01:57:28] Padma Pillay-Esnault: Finally, we'll also need coordination from the eighties and the co working group on any such work in the future. So
[01:57:43] Marc Blanchet: Yeah. I think, Carlos, you got the comments from the chairs on the on the room also. So maybe it's the next step is to focus a bit more on the use cases and come back here so we can we can gauge the temperature in the room on the support for working on it. So, yeah, with that, we have three minutes. Alex, if you like to say something because you are on the if time permits slot, you have two minutes to go.
[01:58:15] Marc Blanchet: Would be quick.
[01:58:16] Marc Blanchet: It doesn't it doesn't work. Mike, it doesn't work? So can you try that, Mike, then? I think this is a dead again. So everything, please take care of the batteries. It's
[01:58:29] Alexander Pelov: not Yes. So that would be a quick thing. I came first with a solution, and then the point was that, is there actually a question that wants to be solved by this working group? And that is, is there a case where we need to see, like, if there is when a packet crosses an interplanetary boundary, should there be a mechanism to tell to the source, hey, there is something happening right? And I thought that that might not be that interesting because maybe if you allocate your prefixes so here you have the Earth talking to the only robot habitable planet in the world, Mars. And so the packets actually are going to go through a lot of hops around the thing. And we can imagine that there are, of course, many other devices on these networks. So we can, of course, put a lot of VPNs and VLANs in order to ensure that the packets get we have this communication there. But we can imagine also that the specific computer has multiple stacks also wanting to talk to other devices, like on the internet. And then the question is, if you have a QUIC stack, for example, and you want to have an adaptation of the timer for your RTT, it may be useful to have a message telling you, hey, your packet right now is going to go over an interplanetary link. So adjust your timers accordingly. So this way, you can have a quick stack that is compatible with the standard internet quick stack. And it just, upon receiving that message, it will say, Okay, I need to actually increase a lot of my timers. So that's the first thing. And the second thing is that I actually thought, well, you know, I call this prefix stuff Alex,
[02:00:11] Marc Blanchet: final words, please. Time is over.
[02:00:14] Alexander Pelov: Yes. So if we have several prefixes here that are from different and some of them don't want to talk to each other, maybe they're going to see, okay, I'm on Mars, but if they're actually going to go to an interplanetary link. So that's the question. Like, is there like, should that be of interest to the working group? Should that be a question to be solved and, you know, before actually going to
[02:00:37] Marc Blanchet: the solution? Thanks, Alex. I think if you are interested, listen to Alexander, and please reply to him during the in the mailing list. And for today's meeting. Padma, final
[02:00:46] Padma Pillay-Esnault: words. Yeah. I would say please bring it to the list. I think you will have a better more chance over there and more time. And also, thanks everyone for being here. Great session. Thanks.
[02:00:59] Marc Blanchet: See you in the next meeting. Bye.
[02:01:04] Padma Pillay-Esnault: And thanks for cheering. Yep. This is the best achievement.