Based on the discussions we had with several folks after the meeting, the feeling was that the some of the Post Sockets API approach probably was in scope for the third item of the TAPS charter.
Here's that item for reference: "3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for the selected service between a given pair of end points. Further, it will provide a basis for incremental deployment. Work on this document will begin when the TAPS Transport Services have been specified." Here's my take for why the post-sockets effort is in scope: 1. I believe that choosing the correct path/protocol stack for a connection, taking into account both client preferences and system policy, requires some API support beyond a socket. We need several things beyond traditional sockets. One is to allow for multipath and fast-open semantics, which can be shimmed onto sockets, but require significant changes that make them incompatible with traditional adopters. Another aspect is the point I brought up in my presentation today: we need support for multiple options that may be attempted and selected (between protocols, interfaces, and endpoints), and this more complex setup is not compatible with a single-five-tuple single-interface socket abstraction. These requirements seem important for "how to select and engage an appropriate protocol", which is in the charter. 2. The charter mentions that the third phase "will provide a basis for incremental deployment". If I try to imagine how we can allow new protocol development to provide functionality in a non-disruptive manner, it seems most tractable to (a) define an API layer that provides the minimal subset in a way that is compatible both with existing deployments and future goals; (b) move clients to adopt said API layer as a common abstraction; and (c) incrementally add more logic for protocol selection and modifications underneath this stable level. This is the approach we've taken in our deployments, and it has worked well for enabling new features. If Post Sockets is the correct expression of the minimal subset that can lift up the API and allow TAPS to add more smarts to the stack, it would seem we would have addressed the work item. The work TAPS has done so far to catalog the protocol options we see in existing transports is (while tedious) very important, and I think leads to the conclusion that a carefully considered API is required to go forward. I am concerned that if we do not aggressively and creatively try to minimize and unify the interfaces applications use for networking, we will end up with still more ossification of the stack. Today, things are ossified around TCP when applications use sockets. If we simply add options for the features we think should be added for TAPS, we still end in ossification if it boils down to "all apps that use the API in a certain manner always get protocol A". I hope that with an architecture like Post Sockets, we can distill the essential patterns of communication between endpoints so far that they can indeed grow along with future network protocol innovations. Thanks, Tommy > On Nov 16, 2016, at 10:48 AM, Brian Trammell <[email protected]> wrote: > > Hi, all, > > Looking at where we are in the agenda, we're not going to get to talk about > Post Sockets in the meeting in Seoul today. As most of the properties of the > API are already being discussed during Colin's presentation, this isn't that > big a deal. However, if anyone who has read draft-trammell-post-sockets would > like to talk to us about it here in Seoul, please drop me a line. > > To answer Zahed's question at the beginning of the meeting: we didn't call > this draft-trammell-taps-post-sockets because it's not clear that it's really > in scope for TAPS. It presents a radically changed replacement in the > abstract for the sockets API. However, if the working group is interested in > continuing to discuss it, we're happy to resubmit as > draft-trammell-taps-post-sockets if it makes things easier to follow. :) > > Cheers, > > Brian > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
