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

[Gorry Fairhurst]

See below.

On 03/04/2020 11:20, Michael Welzl wrote:

Hi,


On Apr 2, 2020, at 10:42 PM, Kyle Rose > wrote:


On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl > 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:

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?


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


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.


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.




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



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.


SGTM.

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 con

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

[Michael Welzl]

Hi,


> On Apr 2, 2020, at 10:42 PM, Kyle Rose  wrote:
> 
> On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl  > 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:
> 
> 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?
> 
> 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.)
>  
> 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.
> 
> 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.


> 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.
> 
> SGTM.
>  
> 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.
> 
> Also LGTM.
> 
> 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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Kyle Rose]

On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl  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:
>
> 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?
>

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


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

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

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

SGTM.


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

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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps