[ 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

Reply via email to