[Cats] Re: draft-ietf-cats-usecases-requirements-10 ietf lastcall Artart review

["Julien Maisonneuve (Nokia)" <[e-mail]>]

Hello Kehan,
It addresses my questions, but may introduce other issues:

  *   How the application “marks” its intention is not crystal clear.
  *   This is a nontrivial functional change that likely impacts the framework and solutions drafts (not to mention implementations), is it appropriate at this (late) stage ?
  *   I fail to understand the benefit of making affinity OPTIONAL if it is not needed or requested at the application level.
Best regards,
Julien Maisonneuve.

From: Yao Kehan <[e-mail]>
Sent: Sunday, December 14, 2025 1:10 PM
To: Julien Maisonneuve (Nokia) <[e-mail]>; Tim Bray <[e-mail]>
Cc: [e-mail]; draft-ietf-cats-usec <[e-mail]>; kehan yao <[e-mail]>
Subject: Re:RE: [Cats] Re: draft-ietf-cats-usecases-requirements-10 ietf lastcall Artart review


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Julien,



Thank you so much for your reply—you’ve raised valuable points that I hadn’t fully considered. The original intent of instance affinity is to ensure better service continuity, but as Tim highlighted, it might lead to performance degradation in certain scenarios (e.g., highly skewed traffic, overloaded instances). As you also noted, this requirement must not result in inconsistent application behaviors, nor should the CATS system be involved in distinguishing or marking application-layer semantics.

To address these concerns, I propose keeping instance affinity as an optional optimization in general, while making it mandatory only when explicitly requested by the application. Here’s the revised R18:



_NEW_

R18: CATS systems MUST maintain instance affinity for sessions and transactions explicitly marked by the application as requiring such affinity. For sessions and transactions without such explicit marking, instance affinity is OPTIONAL and may be used as an optimization method based on resource status or service requirements.



This revision adheres to two key principles:

* It avoids CATS intervening in application-layer logic— the application takes full responsibility for indicating whether affinity is needed, eliminating ambiguity about CATS’ role in distinguishing session types.

* It balances flexibility and determinism— unmarked sessions allow CATS to optimize resource usage (e.g., random spray for load balancing, as Tim suggested), while marked sessions guarantee consistent affinity to preserve service continuity.



Can the modifications address your concerns?



Best regards,

Kehan


----邮件原文----
发件人："Julien Maisonneuve (Nokia)" <[e-mail]<mailto:[e-mail]>>
收件人：kehan yao  <[e-mail]<mailto:[e-mail]>>,Tim Bray  <[e-mail]<mailto:[e-mail]>>
抄　送: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
发送时间：2025-12-13 03:02:03
主题：RE: [Cats] Re: draft-ietf-cats-usecases-requirements-10 ietf lastcall Artart review


Hello Kehan,

One of your last proposals may not improve the problem:
_NEW_
R18: "CATS systems are RECOMMENDED to maintain instance affinity for stateful sessions and transactions."

How should implementers interpret that requirement ? Does it mean some implementations will maintain affinity and other may not ? How can applications adapt to an uncertain  CATS affinity behavior ?
The language suggests CATS can tell “stateful sessions and transactions” from other requests, is this the desired outcome ? If not why mention them specifically in  a general requirement ?

Best regards,
Julien Maisonneuve.

From: kehan yao <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 12, 2025 10:37 AM
To: Tim Bray <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Cats] Re: draft-ietf-cats-usecases-requirements-10 ietf last call Artart review


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Tim,

Thank you so much for your detailed review. Please see some of my replies inline below.
The modifications will be reflected in the next revision.

Best regards,
Kehan

Tim Bray via Datatracker <[e-mail]<mailto:[e-mail]>> 于2025年12月11日周四 03:44写道：
Document: draft-ietf-cats-usecases-requirements
Title: Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases,
and Requirements Reviewer: Tim Bray Review result: Not Ready

This is the ARTART review of draft-ietf-cats-usecases-requirements-10. It has
no special standing and is offered as input to further discussion of the
subject.

While I have never looked at ALTO, I spent 5+ years as an employee of AWS where
a central everyday concern was the design and operation of distributed systems,
so I feel I have some exposure to the issues being addressed.

