Re: [Deepspace] Some questions about the deep space IP architecture

[Marc Blanchet <[e-mail]>]

> Le 17 avr. 2024 à 09:02, 朱亦涵 <[e-mail]> a écrit :
> 
> Hi,
> 
> I am very interested in the deep space IP architecture proposed in the mailing list

Great!

> and am currently conducting some research on it. However, I still have some points that are unclear to me:
> 
> (1) Does the QUIC layer need to handle intermittent connectivity specifically?

Currently, we don’t think so. It is handled at the IP forwarding layer. For QUIC, it is “just” more delay.  

As described in draft-many-deepspace-ip-assessment and also discussed on this mailing list, one may also look at a proxy-based deployment where proxies are on the space edge and maybe those are “more aware” of delays and intermittent connectivity. But I’m not aware of someone who tested it.

> Considering three nodes h1-s1-h2, within the first minute, only h1-s1 is connected; in the second minute, neither is connected; in the third minute, only s1-h2 is connected; or even in more extreme scenarios, is there a possibility that QUIC cannot establish a connection at all?

If you set the proper timer for the QUIC connection, then this is well handled. See my presentation at the last IETF meeting where we describe which QUIC parameters were set. https://deepspaceip.github.io/meetings/ietf119/ietf119-brisbane-deepspaceip-whatis-update-testbed.pdf page 9

> 
> (2) Even though we have implemented store-and-forward at the IP layer,

Great! Which technique have you used? Would be great if you present it at the next deepspace IP meeting. 

> we are faced with a problem: if two nodes are transmitting data for the first time, we might need one RTT to establish a connection and then transmit data,

Yes. 

> a process not required in the DTN architecture.

Of course, because there is no connection semantics in the bundle protocol. Therefore all those connection semantics have to be implemented within each application. If one is using IP with a connection-aware transport such as QUIC, then all this work is done by the transport and free up the application layer (and developer) to make mistakes and to handle complex cases such as loss, reorder, duplicates. And in fact, a reliable Bundle protocol application would probably have to do an RTT anyway to establish a ‘virtual’ connection between the two peers.

One possible deployment scenario is to establish the connection before the spacecraft leaves Earth since one would need to “talk” to the spacecraft on his way to the destination. Therefore, in fact, the connection will be established way before going to space. With QUIC, you can have a connection lifetime almost infinite with almost zero penalty, therefore you can keep that initial connection opened.  In the case of connection loss for whatever reason, the cost is one RTT.

> However, I believe that for subsequent connections, this process is not needed in QUIC either and it directly transmits data, consistent with the DTN architecture.

I think we should rephrase this. DTN means Delay (and disruption)-tolerant networking. This is the use case. It does not indicate the networking stack. Now, we can achieve DTN architecture using either BP or IP. 
> 
> (3) Regarding the issue of intermittent connectivity, would the application layer also be affected, even if we use existing QUIC-based applications? Are these applications incompatible with QUIC in deep space and the deep space environment?

Look again at the slides above. Application layer, as with bundle protocol, has to be asynchronous in design and have appropriate (large) timeouts. Application layer does not see any interruptions, it just sees delays.

An overarching design consideration with the IP stack is the layered approach: each layer is responsible for its own “business”. Therefore, a layer below taking care of an issue makes the layers above agnostic and not taking care of that issue. IP forwarding is taking care of interruptions. QUIC is taking care of delays (both real and induced by interruptions). Applications need to ajust timers and be asynchronous.

> 
> My understanding of the deep space IP architecture may not be very deep yet. These are some doubts I have in my research process.

No issue. Please continue sending questions.

Regards, Marc.

> 
> Cheers
> 
> Kathy
> 
> 
> 朱亦涵
> [e-mail] <mailto:[e-mail]>
> 
> 扫一扫,
> 快速添加名片到手机
> -- 
> Deepspace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/deepspace