Subject: [PANRG] Review of draft-irtf-panrg-path-properties-02

From: "Holland, Jake" <[email-masked]>
Date: Sun, 21 Mar 2021 03:05:29 +0000

Hi Panrg, Theresa, and Cyrill,

I read through draft-irtf-panrg-path-properties-02, and overall I
think it's in pretty good shape.  But I have a few comments and
questions:

1.
I have a little confusion over "Node" definition. 

From 2. Terminology:
   Node:  An entity which processes packets, e.g., sends, receives,
      forwards, or modifies them.  A node may be physical or virtual,
      e.g., a physical device or a service function provided as a
      virtual element.  A node may also be the collection of multiple
      entities which, as a collection, processes packets, e.g., an
      entire Autonomous System (AS).

From 3.1 Path Selection:
For example,
   for sending a small delay sensitive query, a host may select a path
   with a short One-Way Delay, while for retrieving a large file, it may
   select a path with high Link Capacities on all links.  Note, there
   may be trade-offs between path properties (e.g., One-Way Delay and
   Link Capacity), and entities may influence these trade-offs with
   their choices.  As a baseline, a path selection algorithm should aim
   to not perform worse than the default case most of the time.

Just to clarify: is for example a DSCP-selected queue in a switch a
Node under this definition?  I think so, as it may have some specific
relevant properties that are different from other queues, such as latency
targets and capacity limits.

But as written the answer seems unclear to me, and I feel like it might
cause confusion if used that way.  Would it be helpful to include
something this as an example too?

I think the AS example shows some helpful scope in the sense that this
aggregates to a macroscopic context, but if I'm understanding correctly
that it's intended to be generalizable like this, I think it might be
helpful to clarify that depending on the properties and dynamics under
discussion, it can also be useful to slice to a more microscopic context
than a whole device or virtual device.

2.
I think there's a lot of use of the word "entity" when a narrower "Host"
or "Node" would be better.

I'm getting a vague impression that in some situations, like when
information is exposed to an entity that can use it to achieve goals,
like in "3. Use Cases for Path Properties", "entity" is intended to
capture nodes in general plus things like traffic engineering
controllers that might have no part in a traffic path, whereas in
other cases I think it refers only to a host (like in "3.2 Protocol
Selection"--is there any non-host that can select a protocol for its
data traffic?  When it's sending data traffic it's acting as a host,
right?), and it would be nicer if I wasn't guessing at the intended
scope.

I think there's a few ways to handle it, but my first suggestion would
be to use "entity" or "entities" as-is in the definitions, and try to
excise those terms from the rest of the doc, and if there are cases that
can't use a word that's in the terminology section (or combinations like
"nodes or links") as a substitution without losing the intended meaning,
it suggests another term might be needed.

3.
I had a slightly hard time with the Transparency example in Examples
of Path Properties:

   Transparency:  A node is transparent with respect to a protocol
      header, payload, or both for a specific action if the node
      performs this action independently of the given
      (meta-)information.  Actions can for example be blocking packets
      or reading and modifying (other protocol) headers or payloads.  An
      IP router could be transparent for transport protocol headers such
      as TCP and UDP, in contrast to a NAT that actively modifies TCP
      and UDP header information.

Is it correct to say that in this usage, Transparency is defined only in
relation to flow properties?

Is it correct that "block all TCP Syn packets" is transparent with
respect to IP but not with respect to TCP?  (Or does relying on the
protocol type already break that?  And if so, is that still transparent
with respect to the TCP payload?)  Is it also correct that a NAT is
transparent with respect to payloads, but not transparent with respect
to IP, TCP, or UDP headers?

(If I got all that right, I feel like saying a few sharper examples
along these lines would help to clear it up better.  If not, I guess
I'm too confused to know what to suggest, and I think it needs
clarifying.)

4.
Would it be useful to include a path property that captures the value
of broadcast capabilities for point-multipoint flows?

Maybe something like this:

    Replication Efficiency:  A point-multipoint flow can be transported
       over paths with a variety of replication capabilities at
       the different nodes and links along the path.  For example, an
       RTP Translator (RFC 3550) that replicates packets to multiple
       receivers by producing a separate packet for each destination
       in software has a different level of efficiency than a multicast-
       capable router or switch that uses hardware to replicate multicast
       packets to multiple interfaces, which has a different level of
       efficiency than sending multicast IP packets across a broadcast-capable
       physical link, such as GPON or MIMO broadcast channels.

Thanks for a very good doc.

Best regards,
Jake

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 25 Mar 2021 19:01:40 -0700

Hi Jake,

Thank you so much for your review!

Replies inline:

> than a whole device or virtual device.

Yes, a DSCP-selected queue in a switch can be a Node.

To illustrate that a Node is not necessarily a physical or virtual 
machine, but can be defined in a more microscopic context, we have 
already included a service function as an example. To make it clearer, 
we can also add "a single queue" as another example for a (virtual) Node.

I may add text for this some time next week, and then I'll create a PR 
in our GitHub repo. For now, I already created an issue: 
https://github.com/panrg/path-properties/issues/46

> it suggests another term might be needed.

Yes, "entity" is intended to be broader than just nodes on the path and 
can include off-path devices like traffic engineering controllers. It 
doesn't have to be a physical device either, it could also be a service 
running "in the cloud".

