[Cats] Bin Zhang Re: Re: Update version of CMAS

[张宾 <[e-mail]>]

Dear Zongpeng Du,

 

Thank you very much for the simple scenario. I believe we share a common understanding that a client must first obtain a CS-ID before starting any service. The public service platform plays an essential role in the CATS architecture: it defines CS-ID-related information to help clients discover an appropriate CS-ID, assists service sites in deploying the correct CS-ID, and allows service providers (clients, service sites, or third parties) to publish services. The draft does not specify a concrete implementation for this platform, leaving room for capability search engines, service AI agents, DNS, or other approaches. Nevertheless, the platform is a mandatory component in CATS.







Regarding the implementation of the public service platform, I still consider DNS unsuitable. DNS does not support "discovering a Service ID from a service description." Fundamentally, DNS is a forward lookup system: you input a known service identifier (e.g., a domain name or record name), and it returns corresponding resource records. It lacks native capabilities for fuzzy matching, semantic search, or reverse discovery.







Consider the client’s perspective: if you have no prior knowledge of CATS services, you might describe your service requirements or simply ask for all VR services and then choose one. Can DNS handle this? Probably not. However, a capability search engine or a service AI agent can do this easily. The same limitation applies to service sites deploying services.







Now consider the service provider’s perspective: do you think DNS is the right place to publish a service?







The second key point concerns the CS-ID being defined as an anycast IP address. I do not believe this is a suitable choice. Using an anycast IP address as a CS-ID essentially removes the need for a control plane in CATS to decide on a specific service instance. Once the client obtains the CS-ID, client data directly enters data-plane routing.







Anycast IP routing operates purely at the network layer and has no mechanism to interpret or act on application-level service requirements such as: (CS-ID, bandwidth: 10G, time: 10s, cost: 4). Anycast routing selects a site solely based on network topology and conditions. In contrast, the C-PS  selects a specific instance based on combined computing and network state.







Anycast IP offers a coarse-grained, network-layer mechanism, while the C-PS approach combined with C-SMA, and C-NMA enables fine-grained, application-aware selection. They serve fundamentally different purposes:







Anycast = "Get me to any instance quickly"







C-PS + C-SMA + C-NMA = "Get me to the best instance for my specific requirements"




Best regards

Bin




-----原始邮件-----
发件人:"[e-mail]" <[e-mail]>
发送时间:2026-06-12 19:13:31 (星期五)

收件人: 张宾 <[e-mail]>, "Adrian Farrel" <[e-mail]>
抄送: "miao.chuanyang" <[e-mail]>, cats <[e-mail]>
主题: [Cats] Re: Update version of CMAS




Hi, Adrian, Chuanyang, and Bin

Some personal thoughts to share here. Hope it could be useful.




We haven’t talked too much about the service discovery before, and we assumed a simple scenario. An example from the aspect of the client is shown below.

1. The client needs a specific CATS service which is deployed in many places.

2. The client can obtain an anycast IP address (CS-ID) by DNS query.

3. The client sends packets to the anycast IP address.

4. After receiving the packet, the Ingress matches some policy, and steers the packet to a proper service site.




If the service definition is kind of flexible, as you said, with stated network or compute requirements, perhaps the above scenario would not be enough. A platform may be needed, or the mechanism in DAWN would be helpful.




However, IMHO, perhaps we can leave it open about how the CS-ID is obtained. It can be obtained by using DNS, a specific platform, or a unified structure like DAWN. In other words, I think that the platform is optional guidance, not a mandatory component. Meanwhile, I also think that the Service Modelling would be helpful for the deployment of CATS.

 

Best Regards




Zongpeng Du



[e-mail] & [e-mail] 


 
From: 张宾
Date: 2026-06-12 15:21
To: adrian
CC: miao.chuanyang; cats
Subject: [Cats] Re: Update version of CMAS

Dear Adrian,




Thank you for pointing us to the DAWN effort.

This is very helpful. We will look into the DAWN documents and related discussions, especially the parts concerning service/workload discovery and compute-resource-related information.




This draft draft-moussa-dawn-gap-analysis-00 - Gap Analysis and Applicability Statement for Discovery Protocols of Agents, Workloads, and Named Entities (DAWN) evaluated 

DAWN solutions including DNS and CATS. 




I believe the entire CATS process for locating the final service instance (not the CS-ID) represents the DAWN target for service discovery.

CS-ID does not refer to a specific service instance that directly provides services to clients. Instead, it identifies a service that can be distributed across multiple service sites, all offering the same functionality.

The service platform functions similarly to an app store. It can be thought of as a service store, realized through capability search engines or service AI agents. 

Our draft does not specify the concrete implementation of the public service platform.


The following process illustrates its function, using a service AI agent as an example:

The client describes the task to be performed, including network requirements (e.g., bandwidth) and timing constraints (e.g., task completion time). This description is sent to the service AI agent.

The service AI agent returns a list of recommended services, including CS-ID, service description, input specifications, and estimated computing time.

The client selects the appropriate CS-ID that meets the task requirements and formulates a service request such as:
(CS-ID, bandwidth: 10G, time: 10s).
This request is sent to the ingress forwarder and then forwarded to the C-PS.

The C-PS determines the final service contact instance by combining:

the computing service table collected by the C-SMA, and

the network service table collected by the C-NMA.
The resulting CSCI-ID is sent back to the ingress forwarder.

A data channel can then be established between the ingress forwarder and the CSCI-ID (i.e., the service provider’s IP and port).

The entire process described above is the DAWN target for service discovery.

In this framework:

The service platform acts just as a service store that describes service information such as CS-ID, service description, input, deployment requirements, Reference GAS, and Reference Computing Time.

For the client, the platform is used to obtain a suitable CS-ID.

For the service developer, it is used to publish services for usage.

For the service sites, it is used to discover services of interest and deploy them accordingly.

We will refine the draft based on discussion and also follow the DAWN progress. Thank you very much!







 

Best Regards!

Bin










-----原始邮件-----
发件人:"Adrian Farrel" <[e-mail]>
发送时间:2026-06-11 17:40:48 (星期四)

收件人: [e-mail], [e-mail]
抄送: [e-mail]
主题: [Cats] Re: Update version of CMAS




Hi,

 

I think this is a good question and worth looking into in the context of the DAWN effort (https://datatracker.ietf.org/doc/dawn, https://datatracker.ietf.org/doc/bofreq-farrel-discovery-of-agents-workloads-and-named-entities/ and https://mailman3.ietf.org/mailman3/lists/dawn.ietf.org/)

 

You’ll note that section 6.2 of https://datatracker.ietf.org/doc/draft-kay-dawn-use-cases/ mentions “compute resources” while section 7.3 is a place-holder for more discussion of this specific use case.

 

Cheers,

Adrian

 

From: [e-mail] <[e-mail]>
Sent: 11 June 2026 10:34
To: [e-mail]
Cc: [e-mail]
Subject: [Cats] Re: Update version of CMAS

 

Hi, Bin

Thank you for the clarification. I have a follow-up question:

Could DNS serve as an alternative to the public service platform and achieve the same objectives? Given that DNS is already a widely deployed, distributed infrastructure for service naming and discovery, would it be more appropriate to leverage existing DNS mechanisms—potentially with new record types to carry service descriptions, deployment requirements, and CS-ID mappings—rather than introducing a separate platform component?

 

Best Regards!

Chuanyang

 

 

Original

From: 张宾 <[e-mail]>

To: 缪川扬10075421;

Cc: [e-mail] <[e-mail]>;

Date: 2026年06月09日 10:33

Subject: [Cats] Re: Update version of CMAS

-- 
Cats mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

Hi Chuanyang,

 

 

Thank you for your careful review and constructive comments.

 

 

Regarding the first comment, our intention is that the public service platform serves as a supporting component for the CATS architecture rather than being limited to service-oriented metric definitions. The primary purpose of the platform is to provide a common reference for CS-ID interpretation, service descriptions, deployment requirements, and service context information. This allows clients, service sites, and network elements to have a consistent understanding of what a service identifier represents, especially in heterogeneous computing environments.

 

For example, if a client want to ask for a service, how he can find the proper CS-ID that fits for his service requirment if without the service platform?

 

At present, the information model focuses on service descriptions and deployment-related attributes because these are the most immediate requirements for practical CATS deployments. However, the design is intentionally extensible and can accommodate additional service-related information in the future if required by evolving CATS use cases. We agree that clarifying the intended scope and architectural role of the platform would improve readability, and we will consider adding explanatory text in the next revision.

 

 

Regarding the second comment, the draft intentionally avoids defining a mandatory onboarding or publication procedure. Different deployment environments may have different operational policies, trust models, and administrative requirements. Therefore, the draft focuses on the information structure of a service entry rather than prescribing how entries are created, validated, or maintained.

 

 

A service entry is expected to contain information such as service identifiers, service descriptions, deployment requirements, service sites, and service context. The actual publication and maintenance process is left to local implementation and operational policy. This flexibility is one of the key advantages of the proposed approach, as it allows service information to be published by service sites, platform operators, third parties, or clients without introducing additional protocol constraints. We agree that a brief explanation of this design choice would help readers better understand the operational model, and we will consider adding such text in a future revision.

 

 

Thank you again for your valuable feedback.

 

 

Best regards,

Bin

 

 

 

-----原始邮件-----
发件人:[e-mail]
发送时间: 2026-06-08 22:31:46 (星期一)

收件人:[e-mail]
抄送:[e-mail]
主题: [Cats] Re: Update version of CMAS

 

Hi Authors,

Thank you for the work on this draft.

I read the document and think it is a useful contribution to the CATS WG. I have two comments for your consideration.

First, I am wondering whether the scope of the public service platform is intended to support the entire CATS architecture or primarily the service-oriented metrics definition. The current design appears closely aligned with service descriptions and deployment-related information. It may be helpful for the document to clarify whether the platform is envisioned as a general CATS component that could support other CATS functions in the future. A short discussion of the design scope boundaries could help readers better understand the intended role of the platform.

Second, it may be helpful to add a short description of the service onboarding or publication process. The draft mentions that a service entry may be published by a service site, platform operator, third party, or client. It may help readers if the document briefly describes what information is expected when a new service is published, and how the platform accepts or maintains such an entry according to local policy.

 

Best regards,

Chuanyang

 

 

 

 

 

From: 张宾 <[e-mail]>

To: [e-mail] <[e-mail]>;

Date: 2026年05月29日 17:53

Subject: [Cats] Update version of CMAS

-- 
Cats mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

Hi all, 

 

  We have updated draft-zhangb-cats-cmas to make it better aligned with and supportive of the service-metrics-op draft.  

This version describes a  public service platform for CATS.  The platform maintains a common  service catalogue, associates public service identifiers with service descriptions and deployment requirements, and provides the service  context used by service-oriented metric mechanisms.

 

Link  draft-zhangb-cats-cmas-04 - Public Service Platform for Computing-Aware Traffic Steering (CATS)

 

We welcome any feedback on the mailing list.

 

Best regards,

Bin Zhang