Subject: Re: [PANRG] RG Last Call: draft-irtf-panrg-path-properties

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Apr 2022 17:27:19 -0500

I also support the publication of this draft, after rereading it for
the first time in a while. Comments below.

On Fri, Mar 25, 2022 at 3:21 AM <[email-masked]> wrote:

> Hi all,
>
> I support the publication of this draft.
>
> I have only minor comments to this version:
>
> (1) Several application/services manipulate not only observed/assessed
> values, but can also set objectives/targets. I suggest we provision a new
> entry to cover that:
>
> NEW:
>    Target property:  An objective that is set for a property over a path,
>       subpath, or network.  For example, the maximum one-way delay to be
>       observed by packets transmitted from a node. Such properties can be
>       captured on service requests (e.g., Section 4.1.1.1 of
> [I-D.ietf-teas-ietf-network-slices]).
>
> (2) Fix some references as per:
> https://github.com/panrg/path-properties/issues/67.
>
> (3) You may also consider adding pointers for TCPinc and MPTCP.
>
> (4) cite 9097 in addition to 5136.
>
> (5) s/Boudacair/Boucadair
>
> Cheers,
> Med
>

MB’s suggestion about adding target properties seems reasonable, but might
need also to be mentioned in the introduction (and, perhaps, in the
definition in -questions, but that just popped out of the RFC Editor queue
as https://datatracker.ietf.org/doc/rfc9217/), unless "endpoint reaction to
these properties that affects routing and/or data transfer" includes
setting targets.

I’m less certain whether “target property” needs to appear someplace in the
Section 3 use cases, but I should mention that in case others are more
certain.

In the definition of “Path”,

For multicast or broadcast, a packet may be sent by one node and received
by multiple nodes. In this case, the packet is sent over multiple paths at
once, one path for each combination of sending and receiving node; these
paths do not have to be disjoint.

I think the point this text is making is that if a sending node performs
broadcast or multicast over multiple paths, that’s not relevant to the
definition of a path in this document - each one of the paths from sender
to receiver(s) is just another path, according to this definition.

Is that correct? If so, perhaps this could be a second paragraph on its own
within the definition, to be clearer.

In the definition of “Aggregated property”,

The aggregation function can be numerical, e.g., median, sum, minimum, it
can be logical, e.g., "true if all are true", "true if at least 50\% of
values are true", or an arbitrary function which maps multiple input values
to an output value.

Is “50\%” a typo?

In the definition of “Transparency”, I found this sentence difficult to
parse:

A can for example be blocking packets or reading and modifying (other
protocol) headers or payloads.

Perhaps

For example, A can be blocking packets or reading and modifying (other
protocol) headers or payloads.

I’m not sure where to put it, but some of the dynamic path properties can
be so dynamic that they aren’t useful in path-aware networking. For
example, link usage for bursty traffic may vary so dramatically that this
property can’t be used to select between paths without applying dampening
or otherwise avoiding oscillation. This is somewhat related to
https://www.rfc-editor.org/rfc/rfc9049.html#name-reacting-to-distant-signals,
and has been mentioned about every two years for the entire time ALTO has
been chartered. 🙂

Perhaps following this paragraph?

Some path properties express the performance of the transmission of a
packet or flow over a link or subpath. Such transmission performance
properties can be measured or approximated, e.g., by endpoints or by path
elements on the path, or they may be available as cost metrics, see
[I-D.ietf-alto-performance-metrics]. Transmission performance properties
may be made available in an aggregated form, such as averages or minimums.
Properties related to a path element which constitutes a single layer 2
domain are abstracted from the used physical and link layer technology,
similar to [RFC8175].

(and if you wanted to divide the path properties in Section 4 as
“relatively static path properties” and “relatively dynamic path
properties”, that might be helpful to the reader)

Best,

Spencer

---

From: Reese Enghardt <[email-masked]>
Date: Fri, 15 Apr 2022 10:51:16 -0700

Dear Med, Spencer,

Thank you so much for the comments to both of you, and sorry for the 
late reply.

See inline:

On 4/1/22 15:27, Spencer Dawkins at IETF wrote:
>     […]
>     (1) Several application/services manipulate not only
>     observed/assessed values, but can also set objectives/targets. I
>     suggest we provision a new entry to cover that:
>
>     NEW:
> MB’s suggestion about adding target properties seems reasonable, but 
> might need also to be mentioned in the introduction (and, perhaps, in 
> the definition in -questions, but that just popped out of the RFC 
> Editor queue as https://datatracker.ietf.org/doc/rfc9217/ 
> <https://datatracker.ietf.org/doc/rfc9217/>), unless "endpoint 
> reaction to these propertiesthat affects routing and/or data transfer" 
> includes setting targets.
>
> I’m less certain whether “target property” needs to appear someplace 
> in the Section 3 use cases, but I should mention that in case others 
> are more certain.
>
Thanks for the suggestion.

I think it's well worth mentioning target properties in Section 3, as I 
understand they can be part of the objective of use cases - Nodes may 
select which path to use or invoke a service in an attempt to get 
certain properties. And of course, if there is a target property, this 
also implies the need to measure path properties to determine if the 
target is being met.

Med, thank you for the reference to Section 4.1.1.1 of 
[I-D.ietf-teas-ietf-network-slices], this looks helpful. I think it will 
be good to provide one illustrative example in the PANRG draft as well. 
Would you say that an example of "target properties" is a Quality of 
Service requirement for "real-time" media streaming such as a video call?

To Spencer's point, I think "endpoint reaction to these properties that 
affects routing and/or data transfer" can imply setting targets, and/or 
setting targets can be the motivation for an endpoint to react to these 
properties. So I don't think this changes anything about PANRG's questions.

(Let's keep discussing this on the list for now, though I also opened a 
Github issue to eventually track the resolution of this discussion: 
https://github.com/panrg/path-properties/issues/69)

> For multicast or broadcast, a packet may be sent by one node and 
> received by multiple nodes. In this case, the packet is sent over 
> multiple paths at once, one path for each combination of sending and 
> receiving node; these paths do not have to be disjoint.
>
>
> I think the point this text is making is that if a sending node 
> performs broadcast or multicast over multiple paths, that’s not 
> relevant to the definition of a path in this document - each one of 
> the paths from sender to receiver(s) is just another path, according 
> to this definition.
>
>
> Is that correct? If so, perhaps this could be a second paragraph on 
> its own within the definition, to be clearer.
>
Yes, I would say that this is correct.

In general, I think the Path definition is quite long and includes lots 
of aspects. I'll see what we can do to make it clearer.

Created an issue to track this: 
https://github.com/panrg/path-properties/issues/70

> The aggregation function can be numerical, e.g., median, sum, minimum, 
> it can be logical, e.g., "true if all are true", "true if at least 
> 50\% of values are true", or an arbitrary function which maps multiple 
> input values to an output value.
>
>
> Is “50\%” a typo?
>
Yep: https://github.com/panrg/path-properties/issues/68

> In the definition of “Transparency”, I found this sentence difficult 
> to parse:
>
>
> For example, A canbe blocking packets or reading and modifying (other 
Agreed, will change.

Created a Github issue: https://github.com/panrg/path-properties/issues/71

> I’m not sure where to put it, but some of the dynamic path properties 
> can be so dynamic that they aren’t useful in path-aware networking. 
> For example, link usage for bursty traffic may vary so dramatically 
> that this property can’t be used to select between paths without 
> applying dampening or otherwise avoiding oscillation. This is somewhat 
> related to 
> and has been mentioned about every two years for the entire time ALTO 
> has been chartered. 🙂
>
>
> properties can be measured or approximated, e.g., by endpoints or by 
> path elements on the path, or they may be available as cost metrics, 
> see [I-D.ietf-alto-performance-metrics]. Transmission performance 
> properties may be made available in an aggregated form, such as 
> averages or minimums. Properties related to a path element which 
> constitutes a single layer 2 domain are abstracted from the used 
> physical and link layer technology, similar to [RFC8175].
>
This is a great point and should definitely be included, and you found 
the right place for it.

Created a Github issue: https://github.com/panrg/path-properties/issues/72

> properties”, that might be helpful to the reader)

I am not so sure about dividing Section 4. In the first revisions of 
this draft, we had actually split the Path Properties into non-dynamic 
and Dynamic properties, but then we realized that this distinction was 
not always clear or useful, see the discussion here: 
https://github.com/panrg/path-properties/pull/22

I am not sure "relatively static" and "relatively dynamic" work so well 
as section headings, as this sounds like a clearer distinction than 
there actually is, at least to me.

If anyone has thoughts on this and/or suggestions, please let me know.

I will be traveling in the next few weeks, but I hope to be back with a 
revised draft in May.

Best,
Reese