Re: [PANRG] Review (was: Re: The PANRG RG has placed draft-enghardt-panrg-path-properties in state "Candidate RG Document")

[Theresa Enghardt <[e-mail]>]

Hi Med,

thanks for the responses.

Some replies inline:

On 24.09.19 16:58, [e-mail] wrote:
>> On 06.08.19 14:37, [e-mail] wrote:
>>> […]
>>>
>>> Some general comments:
>>>
>>> * Having a terminology I-D may help as a support to architectural
>> discussions, for example. Nevertheless, there is a risk of biased
>> definitions in the absence of a reference architectural framework.
>>
>> I think coming up with a unified architectural framework is a challenge,
>> as the research in PANRG touches upon different areas within the IETF,
>> including the Routing Area, Internet Area, and Transport Area, and
>> possibly more areas within and outside of the IETF.
>>
>> Given that different areas may have different definitions of "Path"
>> (even within the same area, e.g., BGP paths vs. MPLS paths in Routing),
>> coming up with a unified terminology is a challenge.
> [Med] Indeed. This is why I think that having a (even drafty) reference architecture would be helpful to bridge between these domains or at least to bind the definition with a particular context. 

[TE] While it sounds to me like a full-fledged reference architecture
for Path-Aware Networking could be another draft, indeed it might make
sense to give more context, perhaps in the Introduction of our draft.
We'll consider doing this for the next revision and I'll be happy to
discuss this more afterwards.


>>> * The definition of some terms is not aligned with existing
>> practices/techniques (ERO, PCE, SFC, for example). Take the example of
>> "Path" which assumes "alternating between nodes and links". This
>> assumption is not accurate for an SFC/SFP or a path presented as an
>> ordered list including AS Numbers.
>>
>> Regarding the ordered list of AS numbers:
>> Yes, we may want to align our definition with this or add more terms.
>> Right now we can express an entire network or AS as subpaths, e.g.,
>> consisting of all nodes and links within this AS. Maybe, we want an
>> additional "aggregated" path element (group of nodes and links? cloud?),
>> which is not a subpath, but an amorphous component (node?) on the path,
>> which may include multiple nodes and links. As we may not have full
>> visibility of all path elements in practice, from the point of view of a
>> host, most paths probably include at least one such "aggregated" path
>> element anyway.
> [Med] Nodes may have distinct views of a given path. The main point is to avoid requiring the "alternating between nodes and links" in a ** generic ** definition of "path". 

[TE] I see.


>> Regarding SFC/SFP:
>> The definition for a path as path elements "alternating between nodes
>> and links" exists to prevent nonsensical paths, e.g., consisting only of
>> nodes or only of links.
> [Med] I disagree these are "nonsensical paths". Defining a path as a sequence of nodes/functions may be sufficient for an endhost. For example, a collaborative network may decide to announce a set of functions to an endhost; those functions can be invoked individually or in a sequence. The endhost may impose a "path" that is defined (from its local standpoint) as a singleton function or a loose path defined as an ordered list of functions. Also, a MIF device can define a path with reference to its local interfaces (without even caring about further hops upstream).

[TE] Agreed - as long as it is possible to pass packets across the path,
it's not "nonsensical". However, even if a node only has a partial view
of the path, such as a set of functions or a reference to a local
interface, there is still at least one other node (the remote endpoint)
that the node most likely cares about. Then, if the node does not know
or care about the path elements inbetween, we might want to model them
as an "aggregate" path element or something like this.


>  As a path may include multiple nodes on a single
>> physical host, we allow nodes and links to be virtual, e.g., to just be
>> a virtual switch or a virtual interface that packets can pass through.
>> Just to make sure I got your comment right: Here you are saying that
>> defining individual Service Functions (SF) or a Service Function Chain
>> (SFC) to be nodes (which may be virtual) between which links may exist
>> (either physical or virtual, allowing virtual links to not just be
>> between virtual network interfaces but even within a single host) does
>> not solve the problem, right? So the Service Function Path (SFP) cannot
>> just be a sequence of nodes and links? Do you think this is this
>> necessarily just a sequence of nodes, no links, because we would have to
>> stretch the definition of a virtual link too far, or is there a
>> different reason why alternating nodes and links does not work?
> [Med] as I mentioned above, a same path may be viewed differently by distinct nodes. An endhost, for example, does not have to manipulate the same path granularity as a router or a Service Function Forwarder (RFC7665). Also, defining a path as a sequence of nodes/links may not be sufficient in some case as the overall path must also invoke a set of functions that may be collocated within a given node. 

