s/inout/input :-)
Sent from my iPhone > On 16 Nov 2016, at 19:10, Michael Welzl <[email protected]> wrote: > > in line: > > Sent from my iPhone > >> On 16 Nov 2016, at 19:07, Tommy Pauly <[email protected]> wrote: >> >> 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. > > agree, > > >> >> 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. > > yes that's what i mean - it offers good inout to both in fact > > >> 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. > > sounds good to me! - note that there's also a draft on happy-eyeballing, not > presented this time but still active > > cheers > michael > > >> >> Thanks! >> Tommy >> >>> On Nov 16, 2016, at 6:25 PM, Michael Welzl <[email protected]> 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 <[email protected]> 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 <[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 >>> >> > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
