Subject: [Taps] DTN & TAPS

From: "Aaron Falk" <[email-masked]>
Date: Sun, 25 Apr 2021 12:55:53 -0400

I was marveling the news about exploration on Mars this week and this 
caused me to wonder if anyone has looked at DTN as a protocol provided 
by TAPS.  My recollection of DTN is rather rusty and I think it might be 
an informative thought experiment for the API.

--aaron

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Sun, 25 Apr 2021 21:49:11 +0000

Hi Aaron,

  *   I was marveling the news about exploration on Mars this week and this caused me to wonder if anyone has looked at DTN as a protocol provided by TAPS. My recollection of DTN is rather rusty and I think it might be an informative thought experiment for the API.

Funny you should mention that.

A short while ago I had a thought about a TAPS CLA (Convergence Layer Adapter, the layer below the Bundle Protocol and above the Transport Layer) as potentially "one CLA to rule them all". (It was no more than that: a passing thought, quickly evaporating). This would be more or less the complement of your thinking; DTN-over-TAPS instead of DTN as one of the candidate transports that TAPS might select (if all else fails, presumably).

Throwing this as bait to the DTN WG, since there could be someone there interested in either thought experiment. (Not sure how much overlap there is between both communities).

--Ronald in 't Velt

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Apr 2021 20:29:40 +0200

Hi,

> On Apr 25, 2021, at 11:49 PM, Velt, R. (Ronald) in 't <Ronald.intVelt=[email-masked]> wrote:
> 
> Hi Aaron,
> I was marveling the news about exploration on Mars this week and this caused me to wonder if anyone has looked at DTN as a protocol provided by TAPS. My recollection of DTN is rather rusty and I think it might be an informative thought experiment for the API.
> A short while ago I had a thought about a TAPS CLA (Convergence Layer Adapter, the layer below the Bundle Protocol and above the Transport Layer) as potentially “one CLA to rule them all”. (It was no more than that: a passing thought, quickly evaporating). This would be more or less the complement of your thinking; DTN-over-TAPS instead of DTN as one of the candidate transports that TAPS might select (if all else fails, presumably).
> 
> --Ronald in ‘t Velt

Sorry for being negative about what clearly is academically-minded brainstorming… I should be open towards such stuff  :-)
But…  aren’t DTN applications special applications, which make implicit assumptions about the network underneath, i.e. they’re written particularly for the use case, because they expect… well, massive delay?

I can’t imagine such an application being happy with TAPS swapping in TCP or even QUIC as a replacement… and conversely, going with Aaron’s thought model, I can’t imagine a “normal” application benefiting hugely from DTN?

What am I missing in this picture?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Apr 2021 20:34:40 +0200

Sorry, answering myself:

> On Apr 26, 2021, at 8:29 PM, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> 
>> On Apr 25, 2021, at 11:49 PM, Velt, R. (Ronald) in 't <Ronald.intVelt=[email-masked] <mailto:Ronald.intVelt=[email-masked]>> wrote:
>> 
>> Hi Aaron,

Perhaps, when delay gets a LOT better, the DTN application might in fact be happy to run over e.g. TCP or QUIC. Is this a (the only?) use case?  Is it realistic, even?

Cheers,
Michael

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 27 Apr 2021 07:58:04 +0100

not exactly DTN, but opportunsitic networks, as envisaged in Haggle
had pluggable protocols at most layers - 

Haggle: Seamless Networking for Mobile Applications
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/haggle-ubicomp2007.pdf

