Hi, as we seem to have rough consensus in what we want (but may still disagree how this should be achieved), I updated PR #328 in a way that might work for all of us.
I also updated PR #327 the to include #328 and point at the profiles as a the way to specify common requirements instead of requesting exact protocol combinations. I think we should not include explicit protocol selection without having a more convenient way to specify common sets of requirements. > On 23. Jul 2019, at 16:11, Anna Brunström <[email protected]> wrote: > > Hi all, inline > >> -----Original Message----- >> From: Taps <[email protected] <mailto:[email protected]>> On Behalf >> Of Gorry Fairhurst >> Sent: den 23 juli 2019 20:40 >> To: Brian Trammell (IETF) <[email protected] <mailto:[email protected]>> >> Cc: Philipp S. Tiesel <[email protected] <mailto:[email protected]>>; >> Tommy Pauly >> <[email protected] >> <mailto:[email protected]>>; taps WG <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [Taps] On Profiles for TAPS Preconnections >> >> Hi all, see below - how near are we to agreement? >> >> On 23/07/2019, 14:21, Brian Trammell (IETF) wrote: >>> hi Tommy, all, >>> >>>> On 22 Jul 2019, at 19:15, Tommy >> Pauly<[email protected]> wrote: >>>> >>>> >>>> >>>>> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel<[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On 22. Jul 2019, at 15:09, Tommy >> Pauly<[email protected]> wrote: >>>>>> >>>>>> An issue we discussed today in the TAPS meeting was whether or not we >> should add a concept of "profiles" to the Transport Services APIs. An example >> of a profile is a "reliable, secure, in-order stream"; or "unreliable >> datagrams". >> Another way to think of these profiles are as convenient ways to initialize >> common parameters. >>>>>> >>>>>> One option is described in this PR: >>>>>> https://github.com/ietf-tapswg/api-drafts/pull/328 >>>>>> >>>>>> To help discern the working group's position, I'll try to distill the >>>>>> high- >> level options here: >>>>>> >>>>>> 1. Add Profiles as a top-level API document concept that modifies >>>>>> how transport properties and/or preconnections are created. (This is PR >> #328.) 2. Mention in the API document that specific API implementations may >> expose conveniences and profiles (presumably as a way to initialize >> preconnections), but do not modify the API or specify an abstract symbol for >> profiles. >>>>>> 3. Do not mention profiles at all in the API document, but mention >> something in the implementation document. >>>>> I am definitely in favour of option 1. Our implementation experience with >> PyTAPS showed that setting all transport properties necessary to get “UDP >> like service” becomes tedious otherwise. >>>>> I fear not including them in the examples and the core API will result in >> many developers rejecting TAPS as too complex to use. >>>>> The profiles provide a useful convenience to applications (just like the >> the shortcuts properties.prefer(property) instead of properties.add(property, >> prefer)). >>>>> >>>>> In addition, profiles allow us to be less conservative in how we choose >> the defaults for transport properties, i.e., we don’t need the TAPS defaults >> to >> be TCP compatible as long as the reliable-in-order-stream profile is. > > I do not think there is any connection here. Weather we have profiles or not > we will need good defaults. (The above would only hold if all profiles > covered all transport properties and you were required to always select a > profile. I do not think anyone is arguing for this.) > >>>> Speaking not as the person asking the question, but as an individual in the >> group: >>>> >>>> I'm pretty strongly against option (1), and prefer (2). I think we should >> specify that convenience functions can exist, but I think changing the one >> initialization function of the transport properties to take a profile is not >> the >> right move for the API. Everything can be achieved by making the API for a >> convenience profile be a layer on top of the existing API. >>> +1, for the same reasons. > > +1 for option 2 as well. I think we should keep the core API as small and > clean as possible. To me profiles are naturally built on top of the API and > do not need to be part of the core API. > >> I'm fairly striongly against (3). Profiles are really important as a concept >> and >> I'd really encourage the group to write this. > > So far it seems we all agree that profiles are a useful concept and should be > mentioned in the documents. > > Anna > >> Some additional motivation is that it can very significantly impact the way >> the TAPS system is presented to the user. It can help allow applications to >> set >> many TAPS parameters, providing additional info to the selection (racing) >> without the pain of having to understand what each parameter should be set >> to. That's a big simplification. For example a low-rate transactional app >> could >> eplicitly need datagram to make choices for low latency using one profile - >> another app that wishes to optimise for throughput could start by setting a >> different profile. >>>> Specifically, these are the differences: >>>> >>>> (1) Exposes an API in which you always pass a profile (or an explicit nil) >>>> to a >> TransportProperties object; but the TransportProperties *also* lets you set >> each of the individual properties after that. >> The API options win: Apps can choose a profile, and they can - maybe should >> be encouraged to - over-ride anything that is important to them. >>> I really like the idea of being able to pull a profile off the shelf and >>> then >> tweak it. >>> >>> It does seem to me that the right model here is "profiles as >>> convenience constructors or copyable constants" -- that model is >>> pretty reasonably implementable as an add-on, without >>> >>> (That's separate from the question of whether profiles are a "mandatory" >> feature in taps-interface, a suggested feature in an appendix, or something >> that exists in a different document). >>> >>> Cheers, >>> >>> Brian >> +1 if you'd like to have (sample) profile descriptions in an informative >> appendix, that would seem like a way to achieve that. >>>> (2) Allows implementations to expose an API call to deliver a >> TransportProperties that's set up based on a profile, but that isn't the >> fundamental constructor. It is implemented by creating a TransportProperties >> (TransportProperties()) and then setting the properties internally. >>>> >>>> Thanks, >>>> Tommy >> At the start of TAPS, I thought of profiles as the same as other parameters >> (i.e. >> they are inputs to the selection algorithm, that are less signficant than >> apps- >> supplied params, and more significant that the system default). >> >> I'd prefer we call this out explicitly in the documents. >> >> Gorry >> >>>>> AVE! >>>>> Philipp S. Tiesel >>>>> >>>>> -- >>>>> Philipp S. Tiesel >>>>> https://philipp.tiesel.net/ >>>>> >>>> _______________________________________________ >>>> 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 AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
