Re: [dtn] [Deepspace] technical remarks

[Dean Bogdanovic <[e-mail]>]

IP stack has been designed with no timers in mind from very early days. 
The protocol is called UDP.  There is no requirement that UDP datagrams 
be delivered in finite time at all. In other words, it is perfectly 
acceptable never to deliver a UDP datagram.

My main hypothesis:
Network doesn’t have to guarantee packet delivery, let the application 
decide what has to be delivered.

For deep space communication, we have to take an application level view 
of the connectivity, let the application decide about data transmission 
and the underlying network delivers the data. The network doesn’t know 
if data that arrived or is missing is important. TCP takes the 
presumption it is, UDP the opposite.

I can see a scenario where the applications sends all the time limits to 
the routers in space how long to keep the data in the local storage, 
Using QUIC and HTTP/3, the connection is established once and after that 
there is 0 delay to send the data to its destination. No new handshake 
is needed. You don’t need keep alive packets. The application on both 
sides decides for how long it wants to keep listening to it. Even if the 
packets come after the application has decided to discard all the data, 
this can be communicated through the deep space network, so each node 
can drop that type of packet.

We need to figure out a new application design and  network management 
paradigm that is impacted by long delays.

Different applications can define different behavior from the network 
and communicating that information is easier to be done with existing 
frameworks, than inventing something new ones.

Dean

On 25 Sep 2023, at 13:31, Marc Blanchet wrote:

>> Le 23 sept. 2023 à 06:04, [e-mail] a écrit :
>>
>> Well, maybe I am so out of touch with modern Internet standards that 
>> I don’t realize how delay-tolerant the architecture is nowadays.  
>> Here are some of my possibly misplaced concerns.
>>
>> The “late binding” concept built into the BP suite is based on 
>> the idea that connectivity lapses between nodes on an end-to-end path 
>> may be so lengthy (hours certainly; days for some deep space 
>> missions) that the destination node may change its location – its 
>> IP address – while traffic is en route to its earlier address.  
>> Will this simply not happen frequently enough to justify late binding 
>> measures?  If so, can you explain why?  If not, how will Internet 
>> architecture handle these anomalies?
>
> The fact that a node changes location does not mean changing its IP 
> address. QUIC has the IP address and/or port change managed securely. 
> The peers confirm their new IP address/port change by a crypto change, 
> since they already have established a trust relationship in the first 
> handshake. So it is robust to DOS or man-in-the-middle attacks and it 
> works with IP address/port change.
>
>>
>> A related point: will DNS be used across the solar system to resolve 
>> destination names to IP addresses?  If so, will DNS lookup queries 
>> traverse interplanetary links
>
> Should not.
>
>> or will they be resolved by local DNS servers?
>
> yes.
>
>> If the latter, will DNS information be synchronized across the solar 
>> system by zone transfers or something similar?
>
> The ones you need.
>
>>   In either case, are we confident that the volume of DNS 
>> synchronization traffic across the interplanetary network will be so 
>> low as not to significantly degrade science traffic?
>
> As answered to Keith in another email, there is a draft on DNS 
> deployment which is already written and currently reviewed by DNS 
> experts. I’m awaiting a few more reviews and will publish. Up to 
> now, no reviewer got heartburn.
>
>>
>> If a packet arrives at a router from which there is currently no 
>> onward connectivity, it will be retained in storage until the next 
>> onward connection is established, correct?
>
> yes.
>
>> Suppose that next onward connection is never established (maybe 
>> because the next router in the path has been destroyed by a meteor 
>> impact).  The packet is not forwarded, so its hop count does not 
>> increase, so its hop limit is never exceeded; would it continue to 
>> occupy storage at the router indefinitely?  If not, what is the pure 
>> IP functionality that would cause it to be discarded?
>
> This is a forwarding policy/AQM discipline. It is already implemented 
> but again might need to be tuned by increasing timers.
>
>>
>> I mentioned in an earlier email my misgivings about the ability of 
>> QUIC to impose flow control and congestion control over round-trip 
>> times that may be measured in hours or (if exercised only at the 
>> source and destination) days.  I think those are still open 
>> questions.
>
>>
>> Are QUIC retransmission timeout intervals going to be learned over 
>> time by measuring the interval between transmission and 
>> acknowledgment of several packets, or are they going to be provided 
>> by management (e.g., known one-way light time as determined from 
>> orbital elements)?  If the former, won’t it take a long time to 
>> figure out the correct timeout interval for retransmissions if the 
>> round-trip times are measured in hours?  If the latter, is that 
>> capability already defined in the QUIC specification?  And does it 
>> include automatic adjustment of the timeout interval when the end of 
>> a period of bidirectional connectivity is reached?
>>
>> The automatic securing of QUIC connections by TLS is terrific, but it 
>> is only in effect while the packet is in transit, correct?  That is, 
>> once the packet has reached its destination it is no longer 
>> protected?
>
> Well, it is decrypted by the QUIC stack at the destination and then 
> pushed to the application. Like TLS today. I’m not sure I get your 
> point here.
>
>>   This is fine if the QUIC destination is the packet’s final 
>> destination, but in that case the packet retransmission timeout 
>> interval at the source becomes hard to compute: the packet may reside 
>> in storage at one or more routers along the path for various periods 
>> of time, which can only be determined if the entire path to the 
>> destination (not just the next-hop router) is known at the moment the 
>> packet is sourced.
>
> I’m not parsing you here, specially: "the QUIC destination is the 
> packet’s final destination »: it is always the case, unless you do 
> some proxies. And even that, the last leg of the last proxy will be 
> the packet’s final destination. So I’m not sure.
>
>> If, on the other hand, transmission along the path is accomplished by 
>> a string of QUIC proxies as suggested in the deepspace-ip-assessment 
>> draft,
>
> Actually, the string of QUIC proxies was discussed but not 
> recommended. I’ll look again at the text. It may be useful in some 
> deployment scenarios, but we don’t need it.
>
>> then the packet will be delivered by QUIC multiple times while 
>> traversing the path.  In this case it might be resident at multiple 
>> routers while awaiting onward connections and, while resident, would 
>> not be protected by QUIC/TLS.  Does this mean that additional 
>> application-layer security is always going to be needed for all deep 
>> space IP traffic?
>>
>> (A note on your remarks regarding LTP: you say that “to get its 
>> benefits, one has to make sure that all links are using LTP.”  That 
>> is simply false.  Every hop on a BP end-to-end path can use a 
>> completely different convergence-layer protocol.  The ability to 
>> exploit – and/or adapt to – the different characteristics of 
>> different types of links on the end-to-end path, instead of expecting 
>> a single set of communication properties to hold everywhere along the 
>> route, is one of the advantages of the BP architecture.)
>
> Sorry, I should have rephrased as: every link should have a reliable 
> transport under BP to achieve an end to end reliability.
>
>>
>> I understand that HTTP itself can be operated in a RESTful manner, so 
>> that it is no longer a client/server protocol – very helpful!
>
> Well, it is a client-server protocol. RESTFul does not change anything 
> about that.
>
>> What about HTTPS?  Will HTTP always be run over QUIC, so that it is 
>> always automatically secured by TLS?  Or will TLS handshakes be 
>> necessary when establishing a HTTPS session?
>
> See QUIC (RFC9000, RFC9001,…). QUIC includes TLS and TLS is 
> negotiated together with QUiC parameters in a single RTT. QUIC can’t 
> run without TLS.
>>
>> I understand too that, thanks to zero-RT, only connection to a new or 
>> re-located peer (new IP address) or to a socket with a different port 
>> number would force a QUIC connection handshake, resulting in a 
>> communication hiatus of no more than 40 minutes at Mars, assuming no 
>> data loss.  You are certainly correct that new spacecraft are not 
>> likely to be added to the network very often, but of course not all 
>> nodes of the space network are going to be spacecraft – ground 
>> nodes are going to be included in the network as well, right?  Those 
>> are likely to cost closer to $2000 than $100,000,000, so there could 
>> be a good many of them, with new ones added frequently.  Also, 
>> wouldn’t applications running on spacecraft open new sockets 
>> relatively often?
>
> A QUIC connection can be established between 2 peers for an almost 
> infinite amount of time, say for 2 years if you want. A QUIC 
> connection enables multiple streams (connections/sockets in the 
> traditional TCP/UDP sense) to be carried over that « pipe ». So one 
> can have multiple applications, using HTTP or anything, still carried 
> over a single connection between 2 peers.
>
>>
>> How would files be transferred over deep space IP?  Would we use FTP 
>> and SFTP and TFTP as in the Internet?  If so, don’t we pay for a 
>> connection handshake (1 to 3 round trips of up to 40 minutes each for 
>> FTP, more for SFTP) whenever starting a session, plus a 
>> query/response round trip for each file?  If not, what will we use 
>> instead?
>
> File transfer can be done in a myriad of ways. Nowadays, if you 
> transfer a file over Internet, it is ~98% over HTTP.
>
>>
>> Establishing an SSH session requires a multi-round-trip handshake, 
>> but maybe we won’t need SSH in the deep space Internet?
>
> SSH is an example of an interactive application protocol not well 
> suited for space use. As you know, SSH, like Telnet, sends each 
> keystroke in a single packet. I’m pretty sure no one was planning to 
> have that kind of application over BP, because it does not make sense. 
> So don’t use SSH as is. However, one can configure SSH to send the 
> line in a single packet (aka after the CR/LF). That would be more 
> possible, again like any application protocol, if you configure the 
> timeout properly. In a line mode, it would be similar to Command and 
> Control currently used.
>
>> Will we just use RESTCONF instead?
>
> That is one possibility yes.
>
>> Does RESTCONF let you do everything you’d otherwise do with SSH?
>
> RESTCONF can be more compared to DTNMA. So BP will be managed by 
> DTNMA, IP will be managed by RESTCONF.
>
>>
>> I think we’re going to want to send email over this network.
>
> Great!
>
>> Do I understand correctly that SMTP, POP3, and IMAP require 
>> connections, and POP3 and IMAP servers deliver mail only in response 
>> to queries, all of which require round-trip exchanges?
>
> This is more a deployment discussion than the actual protocol. But I 
> remember that we did not discuss it in the draft, so I guess we should 
> add it. In a nutshell, the deep space links are just one link. SMTP 
> can be carried over and then mail sits in the mail server on the 
> celestial body network infrastructure. The user then just use regular 
> IMAP (or even web-based mail) locally on the celestial body.
>
>>
>> How about RTP, DHCP, NTP?  Will their session establishment 
>> procedures work over interplanetary signal propagation delays?
>
> Good questions. As the draft says, there is a need to assess various 
> application protocols to see which one: works as is, works with an 
> adjustable timer, does not work, needs a protocol change, …  From 
> your list:
> - RTP:  I was surprised to see that space agencies in CCSDS have 
> standardized RTP over BP. So I guess if RTP works over BP, it shall 
> work over IP, but I haven’t looked at it.  Cisco and Lockheed Martin 
> have made a presentation on 2-way videoconferencing in space a few 
> IETFs ago. One should look at it.
> - DHCP: I see no use for DHCP over deep space links. Could you tell me 
> why you need it?
> - NTP: interesting question. On celestial body networks, no issue. 
> Over deep space link, don’t know. Question is do we need it. How is 
> time sync done in BP?
>
>>
>> I’d also be worried about the routing protocols – RIP, OSPF, BGP. 
>>  If routing in the deep space IP network is going to rely on current 
>> information about the topology, as in the Internet, won’t we see a 
>> lot of routing errors due to lengthy delays in the arrival of new 
>> information about discovered topology changes?
>
> Yes. Again, TVR wg is looking at this problem. And this is written in 
> the draft.
>
>>
>> There are probably a few other issues I would need to understand 
>> better, but this is all I can think of for now.
>
> Thanks for taking the time to review the draft.  Hope I answer your 
> questions.
>
> Regards, Marc.
>
>
>>
>> Scott
>>
>>
>>
>> From: Marc Blanchet <[e-mail] 
>> <mailto:[e-mail]>>
>> Sent: Tuesday, September 19, 2023 11:29 AM
>> To: Scott Burleigh <[e-mail] 
>> <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]> ; DTN WG 
>> <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [dtn] technical remarks
>>
>>
>>> Le 18 sept. 2023 à 20:39, [e-mail] 
>>> <mailto:[e-mail]> a écrit :
>>>
>>> Hi, Marc.
>>
>> Well, I’ve been pushing that idea. The actual draft has 2 
>> co-authors. So I guess this should be discussed in general, not 
>> targeted to me specifically.
>>
>>
>>>   To get this started, here are some remarks on the new draft from a 
>>> generally technical perspective.
>>
>> Thanks for your great review. Very appreciated.
>>
>>>
>>> In my mind, the central conceptual premise of RFC 4838 and the DTN 
>>> work that grew out of it is that communication round trips must be 
>>> rigorously excluded from the communication protocols used to operate 
>>> an internet over interplanetary links.  This is because long signal 
>>> propagation latencies and potentially frequent and lengthy lapses in 
>>> connectivity between nodes may make round-trip times so long that 
>>> the information received on the return path is obsolete or otherwise 
>>> no longer usable and/or arrived so late that opportunities for 
>>> further transmission had to be foregone - in all cases, an 
>>> unacceptable waste of expensive communication resources.
>>
>> Right. Deep space has specific characteristics (long delays, 
>> interruptions) that some applications/protocols/… are not designed 
>> for that use case, whatever we use IP or BP.
>>
>>
>>>
>>> That concept was (I believe) the rationale for moving beyond the IP 
>>> stack in advocating for a solar system internet: virtually every 
>>> important protocol in the IP stack (IP itself being the main 
>>> exception) required a handshake to negotiate communication 
>>> parameters, issued data from a server in response to a query from a 
>>> client, or both.
>>
>> We start to disagree. Yes, there are some application protocols (or 
>> some applications) that were designed with the use of instant 
>> negotiations and handshakes.  That does not preclude them to be 
>> unusable in a less « friendly » environment. It depends. Our 
>> initial findings is that it is not that quite bad, on the contrary. 
>> An example. While not all applications we are using on Internet make 
>> sense in deep space (this is an important point), a very large 
>> majority is using HTTP as its « application transport ». HTTP does 
>> not have a notion of time by itself, unless one is using some 
>> specific headers (see the draft for details), in which one should be 
>> careful about the values you put in; consequence is no change in HTTP 
>> needed. And HTTP is used a lot, a lot, in current applications with 
>> the RESTful paradigm, or other variations/enhancements such as gRPC, 
>> …. I verified it: it works just fine as is, if you are changing 
>> default timers in configs of clients and servers. No change in code, 
>> no change in protocol, no change in software. Many/Most? Internet 
>> applications we are using today are not well designed for deep space 
>> use case: of course, you won’t buy a Taylor Swift ticket over a 
>> deep space link (at least for now ;-). But, if one is developing an 
>> application for a relevant use in space, then HTTP is able to carry 
>> your application no issue. That is a big big win for getting any 
>> current developer to develop space applications, reusing many 
>> frameworks in use today. Of course, they need a few best current 
>> practice (some are already in the draft, but obviously not 
>> comprehensive) to be careful to use, for example, a completely 
>> asynchronous design (which is in fact the BCP even for Internet 
>> applications) and be careful about timers. That is mostly it.
>>
>> To summarize, while there are some application protocols that are not 
>> suited for space use case, we have a great framework nowadays that do 
>> work well in this environment with simple but careful config.
>>
>>
>>>
>>> The keystone of your draft seems to me to be the substitution of 
>>> QUIC for TCP.
>>
>> Yes, it is an important part of it. But as you have read the draft, 
>> we looked at the different levels of the protocol stack to make sure 
>> it overall works. Looking into only one piece would not work.
>>
>>
>>> QUIC in itself seems to me quite cool: QUIC clearly accelerates 
>>> connection establishment and solves TCP's head-of-line blocking 
>>> problem.  In the BP world, I think QUIC would make an outstanding 
>>> convergence-layer protocol.
>>
>> When you say QUIC CLA, you mean BP over QUIC over IP. Yes, it could 
>> be defined and it would work. The current design for deep space comm 
>> is to use BP over LTP over space links. So I guess the QUIC CLA will 
>> be used in terrestrial networks (or celestial body local networks) as 
>> a replacement of the TCP CLA. Fine, but that is not the proposal in 
>> the draft. To me, while possibly better, replacing the TCP CLA with a 
>> QUIC CLA for terrestrial networks is IMHO a marginal advantage, as 
>> many of the TCP CLA used today is between space agencies private 
>> high-speed networks. I would welcome the dtn wg to look at the QUIC 
>> CLA. Now back to the proposal, which is not about a QUIC CLA.
>>
>>
>>>
>>> Where the draft goes wrong, I think, is in asserting that 
>>> substituting QUIC for TCP would make the BP stack unnecessary.
>>
>> I for one tried hard to not say BP is unnecessary. I’m more saying 
>> that there is an alternative proposal that may also work. It will be 
>> up to the space organizations to decide which one (or both) they want 
>> to use. QUIC vs TCP is not the full story. It is all the pieces 
>> together that make an alternative to a BP infrastructure.
>>
>>
>>> I think that's incorrect:
>>> Supporting multiple concurrent flows over a single connection would 
>>> indeed achieve the same sort of continuous transmission that we 
>>> already get with LTP, a major plus.
>>
>> We can do pros and cons of LTP vs QUIC. However, it should be noted 
>> that there is an important difference between the two:
>> - QUIC is end to end, provides reliable transport over non reliable 
>> links, TLS security end to end (setup in a single RTT), … so 
>> whatever the number and the characteristics of the links in the 
>> network from one endpoint to the other, it maintains its properties.
>> - LTP on the other end is on a per link basis. Therefore, to get its 
>> benefits, one has to make sure that all links are using LTP. 
>> Applications won’t be able to know that, they just have to believe 
>> it is the case. (For those reading and not familiar, LTP is RFC5326 
>> (Experimental status from the dtnrg time; I know that a new version 
>> is being worked on in CCSDS).
>>
>>
>>>
>>> Also, configuring QUIC for zero-RT would eliminate round trips in 
>>> re-establishing a previously established connection, another big 
>>> plus.  But every connection with a new peer,
>>
>> Given that a typical peer in space costs around $100M, that event 
>> won’t happen often. But even if it happens « often », it is a one 
>> RTT to setup.
>>
>> Let’s say a ground software station wants to establish a connection 
>> to a not yet known device (I have a hard time thinking that it would 
>> be the case typically…) which is on Mars, then it would take a 40 
>> minutes max (1RTT) to establish the secured connection. Time it takes 
>> is not because of IP or QUIC, but just the light time. Given that 
>> typically, these devices last for quite some time, sometimes years, 
>> the actual « cost » of a single RTT to establish the connection is 
>> marginal. Moreover, if you know (which is pretty much the case!) in 
>> advance that you would be « talking » to this device, one can 
>> establish the connection between the two peers before the spacecraft 
>> leaves Earth, therefore it would be already « connected » together 
>> when resuming communications later in space.
>>
>>
>>> or with a peer whose location in the topology has changed, would 
>>> still require a handshake.
>>
>> Only if there is a change in IP address or port. It remains to be 
>> seen how such things (change of IP address/port) will happen « often 
>> » in space. But even, It is a single RTT to confirm securely the two 
>> peers. Avoid DOS or man in the middle or else attacks. Very secured. 
>> Tested on a wild environment called the Internet… ;-)
>>
>>
>>> LTP, on the other hand, can always begin transmission to a brand-new 
>>> or relocated node immediately upon the start of a communication 
>>> opportunity, as the parameters of that communication are always 
>>> pre-established when the LTP engine is notified of the change.
>>
>> Per link basis. QUIC won’t need to care about link status changes, 
>> as it is end to end. The link state changes are handled by lower 
>> levels (aka TVR).
>>
>>>
>>> QUIC, like TCP, thinks that flow control is implemented upon 
>>> reception of transmission authorizations.  Christian Huitema 
>>> proposed asynchronous transmission of anticipatory "flow control 
>>> credits" as a way to make this work in space, and sure, you could 
>>> modify the QUIC protocol in this way.  Just using rate control 
>>> informed by contact plans - as LTP does - is simpler.
>>> QUIC apparently thinks that measuring the link data rate and 
>>> sticking to that rate controls congestion.  It does not.  DTN 
>>> congestion control is a matter of limiting storage occupancy, not of 
>>> matching the transmission rate to the acknowledgment rate.
>>> Christian Huitema's experiment showed that QUIC can indeed convey 
>>> data reliably over 20-minute one-way light times, once you revise 
>>> the code and lengthen the timer intervals.  But that is by far the 
>>> simplest part of reliable transmission over interplanetary links: 
>>> accommodating continuous changes in connectivity, link character, 
>>> data rates, network topology, forwarding rules, and required quality 
>>> of service was not considered in any way.
>>
>> I let that cited person to respond to these.
>>
>>>
>>> Obviously all of this stuff is software, and you can always modify 
>>> software to do anything you want.  It is certainly possible to spend 
>>> some time and money modifying all of the many widely exercised IP 
>>> protocols
>>
>> Again, that I think is a false statement. Not that much of changes. 
>> The draft talks about some « major » IP protocols in used today 
>> (probably for the Internet, covering 99% of the traffic), but also 
>> says that some investigation might be needed for other protocols.
>>
>>
>>> in such a way that you reinvent what is already in the BP stack
>>
>> I would claim the reverse. I found over years that the BP framework 
>> was reinventing a lot of stuff that was already well defined in 
>> Internet protocols. I’ll take one example. I would have preferred 
>> not to compare, but I think we need to. (IP) Network management has 
>> gone through roughly two iterations (I’m oversimplifying here) of 
>> protocol frameworks: SNMP+MIB and then NETCONF-RESTCONF+YANG. There 
>> is quite a wealth of implementations, data models, etc… for almost 
>> every kind of device. One can look at the yang data model github 
>> repo. NETCONF is defined to be used over TCP or SSH: that won’t 
>> work as is in deep space. NETCONF over QUIC is specified in a draft. 
>> But RESTCONF is over HTTP. So right off, you can use everything 
>> defined (including the YANG models being discussed in TVR at this 
>> time) in this realm without changes (make sure you configure in the 
>> implementation the timer for expiration to be longer than typical). 
>> On the other hand, I found DTNMA 
>> (https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/) to be very 
>> complex, to read, to implement, and kind of reinventing the wheel. It 
>> may have its own use, but again, if NETCONF-RESTCONF+YANG works, why 
>> redo? I’m sure Ed will chime in on this. ;-)
>>
>> Another example. We tried some time ago to develop a native 
>> application over BP: there was a project interested in looking at 
>> using BP. From the application perspective, it just pass blobs of 
>> data to the BP node with the destination endpoint id (i.e. « address 
>> »). There is no notion or abstraction of a connection (on purpose). 
>> We end up doing a lot of connection identification, state, payload 
>> ids and managing reordering, etc… in the application layer. It is 
>> difficult to do that right and reliably in an application. And then 
>> if you add the need for security, one has to rely on BP security to 
>> be implemented from end to end and made it « known » to the 
>> application: I don’t know of any BP implementation that enables 
>> this, but I guess it could be done. While QUIC does all this, 
>> including security, for you, free, in the single connection, with all 
>> the certificate/keys framework we are using today.
>>
>>
>>> – eliminating all connections and all client/server interactions 
>>> –
>>
>> Actually, I would, on the contrary, not eliminate any connection or 
>> client/server interaction. I would keep them, but make sure they are 
>> tolerant to delay and disruption. Some of that « dirty work » is 
>> done at the transport and IP layer, so it is mostly invisible to the 
>> application protocols and applications (with some care about timers 
>> as discussed above), which is a big big plus.
>>
>>
>>> and call it IP, and maybe that is what the industry will decide it 
>>> prefers.
>>>
>>> What's unfortunate about such an initiative is that it would sap 
>>> time and resources from development and deployment of a protocol 
>>> stack that we already know will work at Mars without significant 
>>> modification, since it was shown to work at interplanetary distances 
>>> (on the order of 1 light minute, with link outages resulting in 
>>> round-trip times on the order of days), in space, 15 years ago.
>>
>> I can’t respond to this except that I’m sorry to bring this now. 
>> It is also the fact that things/protocols have evolved in parallel 
>> and got, IMHO, an overall better solution. But I understand that I 
>> need to work hard to convince you.
>>
>>
>>>
>>> As best I can tell, the only advantage of the proposed initiative is 
>>> that the IP stack's "implementations have been exercised on real 
>>> traffic orders of magnitude more than what has been achieved with 
>>> Bundle Protocol stacks."  This is undeniable, but of course the same 
>>> could have been said about SNA or DECnet in the days before IP 
>>> became widely supported.
>>
>> I hope that argument (being exercised widely) to be taken the right 
>> way. I think you are right that this should not be the only or 
>> primary reason for choosing this new proposal. However, it secures a 
>> lot people using a technology, when software has been exercised so 
>> much: way less chance to have memory issues, crashes, … For a 
>> difficult environment such as space, it is IMHO a very big plus.
>>
>>
>>>
>>> More to the point, we are not here talking about deploying that 
>>> widely exercised stack in space.  We are talking about deploying an 
>>> IP stack that is operationally very different from what we use on 
>>> Earth and which has not yet been specified in detail, much less 
>>> implemented, much less demonstrated, much less exercised on even a 
>>> tiny fraction of the traffic conveyed between Earth and the 
>>> International Space Station over the last seven years of continuous 
>>> science instrument support.
>>
>> IP has been used in space. Just an example: it has been presented at 
>> a recent IETF, by Cisco and Lockheed Martin (see: 
>> https://www.youtube.com/watch?v=V8Xdr0DvGKE).  Webex Earth to Orion 
>> spacecraft. Don’t know if they were using QUIC, but WebRTC so 
>> SIP-RTP-UDP-HTTPwebsockets. Some careful considerations, especially 
>> the use of the right codec. But this is real-time two-way 
>> communications. Not sure we want to do this as is in « far » deep 
>> space (aka Mars).
>>
>>> I am doubtful.
>>
>> Understood. Hope that I, not by myself, but hopefully with the help 
>> of others, will be able to convince you at some point.
>>
>> Regards, Marc.
>>
>> PS. Don’t want to overpromise, but we are working on a testbed to 
>> show the whole stack with simulation of the various conditions as 
>> near to real situations as possible. Will report results when done.
>>
>>>
>>> Scott
>>> _______________________________________________
>>> dtn mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dtn

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