[TE] But functions can also be nodes, right, and then a sequence of
functions (nodes) can be located within a host (also a node)... I'm
wondering if this will get confusing.


> In short, a path can be zoomed in/out as a function of the context. 

[TE] I think what you call "zoom in/out" is similar to what we say in
our current path definition, e.g., "If [a] router does not implement
transport layer functionality, it is hidden when a higher layer, such as
the transport or application layer, is considered." - a host might not
have to care about every individual router on the path. We'll see if we
can make this clearer and/or more explicit.


> Moreover, a path does not need to be strictly defined; loose mode should also be supported.

[TE] What is the difference between strict and loose here - full view
vs. partial view of the physical topology?


>> [Med2]: Instead of reasoning about paths, what actually matters is the
>> connectivity service(s) provided via an upstream network.
>> [TE2]: Well, this is the Path-Aware Networking Research Group, so it
>> makes sense to reason about paths, right?
> [Med] IMO, an endhost does not care about a path per se, but about the service it will get when path(s) is/are used to forwarded its packets. Picking a path or any other decision about how to make use of available ones is an outcome of the intended connectivity service.    
>
>  Yes, as an endpoint you
>> actually care about what services your path provides, but I'm not sure I
>> want to change any text based on this comment.
>> Maybe add "[information … that an entity … might have or want to have]
>> about a path and the services it provides"?
> [Med] This is better. I suggest:
>
> s/about a path and the services it provides/about services provided via a path

[TE] While I agree that services are important, I do think that some
nodes care about the physical path itself and not just the services.
Therefore, I'd like to go with "about a path and the services provided
via a path".


>> [Med5]: [Between two hosts] excludes point-to-multipoint communications.
>> Consider the case of an STB which want to retrieve TV channels using
>> multicast.
>> [TE5]: Right now, we define path as between two hosts (will perhaps
>> change to "between two nodes" to include, e.g., overlays, but of course
>> the two nodes can be hosts), and then point-to-multipoint can be
>> expressed as a set of multiple paths, one for each pair of sender and
>> receiver. Then, the same property can apply to multiple paths and, thus,
>> be essentially the point-to-multipoint communication.
> [Med] This will depend on the nature of a communication. I'm not sure this will apply for SSM, ASM or when anycast is used.

[TE] Neither am I. I'll think about this more.


>> On "Because the current Internet provides an IP-based best-effort bit
>> pipe, hosts have little information about paths to other hosts.":
>> [Med6]: What is the causality effect here?
>> [TE6]: I think here we intend to say that, in the current Internet, the
>> path and its services are transparent to hosts, so hosts only know
>> something is reachable, but they do not get all the details of via which
>> networks, they do not necessarily get details on the services (e.g., QoS).
>> Do you have a proposal of what text to change here?
> [Med] I see. I suggest the following: 
>
> ==
> OLD: 
>
> Because the current Internet provides an IP-based best-effort bit
>    pipe, hosts have little information about paths to other hosts
>
> NEW:
>   In general, hosts do not have information about underlying forwarding paths and associated services. 
> ==
>
> There are some architectures that are deployed which provide assistance to hosts with some path policies/information, e.g., Access Network Discovery and Selection Function (ANDSF).

[TE] Thanks for the suggestion, we'll consider adding something along
these lines.


>> On "[Traffic policies: … Such policies can allow or disallow sending
>> traffic over specific networks or nodes":
>> [Med9]: This is about path selection covered in the 3rd bullet.
>> [TE9]: True, this can be a case of path selection - or you may find out
>> that your policy does not allow you to send your traffic at all. The
>> latter case is not covered by our current definition of path selection,
>> so I think mentioning it here makes sense. But we should rephrase this
>> sentence to make it more clear. Any suggestion?
> [Med] I would move it under path selection and clarify that path selection is fed with policies (e.g., trafic policies). 

[TE] Thanks for the suggestion, we'll consider doing that.


>> On "[select a protocol depending on the capabilities of the] on-path
>> devices":
>> [Med10]: I agree with this example, but I have the following comments:
>> The selection of the protocol is not only specific to on-path devices,
>> but it can be the other way around: It is the selection of the protocol
>> which may infer the devices that will be involved in a path. Consider
>> the example of the 0-RTT Convert Protocol which is involved in a path
>> only when invoked by a host; such invocation will lead to the use of
>> MPTCP or TCPinc while this Is not doable with the default path. Another
>> example of traffic policies is a connection which may be composed of
>> multiple streams, each stream with specific requirements. A host may
>> decide to invoke a given service function (e.g., transcoding) only for
>> some streams while others are not processed by that service function.
>> [TE10]: True, there can be more complex interactions. Do you have a
>> suggestion of what text to add or change here?
> [Med] What about adding this NEW text at the end of the bullet: 
>
> NEW:
>     The selection of a protocol may infer the devices that will be involved in a path. For example, a 0-RTT Transport Converter [I-D.ietf-tcpm-converter] will be involved in a path only when invoked by a host; such invocation will lead to the use of MPTCP or TCPinc capabilities while such use is not supported via the default forwarding path. Another example of traffic policies is a connection which may be composed of multiple streams; each stream with specific service requirements. A host may decide to invoke a given service function (e.g., transcoding) only for some streams while others are not processed by that service function.

