Using the IP Protocol Suite for Deep Space Networking

2:53PM Jun 19, 2025

Speakers:

Keywords:

Deep Space Networking

IP Protocol Suite

TIPTOP Working Group

Space Communications

IETF

QUIC Transport

Delay Tolerant Network

Bundle Protocol

Space Edge Proxy

Network Management

Emergency Messaging

Media Streaming

Transport Protocol

Intermittent Communications

Space Architecture.

100% I think that double screen went off.

Hey, naleni, we can get started in about A minute you want to share the screen, or whoever you think you want to keep the camera on, anything is fine.

And we have about

1516, people in the attendees already, and they are coming in, so we can start, I guess, on time, in a minute. Yeah.

Great, great, great. Yeah, sorry, I was muted. So let me turn I'm going to go ahead and turn my video on. Sure. Oops, I turned it off,

right. So it's exact time we're going to hit Start webinar, and the moment it starts. I will immediately start the recording. You will see that the recording has started, and then you can go ahead and okay, perfect

recording in progress. I

Hi, welcome everybody to the using the IP protocol suite for Deep Space networking TIPTOP presentation. I'm naleeny Elkins with industry network technology council. I hope you can all hear me. Okay, please put something into the chat window. If there's any problems with sound or anything, check the chat okay. So this presentation is being presented by industry network technology council. We are a nonprofit, and one of our purposes is education, in particular about standards. And today there's some sad news about Fred Baker, who was one of the founding board members of INTC, but I know Mark will be talking about that. We partner with the India Internet Engineering Society, which aims to bridge the gap between India and the Internet standard, basically capacity building in India, as that is one of our biggest and growing economies, we've had a number of webinar series. It with INTC. We spent probably two or three years on IPv six, and then quite a bit of time, probably a year, on security. This year, we are taking on new work. Last one we did was on AI, and then now mark will be talking about the deep space. We've had a number of grants from Aaron and also AP neck for training and various deployment and research. Just a couple words about me. I'll keep it early brief. I'm basically a software developer. I write code all day. But let's hear from Mark. Mark has been involved with the IETF for many, many years. He has many RFCs that he's written. He's co chaired a number of different groups, been a part of the IAB, and today we're going to be very interested to hear all the stuff he's doing about deep space. So that is I'm very excited to hear from him. If you have any questions, let us know, but I'm going to stop sharing now. Turn it over to Mark,

good morning, good afternoon, good evening.

Just trying to share my screen. Where is this presentation? I

you see the presentation or the the

screen. Yeah, you might want to put it into a full screen mode,

okay, so you don't see Yeah, yeah, okay.

I think you put it into Yeah, you know, we see the current, yeah, current and next we want to put it into so we see it in presentation mode.

About that perfect, once you go back the screen then,

I mean, go on video. And very excited to hear from you.

Thank you very much. Dhruv contacted me a few weeks ago, well, probably more a month ago, about presenting the what the

TIPTOP Working Group is being doing, and so that's the main purpose of the presentation. He just heard this morning that Fred Baker passed away.

So kind of a

