Subject: [Taps] On Profiles for TAPS Preconnections

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Jul 2019 15:09:17 -0400

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.

Let's use this thread to discuss how to converge!

Thanks,
Tommy

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 22 Jul 2019 18:56:30 -0400

Hi,

> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=[email-masked]> wrote:
> 

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.

AVE!
   Philipp S. Tiesel

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

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Jul 2019 19:15:02 -0400

> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi,
> 

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.

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.
(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

---

From: Max Franke <[email-masked]>
Date: Tue, 23 Jul 2019 09:34:51 -0400

I wonder if this argument is more because at the moment profiles are handed over as a parameter on creation of the properties and not about the existance of properties in general.
Maybe another solution would be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we already have with WithService on the endpoints?

As Philipp said, there are already convenience features in other places of the API which should be removed if we agree on keeping the complexity to the bare minimum for the core interface.

Best regards,

Max

Thanks,

Tommy

_______________________________________________

Taps mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 09:40:37 -0400

Yes, I would be happier with suggesting something like TransportProperties.WithProfile(profile), rather than replacing the primary constructor.

To the point of trimming down the API, I do think that it may be good to only choose one between options like this:

* properties.prefer(property)
* properties.add(property, prefer)

The API prescribed by this document is abstract, and needs to give freedom to implementations to make things elegant in their particular languages.

What about having an appending, that's non-normative and not required for RFC compliance, that describes suggested conveniences, such as "properties.prefer()" and the concept of convenience profiles?

The point is, if you wanted to have the minimal implementation of a TAPS implementation that made it possible to let applications do what they need over TAPS, you wouldn't necessarily need to implement these conveniences, since they don't add any new capabilities, but instead are semantic sugar.

Thanks,
Tommy

> On Jul 23, 2019, at 9:34 AM, Max Franke <[email-masked]> wrote:
>

---

From: Max Franke <[email-masked]>
Date: Tue, 23 Jul 2019 09:51:53 -0400

Yes, I like this idea. I also agree that the API is complex enough as it is and requiring convenience features to be RFC compliant is probably not a good idea. As long as we are consistent with moving all conveniences to the appendix this is my preferred option.

Best

Max

---

From: Michael Welzl <[email-masked]>
Date: Tue, 23 Jul 2019 10:17:13 -0400

> On Jul 23, 2019, at 9:51 AM, Max Franke <[email-masked]> wrote:
> 
> 
> 

+1 on this if it’s a workable solution (sounds like it is), and a particular +1 on the side comment about "consistently moving all conveniences to the appendix”

Cheers,
Michael

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 23 Jul 2019 10:27:57 -0400

> On 23. Jul 2019, at 10:17, Michael Welzl <[email-masked]> wrote:
> 
> 
> 
>> On Jul 23, 2019, at 9:51 AM, Max Franke <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

I am fine with moving all conveniences to the appendix, but we might still need to reference them in the main text to make sure the API does not look overly inconvenient. I also would like to use the profiles in one of the examples.

AVE!
   Philipp S. Tiesel

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 23 Jul 2019 10:35:48 -0400

> On 23. Jul 2019, at 09:40, Tommy Pauly <[email-masked]> wrote:
> 

This has several drawbacks and makes things more complicated:
 - We need to define what should happen when TransportProperties.WithProfile(profile) is called multiple times
 - We need to define whether TransportProperties.WithProfile(profile) should override properties that have been set using TransportProperties.add(property, value)
 - Implementations could choose to do this differently.

Having the profile only in the constructors avoids these, as the behaviour is 100% clear - the profile sets the defaults, everything can be overridden afterwards. Also it makes clear that one can only specify a single profile.

>> On Jul 23, 2019, at 9:34 AM, Max Franke <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Am 22.07.2019 19:15 schrieb Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]>>:
>> 
>> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > Hi,
>> > 
>> >> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]>> wrote:
>> >> 
>> >> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328 <https://github.com/ietf-tapswg/api-drafts/pull/328>
>> >> 
>> > https://philipp.tiesel.net/ <https://philipp.tiesel.net/>
>> >
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
>> 
>> [email-masked] <mailto:[email-masked]>

