OMG! Typo below - NEAT is the a research project implementing TAPS, and I wrote this email after the social… enough said…
very sorry: I meant to say: please discuss on the TAPS mailing list. > On 19. jul. 2016, at 23.05, Michael Welzl <[email protected]> wrote: > > [ Please discuss on the NEAT mailing list ] > > > Hi, > > The TAPS WG is trying to identify which services transport protocols offer, > and then identify which of these services should be exposed to an application > that tries to communicate while being agnostic to the transport protocol > below. A TAPS system should then make a choice about the right transport > protocol and configure it autonomously, and implement e.g. protocol > fall-backs and such. > > Some transport services must be exposed or else they could never be used > (e.g. unordered message delivery). Some can optimize performance if they are > exposed and cannot be used without application involvement, but won’t make an > application fail if they are not used (e.g. turning the Nagle algorithm > on/off). The remaining ones could be “automatized”, i.e. a TAPS protocol > could potentially make a decision on its own about them. > > Note that this raises the abstraction level of the API applications use to > talk to the network. As always, this comes with benefits (of automatizing > more things, and not requiring one specific transport protocol, ..), but also > with reduced control over the available resources. As an extreme example, > nobody in their right mind would write wireshark over TAPS :-) > > One proposal is to consider everything related to the usage of multiple paths > automatable. That is, not expose it as a TAPS service. > > What do people here think about this? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