I agree it would be good to substitute "entity" with a more specific 
term in many instances later in the document.

However, I am not sure what a good term for these is, as I'm not sure I 
want to overload "Node". But maybe it actually is a Node, which may be 
on-path or off-path, and maybe in some cases it has to be on-path? 
(Though I imagine there could be cases where an off-path Node actually 
selects a protocol that some on-path Node then uses, or at least 
attempts to use.)

> relation to flow properties?

Transparency is defined in relation to a particular flow. Not sure if 
it's necessarily "in relation to flow properties", as I wouldn't say 
that a protocol header itself is necessarily a flow property. But I 
guess the presence of a header, or of a header field,  could be a flow 
property. For example, we already have a "Protocol Features available" 
property for features like ECN, and now one could define the actual 
presence/usage of ECN as a flow property.

> with respect to the TCP payload?)

I think our Transparency definition does not yet go into that level of 
detail, but answering questions like these will refine it.

As a first proposal, I would say that blocking packets is not 
transparent to any part of a flow, as it prevents the entire flow from 
actually traversing the path. Therefore, it wouldn't be transparent with 
respect to IP either.

Would you agree with that?

Cyrill, do you have more thoughts on this, as you originally added the 
text for this Property?

> Is it also correct that a NAT is

Generally, yes.

We refined the Transparency definition to include different "degrees" of 
transparency with respect to a specific action. For example, NAT may not 
be transparent with respect to reading IP and TCP or UDP headers, but it 
could be transparent with respect to modifying TCP/UDP headers if it 
does not change port numbers (which might not be common or a good 
example - but I'm sure there's several on-path nodes that may read 
headers, but not modify them).

So I guess a specific path element can be "read-transparent" with 
respect to some parts of a packet/flow, and "modify-transparent" with 
respect to other (fewer) parts of a packet/flow.

Does that make sense?

> I'm too confused to know what to suggest, and I think it needs

I agree that adding examples will be good.

>         physical link, such as GPON or MIMO broadcast channels.

Thanks for the suggestion.

As the examples in the document are intended to focus on properties 
related to the use cases in Section 3, I'm wondering what's the primary 
use case for this property? I imagine it might be related to protocol 
selection, i.e., a node could select between different protocols based 
on the replication efficiency of the path.

Could this property also be captured by the "Service function" property, 
e.g., have the RTP Translator be a path element, and have its 
functionality be defined as a service function that it applies to 
particular flows?

Is there a specific definition for a certain level of replication 
efficiency, e.g., is it possible to capture it as a number with a unit?

Best,
Theresa

---

From: <[email-masked]>
Date: Fri, 26 Mar 2021 08:09:03 +0000

Hi Theresa, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Panrg [mailto:[email-masked]] De la part de Theresa
> Enghardt
> Envoyé : vendredi 26 mars 2021 03:02
> À : Holland, Jake <[email-masked]>; [email-masked]; draft-irtf-
> [email-masked]
> Objet : Re: [PANRG] Review of draft-irtf-panrg-path-properties-02
> 
> Hi Jake,
> 
> > relevant properties that are different from other queues, such as
> > latency targets and capacity limits.
> >
> > But as written the answer seems unclear to me, and I feel like it
> > might cause confusion if used that way.  Would it be helpful to
> > include something this as an example too?
> >
> > aggregates to a macroscopic context, but if I'm understanding
> > correctly that it's intended to be generalizable like this, I think
> it
> > might be helpful to clarify that depending on the properties and
> > dynamics under discussion, it can also be useful to slice to a more
> > microscopic context than a whole device or virtual device.
> 
> already included a service function as an example. To make it
> clearer, we can also add "a single queue" as another example for a
> (virtual) Node.

[Med] Another example we can add is the VRF or the more general concept of "VPN Node" defined in:

draft-ietf-opsawg-l3sm-l3nm-07:

   VPN node:  An abstraction that represents a set of policies applied
      on a PE and that belong to a single VPN service.  A VPN service
      involves one or more VPN nodes.  As it is an abstraction, the
      network controller will take on how to implement a VPN node.  For
      example, typically, in a BGP-based VPN, a VPN node could be mapped
      into a Virtual Routing and Forwarding (VRF).

> 
> I may add text for this some time next week, and then I'll create a
> PR in our GitHub repo. For now, I already created an issue:
> can include off-path devices like traffic engineering controllers.

[Med] Agree. That can be captured by making sure to convey the message that these entities may not belong necessary to the data plane, but to the control plane.  

 It
> on-path or off-path, and maybe in some cases it has to be on-path?

[Med] Not sure about this. I'd prefer to add an entry for "entity" in Section 2 to cover the intended usage (data plane, control plane, on-path, off-path, can be a node/host). 

> selects a protocol that some on-path Node then uses, or at least

[Med] Yeah, this is for example the case of ATSSS (https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.3) where the network instructs the host which protocol to use for traffic steering. 

> I agree that adding examples will be good.

[Med] FWIW, another common usage of "transparent" is when a network function is invoked without requiring any signaling from the endpoints (unlike explicit mode) and while its presence is not easily detected by the endpoints (e.g., transparent proxies).

It would be useful if the overlap with the common usage is clarified/avoided. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.