Re: [Taps] draft-trammell-post-sockets

[Tommy Pauly <[e-mail]>]

Hi Michael,

I definitely agree that the current Post draft is not the fulfillment of the charter item 3. My point was that it is not necessarily out of scope, and the work it is looking into may very well be a necessary part of satisfying the charter.

I had read the second charter item as listing out the pieces of functionality that are required for TAPS to provide, rather than how these pieces should be exposed. Perhaps the API work is somewhere split between 2 and 3? I can certainly see it either way.

Another point is that the Post draft is still in quite early stages. As discussed today, I'd like to write up the approach I presented today as a draft, and that could get folded into Post, since I think it requires a Post-style API in order to be used. I think there is a lot of detail yet to add about how to select and use protocols and paths and options internally to the connection implementation.

Thanks!
Tommy

> On Nov 16, 2016, at 6:25 PM, Michael Welzl <[e-mail]> wrote:
> 
> Hi Tommy,
> 
> Being part of the discussions after the meeting, I completely agree. However, to me, saying X matches charter item Y is rather premature at this stage.
> 
> This draft presents a few services, which, as was discussed during the meeting,
> 1) overlap quite a lot with draft-mcquistin-taps-low-latency-services  (good!).
> 2) match very nicely to the services we already have in e.g. the minset draft  (good!).
> (with some small differences that we also discussed - one being message dependencies).
> 
> 
> I see this draft as very good input but I’d like to do things one by one.
> As you know I also agree with this statement of yours:
> 
> "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”
> 
> so yes, this will definitely happen, but it’s clearly part of charter item 2, and here this (and the other) draft are great input!
> 
> However, while an API can be part of item 3, the relationship to item 3 all in all isn’t so clear: the draft does not really address much of what item 3 says. It doesn't explain much along the lines of selecting and engaging a protocol; it doesn’t explain how incremental deployment will work; it doesn’t explain how to discover which protocols are available for the selected service.
> 
> Again, I’m not saying an API (which is part of what this draft provides) is out of scope of item 3, but then item 3 should probably be approximately 3 drafts (I also have nothing against that  :)  but this is not my decision). It’s just that there’s a LOT still missing here, so let’s not jump the gun and do things step by step, as the charter also prescribes: "Work on this document will begin when the TAPS Transport Services have been specified."
> 
> Let me be clear, with “step by step” I’m by no means saying we should slow things down - and as I said before I see a lot of value in this draft!
> My concern is just about mapping drafts to charter items.
> 
> Very useful input, yes; in scope of charter item 3: maybe, to some degree, but at this point more useful as input to item 2 IMO.
> 
> Cheers,
> Michael
> 
> 
>> On Nov 16, 2016, at 4:12 PM, Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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 <[e-mail] <mailto:[e-mail]>> 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
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> _______________________________________________
>> Taps mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/taps
>