sad news, I started to be more really involved in the IETF about the time, during the time he was the IETF chair was involved at that time for, you know, deploying IPv six. So news to year. So this has been said, I'm presenting this often to different type of people. Sometimes, you know, because it's kind of a bridging two ecosystems, essentially the space communications people and the Internet Engineering people. So this presentation assumes some knowledge of each because we don't want to go too much into the basics, but not too much. So hopefully we'll get you'll get the right level. For example, sometimes I for space people, I make a few slides on what is the quick transport in this context here, I'm not doing it. Often discussions actually are about to understand each other and essentially, for example, understand the keywords of each ecosystem. And sometimes we haven't faced the problem that we are using the same keyword for two different purposes. And l2 is a good example, if you know this usage in each OCO systems. Just to make sure this presentation is only my personal contribution and opinion, I do not talk on behalf the IETF or the TIPTOP working group. So what's the TIPTOP working group? So TIPTOP is keyword suggested by Wesley Eddie, and it's expanded to taking IP to other planets. So in a nutshell, and that's really a short version to give you the perspective to start with the start with. The nutshell of the charter is that, given the delays and disruptions involved in space communications, we need to engineer, you know, IP based internet working and support IP applications end to end. So essentially, the IETF only protocol suite, but the context of space communications, the protocol themselves can be profiled, but the charter a bit working on new protocols. The target scenarios are Moon and Mars and deep space. What is out of scope is the bundle protocol, and I'll come back to it later, and anything around the earth so Leo Meo, Geo, low earth orbit, medium air and geo scenarios are out of scope. This is kind of a fun or, you know, elsewhere, and obviously, we'll need to coordinate and collaborate with the different space organizations. And within the IETF, current work items is defining essentially what is different in space than normal, internet characteristics, use cases and requirements, the differences that apply to the IP architecture, recommendations for existing transport protocols, starting with quick and considerations for DNS. Why? Before going too much into the details. Why are we doing this? Well, the first order question is, do we really need a network in Deep Space? Well, it has been proposed to use a network in deep space for five years or so, but even more nowadays, where, for moon, the current environment, or the current direction, is to instead of having space agencies doing their own, you know, sending, launching and sending their spacecrafts to moon, for example, we're more In the commercial environment. So it's similar to internet, where before it was more government funded than within, you know, a smaller set of people, and then it opens up commercial so we're seeing the same thing in space, where we'll have commercial providers doing offering services, communications, networking, you know any ENT, what we call PNT, which is about position and navigation and timing. We will have multiple users and commercial users that may do various and offer various sources on the Moon or Mars. We'll have various assets, we need them to share links and utilize as much as possible the full the link so, and this is compared to what has been done since the beginning of the space era, where Link usage was planned and is still planned and dedicated to single mission per Communication window. So for this link that time is for you. So clearly, we need to build a layer three network and twin the choices of the network layers above, CCSDS. CCSDS stands for Consultative Committee for space data systems. These are the standards for link layers in space, you know, in some ways similar to Ethernet or, you know, Frame Relay, or all those layer two, we have two choices for network layer, bundle protocol and Internet Protocol. And I'll come back with two slides on bundle protocol to set the stage. But the main purpose of this presentation is IP terminology, deep space in it definition means doesn't include moon, but we're kind of including moon in general in this presentation, in the work of the TIPTOP working group. So what are the main challenges for networking deep space? There are many, many challenges in deep space, and just landing something on moon is difficult, as you may if you if you see what's going on in the industry and landings that were tried over the last years. But so overall, you know, we could discuss in length for all the challenges, but let's focus on what has an impact on networking, which is above layer two, right? So there's a lot of things in conclusions and layer two in layer one in space that will be handled at that level, where we really care about mostly is the long delays. So compared to internet, long delay one way, delay to Moon is a bit short of two seconds, and Mars, depending on the positions of two planets, is four to 22 minutes. So the RTT is kind of the double so an RTT, one RTT for Mars, the worst case is 44 minutes. You know, it's kind of simpler to fix, because you roughly just adjust timers, whatever you do in your protocol, you instead of expecting something within 100 milliseconds, you expect two minutes or more. But on consequences, you cannot expect immediate reaction to evidence because delays. That is more complicated, in fact, is the intermittent communications. And if you see the drawing on the right of the screen, from the end to end, point of view, the round trip time is pretty large, but more importantly, it's very variable, because it jumps right if you look at the drawing, orbiter, when it's behind, Mars doesn't communicate anymore with Earth. So you'll see a kind of black hole of communication, right? And it's only when the orbiter comes back in the line of sight for Earth, similar to rover, and then if you have multiple rovers in different places, and all this makes communication going and then up out of the sudden, no communications. So a mechanism anywhere in in in any protocol, assuming a relatively stable RTT, will just fail. Well, RTT is not simple, stable on internet, right? Sometimes congestion happens, then recovery kicks in, but there's an immediate and fast reaction which is possible on internet, which is not the case in space, but you need to be careful the whole thing here, those challenges are under an umbrella of a name scale, which was called initially delay tolerant network, and then it became delay and disruption tolerant network. DTN can be delivered using BP and IP, or IP both. Obviously we're talking about IP. So if you look at the network architectures that in communications for lunar and Mars, the IOAG, which is the Interagency operations advisory group, which is the kind of a collection of coordination of many space agencies. They delivered the architecture documents for Moon and Mars and NASA has a zone for Luna net and is as a zone for moonlight, called Moonlight and the reference are on the

