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
