Re: [Deepspace] [dtn] technical remarks

[Dean Bogdanovic <[e-mail]>]

I’m not very familiar with LTP, but it can run over UDP, so uses the 
same approach as QUIC. The frameworks that could be useful in deep space 
communication (routing protocols, network management tools, application 
development) can run or already run over QUIC. This provides more 
options to build a deep space network based on application requirements 
vs using LTP.

Dean

On 25 Sep 2023, at 17:22, Jorge Amodio wrote:

> That is one of the reasons for LTP existance.
>
> -J
>
> On Mon, Sep 25, 2023 at 4:15 PM Dean Bogdanovic <[e-mail]> 
> wrote:
>
>> 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]>
>> *Sent:* Tuesday, September 19, 2023 11:29 AM
>> *To:* Scott Burleigh <[e-mail]>
>> *Cc:* [e-mail]; DTN WG <[e-mail]>
>> *Subject:* Re: [dtn] technical remarks
>>
>>
>>
>> Le 18 sept. 2023 à 20:39, [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]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>>
>> --
>> Deepspace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/deepspace
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>