Re: [dtn] [Deepspace] Fwd: New Version Notification for draft-many-deepspace-ip-assessment-00.txt

["Alberto Montilla (SPATIAM)" <[e-mail]>]

Thanks Dean for your reply. Please see below some comments/answers to your questions.

Regards;
Alberto

From: Dean Bogdanovic <[e-mail]>
Date: Tuesday, October 3, 2023 at 9:33 PM
To: Alberto Montilla (SPATIAM) <[e-mail]>
Cc: DTN WG <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Deepspace] [dtn] Fwd: New Version Notification for draft-many-deepspace-ip-assessment-00.txt

On 3 Oct 2023, at 16:35, Alberto Montilla (SPATIAM) wrote:

> (resending to the deepspace mailing list)
>
>
>
> Comments on [Deepspace] IP Assessment document.
>
>
>
> Hi Marc, Christian, Dean;
>
>
>
> First of all, thanks for your draft. It has certainly ignited engagement which is always good. It took me a while to read the draft (and the discussion) to the point I think I have some comments, questions and concerns. Please find them below.
>
> Relative to the abstract and introduction.
>
>
>
>   *   You mention “RFC4838 reports an assessment done around 25 years ago concluding that the IP protocol stack was not suitable for deep space networking.”
>
>
>
> I would suggest you change “was” to “is”. The reality is that, in general, the IP protocol stack “is” not suitable for deep space networking. I hope we can all agree here that the IP protocol stack(s) (BTW there is more than one stack considering the different transport protocols available, and the fact that there are two IP protocol versions) are not suitable “as is” for deep space networking.
>
>
>
>   *   You mention “This document revisits the initial assessment of rejecting IP...”
>
>
>
> I would suggest rephrasing this to “This document proposes modifications to the IP protocol stacks to overcome the limitations identified when applied to networking at interplanetary distances (aka deep space)”. IETF is not an authoritative/regulatory body, there are multiple options to achieve the same thing, and this proposal is not challenging the assumptions and requirements expressed in the DTN BP literature but more about how to adapt the IP protocol stack.
>
> I would suggest you look at all instances you mention “rejecting IP” in the document.
>
>
>
>   *   You mention “IP in deep space means running IP over deep space layer-2 links, a reliable transport over IP, applications protocols over that transport and applying proper routing, security and network management on that IP network.  Reusing the whole IP stack in deep space enables the reuse of all protocols, tools and software currently used on the Internet. However, as one might already argue, most of the IP stack cannot be used as is and therefore requires careful configuration and possibly some protocol changes that are discussed in this document.
>
>
>
> I find this text a little confusing, which could mislead the reader, so I offer some suggestions:
>
>  “IP in deep space” means running IP “as the internetworking layer” at interplanetary distances, including, running IP over deep space layer-2 links, a transport protocol over IP, application protocols over that transport, and applying proper routing, security and networking management on the IP network. It is anticipated that reusing the existing IP stacks in deep space is not possible without specific configuration and protocol changes. These specifics are discussed in this document.
>
>
>
>   *   You mention “More recently, space agencies are planning to deploy IP networks on celestial bodies, such as Moon[ioag] or Mars[ioag-mars], ground, and...”
>
>
>
> I would also suggest adding that the SSI networking architecture is currently based on the Bundle Protocol (CCSDS, IOAG Mars) and it is currently a mandatory capability for LunaNet and Moonlight. This is not to compare BP vs IP but to make clear that the requirements of DTN are not being questioned. The way it reads seems to imply “space networks are going IP” ...which is misleading in my opinion.

Alberto,

Thank you for the thoughtful review, editing suggestions above. We will take them into the account for v1 of the draft.

>
> I would also suggest mentioning that several experiments in missions have successfully demonstrated Bundle Protocol in space. Same reason, state that space agencies (and commercial companies) are moving (slowly) but ahead with the BP-based network overlays.

if you could share some use cases, that would be very helpful.

[Alberto]

The use cases range from transferring standard payload TT&C (Command, Control and data intensive telemetry), benefiting from the scheduling and transmission volume capabilities of DTN to transfer non-real time data, and more recently streaming of data (primarily video). The upcoming operational use cases for the Moon are covered in LunaNet and Moonlight, which later are going to be realized in a similar way in Mars.

In terms of the demonstrations, a good starting point is the NASA DTN page where several of the NASA sponsored/supported experiments and missions running DTN: https://www.nasa.gov/technology/space-comms/delay-disruption-tolerant-networking-faq/

NASA, and ESA have their BP implementation(s) which has been operationally tested (DTNME, ION, ESA JAVA BP implementation).

Spatiam Corporation is building a DTN Platform to enable DTN (using Bundle Protocol) for Space. There are other companies (of all sizes) moving towards supporting BP.


>
>
>
> Some questions and concerns
>
>
>
>   *   You don’t mention any tangible benefit of modifying the IP stacks to make it suitable to work without the Bundle Protocol versus modifying IP to work as a convergence layer of the Bundle Protocol (it is a very different scope and potentially a simpler problem). I personally think it is important you discuss those in the document. Why? This proposal is a bit counterintuitive to the progress of the IP stack for the terrestrial internet where new protocols are added on top of IP wherever needed instead of modifying IP. For example, for SDN (software defined networking) we are running L2 (VXLAN) over TCP/IP which is basically an overlay. Same as the Bundle Protocol.






>   *   On routing. I disagree with the generic statement that “static routes are enough” or “BGP” or other protocols. I think it is fair to say that routing protocols for deep space is an open and evolving topic, that CGR is there and has scalability issues, and that existing IP routing protocols assume permanent connectivity and/or are chatty. This is a problem to solve. Your argument seems to oversimplify it, reducing the importance of solving this problem to make IP a feasible solution overall.

