From: Michael Welzl <[email protected]> > 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? > > What am I missing in this picture? 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