[TE] Thanks for the suggestion and pointer, this is a really interesting
feature. We'll probably add text along these lines.


>> On "the monetary cost [of the link]":
>> [Med11]: This is linked to a network, not a path.
>> [TE11]: Yes, this usually applies to only a part of the path, e.g., a
>> specific network. However, from the point of view of a host, which sees
>> the path containing this network, it may be a property of the path.
>> Perhaps we should change the sentence here to "the monetary cost to send
>> data across a network on the path" to make the example clearer.
> [Med] What about: 
>
> "the monetary cost to send data across a network, eventually on a given path"

[TE] Why "eventually"? If the property applies to some path elements on
the path, that means that the network in question is on the path.


>> On "Another example is an enterprise network where all traffic has to go
>> through a firewall, in which case the host needs to be aware of on-path
>> firewalls."
>> [Med12]: How this information is useful for enforcing “traffic policies”
>> discussed in this bullet? What would be interesting is to have means to
>> control such firewalls.
>> [TE12]: The idea here was that a host may have a policy to have all its
>> traffic filtered through a specific firewall, so if the firewall is not
>> available for some reason, it will not sends its traffic, or it will
>> send different traffic, e.g., encapsulate it using a VPN. Does this
>> example make sense to you?
> [Med] What about changing the text as follows: 
>
> OLD: 
>      Another example is an
>       enterprise network where all traffic has to go through a firewall,
>       in which case the host needs to be aware of on-path firewalls
>
> NEW: 
>      Another example is an
>       enterprise network where all traffic has to go through a specific firewall,
>       in which case the host needs to be aware of paths involving that firewall.

[TE] Makes sense, thanks!


>> Agree that controlling firewalls from the host could be another
>> interesting use case, but I'm not sure if this is in scope of this
>> draft. After all, our model is that the host gets information about the
>> path, not that it manipulates the path.
> [Med] This assumes the path is predefined. I'm not sure about that assumption. Consider the following example:
>
> Operators already provide tools to enterprises to dynamically invoke some added value services. They even can impose the ordering of invoking those functions. You may also check the proposal: https://tools.ietf.org/html/draft-bernardos-sfc-discovery-03 
>
> A path may not be pre-defined, but be imposed by a host in such cases.

[TE] Agreed.


>> On "Network monitoring: Network operators can use path properties (e.g.,
>> measured by on-path devices), to observe Quality of Service (QoS)
>> characteristics of recent end-user traffic, and identify potential
>> problems with their network early on, before the end-user complains."
>> [Med13]: Which information is exposed here?
>> [TE13]: The idea here is to expose performance characteristics, such as
>> latency or packet loss, to nodes on the same subpath, so the performance
>> problem can be mitigated. Think LOOPS overlay nodes which might detect
>> an increase in packet loss and, as a result, retransmit packets or add
>> FEC. Perhaps "monitoring" is not the right term here, because this
>> scenario also involves mitigation - maybe "Performance enhancement" is a
>> better term here?
> [Med] That is better. The explanation about subpaths is useful because I was looking for the role of an endhost. Having a figure would be helpful for this one.

[TE] I see. We'll consider adding figures.


>> [Med16], on "Domain properties expose a high amount of information to
>> hosts": Why?
>> [TE16]: The assumption here is that from nearby path elements, you may
>> be more likely to get performance information, such as Channel
>> utilization and such from QBSS information elements sent by a WiFi
>> access point, or that you are more likely to know about and explicitly
>> configure an HTTP proxy within your own administrative domain.
> [Med] I'm not sure there is a rule there. You may be in a local network but the administrator restricts the amount of information you may have access ti from within that local network, but you can connect to a cloud and select the appliances you want to invoke. 
>
> I would just remove such statement. 

[TE] We'll consider doing that.