bottom of the slide. So the architecture is that they expect that on celestial body surface, such as Mars or moon and around you'll have a three GPP network. So 456, G and Wi Fi creating an IP network the orbiters around celestial bodies will carry both IP and BP and the CCSDS Deep Space links, for example, from Earth to the orbiter lunar Mars carry BP and IP. The LUNA net interoperability specification at NIS actually which is a public document defines IP and BP as network layers, so therefore you can see the following regions, right? So we heard our internet and private networks are running IP, the Deep Space links to the celestial bodies are using CCSDS link layer that can carry IP or BP a moon surface network is running IP over 334, 5g, 6g and Wi Fi, the orbiters are around celestial body. Can run BP and IP for can do IP or BP forwarding. And within the spacecraft, typically, there's a typical internal IP, if you see, as my I try to highlight is the fact that there's a common networking protocol use everywhere, which is IP. So IP then everywhere, right? The good part is that if you have a single network layer, is it makes everything more simpler and way more less effective. You don't have complex gateways between protocols which are less which are more fragile and brittle. An application, if you think about an application you only use, you know, sockets or a single interface. Don't have to think about two different network layer that are very different. You can if you have a single network layer, you can do and manage the whole network from any vantage point. And you know, a lot of

advantages.

Why not BP bundle protocol, right? So what happens is a study was made by GPL engineers and Vint Cerf early 2000 actually a couple of years before, and at that time, if you remember, if you were involved, TCP and UDP work, dominant transport, yeah, chatty protocols. And, you know, rough, roughly, low usage of IP. So they concluded, appropriately, that the IP suite is not suitable for space. So they need, we need something different. Therefore we design a new networking stack,

bundle protocol.

Bundle protocol, to me and my that's my personal opinion. Has many issues, one of which is doesn't have any transport semantics. I'll have one slide on this, and then we'll forget BP. But since 2000 we have quick the quick transport, which is really modern, agile, comfortable, efficient. It does one and shake, one, RTT and shake for both the connection establishment and the TLS, the security its user space. Directly manage mobile. We try many ways to handle mobile at the IP layer and really the right places that transport. It has all encrypted end to end transport, and you can have all limited request response streams applications over the possibly very long testing connection. So this is very different. And you know, as a is a key component of of the work. The other thing is, we know how to handle IoT. And IoT means essentially, low bandwidth, small memory, slow CPU, energy efficient devices. That's pretty much the same requirements of space, right? So we can do for IoT, it's essentially the same requirements. So we did with a team of people, reassessment of IP in space in 2002 and and here we are. So the first question usually I'm getting for this presentation is, how do they compare? Obviously, we could do a whole presentation by itself. And, you know, please be careful. This is just a, you know, an overall idea. If we want to debate, I'm happy to do, but I'm getting every time. No, it just makes sense. How do they compare? So here's the one slide for for the comparison. And inside it, instead of going into too many features, I wanted to have a describe a bit the design of the architecture. And here on your left is, is is the an extract of Steve daring plenary presentation on IP hourglass that makes the case of internet, not IP. Internet layer with global addressing, virtualize the network to isolate any kind of end to end protocol from networking detailed or changes different link layers, maximize interoperability, minimize the number of in service interface, exactly what I was saying just a minute ago. Narrow Internet Protocol, so very thin, very the least amount of network functionality maximize the number of usable networks. And I would say it's a layered architecture. Each layer does its job, and hopefully well, and intermediate nodes, because it's very simple, you know, layer three protocol, they can forward very fast by having limited functionality to process and implement right. On the contrary, BP suit not have a transport therefore, in the BP protocol suite, there is no congestion control, no flow control, all we are doing or duplication recovery, no end to end, loss recovery. Only thing that on the last side is the designer up by up. But the problem is, if one up goes down and you know, kind of drop the packet, then you're the packet, or actually the bundle. At that time, the bundle just is us forever, because the endpoint don't have the copy anymore, and there is no transport security. TLS, BP suite has very few applications, and one of the reason is deploy developing in the BP application, and I try that essentially requires to re engineer transport, right? So you have to, you know, handle congestion, flow control, reorganize all those things. Has to be done by the application, and it's not standardized. And from the design point of view, BP engineering essentially is trying to make the network layer fatter by adding more features into it. And one example, the recent example is adding bundle sequence numbers and extension blocks, or editors, extension editors, if you want. And that's for kind of a starting to look at the transport, you know, kind of a identifying a sequence number so you know when, which one you lost, right? So another thing is on by design, is BP nodes as permanent ID. So this is our typical IETF discussion on application versus, you know, permanent ID. And there's so the drawback of this is there's no possible way to aggregate Brooks and mobility means then, if you go to another place, bundle protocol agent, move to a different place in the network, then you need to somewhat advertise your notification to the whole network, or at least to your peers. So anyway, so this is a short summary of difference between BP and IP. What needs to be done on IP suite for deep space. Obviously, this is kind of a symbol, but it centrates You to the key points. If you think about the IP protocol and UDP and even ihtp, they have no notion of time. There is nothing to do an IP packet or UDP datagram or HTTP request could could be for a year, right? There's no in within the protocol. There's nothing here. HTP has a few editors that are related to time, mostly about caching or life cycle things. But if you don't use them, then an HTTP request can be in flight for a year. However, for So, what you have to do is for forwarding devices that are facing intermittent links. So for example, if you remember the the small drawing, the the forwarder that is on earth that is facing, talking to the orbiter, and sometimes, oops, the orbiter is out, and then it comes back. And in a typical IP forwarder sense, you will lose the route to the destination because the link is done, and then you will drop the packet in space, because you expect those to happen. You store the packet at the forwarder, but only the forwarding devices that are facing intermitted links, routers behind or routers elsewhere, need to do this. It's only the forwarding devices facing intermitted links. Storing packets is not difficult to do. It's the same we did it 500 lines of C code, and we did another version on rust. It's not a big thing to do. Obviously, our implementation is not, you

