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

[[e-mail]]

A few remarks in-line below.

 

Scott

 

From: Deepspace <[e-mail]> On Behalf Of Marc Blanchet
Sent: Wednesday, April 17, 2024 7:19 AM
To: 朱亦涵 <[e-mail]>
Cc: [e-mail]
Subject: Re: [Deepspace] Some questions about the deep space IP architecture

 

 

Le 17 avr. 2024 à 09:02, 朱亦涵 <[e-mail] <mailto:[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.

 

[SB]        “Just” more delay, of variable and non-recurring length.  How is this not a problem in retransmission timeout interval calculation?

 

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


[SB]     But the proper timer for the QUIC connection may be changing constantly.  Do you build some bolt-on stuff that continuously updates those round-trip times, for all nodes in the network?

 

(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.

 

[SB]     Why do any connection semantics need to be implemented at all?  We have such a thing as asynchronous communication, e.g., you subscribe to information and when it becomes available you get a copy.  Connection semantics are a luxury, made possible by insignificant round-trip times, that we have gotten used to on Earth but cannot sustain over deep space distances.  Delay-tolerant applications don’t have to implement connection semantics; non-delay-tolerant applications will not be successful over interplanetary links.

 

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.

 

[SB]        That’s not even remotely true.  There are no connections, virtual or otherwise, in Bundle Protocol.

 

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.


[SB]     Another way of saying this is that you lose one RTT of communication opportunity every time you lose your connection.  Connections in the luxuriantly resourced terrestrial Internet are lost fairly often.  Are you suggesting that connections will be easier to sustain among spacecraft communicating over interplanetary distances?

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.

 

[SB]        DTN is a term of art.  It has not yet been demonstrated that IP can achieve DTN architecture, originally articulated in RFC 4838.

 

(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.

 

[SB]        Here you are correct.  Delay-tolerant network protocols don’t erase delay; applications must be delay-tolerant as well.

 

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.

 

[SB]        Applications that expect Internet-like network behavior over deep space links to be preserved if they merely adjust their timers are doomed to disappointment.


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


  <https://img.zone139.com/Upload/Photo/CommonHeadImage/E69CB1/E69CB1_5792c9.gif> 

朱亦涵

[e-mail] <mailto:[e-mail]> 

  <https://smsrebuild1.mail.10086.cn/addr_p3_gw/qrcode/ContactsServlet?type=3&name2=JUU2JTlDJUIxJUU0JUJBJUE2JUU2JUI2JUI1&email2=MTM5NjE2NzM3NzclNDAxMzkuY29t> 

扫一扫,

快速添加名片到手机

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