Routing is the process of selecting and defining paths for IP-packet traffic within or between networks as well as the process of managing network traffic overall. What is selecting and defining path is now the question?
It can be dynamic protocol that is using control channel to send updates between the nodes.
Or
it can be a network management application that is doing that and sending this information to the network nodes. (OpenFlow anyone)

The latter is SDN concept that could be used in space. Developing such an application for topology of 100 nodes with predictable trajectory and connectivity shouldn’t be too much of a challenge.

[Alberto]  Yes, in principle that could work provided the data volume as product of delay and the schedule part of it is incorporated into the routing considerations. This needs to be defined to see how routing tables (and state machines) among other things would change.



>   *   Scheduling does not seem to be considered in your proposal (at IP level). I am curious as to how scheduling would be handled in your proposal.


>   *   Endpoint/Network mobility is not considered in your proposal. Given we are talking about spacecrafts, space stations, this should probably be covered. Is there a reason for that? Mobile IP (and Mobile-IPv6) among other protocols is there to solve the endpoint/network mobility problem, they work on binding local vs global address.
At the moment I don’t see a reason for mobile IP. It doesn’t matter that spacecrafts are moving. They are not changing the domains.

[Alberto] I am not promoting Mobile-IP, however I think there is a need to describe a solution for a moving endpoint and moving network. Very soon, we will be in a multi-service provider scenario in cislunar space. I would envision multi-administrative domains for LunaNet and endpoints roaming across distinct networks (while in motion?).


>   *   On security. Like routing, I think this problem is oversimplified in the document. Key distribution, use of chatty protocols, etc must be solved (for any protocol stack) to say, “it is feasible”. I would suggest that it becomes an open topic.
>
>
>
> My general point of view:
>
>
>
> The Bundle Protocol is an elegant solution to the deep space networking problem, basically because it was built for that purpose. When I say elegant, it is because it can run over many transport, networking and even L2 protocols, which provides a future proof evolution without dictating how the lower layers evolve. This is the foundation of software defined networks.

I would say BP is flexible and would not say this is foundation of SDN.
[Alberto] Reading my opinion twice, I think I could have written this better. Network Overlays (not BP) are part of the SDN foundation, as it enabled simpler programmability via overlays. That’s what I tried to say.

>
> Any protocol stack aiming to provide networking at deep space will end up one way or another having to implement the functionality currently present (and envisioned) for the Bundle Protocol, including the application stack.

use cases are use cases that have to be addressed. And don’t think they will change. It is the cost of implementing it. More and more organizations are looking at cost optimization and are moving from very specialized HW/SW to more generic of the shelf. Space is a different story, as it has big budgets, but still the cost optimization is becoming bigger and bigger pressure.

[Alberto] Agree 100% with more off the shelf. In that regard, BP is an overlay (SW functionality). In terms of costs I would argue it is as optimized as a modified space-IP, but of course, it is probably too early to run any time of comparison on the economics.


>
> It has taken 25+ years to build concepts, architectures, protocols, prototypes, experiments and missions around the Bundle Protocol from which many learnings have emerged, this should not be ignored or minimized.

We are not doing it. We are just putting some new ideas into the open.

[Alberto] Agreed (and thanks for bringing the ideas), just wrote this in the spirit of highlighting that making IP for deep space will require same level of consideration,  work and experimentation.

>
> In the coexistence of the Bundle Protocol and the IP Protocol stack, I believe an elegant (and incremental) solution is to use BP over the modified IP (BP/UDP/IP as example) with IP as a Convergence Layer. This way the IP stack could evolve incrementally. Any further attempt, like the one described in the draft, means replicating a bunch of functionalities already available. To do it, the benefits would need to be obvious, which do not seem to be the case in my opinion given the major modifications to the IP stacks including the applications.

Very interesting point of view and very worth discussing it further.

Dean

>
> Regards, and thanks again for igniting this discussion.
> Alberto
>
> From: dtn <[e-mail]> on behalf of Marc Blanchet <[e-mail]>
> Date: Friday, September 8, 2023 at 6:39 PM
> To: DTN WG <[e-mail]>
> Subject: [dtn] Fwd: New Version Notification for draft-many-deepspace-ip-assessment-00.txt
> Hello,
>  This might be of interest to this community.
>
> Regards, Marc.
>
>> Name:     draft-many-deepspace-ip-assessment
>> Revision: 00
>> Title:    Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions
>> Date:     2023-09-08
>> Group:    Individual Submission
>> Pages:    20
>> URL:      https://www.ietf.org/archive/id/draft-many-deepspace-ip-assessment-00.txt
>> Status:   https://datatracker.ietf.org/doc/draft-many-deepspace-ip-assessment/
>> HTML:     https://www.ietf.org/archive/id/draft-many-deepspace-ip-assessment-00.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment
>>
>>
>> Abstract:
>>
>>   Deep space communications involve long delays (e.g., Earth to Mars is
>>   4-20 minutes) and intermittent communications, because of orbital
>>   dynamics.  Up to now, communications have been done on a layer-2
>>   point to point basis, with sometimes the use of relays, therefore no
>>   layer-3 networking was possible.  RFC4838 reports an assessment done
>>   around 25 years ago concluding that the IP protocol stack was not
>>   suitable for deep space networking.  This result lead to the
>>   definition of a new protocol stack based on a store-and-forward
>>   paradigm implemented in the Bundle Protocol(BP).  More recently,
>>   space agencies are planning to deploy IP networks on celestial
>>   bodies, such as Moon or Mars, ground, and vicinity.  This document
>>   revisits the initial assessment of rejecting IP and provides solution
>>   paths to use the IP protocol stack, from IP forwarding to transport
>>   to applications to network management, in deep space communications.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn

> --
> Deepspace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/deepspace