I feel that this document is not suitable for publication as an RFC. Quoting
from the Shepherd Report:

  The WG milestones only explicitly say to adopt this document (not to publish
  as an RFC). However, the charter does not preclude this. The working group
  discussed this point and had strong consensus that publication as an
  Informational RFC would be helpful for future protocol work.

This document contains a lot of RFC 2119 language, which I don't think belongs
in an informational RFC.  After my review, I am left dubious of the claim that
this "would be helpful for future protocol work".  Perhaps this would be
suitable for leaving as a draft for guiding the work of the WG?
[KY] The working group has conducted detailed discussions on this matter previously. The authors and contributors are eager to publish this document as an informational RFC, and this initiative has received substantial  support from the working group. On one hand, it provides guidance for the CATS framework, metric definitions, solution design, and other related work. On the other hand, a more critical reason is that publication of this work by the IETF will facilitate its  reference by external parties and other organizations (e.g., 3GPP, ETSI, etc.). During the document update process, we have also received significant interest and support from outside the working group. Publishing it as an RFC may therefore better enhance  the influence of both this work and the IETF.

I found this draft difficult (and very time-consuming) to read and am not
convinced that it offers practical value.  Perhaps it is aimed at a class of
system or protocol designer who is working on problems different from those I
faced, so my experience is not relevant and the comments below are not helpful.
 If so, sorry.

The draft is extremely verbose, 11K words in length. I found it difficult to
read and understand because of this and because the language is often general
and nontechnical.  (Also the quality of the language needs work, there are many
grammatical errors.)  It would benefit from the attention of an editor with the
goal of reducing its size and increasing its clarity.  For example, I think the
entirety of Section 1 could be replaced by the following without loss of value:
"It is often desirable to distribute compute workloads across multiple compute
resources.  These resources can include servers and load balancers in data
centers and compute capacity deployed in CDN POPs.  Routing requests for
service to such nodes with the goals of providing good response to variable
loads presents multiple complex problems."
 [KY] Thanks. I do acknowledge that the document is relatively lengthy, particularly the sections on problem description and scenario elaboration. As one of the editors, my native language is not English, which  has indeed led to some grammatical errors. I apologize for this. Moving forward, I will appropriately condense redundant content in subsequent updates to improve readability for audiences with diverse professional backgrounds.

2, 3.1 Edge computing could mean two different things: Resources at CDN POPs,
or resources at infrastructure locations which are specialized at mediating
access to internal servers and the Internet. These offer functions including
load balancing and firewalling. The draft uses the term "edge" in a very
generalized way.
[KY] Regarding the question about "edge computing", please allow me to provide a brief clarification. Similar questions were raised by experts in the working group, including the chair, during the document update.  To better distinguish between the two terms, we have defined "edge computing" and "network edge" in section 2 as follows:
“Network Edge: The network edge is an architectural demarcation point used to identify physical locations where the corporate network connects to third-party networks.
Edge Computing: Edge computing is a computing pattern that moves computing infrastructures, i.e, servers, away from centralized data centers and instead places it close to the end users for low latency communication.
Relations with network edge: edge computing infrastructures connect to corporate network through a network edge entry/exit point.”

I believe that the former understanding provided by you is ‘edge computing’ while the latter is ‘network edge’. I wonder if we can reach a consensus on this point?

I am unconvinced that some of the scenarios offered are realistic:

4.1 "Cloud VR/AR introduces the concept of cloud computing to the rendering of
audiovisual assets in such applications. Here, the edge cloud helps
encode/decode and render content.” I'm surprised. Rendering AR/VR requires
considerable compute cycles and typically would be accomplished either on
client hardware (mobile phone, AR/VR headset) or in a data center server, the
results being cached by the edge. But rendering on edge devices? I don't think
so? I haven't worked on AR in a few years so maybe I'm out of date, but this is
still surprising.
[KY] Regarding AR/VR scenarios, large-scale deployment has not yet been achieved at present. However, with the emergence of more intelligent terminals (e.g., AI headsets, AI smart glasses), computing resources  deployed in edge data centers will be required to provide rendering services. While the evolution of this scenario is relatively slow, we believe it still has significant deployment potential and value for the future. For example, during the 118th IETF meeting,  the BBC shared similar work in the CATS working group—the AI4ME project. For reference:
https://datatracker.ietf.org/doc/slides-118-cats-2a-ai4me-and-bbc-cats-use-cases/