know, you know, for

the commercial hardware vendors will do way better than this. But to tell you, you know, it's not rocket science. We don't need to do any for storage of packets on the surface of celestial body where there's a G or 6g network or Wi Fi. We don't need to do storing packets if they are the orbiters or the gateways are layer two, because they don't know about IP, they just forward, based on their information, like a bridge, right? Like a switch, layer two switch, and that's what is being done by the Mars orbiters. There's four Mars orbiters currently, and they do this actually. This is layer one, but roughly the the store packets, but they don't. They store bits, right? They don't know about IP. Now, obviously the end nodes that are not forwarding don't need to store only very space edge, essentially, the those forwarders as to store packets instead of dropping packets. Second is you need to, if you need to deliver end to end reliability, you need to configure transport based on a deep space profile. So you need to do the right set of values for timers. You need, you should, one way to do it is to the intermittence is not directly seen by the transport transport, it's just a long and variable delays. Well, that just that sentence, you know, obviously, for people, you know, experts in transport, there's a lot of to say about it, but let me be simple at this point and if given that the RTP, RTT is actually changing a lot with large values and small and stuff, so you need to not rely on typical RTT for internal calculation. So on the application side, you don't have to do much in the sense that it has to be an asynchronous design, which is typically what good web app is currently doing. And, you know, I just cameras, obviously you don't expect a response within a second. It will take more time. Having said that, that doesn't mean that a typical web application will be ready to go for space, because you see, there's a lot of assumptions about traction, right? So be careful that's we're not envisioning, but we're vision minute mission and science based applications, not know we call the web applications. This is kind of the Deep Space protocol stack, IP protocol stack you have on the bottom the layer three, layer two, which are CSDs, space links, Wi Fi, or GTP, or any kind of Ethernet. 211, or two, three IP, UDP TCP doesn't work in this environment. For UDP, you could have co app, which is an IoT based protocol, similar to HTTP semantics, good. You may be able to run an NTP, SNP, media apps over UDP. You can use QUIC, which runs over UDP, which includes TLS, and then over it. You can use media like mock. You can tunnel like mask. You can have apps over quick directly, or you can have apps or media over HTTP over quick. That's kind of a the overall protocol step be in your mind is, does IP actually work in Deep Space? Well, let's put in test. One is like 1.5 seconds, so it's kind of too easy. Let's do Mars. Here's a simulation of Earth to Mars via an orbiter. The simulation is an HTTP over quick request and response quick stacks. There were two different quick implementation. Use the obviously, as I said, you set the proper timeouts, the proper values. And for this simulation, we use the where the two planets are nearest. So four minute, one way, delay, by the way, if you ever do those simulation using tcnet M, which is on Linux, be careful, because before they were not supporting more less than they were not supporting delays more than 270 seconds. But after contacting the maintainer, you made a patch, and now you can essentially simulate to multiple galaxies away. In this simulation is a Dark Earth Mars orbiter and Mars asset. There's no intermittence. The HS here means the one, RTT and shake with quick. Then you do the request and response, and then you do connection close. You see connection close here is not needed in reality, because you can keep the connection forever for additional requests. Obviously, I know that you cannot go in details about the wireshack, but I guess you could look at it offline. So this was without intermittence. Can we do? Does that work with intermittent such as orbiter with blackout? So same kind of environment, but now orbiter is as an intermittence of one hour times, and we submit two times, and we send one request every 15 minutes. So some will pass, then some will will happen to be during the intermittence. What happens if you look at the right side, that when there is, you know, orbiter is no more available, then we will be, or it will or it doesn't see the asset, then the orbiter will store the packets, receive and will wait until the asset is visible, send the packets to the asset. And maybe the asset is not, is seeing the orbiter, but the orbiter now doesn't see the Earth, so it's the storing packet. So I guess you understand what I'm meaning errors that we're demonstrating, storing and so again, this is the Wireshark Well, the gap shown with Wireshark, and you see on the left the arrows on the top showing every 15 minutes sending a request, continuing. Then the middle of the slide, you'll see that the if you look carefully, that there's no reply back, because the orbiter is actually storing the packets. Well, I showed the few minutes delays. Longer delays possible. Well, we tried in simulation and HTTP request to Voyager 18 hours, one way delay, dark, linked to the Voyager node. HTTP over quick. And you know, it just works. You just need to make the to apply the right values for the timers in the Quick establishment connection API. About packet loss, let's write percent packet loss over a long delay. So delay of 24 hours and 5% packet loss. So what we did here is we essentially repeat 10 times HTTP request and response in the same connection full time was actually the same as without packet loss, because over the time of the whole simulation, the packet loss was randomly done on the server side, and then the client detected and then retransmit before the whole set of requests and response were done. So, in fact, and we didn't try to do this is just what happened so. But the key point here is quick, recovered successfully. Now, data into N were probably properly sent reliably. Connection may a quick connection, generally last seconds, minutes, hours, days, weeks or months. There's no limitation on this. And within a quick connection, which is really new here as a transport is you can have multiple requests and response carried out by either the client or the server or both, right? They can initiate each way. They can be direct, directional or unidirectional. You can have multiple protocols or applications running within this client connections like a virtual pipe, right, where you can have HTTP requests and response, but also video streaming coming from one side, work, management queries, whatever. That's very powerful for especially for space, because for space, given that the connection establishment can take like, 40 minutes, you don't want to do this all the time. You want to. Would highly prefer to get a connection done initially, as soon as possible, then keep it good, good forever, or the most longer time. But if, whatever reason, the connection dies, then the margin cost is one, RTT, and you're back on track. And if you don't need reliability, then just use a pure UDP