DTN is also sometimes interpreted as "Disruption Tolerant Networking",
(e.g. not just delay between earth and mars, but phobos or deimos
get in the way from time to time, so ingenuity crashes without anyone
seeingg

(or in the terrestrial case, you'ree train goes into a tunel whether
there's no cell phone coverage)...

> Sorry, answering myself:

speaking for and probably to  myself:)

> >> On Apr 25, 2021, at 11:49 PM, Velt, R. (Ronald) in 't 
> <Ronald.intVelt=[email-masked] 
> <mailto:Ronald.intVelt=[email-masked]>> wrote:
> >>
> >> Hi Aaron,
> caused me to wonder if anyone has looked at DTN as a protocol provided by 
> TAPS. My recollection of DTN is rather rusty and I think it might be an 
> informative thought experiment for the API.
> >> A short while ago I had a thought about a TAPS CLA (Convergence Layer 
> Adapter, the layer below the Bundle Protocol and above the Transport 
> Layer) as potentially “one CLA to rule them all”. (It was no more 
> than that: a passing thought, quickly evaporating). This would be more or 
> less the complement of your thinking; DTN-over-TAPS instead of DTN as one 
> of the candidate transports that TAPS might select (if all else fails, 
> presumably).
> >>
> >> Throwing this as bait to the DTN WG, since there could be someone 
> there interested in either thought experiment. (Not sure how much overlap 
> there is between both communities).
> >>
> >> --Ronald in ‘t Velt
> >>
> >
> > Sorry for being negative about what clearly is academically-minded 
> brainstorming… I should be open towards such stuff  :-)
> > But…  aren’t DTN applications special applications, which make 
> implicit assumptions about the network underneath, i.e. they’re written 
> particularly for the use case, because they expect… well, massive delay?
> >
> > I can’t imagine such an application being happy with TAPS swapping in 
> TCP or even QUIC as a replacement… and conversely, going with Aaron’s 
> thought model, I can’t imagine a “normal” application benefiting 
> hugely from DTN?
> >
> Perhaps, when delay gets a LOT better, the DTN application might in fact 
> be happy to run over e.g. TCP or QUIC. Is this a (the only?) use case?  
> Is it realistic, even?
> 
> Cheers,
> Michael
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 27 Apr 2021 23:31:16 +0000 (UTC)

> there's no cell phone coverage)...

In the interplanetary internet delay-tolerant networking case link loss can
be planned for and scheduled into operations. Orbital mechanics are
quite predictable in the short-to-medium term. Path delays are long.
(and phobos and deimos don't cast large shadows...)

Trains are also scheduled and run according to plan -- in most countries.
When a car goes into a tunnel, however, is less amenable to planning.
Disruption is, by its nature, unplanned. Path delays are shorter.

A graph that attempts to represents the orthogonality of delay- and
disruption-tolerant networking, and how they differ, is in fig 1 of:

Sharing the dream: The consensual networking hallucination offered by the Bundle Protocol

http://dx.doi.org/10.1109/ICUMT.2009.5345655

http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/index.html#e-dtn-position

TCP is pretty much the default for DTN, because much development was done
over TCP, it was well-understood, convenient, reliable. Transports for actual
delay and disruption are far harder.

Lloyd Wood 
http://lloydwood.users.sourceforge.net/Personal/L.Wood/dtn/

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 28 Apr 2021 00:21:50 +0000

From: Michael Welzl <[email-masked]>
> But...  aren’t DTN applications special applications, which make
> implicit assumptions about the network underneath, i.e. they’re
> written particularly for the use case, because they expect...
> well, massive delay?

Such an app still would benefit from a saner transport API.  The
core problem TAPS solves is that doing transport while restricting
yourself to use of the existing system calls (particularly sockets)
makes life much harder than it needs to be, and this problem seems
nowhere more true than in DTN.

> I can’t imagine such an application being happy with TAPS swapping
> in TCP or even QUIC as a replacement… and conversely, going with
> Aaron’s thought model, I can’t imagine a “normal” application
> benefiting hugely from DTN?
>

I agree it would need to avoid accidentally swapping in TCP or QUIC
naively.  But that's because you'll see too many errors to be useful,
not because the needs of data transfer for DTN use cases can't be
expressed in terms of transport properties and transport-relevant
events.

> Perhaps, when delay gets a LOT better, the DTN application might in
> fact be happy to run over e.g. TCP or QUIC. Is this a (the only?)
> use case?  Is it realistic, even?

I expect these might be part of the story for a DTN layer, but I'll
submit that it's irrelevant to the questions of whether DTN
applications would benefit from the use of a TAPS API, or whether
such an API could be implemented in a way that meet the needs of DTN
use cases.

Note: I'm not saying there's no problems to solve here, potentially
requiring extensions that go beyond TAPS-as-currently-written or
things that might need special handling.  For instance, maybe they'll
need support for a write completion after a reboot of the device, or
other such craziness.  However, I think they could do lots worse than
starting with a TAPS-based API and trying to make it work as a generic
DTN-capable transport layer for the endpoints that need it.  I see
no fundamental reason local disk caches and session re-initialization
from a prior state can't be part of an implementation layer, if you
think about it a little broadly.

Just my 2c.

Best regards,
Jake