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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> 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