about network management, Qs, streaming, and the list can be, you know, can grow, whatever. The good news here is we have a whole bunch of protocols and applications protocols that are available in the IP suite. The question is more, which one works. Which means which one needs to be profiled, which one needs to be, you know, modified. So, for example, for network management, we we simulate SNP and send MP, get an SMP, get over UDP, just works fine. No problem. You just need to set the if you use the for all the friend, SNMP, DN, so in SNMP get you set the timeout properly and just works. Or you can use Netcom for Escom for QUIC, conf being HTTP, can run over QUIC NETCONF directly over. QUIC is a draft that is a working group item of the net conf working group. So that's possible to hear Qs. We can, you know, use our old IP Qs traffic engineering toolkit you can, you know, work based on service, destination, address, diffusers, OhH, sorry, that was DiffServ marking, port, service, Flow Label all the toolkit, gaming. You can use DNS, but be careful, because you don't want to have DNS queries going back and forth on the Deep Space thing. So we'll use DNS locally on the social, social body network on Earth. And then you make sure that you synchronize the you know, whatever you know, architecture or deployment scenarios you're using. Make sure that the DNS queries don't go through space, because they will take much time. We have emergency messaging is key for space, for search and rescue, for anything about this, we may be able to use, reuse those framework we have time distribution. We may use NTP. RY simulation seems to be working for NTP, but more work has to be done. We're currently looking at this and we could do media streaming over RTP, media over quick, or everything. So it's just a small list, but the key point here is we have a whole set of protocols that can be reused. Needs to be verified or assessed for their use in space they may not be possible. You know, as is one thing about possible deployment scenarios. This comes back again and again. We can do end to end. So, for example, an application on Earth, and then through the whole links and everything, to an asset, a rover on moon, partly, we can do a proxy based architecture. And one architecture that has been said many times is a space edge proxy. So last order before going to space, and the first order on, for example, Moon that received from space, those act as proxy at that could be at different levels, right, transport or applications or, you know, whatever. And and then each proxy and also has two legs. One is on the surface side, which is typical standard body. You know, I speed well connected networking, and then the under on the underside, on the Deep Space side, Danny tandels knows more about specific of deep space. May even include College of intermittent right? They made those proxies. They know well, I'm expected that the link to the orbiter will go down in a minute before I'll start doing something, you know, storing or whatever, or signaling back to the the other guys, you know, phase down. You know what? I'm not able so those kinds of concepts can be, you know, think of we haven't worked on this yet. I hope you understand now why we are. We have a working group in the IETF, again, just repeating the charter here, saying even specific of space we need to do for the IP based protocols. We have few work items at the current time, find the specifics what needs to be done. You know, in terms of the RP architecture and protocol profiling, transport protocol profiling and consideration for DNS timeline for the working group, we started this reassessment work, so we're to the TIPTOP working group. A couple of years ago, the Deep Space informal mailingness was started the summer 2023 we had about a year of informal Deep Space site meetings, informal we talk about problem, solution, simulation results. Co app, which is ether compression, SRV six profile study on Mars orbiters over intermittent all this is available if you're interested at this link, there is a last fall we had at the Dublin IETF. There was a working group forming both presentations from or about China space agency KDDI, a provider in Japan that is planning to offer services communication and network services on moon NASA, about NASA lnis and internet plans and proposed architecture profile working group was formed in February 2025 the Deep Space name was not agreed. TIPTOP name was a suggestion from Wesley Eddie, and I've been told by Silvia again, that TIPTOP means perfect in German, so it's a great confidence coincidence or too difficult expectation. At that time, the working group was started and chaired by Padma delay snow. I was been named the technical advisor and delegate and our director is Erik venk from int. First meeting of the working group was in Bangkok last spring. Co chair was added, Zayed, and we talked about use case architecture and quick profile draft. The other topics were pushed for because of lack of time, and we plan to have a second meeting in Madrid. IETF, next. IETF, if you are more interested in documents and what's going on, we have those on the right are the ones from the data tracker. None of these are currently working group docs yet. The use case, IP architecture, free profile were presented in the first meeting, and I listed a few of additional drafts that may be of interest of you if you're interested in learning more. First one IP assessment is the one assessment back and then gales Gomez wrote something about CO app over in Deep Space. Christian utmo and I work on quick in space. Tony Lee worked on addressing an address space for space, and there's work recently about quick compression, other compression from the Schick people, okay, and that's about the last slide I have. Well, a couple of more, but in terms of real content, so it's obviously in surface. And when I was talking about transport, this is probably where we'll spend most of the time, because that's where it's it's more injuring to do, let's say. And as you may understand, but I haven't too much, just a bit. IP and BP designs are really different, but they essentially share very similar difficult topics, like, for example, routing on a large scale. I used to say, when we will have 10,000 spacecraft all network on Mars and Moon and Jupiter, we may need to revisit routing in this context, right? Right now, kind of sample we can manage with, you know, basic stuff. But how would would we be advertising changes in time? Right? Given delays and disruptions, do we properly because all those schedules of Orbiters going off can be all calculated, right? So we can use that knowledge to actually do better entering but so where do we put those schedules knowledge, right? Do we use it and what happens if schedules are not happening as you know, as as it should be, right? And in space, this happens often. I'll give you an example.

