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

[[e-mail]]

Thanks, Marc.  A couple of (I hope) clarifications in-line, marked [SB2].

 

Scott

 

From: Marc Blanchet <[e-mail]> 
Sent: Wednesday, April 17, 2024 9:23 AM
To: Scott Burleigh <[e-mail]>
Cc: 朱亦涵 <[e-mail]>; [e-mail]
Subject: Re: [Deepspace] Some questions about the deep space IP architecture

 

Comments using <MB></MB>

 

Marc.





Le 17 avr. 2024 à 11:02, [e-mail] <mailto:[e-mail]>  a écrit :

 

A few remarks in-line below.

 

Scott

 

From: Deepspace <[e-mail] <mailto:[e-mail]> > On Behalf Of Marc Blanchet
Sent: Wednesday, April 17, 2024 7:19 AM
To: 朱亦涵 <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[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?

 

<MB>retransmission is the same problem whatever the network layer you use. Here we suggest that IP forwarding is taking care of the interruptions. QUIC is managing the transport semantics. A different approach.


[SB2]   So you are saying that QUIC is already designed to continuously compute different retransmission timeout intervals for all connections as links are lost for variable, non-recurring periods of time, yes?

 

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.

 

<MB>QUIC is a transport, so it has the necessary mechanisms for handing packets and their related issues. For example, it has a pretty efficient way to do acknowledgements. The timer is set to whatever value is best for the mission/application/… Acknowledgements tells you what is missing. Similarly in BP, one has to rely on acknowledgements to know if a bundle has arrived properly to the destination and some timers to know what to do when the timer expires.</MB>

 

[SB2]     So QUIC just knows how to do this, right?  It sets timers to whatever value is best for the mission/application, while the round trip time is constantly changing?  Actually in BP one does not rely on acknowledgments and retransmission timers; this was an element of the “custody transfer” mechanism of BPv6 that contributed to the general intractability of that mechanism, for which reason it was omitted from BPv7.  In the general case it is not possible to compute an accurate end-to-end round-trip time for transmission over a non-trivial delay-tolerant network.

 

  Do you build some bolt-on stuff that continuously updates those round-trip times, for all nodes in the network?

 

<MB>nope</MB>

 

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

 

<MB>I think you are confusing TCP and QUIC. A QUIC connection is established in one RTT and then it is a state in each peer. Thereafter, all trafic, such as HTTP Request/Responses, media, … goes into streams within the established QUIC connection. The benefits of connections semantics at the transport layer (above IP) is that it relieves the application layer to have to take care of that. Applications are way more easier to develop reliably.  

On the other hand, TCP (and protocols using TCP) is not working in deep space, as you and others have written in RFC4838. None of this deep space IP work is using TCP.</MB>


[SB2]   Actually I don’t think I’m confusing anything with anything.  Protocol engine state is always retained in every peer of the protocol.  If that state cannot be established absent a round-trip message exchange, then we say the protocol engine state is established by connection.  If anything significant about the state of the protocol engine changes, for whatever reason, its re-establishment by connection – a round-trip message exchange – is required.  Now, if you’re saying that re-connection in QUIC is unnecessary because protocol engine state doesn’t change, that is good news.  I am a little surprised, as it seems like an awful lot of Internet traffic is carried by QUIC nowadays and I still find myself dealing with connection losses, but maybe those are all TCP connections.

 

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.

 

<MB>Okay, I was trying to say that the application layer has to do some work, that is not needed if the transport is connection aware. </MB>

 

[SB2]     Still not true, right?  If there are no connections then the application layer doesn’t have to support connection semantics.

 

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?

 

<MB>Again, we are talking about QUIC, not TCP.  See above. </MB>





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.

 

<MB>Well, the more we test this, the more it is showing that it works. I know we disagree, but as we are getting more results, we will show them.</MB>

 

Marc.


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