License: Other
This is the working area for the individual Internet-Draft, "A Framework for Computing-Aware Traffic Steering (CATS)".
See the guidelines for contributions.
Contributions can be made by creating pull requests. The GitHub interface supports creating pull requests using the Edit (✏) button.
Formatted text and HTML versions of the draft can be built using make.
$ makeCommand line usage requires that you have the necessary software installed. See the instructions.
2. Terminology
Old
Computing Service:
An offering is made available by a provider by orchestrating a set of computing resources (without networking resources).¶
New
An offering is made available by a provider by orchestrating a set of computing resources (without networking resources in the network domain).
Reason of suggestion:
In fact, the server has network cards, which can be regards as networking resources. However, it is on the host, and belongs to the computing domain.
So, maybe some explanation can be added here.
From Nagendra Kumar:
In the example shown in Figure 2, when the client sends a service
request to "CATS-Forwarder 1"
- Can you please help me understand what type of request is this?. Is it a request from the end client requesting for a compute service to host any new service or a SF hosted in a site (host)?.
[Med] This is the request to access/invoke the service. It is not sent explicitly to the forwarder, but is intercepted. The text should be clarified. Thanks.
4.5. Service Contact Instance Affinity
Old
Specifically, the same Egress CATS-Forwarder may be sollicited to forward the packets.
New
Specifically, the same Egress CATS-Forwarder may be solicited to forward the packets.
Old
The affinity is determined at the time of newly formulated service requests.
New
The affinity is configured on the C-PS when the service is deployed, or is determined at the time of newly formulated service requests.
Reason of suggestion:
IMHO, some services, such as the Video on Demand in CDN system, can be without the Service Contact Instance Affinity by default.
A CATS implementation may rely upon a control plane or a management plane to distribute service metrics and network metrics - this document does not define a specific solution.
I'm not sure I would keep this unless further elaboration is provided. In addition, the initial text mentions underlay nodes (as far as metric distribution is concerned), which somewhat contradicts the previous statement about the underlay/overlay taxonomy: if CATS routers are not supposed to be involved in the IP/MPLS control and forwarding planes of the so-called underlay, then what's the point of feeding underlay nodes with CATS metrics?
BTW, I have read the draft, and have two small suggestions:
Computing-aware forwarding (or steeting, computing): A forwarding
(or steeting, computing) scheme which takes as input a set of
metrics that reflect the capabilities and state of computing
resources.
steet--->steering
CATS Service ID (CS-ID): An identifier representing a service, which
the clients use to access it. Such an ID identifies all the
instances of a given service, regardless of their location.
The CS-ID is independent of which service contact instance serves
the service request.
service requests are spread over the service contact instances
service requests are ---- > Service
The Egress CATS-Routers are the egress endpoints of overlay paths
I fail to see the need for this. Again, this suggests (unnecessary) distinction between two types of CATS routers at the risk of obliterating the very likely heuristic.
--Discuss more threats: integrity-protection of advertized information, origin authentication, prevent ddos, ...
4.4. Service Access Processing
Old
However, it is expected that a service request or local policy may feed the C-PS computation logic with Objective Functions that provide some information about the path characteristics (e.g., in terms of maximum latency) and the selected service contact instance.¶
New
However, it is expected that a service request or local policy may feed the C-PS computation logic with Objective Functions that provide some information about the path characteristics (e.g., in terms of maximum latency) and the preference in selecting the service contact instance.
Reason of suggestion:
IMHO, it is better to describe more generally here. It is suggested to be some information about the service contact instance, and it does not have to be the CIS-ID.
2. Terminology
old
CATS Traffic Classifier (C-TC):
A functional entity that is responsible for determining which packets belong to a traffic flow for a particular service request. It is also responsible for forwarding such packets along a C-PS computed path that leads to the relevant service contact instance.
New:
A functional entity that is responsible for determining which packets belong to CATS, and additionally, it may distinguish which packets belong to a traffic flow for a particular service request. It is also responsible for forwarding such packets along a C-PS computed path that leads to the relevant service contact instance.
Reason of suggestion:
Some services for CATS, perhaps, do not need this Service Contact Instance Affinity. However, their traffic should also be recognized and forwarded to a service contact instance.
So, IMHO, the function of the C-TC should be described more generally.
3.4.5. CATS Traffic Classifier (C-TC)
Old
CATS Traffic Classifier (C-TC) is a functional component that is responsible for associating incoming packets from clients with existing service requests. CATS classifiers also ensure that packets that are bound to a specific service contact instance are all forwarded towards that same service contact instance, as instructed by a C-PS.
New
CATS Traffic classifier (C-TC) is a functional component that is responsible for CATS traffic classification, and it may also be responsible for associating incoming packets from clients with existing service requests.
CATS classifiers can ensure that packets that are bound to a specific service contact instance are all forwarded towards that same service contact instance if needed, as instructed by a C-PS.
Not clear to me some parts fo the figures. Assuming Figure 3 is ok, then it is not clear to me the line at the bottom from CS-ID 2 up to CATS forwarder 1. Also whyService CS-ID 2 has no metrics at the bottom part in Figure 5. More clarification text can be benefitial.
3.5. Deployment Considerations
Old
In the latter case, the CATS computation logic may process incoming service requests to compute and select paths and, therefore, service contact instances.
New
In this case, the CATS computation logic may process incoming service requests to compute and select paths and, therefore, service contact instances. Or for a specific service, the CATS computation logic can compute and select paths in advance.
Reason of suggestion:
IMHO, if the controller needs to compute the path after obtaining an incoming service request packet, it is on-demand but slow.
If the controller is configured to collect the information about a specific service, it can computer the path without receiving an incoming service request packet.
Old
Centralized model:
Computing metrics are collected by a centralized control plane, and then the centralized control plane performs service scheduling function, and computes the forwarding path for service requests and syncs up with the Ingress CATS-Forwarder.
New
Centralized model:
Computing metrics are collected by a centralized control plane, and then the centralized control plane computes the forwarding path and syncs up with the Ingress CATS-Forwarder.
Reason of suggestion:
IMHO, the service scheduling is related, but may be out of the scope of CATS. So, no need to emphasize it here.
Few typos identified below:
s/single eservice/single service
s/service requests that are forwatded over/service requests that are forwarded over
[Jim Guichard as individual] From the WG pespective, we do have some high level discussion of compute metrics and deciding which service instance to use, but we do not have some specific discussion of service identifiers. For example, how to map the service ID to a specific service instance in the real network, and what’s the excat metrics for this service. We had some discussions in SFC WG but haven’t solved it yet.
[Adrian] Yes. The problem is even worse for CATS. For CATS little clusters of packets go to a specific service instance, but in SFC all packets in a flow will be forwarded to the same service instance., but in CATS, they might be forwarded to different service instances. Problem should be solved.
In the introduction，the 4th paragraph，
Old
A single service site may host one or multiple service contact instances.
New1
A single service site may host one or multiple service instances, and one or multiple related service contact instances.
Or New2
A single service site may host one service instance for a given service, and in this case one associated service contact instance; meanwhile, a single service site may host multiple service instances for a given service, and in this case one or multiple associated service contact instances.
Reason of suggestion:
It is a little hard for a new reader of the draft to understand the relationship among a service site, service instances, and the service contact instance.
IMHO, more explanation should be added here or someplace else.
A service transaction consists of one or more service packets sent by the client to the CATS-Router it is connected to
Shouldn't this be part of the Definitions section of the draft?
Currently, in the draft, it is described that:
Service contact instance:
A client-facing service function instance that is responsible for receiving requests in the context of a given service. A service request is processed according to the service logic (e.g., handle locally or solicit backend resources). Steering beyond the service contact instance is hidden to both clients and CATS components.¶
a service contact instance is reachable via at least one Egress CATS Forwarder.
A service can be accessed via multiple service contact instances running at the same or different locations (service sites).
The same service contact instance may dispatch service requests to one or more service instances (e.g., an instance that behaves as a service load-balancer).
I wonder what the an instance means here. Is it a Service contact instance, or a service instance ?
IMO, it is a Service contact instance. Thus, it can be changed to:
The same service contact instance may dispatch service requests to one or more service instances (e.g., a service contact instance that behaves as a service load-balancer).
.
If I misunderstand it, please correct me, thanks.
I also posted an email about the problem, and I hope to obtain some feedback here.
The ID is likely to be globally unique, but is that required?
usually provide relatively static service dispatching
I don't get what is meant here. Does this mean "service design remains relatively static in a sense that the resources that participate in the delivery (and the operation) of a service remain the same over time, regardless of various, yet possibly affecting criteria like the number of end-users, their location and whether they are in motion or not"? If so, I would rephrase.
3.4.6. Overlay CATS-Forwarders
Old
If a C-PS has selected a specific service contact instance and the C-TC has marked the traffic with the CIS-ID, the Egress CATS-Forwarder then forwards traffic to the relevant service contact instance.
New
If a C-PS has selected a specific service contact instance and the C-TC has marked the traffic with the CIS-ID related information, the Egress CATS-Forwarder then forwards traffic to the relevant service contact instance according the information.
Reason of suggestion:
IMHO, it is better to describe more generally here. It is not a MUST CID-ID is marked directly in the packet.
3.4.1. Service Sites, Services Instances, and Service Contact Instances
Old
The CS-ID does not need to be globally unique, though.
New
The CS-ID does not need to be globally unique, though, for example, in the case of CATS working in a limited domain.
Reason of suggestion:
IMHO, it is better to give some explanation here.
Limited Domains and Internet Protocols
https://datatracker.ietf.org/doc/html/rfc8799
It has been talked before; however, some explanation may be helpful here.
2. Terminology
Old
CATS-Forwarder:
A network entity that makes forwarding decisions based on CATS information to steer traffic specific to a service request towards a corresponding yet selected service contact instance.
New:
A network entity that steers traffic specific to a service request towards a corresponding yet selected service contact instance according to the forwarding decisions made by the decision point based on CATS information. The decision point, which is on the C-PS, is responsible for making the steering policy, and it may or may not on the CATS-Forwarder.
Reason of suggestion:
The CATS-Forwarder may or may not be the decision point for CATS.
The C-SMAs and C-NMAs share the collected information with CATS Path Selectors (C-PSes) that use such information to select the Egress CATS-Routers (and potentially the service instances) where to forward traffic for a given service demand
This wording suggests a somewhat limited role of C-PS (seemingly restricted to the selection of egress CATS-Routers), whereas the initial definition of a C-PS rather suggests path computation capabilities. I would therefore rephrase the above wording (by introducing the notion of path computation and selection besides the selection of egress CATS routers).
the "underlay infrastructure" indicates an IP/MPLS network that is not necessarily CATS-aware. The P-CS-computed CATS routes will be distributed among the overlay CATS-Routers, and will not affect the underlay nodes.
This reads like a pretty strong statement. It not only assumes that CATS routers are distinct from IP/MPLS routers of the underlay (which is highly debatable). It also asssumes that CATS routers will not affect (whatever that means) undermlay nodes: it seems to me that LIBs and FIBs maintaintes by PE routers (for example) may very well be populated by P-CS-computed routes (at least I fail to understand why not). So, I thiçnk this should deserve some elaboration. In addition, the IP/MPLSunderlay could contribute to the improvement of C-PS-computed routes (e.g., by means of Segment Routing). So, I don't think the underlay/overlay is that black and white.
--detail any required provisioning at CAN elements (booptsrapping, credentials of peer CAN nodes, services, optimization metrics per service, etc.)--
forwarded along the same path
The current wording implicitly suggests there's no room for traffic load balancing. I would relax (or clarify) this a bit as the outcomes of C-PS ccomputation may very well encourage traffic load distribution as a function of the traffic ocngestion conditions, possibly leading to multi-path forwarding policies towards a given service instance.
if the edge site can support consistently service instance selection
I don't understand what that means.
Still waiting for text from authors from https://datatracker.ietf.org/doc/draft-yao-cats-awareness-architecture/
will reach out to them later.
too many updates may affect network stability.
Not a security issue per se. This rather enoucrages a dedicated "discussion" section for all the issues that may arise from the deployment of a CATS environment - scalability, coexistence of multiple C-PS functions, traffic load balancing implications, etc. Route flap dampening is not a security consideration per se.
Hi WG,
Section 3.5, "Deployment Considerations," mentions both the Distributed and Centralized models.
However, Section 4, "CATS Framework Workflow," does not mention the Centralized model.
I suggest adding a centralized workflow to the framework. Thank you.
Thanks,
Changwang
A monolithic function that is provided by a network operator according to a specification. A composite service can be built by orchestrating multiple monolithic services.
This reads strange as the woring mixes function with service. I would encourage some consisitency, e.g., based upon the terminology used by RFC7665 (Service Function). Also, since earlier text mentions service provider, I would suggest s/network operator/service provider.
We do currently say that:
CATS Service ID (CS-ID):
An identifier representing a service, which the clients use to access it. See Section 3.2.
However, the identifiers that are used by clients is not always available in clear. There are some hidden assumptions that we need to dive into as this will have implication on the CATS Classification
Computing-aware forwarding (or steeting, computing):
A forwarding (or steeting, computing) scheme which takes as input a set of metrics that reflect the capabilities and state of computing resources.
The syntax seems incorrect or hard to be understood.
hope to make it clear for readers.
(From Luis)
I see we mention several times about “network state”, with the idea that the C-NMA will handle such information. I guess network state can be define using existing solutions/metrics. The question is, do we expect in CATS to define something in this respect on how to feed the C-NMA or what kind of existing information/metrics the C-NMA will lever on, or not? If not, probably we can state that C-NMA is expected to use existing solutions/metrics, maybe providing some reference as well, and concentrate on C-SMA.
Section 4.4 have the following, which may seem to be contradicting:
In the example shown in Figure 2, when the client sends a service request to "CATS-Forwarder 1", the forwarder solicits the C-PS to select a service contact instance hosted by a service site that can be accessed through a particular Egress CATS-Forwarder.
and
The Ingress CATS-Forwarder classifies incoming packets received from clients by soliciting the CATS classifier (C-TC). When a matching classification entry is found for the packets, the Ingress CATS-Forwarder encapsulates and forwards them to the C-PS selected Egress CATS-Forwarder.
We need to discuss if we allow both Pull/Push modes or only a mode. Then, make sure we are consistent in the doc
The C-SMA then advertises the CS-IDs along with the metrics to be received by all C-PSs in the network
This encourages some clarification about the respective roles and responsibilities of all the C-PSes deployed in the network. let alone the security and consistency issues that may arise because of such design. This should deserve an editor's note at least.
4.3. Metrics Distribution
Old
Additionally, the C-NMA collects network-related capabilities and metrics. These may be collected and distributed by existing routing protocols, although extensions to such protocols may be required to carry additional information (e.g., link latency).
New
Additionally, the C-NMA collects network-related capabilities and metrics. These may be collected and distributed by existing measurement protocols and/or routing protocols, although extensions to such protocols may be required to carry additional information (e.g., link latency).
Reason of suggestion:
IMHO, most straightforwardly, the C-NMA can measure the delay between the Ingress and the Target Egress as the metric of the network.
ingress-based overlay
This should be elaborated as it suggests some directionality that is debatable.
[1]
2. Terminology
Old
Service contact instance:
a service contact instance is reachable via at least one Egress CATS Forwarder.¶
New
a service contact instance-->A service contact instance
[2]
3.3. Framework Overview
Old
Starting from the bottom part of Figure 1 and moving to the upper part, the following planes are defined:
New
Starting from the upper part of Figure 1 and moving to the bottom part, the following planes are defined:
[3]
3.4. CATS Functional Components
Old
CATS nodes make forwarding decisions for a given service request that has been received from a client according to the capabilities and status information of both service contact instances and network.
New
CATS nodes make forwarding decisions for a given service request that has been received from a client according to the capabilities and status information of both service instances and network.
Reason of suggestion:
Sometimes, it is referred as status of service contact instance, and sometimes, it is referred as status of service instance. IMHO, it should be status of service instance.
[4]
3.4.7. Underlay Infrastructure
Old
The CATS paths that are computed by a P-CS will be distributed among the CATS-Forwarders (Section 3.4.6)
New
P-CS --> C-PS
[5]
4. CATS Framework Workflow
Old
The following subsections provide an overview of how the CATS workflow operates assuming a distributed CATS design.
New
The following subsections provide an overview of how the CATS workflow operates assuming a distributed CATS design by default.
[6]
5. Security Considerations
Old
The computing resource information changes over time very frequently, especially with the creation and termination of service contact instances.
New
The computing resource information changes over time very frequently, especially with the creation and termination of service instances.
Old
This issue could be exploited by an attacker (e.g., by spawning and deleting service contact instances very rapidly).
New
This issue could be exploited by an attacker (e.g., by spawning and deleting service instances very rapidly).
[7]
6. Privacy Considerations
Old
Since the service will, in some cases, need to know about applications, clients, and even user identity, the C-PS computed path information should be encrypted if the client/service communication is not already encrypted.
New
Since the service will, in some cases, need to know about applications, clients, and even user identity, the C-PS computed path could be encrypted if the client/service communication is not already encrypted.
Reason of suggestion:
It is confusing what need to be encrypted here, the path information or the overload of the path.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.