When we were looking at the Maras data. For us is the Mars communication window database. We saw that Naveen, one of the orbiter was there was no link used at one of the pass over the rover. And so I sent an email to the manager at GPL, and he told me that the problem, which happens often or sometimes, is that the rover battery was not enough to actually do communication. So they had to get that link window because battery not enough energy, right? So even if you schedule that to communicate, you may not so if, whenever we input schedules in, you know, protocols or nodes or whatever, we need to be careful with that being fragile, things don't happen as it should be. Oh, do we handle congestion right when typical signaling or finding or guessing there's congestion may happen kind of too late, right, when it's far away, and especially if your store packets. Well, it's not really congestion, as we know, right? It's kind of variation of it. So we should not declare congestion if it's just stored right? How do we handle, you know, storage itself, right? To prevent full storage, and then you need to drop packets, and all these are kind of common to BP and IP. How do we properly prefetch our cache data? For example, key validation chains. If you want to validate some certificate, you know, on moon or Mars, you don't want to do queries back to earth about, no, and do queries of the whole validation chain, right? So therefore, you need to, kind of cache this. This is similar to DNS, also, which needs to be cached, right? So there's, this is where you need to, you know, cache data. And, you know, by the way, there's a proposal for an i RTF research group for space. That's my Acknowledgement Page, which you know, want to go through all of this. But many people have contributed. People here, not every name here, not everybody agreed that we had very good discussions. And the last slide, Internet Protocol Suite in deep space is being discussed in the IETF working group to make it work, store packets, configure transport with a spice Space profile, and for applications mid modified timeouts, URL for IETF working group, some documents, and thank you very much for

