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

From: <[email-masked]>
Date: Tue, 24 Sep 2019 14:58:27 +0000

Hi Theresa,

Apologies for the delay to reply. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Theresa Enghardt [mailto:[email-masked]]
> Envoyé : mercredi 7 août 2019 13:59
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> Objet : Review (was: Re: [PANRG] The PANRG RG has placed draft-enghardt-
> panrg-path-properties in state "Candidate RG Document")
> 
> Hi Med,
> 
> thank you for the detailed read and the extensive review! Your comments
> are greatly appreciated.
> 
> I'm first replying to your general comments inline and then inserting
> the specific comments and my responses at the bottom of this e-mail.
> 
> 
> On 06.08.19 14:37, [email-masked] 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. 

> In our internal Github wiki, we are collecting links to different
> definitions and other references:
> https://github.com/theri/draft-enghardt-panrg-path-properties/wiki -
> Maybe this plus some discussion of the differences between their and our
> definitions could become an appendix to our document at some point?

[Med] You have already done a great job in collecting the documents. 

> Feel free to point out more documents or work that you feel should be
> included here.
> 
> 
> > * The document implies some architectural assumptions that are not
> justified (e.g., domain vs. backbone, hosts assumed to be within the same
> domain as the access network, etc.)
> 
> We introduced the classification into domain properties, backbone
> properties, and dynamic properties in the hope that such classification
> might make it easier to talk about different properties, use cases, etc.
> However, right now I'm not sure if the current classification into
> "domain" and "backbone" properties is indeed the right way to go

[Med] OK.

> 
> In the draft we give a number of reasons why it may matter if a path
> element that has a specific property is in the same administrative
> domain as a host or not.

[Med] Those are fine. 

 I'm sure there are considerations here that
> already touch upon other research questions in the Questions draft,
> e.g., the second question of Discoverability, Distribution, and
> Trustworthiness of path property. However, the second question already
> asks how an endpoint can get access to trustworthy path properties,
> which we do not attempt to answer in the path properties draft.
> 
> I think here we should try to find the sweet spot between a narrow focus
> on "just terminology" vs. an extensive discussion of where path elements
> may be located, who may control them, and how this may influence path
> properties and their availability, etc.

[Med] Agree.  

 I'm sure we can have useful
> discussions here, which may have an impact on our definitions of path
> properties, but we should also make a conscious decision of how much of
> this to put in the path properties draft.
> 
> I'm very interested in getting input from the Research Group regarding
> this question.
> 
> 
> > * Some terms are already defined in existing RFCs, no need to define new
> ones (e.g., one-way delay, one-way delay variation, one-way loss, etc.).
> It is OK to list them, but with pointers to the authoritative RFCs.
> 
> Yes, our intention is to list path properties, not to redefine a
> property if it already exists (or something very similar exists). We
> will add references to existing definitions.

[Med] Great, thanks. 

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

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

 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. In short, a path can be zoomed in/out as a function of the context. Moreover, a path does not need to be strictly defined; loose mode should also be supported.     

> 
> 
> > My review of the draft is available at:
> >
> > * pdf: https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/draft-enghardt-panrg-path-properties-02-rev%20Med.pdf
> > * doc: https://github.com/boucadair/IETF-Drafts-
> Reviews/raw/master/draft-enghardt-panrg-path-properties-02-rev%20Med.doc
> 
> Responses to the individual comments follow:
> 
> On "This document defines and categorizes information about Internet
> paths that an entity, such as a host, might have or want to have.":
> 
> [Med1]: This assumes a global connectivity. I don’t think this
> restriction is justified (consider enterprise networks, mesh networks,
> etc.).
> [TE1]: I agree - perhaps change "Internet paths" to "paths across a
> network"?
> 

[Med] That's better. Thanks. 

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

> 
> On "This information is expressed as properties of paths between two
> hosts."
> 
> [Med3]: A host will have a partial visibility of the available path(s)
> (and their associated services). The full visibility cannot be
> established beforehand. Furthermore, such information is volatile (e.g.,
> handover or multi-attachment with session continuity).
> [TE3]: I agree, but I'm not sure I want to add text to the abstract
> based on this. I don't think we imply full visibility here if we talk
> about "information" that a host can get about paths. But we have to make
> sure this point is clear in the body of the text.

[Med] Works for me. Thanks.

