Re: [Taps] On Profiles for TAPS Preconnections

["Philipp S. Tiesel" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi all, inline
> 
>> -----Original Message-----
>> From: Taps <[e-mail] <mailto:[e-mail]>> On Behalf Of Gorry Fairhurst
>> Sent: den 23 juli 2019 20:40
>> To: Brian Trammell (IETF) <[e-mail] <mailto:[e-mail]>>
>> Cc: Philipp S. Tiesel <[e-mail] <mailto:[e-mail]>>; Tommy Pauly
>> <tpauly=[e-mail] <mailto:tpauly=[e-mail]>>; taps WG <[e-mail] <mailto:[e-mail]>>
>> 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<tpauly=[e-mail]>  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel<[e-mail]>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On 22. Jul 2019, at 15:09, Tommy
>> Pauly<tpauly=[e-mail]>  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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/taps
>>> _______________________________________________
>>> Taps mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> _______________________________________________
>> Taps mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps

AVE!
   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/