for attending. Thank you so much. Questions, yeah, thank you so much. That was that was very, very interesting. So, so you know what, anybody who would like to talk, we have power about 1010, minutes, you know, please raise your hand and let's see if we can unmute you. Maybe you can help me. But from watching the chat, seems there's, there's a couple of threads going on mark one thread has to do with retransmission, and there are people saying that because bundle protocol is you is used in terrestrial cases, I think They were using like nomadic tribe and such like that. Where, where I think that it was. It seemed to me, it was like the hop by hop Act were, were pertinent if, whoever it was, you know, if any of the people interested in that conversation would like to jump in if I'm not stating this correctly, please, please do that. Yeah, but

since you know, we started to do this work, I all the time was refraining, trying to compare the two. And see, I think, the different designs. And you know, there's pros and cons in each design, but every time. And you see now that people, you know, want to, you know, talk about bubble protocol design. And so we had discussions on, on, maybe writing a draft on, you know, comparing both details and probably take, like a whole, you know, presentation by itself. So, so back to retransmission. So when we started to look at Quick, it was surprising that, because it's a really modern design that, you know, we were looking at, okay, how does that work? And then, well, it actually works the way they would design. It was, you know, almost like right way you could think. And I'm not a transport expert, so I'm kind of a I'm at her ear, but so for example, just to go into one example of quick, again, we could have the long, you know, conversation on it. I expect to be, you know, soon, in the working group. So if you're interested, please come quick. The way loss is actually handled is, let me, I don't know, I guess I probably unshared, or did I share?

No, we can still see your screen mark, okay, whatever. So,