> 
> [Med4]: GENERAL: the properties are dependent of the direction. Some
> properties will apply for inbound, outbound, or both.
> [TE4]: I agree, and I think our (planned) definition accounts for this:
> Links are unidirectional, the reverse direction is another
> unidirectional link between the same nodes, and a property applies on a
> sequence of path elements.

[Med] The point is to make this clear in the draft. 

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

> About the text of the abstract, perhaps changing this to "[properties of
> paths] between two or more nodes" helps?

[Med] OK.

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

> 
> On "A Path Aware Network exposes information about one or multiple paths
> through the network":
> [Med7]: I do still believe this is a weird term: networking is about
> manipulating paths, by essence!
> [TE7]: Well, hosts do not usually directly manipulate paths, unless they
> do source routing, right? Anyway, the term "Path Aware Network" is taken
> from the questions draft, which is an adopted Research Group document,
> so I wouldn't change it and introduce even more terms in the process.
> 
> [Med8]: Difficult to parse
> [TE8]: Will see how we can rephrase this.

[Med] Thanks.

> 
> Crossed out second part of this sentence: "[It is impossible to provide
> an exhaustive list of path properties], as with every new technology and
> protocol, novel properties might become relevant"
> [TE]: Is the comment here that the crossed out part does this not work
> as an explanation of the first part of the sentence? Why not?

[Med] This is trivial; you don't even need to justify yet. 

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

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

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

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

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

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

> 
> On "[a non-dynamic path property might stay relevant, e.g. a NAT can be
> assumed to stay on a path during the lifetime of a connection, as the
> removal of] the NAT would break the connection."
> [Med14]: Not for MPTCP/QUIC.
> [TE14]: Right, this was written with single-path TCP in mind.
> Perhaps change this to "a non-dynamic path property might stay relevant
> for a longer period of time, e.g. a NAT typically stays on a specific
> path during the lifetime of a connection involving packets sent over
> this path"

[Med] Yes. 

 - this leaves it open whether NAT rebinding occurs and
> whether additional packets of the same connection are sent over
> different paths. I think the only case in which the "typically" does not
> apply here is if the NAT were to be removed from the specific path,
> e.g., the NAT functionality of the router switched off. And this I find
> unlikely to occur during most connections.

[Med] Indeed. 

