Subject: [Taps] Kyle Rose's review of the API draft

From: Michael Welzl <[email-masked]>
Date: Thu, 2 Apr 2020 16:53:53 +0200

Hi,

I sifted through the review now, trying to address some easy things, removing some more things that were already addressed, creating issues for things that require some discussion… as a result, we now have new PR #515, issues #520 - #526, and here is one item thatI’d like to check with Kyle via this email:

5.2. Specifying Transport Properties

* Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output of selected properties seems like a shortcut that will lead to some confusion.

MW: I agree;  partially addressed: s/Required/Require wherever it's a Preference level.

Kyle: FWIW, my objection to the other issue (using a normative term as an indication of what was chosen) isn't that it's underspecified, only that it's confusing. I put it roughly in the same category as specifying -1 as an error indicator in an abstract API. Is the idea that the output parameters could be fed into the protocol selection logic for a subsequent connection to select the same protocol? Is that useful?

Philipp Tiesel: We had text saying that these should turn into Boolean when queried and should reflect whether the protocol stack chosen provides the feature. I will have to double-check whether this text is still in the description of the preference type.

MW: I found this text: "Querying a Selection Property after establishment yields the value Require for properties of the selected protocol and path, Avoid for properties avoided during selection, and Ignore for all other properties."   - this seems ok to me. Kyle?

Cheers,
Michael

- - -

PS:   I believe that the ones below are resolved, but I'm repeating them here in case someone disagrees with an answer:

11.1.10. Capacity Profile

* Very little of this section is about capacity. Traffic Profile?

Gorry Fairhurst:
> I don't much like Traffic Profile - to a traffic profile specifies the characteristics of the traffic the sender is transmitting, not the treatment that traffic expects from the network service.

5.2.11. Provisioning Domain Instance or Type

* What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi.

Philipp Tiesel:
> Each cellular provider will have a unique PVD.

8.2. Receive Events

* "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events?

* Also, can the draft be consistent about Receive vs. Received, et al.?

MW: I can't find a consistency problem; I think that some such things were already fixed with recent PR's, perhaps this problem has self-resolved.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 2 Apr 2020 16:42:04 -0400

On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <[email-masked]> wrote:

> Hi,
>
> I sifted through the review now, trying to address some easy things,
> removing some more things that were already addressed, creating issues for
> things that require some discussion… as a result, we now have new PR #515,
> issues #520 - #526, and here is one item thatI’d like to check with Kyle
> via this email:
>
> * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried
> output of selected properties seems like a shortcut that will lead to some
> confusion.
>
> Kyle: FWIW, my objection to the other issue (using a normative term as an
> indication of what was chosen) isn't that it's underspecified, only that
> it's confusing. I put it roughly in the same category as specifying -1 as
> an error indicator in an abstract API. Is the idea that the output
> parameters could be fed into the protocol selection logic for a subsequent
> connection to select the same protocol? Is that useful?
>
> Philipp Tiesel: We had text saying that these should turn into Boolean
> when queried and should reflect whether the protocol stack chosen provides
> the feature. I will have to double-check whether this text is still in the
> description of the preference type.
>
> MW: I found this text: "Querying a Selection Property after establishment
> yields the value Require for properties of the selected protocol and path,
> Avoid for properties avoided during selection, and Ignore for all other
> properties."   - this seems ok to me. Kyle?
>

I don't have a strong opinion about it. I just find it potentially
confusing. Just in case, the alternative I had in mind was having an output
enum something like { Selected, Avoided, Ignored } independent of the input
type. As long as you understand this and are still okay with the interface
you've chosen, that is fine by me.

If you go with the existing approach, I wonder if "Avoid" should be
"Prohibit", analogous to "Require" for selected properties. (Similarly,
maybe the opposite of "Selected" is "Prohibited" in my alternative
approach.)

> > I don't much like Traffic Profile - to a traffic profile specifies the
> characteristics of the traffic the sender is transmitting, not the
> treatment that traffic expects from the network service.
>

I'm trying to think of "capacity" as "path and protocol selection and
network treatment", but it's just not clicking. Maybe there's a term of art
definition of "capacity" I'm just not familiar with. I buy "capacity" as
"network treatment", but path selection and protocol selection are both
properties of the traffic as defined by the endpoints, is it not? Maybe
"Capacity and Traffic Profile"? (Again, not something I feel especially
strongly about.)

> > Each cellular provider will have a unique PVD.

SGTM.

> 8.2. Receive Events
>
> * "A call to Receive will be paired with a single Receive Event" or
> possibly multiple ReceivedPartial Events?
>
> MW: I can't find a consistency problem; I think that some such things were
> already fixed with recent PR's, perhaps this problem has self-resolved.
>

Also LGTM.

Thanks for the thoroughness, BTW. This is also the kick in the ass I needed
to get back to looking at this. :-)

---

From: Michael Welzl <[email-masked]>
Date: Fri, 3 Apr 2020 12:20:03 +0200

Hi,