AVE!
   Philipp S. Tiesel

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Jul 2019 10:46:54 -0400

TransportProperties.WithProfile(profile) *is* a constructor, I believe? (Or at least that's what I interpret and suggest). Calling it multiple times creates two different sets of properties. It's just a convenience way, but not the only way.

Thanks,
Tommy

> On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> 
> 
>> On 23. Jul 2019, at 09:40, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 23 Jul 2019 10:56:38 -0400

> On 23. Jul 2019, at 10:46, Tommy Pauly <tpauly=[email-masked]> wrote:
> 

I interpreted that differently - WithProfile being a methond of an TransportProperties instance.

Anyway – I don’t really mind if the profile is an optional parameter to the primary constructor or whether there is an alternate constructor that takes it as a mandatory argument. For me, the latter is just one way to realise the former in a language that does not support optional parameters and thus an implementer’s choice.

> 
> Thanks,
> Tommy
> 
>> On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

AVE!
   Philipp S. Tiesel

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 23 Jul 2019 14:21:45 -0400

hi Tommy, all,

> On 22 Jul 2019, at 19:15, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> 
> 

+1, for the same reasons.

> (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 t…

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Jul 2019 14:39:37 -0400

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=[email-masked]>  wrote:
>>
>>
>>
>>> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel<[email-masked]>  wrote:
>>>
>>> Hi,
>>>
>>>> On 22. Jul 2019, at 15:09, Tommy Pauly<tpauly=[email-masked]>  wrote:
>>>>
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.
>> (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…
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.
> (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).
+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 Tran…
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

---

From: Anna Brunström <[email-masked]>
Date: Tue, 23 Jul 2019 20:11:52 +0000

Hi all, inline

> -----Original Message-----
> From: Taps <[email-masked]> On Behalf Of Gorry Fairhurst
> Sent: den 23 juli 2019 20:40
> To: Brian Trammell (IETF) <[email-masked]>
> Cc: Philipp S. Tiesel <[email-masked]>; Tommy Pauly
> <tpauly=[email-masked]>; taps WG <[email-masked]>
> Subject: Re: [Taps] On Profiles for TAPS Preconnections
> 
> >> On 22 Jul 2019, at 19:15, Tommy
> Pauly<tpauly=[email-masked]>  wrote:
> >>
> >>
> >>
> >>>> On 22. Jul 2019, at 15:09, Tommy
> Pauly<tpauly=[email-masked]>  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
> >>>>
> >>>> 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.)

> >> 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 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.
> >> (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.
> > 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
> >> (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).
>

---

From: Anna Brunström <[email-masked]>
Date: Tue, 23 Jul 2019 20:46:57 +0000

From: Taps <[email-masked]> On Behalf Of Michael Welzl
Sent: den 23 juli 2019 16:17
To: Max Franke <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; [email-masked]
Subject: Re: [Taps] On Profiles for TAPS Preconnections

On Jul 23, 2019, at 9:51 AM, Max Franke <[email-masked]<mailto:[email-masked]>> wrote:

I agree an appendix can be a good idea. I would still prefer not to define a list of profiles, rather mention the concept of profiles as one of the convenience functions and perhaps give an example.

Anna

Cheers,
Michael

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 23 Jul 2019 17:02:57 -0400

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-masked]> wrote:
> 
> Hi all, inline
> 
>> From: Taps <[email-masked] <mailto:[email-masked]>> On Behalf Of Gorry Fairhurst
>> To: Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>>
>> Cc: Philipp S. Tiesel <[email-masked] <mailto:[email-masked]>>; Tommy Pauly
>> <tpauly=[email-masked] <mailto:tpauly=[email-masked]>>; taps WG <[email-masked] <mailto:[email-masked]>>

AVE!
   Philipp S. Tiesel