CATS @ IETF-119
Friday 22 March 2024
Room: M4
13:00 - 14:30 Brisbane
See Materials: https://datatracker.ietf.org/meeting/119/session/cats
Note taking: https://notes.ietf.org/notes-ietf-119-cats
Meetecho:
https://meetings.conf.meetecho.com/ietf119/?group=cats&short=cats&item=1
Zulip https://zulip.ietf.org/#narrow/stream/cats
Note takers: Cheng Li and Adrian Farrel
1 13:00 10mins Title: Intro, WG Status
Presenter: Chairs
[Peng&Adrian] Chairs introduce the progress of CATS WG, including
accepting use case draft and framework draft as planned.
No comments on the agenda.
2 13:10 10mins Title: CATS Problem Statement, Use Cases, and Requirements
Presenter: Kehan Yao
[Kehan] Update of the use cases.
- Merged the content from Alibaba's draft regarding AI use
cases(Computing-Aware AI Lagre Language Model ).
- Added R9, deleted R14.
- is SFC is a use case of CATS? Summary of the discussion in the CATS
WG ML.
- Next step: Update the service definition in the existing two WG
drafts?
[Daniel] Wrt 1st question: we should update the draft accordingly.
Especially because of the mailing list discussion about SFC, we ned
to clarify what is the "computing service" under the CATS
architecture. From my point of view, in SFC the service function is
a networking service function not a computing service function.
[Cheng] We should update the computing service definition in both
drafts as soon as possible.
[Peng] It's good to have this discussion and we need to record the
consensus of the relationship between CATS and SFC.
[Adrian] Please don't leave it to the editors of the documents to
come up with a new definition of a computing service. If you have an
opinion, please put it on the list.
[James] (From the chat) SFC comments seem right.
[Med] (From the chat) Here the def we have "Computing Service: An
offering is made available by a provider by orchestrating a set of
computing resources (without networking resources)." Not sure which
modification is needed.
[Adrian] (From the chat) I think the concern is about whether
it is an on-path service or an "end-point" service.
[Kehan] (From the chat) From my point of view, the difference is
that "Computing service" at endpoints need to be aware of
application content, that is to process application layer
information carried inside the payload. While "Service" in SFC
doesn't directly process these information, but will implement
network functions on-path.
[Adrian] (From the chat) That is a good point. On-path for SFC
tends to be seen as packet by packet. CATS is definitely
"transaction-based". But the BBC use-case seemed to be somewhere in
between. @Kehan, please make sure this moves to the list or we will
lose the discussion!
3 13:20 15mins Title: A Framework for Computing-Aware Traffic Steering (CATS)
Presenter: Cheng Li
[Daniel] In the latest version, the stop of the service traffic would
be the service contact instance, so where is service instance positioned
in architecture? Suggest we need to clarify service instance. From my
point of view control plane and data plane don't have anything to do
with service instance, only service contact instance.
[Cheng] Need to discuss this on list. The service contact instance is
to avoid too many details of service instance.
[Peng] thanks for the hard work to merge the drafts. Still some
adoption comments to address. Please also be aware of other drafts that
might give input.
4 13:35 25mins Title: Compute Modeling and Metrics
Presenter: Zongpeng Du (remote) 15mins
No comments.
Presenter: Luis M. Contreras 10mins
[Daniel] Steering decision is made based on network and service
metrics. Need to make the computing metrics compatible with network
metrics. Need to be careful about "complex" metrics. I agree with
Zongpeng's proposition to make the computing metrics as simple as
possible.
[Luis] We want to re-use as much as possible. Tricky point is not
having a clear view of what steering needs. Zongpeng refers to "server
load" but is that related to the service function of the server
resource? Look at whole service lifecycle to understand what metrics we
could consume, and then identify what could be useful for traffic
steering.
[Cheng] Thanks for the work, I will participate more. Regarding the
metrics from Computing to the Network, it should be done in CATS WG. But
I am not sure that where we can do the work for the metrics from the
Network to the Computing side.
[Luis] Work to be done in CATS, but charter is so specific so we might
lose some other metrics [needed for other purposes] e.g., server load.
So our approach is to list all metrics and then narrow the scope for
CATS.
[Dongyu]
- Sevice deployment and service selection is about steering to one
place. When we steer traffic to a service contact instance, it may
create a new service instance as needed.
- Joint exposue of metrics may have same dimensions (network and
compute) and may be treated as having a cumulative form, but some
compute metrics may need to be evaluated individually. So may need
to classify metrics.
[Luis] 2nd point is completely right. Need to identify base
metrics and those which are more sophisticated.
For 1st comment, I think you are saying they could be processed at
the same time in the service life cycle, but even if they can be
processed together, you may have different needs in the different
stages.
[Adrian] Really pleased to see work on these two drafts because it
has been a big hole in the CATS work. Ideally we would have generic
metrics useable across many applicatoins, but also we do not want
CATS getting bogged down in discussions of applications with
different or wider scopes than CATS. In particular, we need to (and
don't yet) understand what can be exposed by servers, and what the
steering points need to know.
[Adrian] Please think about how we want to advance the discussion
of metrics. Waiting for new revisions and discussing at IETF-120
seems too slow. We might have an interim, we might set up a Design
Team to meet regularly, we might just discuss on the list. I'll
bring this to the mailing list to come to a decision.
[Jeff] Two questions(see question a and b below):
a. Wrt path selection/computation. Do you envisage where next
element in the path could be dictated by the previous one, rather
than fully computed path like we do in PCE?
[Luis] No. I need to think.
[Adrian] We don't do paths in CATS. We do steering onto paths.
[Jeff] Sure, but what if path resolution is dynamic based on
previous computations?
b. Selection may be based not only on available resource, but on
proximity between elements. Collective operation requires everybody
to do the same thing at the same time. Do you envisage including
proximity as a metric?
[Luis] Maybe this could be delay or latency.
[Jeff] There could be an array of latencies.
[Jeff] To the chairs... Are collective operations in scope of this
workin group? There is other work on compute metrics elsewhere in
the IETF (e.g., 2 I-Ds in RTGWG related to in-netwrk computing).
What part should be here and what part somewhere else? Will send
pointers to the I-Ds to list after the meeting.
5 14:00 10mins Title: Compute-Aware Traffic Steering for Midhaul Networks
Presenter: Luis M. Contreras
[Tianji] I see a bug here. You are having a DU to select one CU (of
many candidates). but, the DU does not have the IP info yet (the PDCP is
between UE and CU).
[Luis] Consider ORAN. We need to think what will be the interaction
between the SMO and transport management entity.
[Tianji] Your PDCP IP stack is on the client. But in the middle, I
don't know how you are going to get the IP level.
[Luis] In Midhaul you have IP connectivity. You tunneling the
preprocessed signal across tunnels. You are doing CU to DU over IP
tunnels. The payload is not IP.
[Tianji] (From the chat) Luis, for your draft, you are having a DU to
select one CU (of many candidates). but, the DU does not have the IP
info yet (the PDCP is btwn UE and CU). Here we are talking about CATS;
so how to fit into the IP?
[Peng] (From the chat) Tianji, you can also send the question to the
mailinglist.
[Tinaji] Further, your suggetion is really impacting the RAN
behaviors; might involve (unnecessary) handover. so, I am seeing
pushback for sure from wireless people.
[Luis] (From the chat) Thanks Tianji for the question. The traffic
between DU and CU is encapsulated in IP network, for instance using VPN
or slices. This is documented in O-RAN Xhaul Packet Switched
Architectures and Solutions 7.0 from the O-RAN alliance, accessible
here: https://orandownloadsweb.azurewebsites.net/specifications
Regarding your second question, it is very pertinent, and one of the
aspects to consider. The frequency of selection between CUs would
probably be not so frequent as in other CATS cases. It would be much
more tactical for instance depending on the status of the compute
infrastrcuture supporting the virtualized CU. That is, changing the
association when problems in the existing CU will appear.
[Tinaji] (From the chat) Luis, thanks for the info. I am afraid your
draft suggests changing the RM process, especially how the gNB (CU) is
selected from the RAN spec (this is nothing related to IP)
6 14:10 10mins Title: Analysis of methods for distributing the computing metric
Presenter: Hang Shi
[Daniel] Two questions(see question 1 and 2 below)
- In my view the metric will only be distributed within the CATS
architecture which does not include the consumer. Why take the
consumer into consideration.
[Hang] The "consumer" here is the C-PS
- The computing site will expose computing information "unmodified."
Don't assume that the computing site will do anything special for
CATS. So CATS forwarder or SMA has to make refinement according to
CATS architecture.
I like the idea of a DT to discuss metrics
[Hang] Yes, may be a difference between the metrics exchanged
between the computing side and the SMA (outside the CATS
architecture), and between the SMA and C-PS (inside the CATS
architecture). You're assuming that the server side does no
aggregation or preprocessing of the computing metrics and it is done
by, for example, the C-SMA.
[Peng] This draft is about how the CATS system distributes the
CATS metrics. There is a point about what information CATS can get
from the servers.
[Adrian] We need a feedback loop between this draft and the
metrics draft. Now we have this formula we need to know (e.g.) what
is the metric size. So we can then start to rule out options for
distributions.
[Med] (From the chat) Not fan of DTs, it would be great to trigger
discussion on the list on the metric distribution.
[Adrian] (From the chat) Yes. The question is how to force some
progress on this. Sometimes meetings can make people concentrate on
what needs to be decided. I really don't want us all to leave
Brisbane agreeing that "something needs to be done" but then not do
anything until we see the deadline for IETF-120.
[Med] (From the chat) Same here
[Cheng] (From the chat) At least for me, two work should be done
after the meeting. 1. address the comments of framework draft
received in WG adoption call. 2.trigger the discussion, even create
a Design team to accelerate the discussion. But indeed, we need to
pay more attention to the work, it is not easy, and will not be done
in several days.
7 14:20 10mins Title: Flash presentations of possible solution technologies – “Please read my draft”
7a 2mins Computing-Aware Traffic Steering (CATS) Using Segment Routing
Presenter:Cheng Li
7b 2mins CATS based on Real Locator
Presenter:Hang Shi
7c 2mins Application-aware Computing Network
Presenter:Hang Shi
7d 2mins Computing Aware Traffic Steering using IP address anchoring
Presenter:Carlos Bernardos/Alain Mourad
[Adrian] It is a little bit early to discuss solutions, but these were
flash talks to draw people's attention to the work. We are talking about
how to get the packets across the network and mark them, but we also
need to talk about how we make the steering decisions.
A show-of-hands about flash talks is raised.
- Do you like having flash presentations like these?
Result is 18(Yes) : 1(No) : 1(No opinion)
Another show-of-hands for the discussion of metrics:
- Would you like to be driven on the metrics discussion by the chairs
scheduling some form of meeting?
Result is 15(Yes) : 4(No) : 5(No opinion)
[Adrian] This is good information for the chairs. We will consider how
to action it.
8 Open Discussion and Next Steps(if there is anytime)
Chairs and ALL
No further points were raised.