4.2 Repeated discussions of the same problem which could be summarized “try to
use the nearest edge PoP to reduce latency, unless it’s overloaded, in which
case fall back to somewhere else, while reporting the problem”
[KY] Thank you. I will refine the expressions in this section in the next update.

4.5.2 “Distributed AI training” - Is this really a thing?  It’s not my
understanding of how model building/training is done in practice.  This and the
other use cases would benefit from citations to real-world research.
[KY] First, inference is a typical use case for CATS, as it is highly sensitive to metrics such as latency and memory consumption. For distributed training, federated learning, and related technologies, there  is also strong relevance to CATS. Relevant references are listed below:
FedFog: Resource-Aware Federated Learning in Edge and Fog Networks
https://arxiv.org/abs/2507.03952
ARES: Adaptive Resource-Aware Split Learning for Internet of Things
https://dl.acm.org/doi/10.1016/j.comnet.2022.109380

The authors will add relevant citations in the next revision.

5.2, R5 “The Resource Model MUST be implementable in an interoperable manner.“
The use of RFC2119 language on such a vague, general statement feels like
mis-use to me.  This comment applies to a high proportion of the requirement
assertions.
[KY] There are some explanations after this requirement,
“R5: The Resource Model MUST be implementable in an interoperable manner. That is, independent implementations of the Resource Model must be interoperable.”
If you think this is not sufficient, how about the following modifications:
_NEW_
“R5: The Resource Model MUST be implementable in an interoperable manner. That is, metrics generated by this resource model MUST be understood and interoperable across independent implementations.”

R6: "The Resource Model MUST be executable in a scalable manner. That is, an
agent implementing the Resource Model MUST be able to execute it at the
required time scale and at an affordable cost (e.g., memory footprint, energy,
etc.)” The absence of discussion of scaling metrics such as for example “p99
latencies” is striking. Note that 5.3 is about metrics, but provides no
examples nor does it enumerate any specific metrics.
[KY] How about adding some examples at the first paragraph in section 5.2:
_NEW_
“Computing metrics can have many different semantics, particularly for being service-specific. For example, delay, measured as milliseconds (ms), can gauge packet transmission time as well as service processing time, GPU memory, measured as Gigabytes (GB) or  MegaBytes (MB) can represent the computing load that influence how many service requests that can be handled in a pre-defined time duration. These representations may entail information on the semantics of the metric or sometimes metrics may also be purely  one or more semantic-free numerals.”

R7: "The Resource Model MUST be useful." Once again, the 2119 language feels
inapplicable.
 [KY] Thanks for the criticisms.If it is not appropriate and compelling, authors could consider to delete this requirement.

R18: "CATS systems MUST maintain instance affinity for stateful sessions and
transactions." This may be true in some service scenarios but in large-scale
distributed systems it can cause all sorts of problems.  I personally was
severely bitten by a misguided attempt to provide instance affinity in a
large-scale cloud application, see
https://www.tbray.org/ongoing/When/201x/2019/09/25/On-Sharding (also have a
look at some of the other issues discussed there, which feel like they ought to
be relevant to this subject matter)

There is no discussion of shuffle sharding, which is overwhelmingly seen as a
best practice to make systems resilient in the face of inevitable server
failures.  In fact, there is little discussion of resilience in the face of
server failures. That feels like one of the big and hard problems in operating
real-world distributed systems.

 [KY] Thank you for providing the reference materials. Indeed, we lack practical experience in distributed systems. We will strive to incorporate considerations related to fault resilience in the next update.  Regarding instance affinity, after reading your blog, we agree that the current wording is overly absolute. Situations such as traffic surges could restrict system optimization options due to this requirement. Therefore, we propose weakening the wording as  follows:
_NEW_
R18: "CATS systems are RECOMMENDED to maintain instance affinity for stateful sessions and transactions."

The Security Considerations section seems short.  One of the functions required
of every system is authentication of its users, and not all classes of servers
can perform this task; how does authentication figure in the CATS ecosystem?
 [KY] Similar comments have also been raised by DNSdir review, I’ve proposed some revisions in previous thread, please take a look to see if approriate.
https://mailarchive.ietf.org/arch/msg/cats/mpjybHZE9X91EaiY7oJrSKbTFkU/

--
Cats mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>