Re: [Taps] On Profiles for TAPS Preconnections

[Gorry Fairhurst <[e-mail]>]

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.
>> 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.
I'm fairly striongly against (3). Profiles are really important as a 
concept and I'd really encourage the group to write this.

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