Sorry, answering myself: > On Apr 26, 2021, at 8:29 PM, Michael Welzl <mich...@ifi.uio.no> wrote: > > Hi, > > >> On Apr 25, 2021, at 11:49 PM, Velt, R. (Ronald) in 't >> <Ronald.intVelt=40tno...@dmarc.ietf.org >> <mailto:Ronald.intVelt=40tno...@dmarc.ietf.org>> 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. >> 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 >> > > 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?
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 Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
