renghardt
commented
5 years ago In the introduction, we might want to add some context on the architecture we're thinking about, as raised by Med's comments. In reply, I wrote: 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.
To [Med6], he suggested 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)."
To the crossed out part: "This is trivial; you don't even need to justify yet."
To [Med9]: "I would move it under path selection and clarify that path selection is fed with policies (e.g., trafic policies)."
To [Med10] he suggested the following text: "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."
To [Med11], he suggested: "the monetary cost to send data across a network, eventually on a given path" I don't understand why "eventually", so I asked.
To [Med12], he suggested: "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."
We also had a brief discussion that the host may be able to manipulate the path, see https://tools.ietf.org/html/draft-bernardos-sfc-discovery-03
To [Med13]: " 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."
To [Med14] he agrees with my points
To [Med16]: "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. "
To [Med17] and [Med18] he agrees with my points.
I said we'd consider his suggestions, but I didn't promise anything further and I didn't mean to make any decisions by myself - so, Cyrill, feel free to disagree with what I'm writing here!
Replying to Med's comments on the Introduction:
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? 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?
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! 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 Will see how we can rephrase this.
Crossed out: "[It is impossible to provide an exhaustive list of path properties], as with every new technology and protocol, novel properties might become relevant" 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?
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. 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?
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. True, there can be more complex interactions. Do you have a suggestion of what text to add here?
On "the monetary cost [of the link]": [Med11]: This is linked to a network, not a path. 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.
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. 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? 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.
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? 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?
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. You're 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" - 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.
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? In our current definition, they would not be domain properties. [Med16], on "Domain properties expose a high amount of information to hosts": Why? 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. [Med17], on "strongly influence the connection behavior": ? 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. [Med18]: You may need to call out your topology assumptions because some conclusions may not apply to some topologies. Agreed, and I think this leads us to a more general discussion about the scope of the draft.