> 
> On "Non-dynamic properties are further separated into (local) domain
> properties related to the first few hops of the connection, and backbone
> properties related to the remaining hops. Domain properties expose a
> high amount of information to hosts and strongly influence the
> connection behavior while there is little influence and information
> about backbone properties."
> [Med15]: Advanced service (e.g., NAT, IDS, ..) may be located in a
> Centralized PoP or hosted by a third party (DDoS protection, for
> example). Do you consider these as domain properties?
> [TE15]: In our current definition, they would not be domain properties.
> 
> [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. 

> 
> [Med17], on "strongly influence the connection behavior": ?
> [TE17]: The assumption here is that, for example, performance may be
> more strongly influenced by the access network because it includes the
> bottleneck or a proxy. This doesn't always hold though, and perhaps we
> need to revisit our assumptions.

[Med] Agree. 

> 
> [Med18]: You may need to call out your topology assumptions because some
> conclusions may not apply to some topologies.
> [TE18]: Agreed, and I think this leads us to a more general discussion
> about the scope of the draft.

[Med] OK, thanks. 

> 
> On "Host":
> [Med19]: I personally prefer the definition in RFC1122 ["Host: ultimate
> consumer of communication services. A host generally executes
> application programs on behalf of user(s), employing network and/or
> Internet communication services in support of this function."]
> [TE19]: Thanks for the suggestion, I really like this definition, too.
> The distinction based on "processes packets that are addressed/not
> addressed to [a node]" has its problems, as this does not say on which
> layer we consider the addresses, this gets more complicated with
> encapsulation, etc. So I'm in favor of changing our definition of a host
> to something along the lines of RFC 1122.

[Med] Great. 

> 
> [Med20]: This is about receiving. You may also cover sending
> [TE20]: We understand "processes packets" to include both sending and
> receiving,

[Med] Hmm. The text says "processes packets that are *** explicitly addressed to itself ***"

 but I suggest we switch to a different definition as
> discussed above.

[Med] OK.

> 
> On "Path element: Either a node or a link."
> [Med21]: This definition does cover, for example, the case of a path
> identified by an ordered list
> of AS Number. Check for example the definition of ERO in RFC3209, or
> even in recent documents
> such as RFC7570
> [TE21]: True. ERO can include groups of nodes, possibly this can mean
> entire ASes. As said above, we may want to allow "aggregated" path
> elements that are entire networks, represented by the network's AS number.
> 

[Med] Looking forward reading your updated text. 

> On "Path: […] alternating between nodes and links":
> [Med22]: This definition excludes recent notion such as SFP defined in
> RFC7665
> [TE22]: (Repeating the reply from above) 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] See my reply above. 

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

> On "Property: A trait of one or a sequence of path elements […]"
> [Med24]: I’d like to double check If the defining covers also the
> concept of SFC/SFP. The path will be built to accommodate a property
> (result of SFC).
> [TE24]: I think this depends on how we define the sequence of path
> elements, see above, to make sure we cover these concepts.
> 
> On "Aggregated property: A collection of multiple values of a property
> into a single value, according to a function."
> [Med25]: Note this cannot be applied to all properties of a connectivity
> service.
> [TE25]: Correct. For all properties of a connectivity service, you would
> need a set of all aggregated properties.
> 
> On "Measured property: A property that is observed for a specific path
> element or path, e.g., using measurements."
> [Med26]: I prefer « Observed » rather that measured because properties
> may not only be about traffic performance metrics.
> [TE26]: True, we define lots of other properties for which we can
> observe a value. So we may change this.

[Med] OK

> 
> On "Estimated property: An approximate calculation [CROSSED: or
> judgment] of the value of a property."
> [Med27]: As above, this is too measurement-centric. This may not be
> applicable to all properties.
> [TE27]: The intention of the "or judgment" is to express that this may
> not be a numeric and/or performance-related property. I understand
> "estimate" to be broader than numerical but rather to include "an
> educated guess". However, it seems to me like most words in this space
> imply numeric values. So I'm looking for the right word here - does "An
> approximate calculation or assessment of a numeric or non-numeric value
> of a property" work? Any other suggestions?

[Med] "approximate assessment" would be OK.

> 
> On "3. Domain properties":
> [Med28]: I’m afraid this section (and section 4) implies architectural
> considerations which may not be appropriate in a terminology document.
> [TE28]: As the scope of this document is to answer the first question of
> the Questions draft (Section 2.1 in draft-irtf-panrg-questions), "how
> are path properties defined and represented?", yes, this is a
> terminology document, but I wonder if possible classification of path
> properties is in scope. Here, our intention was to introduce such
> classification (e.g., dynamic and non-dynamic) to make it easier to
> reason about different properties, their usefulness, etc. Repeating what
> I wrote above, I'm not sure if the classification into "domain" and
> "backbone" properties is indeed the right way to go, and I'm very
> interested to get input from the Research Group here.
> 
> On "the first few hops":
> [Med29]: 2, 10 ?
> [TE29]: We kept this intentionally open to cover both cases in we really
> consider only the first hop and cases in which we consider the entire
> access network behind that hop as well. I think deciding whether we want
> a clear definition here depends resolving the issue raised by the
> comment [Med28] above.
> 
> On "the same administrative domain as a host considering them."
> [Med30]: L2, L3, ?
> [TE30]: Personally I mostly think about domains in this document as
> everything covered by the same AS, but yes, it would be very interesting
> to come up with a clear definition of domain here.

[Med] Noted. 