> On Apr 2, 2020, at 10:42 PM, Kyle Rose <[email-masked]> wrote:
> 
> On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> I don't have a strong opinion about it. I just find it potentially confusing. Just in case, the alternative I had in mind was having an output enum something like { Selected, Avoided, Ignored } independent of the input type. As long as you understand this and are still okay with the interface you've chosen, that is fine by me.

I got it now, and I think your proposal is much better. I’ll do this in a PR.

> If you go with the existing approach, I wonder if "Avoid" should be "Prohibit", analogous to "Require" for selected properties. (Similarly, maybe the opposite of "Selected" is "Prohibited" in my alternative approach.)
>  
> I'm trying to think of "capacity" as "path and protocol selection and network treatment", but it's just not clicking. Maybe there's a term of art definition of "capacity" I'm just not familiar with. I buy "capacity" as "network treatment", but path selection and protocol selection are both properties of the traffic as defined by the endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, not something I feel especially strongly about.)

I also don’t have a strong opinion about this, but I’ll leave it for Gorry to answer.

> Thanks for the thoroughness, BTW. This is also the kick in the ass I needed to get back to looking at this. :-)

Thanks to you for your careful review!

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 3 Apr 2020 12:42:26 +0100

See below.

On 03/04/2020 11:20, Michael Welzl wrote:
> Hi,
>
>
>> On Apr 2, 2020, at 10:42 PM, Kyle Rose <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     I sifted through the review now, trying to address some easy
>>     things, removing some more things that were already addressed,
>>     creating issues for things that require some discussion… as a
>>     result, we now have new PR #515, issues #520 - #526, and here is
>>     one item thatI’d like to check with Kyle via this email:
>>
>>     * Using the same enum (Require(d[sic])/Avoid/Ignore) for the
>>     queried output of selected properties seems like a shortcut that
>>     will lead to some confusion.
>>
>>     Kyle: FWIW, my objection to the other issue (using a normative
>>     term as an indication of what was chosen) isn't that it's
>>     underspecified, only that it's confusing. I put it roughly in the
>>     same category as specifying -1 as an error indicator in an
>>     abstract API. Is the idea that the output parameters could be fed
>>     into the protocol selection logic for a subsequent connection to
>>     select the same protocol? Is that useful?
>>
>>     Philipp Tiesel: We had text saying that these should turn into
>>     Boolean when queried and should reflect whether the protocol
>>     stack chosen provides the feature. I will have to double-check
>>     whether this text is still in the description of the preference type.
>>
>>     MW: I found this text: "Querying a Selection Property after
>>     establishment yields the value Require for properties of the
>>     selected protocol and path, Avoid for properties avoided during
>>     selection, and Ignore for all other properties."  - this seems ok
>>     to me. Kyle?
>>
>>
>> confusing. Just in case, the alternative I had in mind was having an 
>> output enum something like { Selected, Avoided, Ignored } independent 
>> of the input type. As long as you understand this and are still okay 
>> with the interface you've chosen, that is fine by me.
>
>> "Prohibit", analogous to "Require" for selected properties. 
>> (Similarly, maybe the opposite of "Selected" is "Prohibited" in my 
>> alternative approach.)
>>
>>     > I don't much like Traffic Profile - to a traffic profile
>>     specifies the characteristics of the traffic the sender is
>>     transmitting, not the treatment that traffic expects from the
>>     network service.
>>
>>
>> network treatment", but it's just not clicking. Maybe there's a term 
>> of art definition of "capacity" I'm just not familiar with. I buy 
>> "capacity" as "network treatment", but path selection and protocol 
>> selection are both properties of the traffic as defined by the 
>> endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, 
>> not something I feel especially strongly about.)
>
To me:

Traffic profile makes me think of TSpec, MF-Classifier, etc. Something 
that I can define within a network device that will decide what 
forwarding behaviour I see, and how I may police to this. in DS, this 
could be defined as "A traffic profile specifies the temporal properties 
of a traffic stream selected by a classifier. It provides rules for 
determining whether a particular packet is in-profile or 
out-of-profile." [RFC2475]. To me this isn't that?

Capacity is about how fast a sender can currently send along a path. My 
expectations for accessing capacity might be related to the treatement I 
tell the network that I wish to receive, such as the DSCP that is set. 
However, this isn't a capacity specification, and a capacity profile is 
just about OK to me - but not perfect, because the description doesn't 
"profile" capacity.

I'd be OK with a range of words here - and not OK with some others.

Other possibilities could be:

"Network Service"

"Network Service Marking"

Or even more-specific:

"DS Marking"

I would be very happy to think upon others - but the keyword space is 
limited and we should avoid overlap with terms that mean something else :-).

Gorry

>>     * "A call to Receive will be paired with a single Receive Event"
>>     or possibly multiple ReceivedPartial Events?
>>
>>     MW: I can't find a consistency problem; I think that some such
>>     things were already fixed with recent PR's, perhaps this problem
>>     has self-resolved.
>>
>>
>> Also LGTM.
>>
>> Thanks for the thoroughness, BTW. This is also the kick in the ass I 
>> needed to get back to looking at this. :-)
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

-- 
G. Fairhurst, School of Engineering