>> On "A path can be viewed as an abstraction on a specific layer, omitting
>> lower layer path elements."
>> [Med23]: Contradicts with the sentence about alternating nodes/links.
>> [TE23]: Why? If we define a path on, e.g., layer 3, we can treat the
>> link between two layer 3 devices as a virtual link, so we abstract from
>> all physical links and nodes on layer 2. Do you have an alternative
>> proposal how to phrase this?
>>
> [Med] I would simply remove that sentence as I don't see how (assuming it is true) it can be useful. 

[TE] Perhaps this is related to our discussion about views of the path.
We'll think about this more.


>> [Med31]: This would exclude then a host connected to a UE connected to a
>> PLMN or a CPE connected to an enterprise or provider networks. These
>> elements do not belong to the same
>> administrative entity.
>> [TE31]: In my understanding, an element belonging to an administrative
>> domain does not necessarily mean that the element belongs to the entity
>> which owns the domain. For example, if my phone (the UE) connects to a
>> cellular network (the PLMN), the mobile phone still belongs to me.
> [Med] Agree. 
>
>> However, the phone might also be a host on a path through this cellular
>> network. In this case, I intend the definition to have the phone, the
>> base station, and the cellular infrastructure behind the base station
>> all belong to the same administrative domain, as for example all L3
> [Med] even at L3, that host does not belong to same domain. 

[TE] I guess whether a specific path element belongs to a specific
domain depends on the exact definition of domain. If it's defined by
"who owns the address space on L3", I don't see why it wouldn't belong
to that domain.


>> devices here get assigned IP addresses from a common address space that
>> belongs to the provider of the cellular network. If my phone leaves the
>> cellular network, it does not keep the IP address, then it's no longer
>> part of that administrative domain. Can we come up with a more general
>> definition of a domain that does not rely only on IP address space?
> [Med] May be, but my main concern (still) is whether there is a need to define domain/backbone.

[TE] I see.


>> On "Due to the potential physical proximity and pre-existing trust or
>> contractual relationships between hosts and path elements within the
>> same domain, domain properties may be more accessible to the host than
>> other properties."
>> [Med32]: Which contractual relationships would apply to this case?
>> [TE32]: For example, if my host connects to a service provider's
>> network, I may be a customer of this service provider, e.g., through my
>> DSL subscription. This MIGHT mean that the provider is more willing to
>> or has to give me (or my host) more information, e.g., about network
>> performance characteristics.
> [Med] I was concerned about "relationships between hosts and path elements within the
> ** same domain **". Contracts are usually between elements that do not belong to the same domain.  

[TE] That's for a different definition of domain. But yes, contracts may
exist with different entities along the path, so we'll rethink this
along with the definition and notion of domain.


>> On "Access Technology: The physical or link layer technology used for
>> transmitting or receiving a flow on one or multiple path elements in the
>> same domain. The Access Technology may be given in an abstract way,
>> e.g., as a Wi-Fi, Wired Ethernet, or Cellular link. It may also be given
>> as a specific technology, e.g., as a 2G, 3G, 4G, or 5G cellular link, or
>> an 802.11a, b, g, n, or ac WiFi link. Other path elements relevant to
>> the access technology may include on-path devices, such as elements of a
>> cellular backbone network. Note that there is no common registry of
>> possible values for this property."
>> [Med37]: This is basically in a domain != from the local network
>> [TE37]: Why not in the local network? I think this specifically applies
>> to many local networks, where it's actually interesting if, e.g., a WiFi
>> AP supports 802.11ac or not. Perhaps I'm misunderstanding your comment.
>> Could you clarify, please?
> [Med] I think the disconnect is the terminology but also the architectural assumptions. Usually, access technology is used between a device an access network with distinct administrative boundaries.

[TE] Yes, it's often the first link between a device and the node which
is the first hop, such as an access point or base station. Does it help
if we just remove "in the same domain" or change it to "in the local"
network or something similar? Because I think we can define this
regardless of the larger "domain" issue.


>> On "Administrative Entity: The administrative entity, e.g., the AS, to
>> which a path element or subpath belongs."
>> [Med42]: This is an administrative domain, not * entity *
>> [TE42]: Isn't an AS also an entity?
> [Med] The administrative entity is the network operator of that AS. 

[TE] Right. We may need a different word here.


>  But yes, maybe we could have the
>> administrative domain be a property instead?
> [Med] That would make sense. For example, an application can decide to select a path that does not cross a given AS or better, an application can indicate a hint to an upstream network to avoid forwarding data via paths including a given AS.

[TE] Yes, that's the primary use case we had in mind, so we'll make sure
it's supported.


Once again, thank you for the extensive feedback and the pointers.

I'll work with my co-author Cyrill to get the next revision ready by the
Singapore meeting.

Best,
Theresa