> For example, PCE defines a domain as a "collection of network elements
> within a common sphere of address management or path computation
> responsibility, can be IGP areas, ASes, multiple ASes within a Service
> provider network. may also exist as sub-domains of areas or ASes.".
> PANRG is more broad, but maybe we can come up with something similar here?
> Again, I think deciding whether we want a clear definition here depends
> resolving the issue raised by the comment [Med28] above.
> 
> [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. 

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

> Again, I think deciding whether we want a clear definition here depends
> resolving the issue raised by the comment [Med28] above.

[Med] Indeed. 

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

> Physical proximity is easier, I think: A WiFi AP may send out
> information of its currently observed channel utilization within QBSS
> information elements. A host only gets this information because it's
> directly connected to the AP, which implies physical proximity.
> Again, such considerations already touch upon the second question of the
> Questions draft.
> 
> [Med33], on the same text: I’m not sure about this.
> [TE33]: This may not always be the case, naturally. We just thought it
> might be helpful to state that it might be the case to motivate our
> classification into domain and backbone properties.
> Again, this depends on [Med28] resolution.
> 
> On "hosts may be able to influence […] which domain they are in"
> [Med34]: Connecting to a domain does not mean that the host belongs to
> that domain.
> [TE34]: Then this is a wording issue and we should change something in
> our definition to "connect to a domain" or "be in a domain" instead of
> "belong to a domain".
> However, again, this depends on [Med28] resolution.
> 
> On "they may be able to influence the properties of path elements within
> this domain."
> [Med35]: An example ?
> [TE35]: Given in the rest of the paragraph: "when connected to an Access
> Point, the user may move
> closer to enable their device to use a different access technology,
> potentially increasing the data rate available to the device."
> 

[Med] I still have an issue with the notion of domain. 

> [Med36]: How a host can influence the one-way delay provided by a network?
> [TE36]: Probably not. We never suggest that a host can influence ALL
> properties.
> 
> 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.

> 
> On "[Monetary Cost: The price to be paid to transmit a specific flow
> across a] subpath."
> [Med38]: A network
> [TE38]: Right now, in the context of a path, all path elements within
> the network form a subpath. So this applies to the subpath. However, if
> we extend our terminology to include aggregated/abstract path elements,
> maybe we can have an abstract path element that represents a network.
> 
> On "Typically, backbone properties are less accessible to a host than
> domain properties, due to the potential increased distance and the lack
> of pre-existing trust or contractual relationship."
> [Med39]: Not sure about this.
> [TE39]: Not sure if "typically" is the right word here either, but,
> similar to the part with [Med33], the intention is to say that this
> might be the case.

[Med] OK, but still don't see the need to have such assertion included. 

> 
> On "hosts are less likely to be able to influence which path elements
> form their path in the backbone, as well as their properties."
> [Med40]: This may contradict with slicing use cases.
> [TE40]: Sounds interesting. Could you point me to a specific reference,
> please?

[Med] see, e.g., https://tools.ietf.org/html/draft-homma-slice-provision-models-00 

> 
> On "Presence of a certain [CROSSED: network] service function on the
> path":
> [Med41]: To be aligned with RFC7665
> [TE41]: Agreed.

[Med] Thanks.

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

 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.

The same considerations would apply for application-specific domains such as ITADs (IP telephony administrative domains, https://www.iana.org/assignments/trip-parameters/trip-parameters.xml#trip-parameters-5). 

> 
> On "Disjointness":
> [Med43]: you may also refer to the PCE RFCs which defines also the
> notion of near disjointness
> [TE43]: I found RFC 4655 saying "The path computation request may
> include a significant set of requirements, including the following: […]
> the number of disjoint paths required and whether near-disjoint paths
> are acceptable", but it does not define what near-disjoint is. Is there
> a specific degree of disjointness that is generally still considered
> "near"? Anyways, I think if a host or other entity knows about the
> degree of disjointness, it can decide whether this is "disjoint" enough.
> Maybe we want to add a reference to PCE as an example use case.

[Med] That would be helpful. 

> 
> On "Latency", "Latency variation", "Packet loss":
> [Med44]: Please use conventional terms : one-way delay, one-way delay
> variation, one-way loss, etc.
> [TE44]: Yes, it might be useful to use terms as defined, e.g., in IPPM,
> and add references here.

[Med] Thanks. 
> 
> 
> Again, thank you for the extensive feedback.
> 
> Best,
> Theresa

---

From: Theresa Enghardt <[email-masked]>
Date: Mon, 30 Sep 2019 19:24:35 +0200

Hi Med,

thanks for the responses.

Some replies inline:

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

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

> [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…

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

> [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?

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

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

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

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

>     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 invoke…

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

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

>       in which case the host needs to be aware of paths involving that firewall.

[TE] Makes sense, thanks!

> A path may not be pre-defined, but be imposed by a host in such cases.

[TE] Agreed.

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

> I would just remove such statement. 

[TE] We'll consider doing that.

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

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

> [Med] May be, but my main concern (still) is whether there is a need to define domain/backbone.

[TE] I see.

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

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

> [Med] The administrative entity is the network operator of that AS. 

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

> [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 for…

[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