so quick machinery for loss detection is based on Haq, and one way is that there is so if, if you have received an ACK for a packet, which is, should be later, actually later than one, which you don't have. And then you wait for a certain number of packets not receive. And the typical number is three. This is like based on, you know, 40 years of experience with transport to TCP, then, then you declare it, you know, kind of loss, and then you retransmit, right? So that's kind of an example of quick machinery, which not depends on time, but more on the behaviors of acknowledgements, right? So that's, that's that's the example I showed of the simulation of packet loss was exactly that. Because what happens is the machinery, the quick machinery, found that, Oh, okay. One, I haven't got the hack, but, you know, a few, I receive a few packets since then, and they're all fine. So declare less transmit the thing about time, the second way that packet less is done in quick is or therefore transmission, is it time based? And then that's where. And it's kind of the, not the second way, but the other way. And then that time, you need to be careful with setting the right thing, and it's essentially based on calculations based on RTT. So back to the presentation I made a while ago. Be careful, because the RTT can change a lot. So things like that. Third thing is a quick actually, do not resend the packet. It actually, if you read RC 9002 you'll see that it's actually smart, because Qwik is actually doing frames within packets, and the packet as you lost, you don't necessarily need to repeat everything. So you will actually create a new packet, but only with the thing that really needs to be sent. So it's very, very efficient. Only fi answer the question, but we can spend another

Thank you, Mark. That's very, very interesting. I mean, I mean, I think the whole thing that what you're discussing about selective ask, and then the way, even RTO and RTT, all that works in CP, very similar questions that we've all been struggling with for many, many years. And you know, of course, there are their applications that are that retransmit too quickly, overly reactive, and causes more problems if you overly reactive. Yeah,

continuing to what you just said, here's the thing here, please do not try quick, you know, non configured quick, you know, stack or client over long delays, it will not work

well. You know, you know Jannah. You know Jannah. Iyengar Jenna was he spoke to us about quick, I think it was maybe last year or something like that. And what he was saying is, in India, is lot of the villages people doing streaming video in villages. He says Quick is so much better. You know? He says it's recovery from loss much better. Which makes me think, but actually, to get back to the other question, fundamentally, I think the question was about re transmitting over multiple hops. Now I am not getting my head around. What are these multiple hops like? Do we actually have, like, multiple routers in space, or is it a point to point link? You see my question, okay,

good point. Most are point to point links. They may have multiple ops, but I think what you're asking here is, is that, remember the slide I made about, you know, kind of a IP hourglass and BP, and, you know, in my opinion, as BP is more, kind of fatter, because it includes more stuff within the network layer, right? So, the way BP design was is to really, there's no Connect. There's no notion of connection or state between endpoints and stuff. It's there's nothing about that. There's no transports managed. So what happens is really kind of a up by up thing. So in BP, you there's a optional service or feature which is, which is called custody. So what happens is the previous up being a bundle, send the bundle to the next up, then the next up will kind of tell the previous up. Okay, I got it. I take custody, you know, or and then the previous app can just release the memory of that bundle, because it's guaranteed is there, right? So that's kind of a design that is up by up, right? I'm saying here is that IP has a different design, which is IP. IP itself kind of assumes that the network below can be unreliable and and doesn't matter you losing a packet is not a big thing. Then you rely on the transport to actually recover whenever you need to retransmit that data, right? And that's something I said a few minutes ago. The position is, in some ways, the transport becomes the I think, to me, my opinion, the transport should be essentially unaware, completely unaware, of intermittence or anything happening, right? It's just end to end. You know, the other party didn't receive something. Well, all we transmit. And the good thing is TCP was, you know, we would need to redo TCP again if we want to do Cp over space. Well, why we would do this? Given that QUIC is actually, you know, kind of a summary of all the experience we had for 40 years, and it's mechanics is pretty well for for that use case.

Yeah, is, that's great. Now this is just a wonderful talk, Mark and and you really, really appreciate you coming on, spending your time with us. That's great. And guys, I really all the people who spent all these wonderful questions, I encourage you to join the working group email list, ask those questions there and participate in that working group and do please, if you have other questions that you want, please go ahead and send them to myself or mark, and I'm sure that Mark would be happy to answer and discuss more. So again, thank you all so much for joining, and I believe next time we'll be discussing one of the folks, one of our board members from Akamai, will be talking about some some of the new things going on as far as the whole CDN world. And if you guys have any ideas for more things we should be doing, please go ahead and send, send me or pranit, or you know any of us in the email. And thank you again. Mark, thank you. Bye. You Bye

recording.