Re: [dtn] [Deepspace] technical remarks

[Jorge Amodio <[e-mail]>]

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
>