CATS Agenda for IETF 117 (San Francisco and Online)
Thursday 27 July 2023
Room: Plaza B
09:30 - 11:30 San Francisco
See Materials: https://datatracker.ietf.org/meeting/117/session/cats
Note taking: https://notes.ietf.org/notes-ietf-117-cats
Meetecho: https://meetings.conf.meetecho.com/ietf117/?group=cats&short=cats&item=1
Zulip: https://zulip.ietf.org/#narrow/stream/cats
#1 09:30 5mins Title: Intro, WG Status
Presenter: Chairs
Minute takers: Cheng Li and Daniel King
#1. Introduce the IETF Conduct Guidelines[see BCP54]:
[Adrian & Peng]
1. Resepct and courtesy
2. Impersonal discussions
3. Devise solutions for golbal internet that meet the needs of diverse technical and operational environments
4. Contribute to the ongoing work of the group
2. Milestone of adopting Use cases draft has been reached
3. Agenda introduction
#2 09:35 20mins Title: Discussion of the Terminology
Presenter: Med Boucadair
(What is a service, service instance, computing service?)
[Med] Introduce the terms of service defined in current RFCs(E.g., RFC7665) and the gap between them and the "Service"
discussed in CATS WG. People in CATS WG need to sync up on what is a "service". The definition of a service, service
instance, service contact instance is provided for discussion(Not done yet). For details of the service definition,
please see the slide of this slot.
[Joel] Good document. One nit: really a nit. One of the definitions includes the word monolithic, I dont know what that means in
this context, I would remove it. (Acked from Med)
[Cheng Li] Good start. Service and Service Instance definitions are clear, while the Service Contact Instance is not so clear to me.
Do we have a case that a Service Contact Instance which is the Service Instance itself. Will be good to have discussion further.
[Med] This use case can be covered by the definition of the Service Contact Instance. There is no assumption of whether the
Service Request will terminate at that point (Service Contact Instance) or it will be handed to some other resources.
An example in VoIP we have the service border controller and that is the only point that is visible to customers.
How the Service Contact Instance is implemented/deployed depends on the service logic.
[Daniel Huang] First definition, taking about Service Contact Instance, it should be under the CATS network. But
its function is like a Load Ballancer which is located in a DC domain, which is out of control by a routing network domain.
Second concern is about the Service definition (clear for me), should there be a unified defnition of service/interface, etc., so
that a service can be provided by multiple operators in the future.
[Med] Clarification to your first comment. Are you saying that Service Load Ballancer should be part of CATS? Or just the way we steer the request to that Service Load Ballancer?
[Daniel] The Load ballancer is not always within the routing network, but may be in the DC network. So suggest to make the Service Instance to be within the same domain.
[Jim Guichard] Nice work. I did not see any discussion of naming of services. Struggled with that in SFC. Would like to see services associated with some kind of naming.
Would also like to see the description of how the framework fits into other aspects of the service ecosystem, for example how does ALTO fit into this, how does
a consumer instantiate what CATS is providing.
[Med] Service name is not presented here because it is a little bit deviating from the framework. But it might be interesting
to be covered in the framework.
[Renan Krishna] Slide 6: Are we talking of a set of resource or an abstraction of a set of resrouce?
[Med] At the level of the instantiation of the service, it is not important and can be abstract, but when it comes to the service instance, the physical resources need to be involved.
[Renan] So maybe in the first bullet s/offering/abstraction/
[Richard Yang] We are talking about services. In Kubernetes, we do not have definition of service contact instance, we only have service instance, pod, etc. with every pod must be located
at a single host. Why not try to reuse some terms in Kubernetes to simplify the terms and framework.
[Adrian] Please keep discussing 0n the CATS mailing list to get the precise words for the framework document.
#3 09:55 20mins Title: Problem statement and use cases
#3a Presenter: Kehan Yao 10mins
Draft: https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements/
[Kehan] Introduce the use cases of CATS.
[Adrian] The draft is adopted but the work just begins, so please contribute to the work. We are not aming to include
every possible use case, we are looking for a set of use cases that will help drive the requirements.
[Arashmid Akhavain] Thanks for the work, it is a well-done draft. A service may have contradicting requirements (e.g., compute and delay): how to handle this?
[Kehan] Will consider to address it in the next revision.
#3b Presenter: Qing An 10mins
Draft: https://datatracker.ietf.org/doc/draft-an-cats-usecase-ai/
[Qing An] Introduce the basic info of AI models like AI Foundation Model and AI Customized Model, AI model training and inference.
[Adrian] Show of hand polls: Do you object to add AI into the use case draft?
The final result is 7 (Object) : 43 (No object)
[Rick Taylor] No objection to the inclusion of AI. Have a question about the AI use case in general. Some use cases are about understanding the nature of the network so you can place
the components correctly; some of the use cases are that given AI workloads, need to steer traffic to those components. First is reactive (to the state of the network and making placements),
other is proactive (and must change the network). So what is the case that CATS is trying to solve? Reactive, Proactive, or both adjustment of network?
[Adrian] We are in such an early stage that we are still finding the use cases, and trying to understand what problem we are trying to solve.
[Rick Taylor] Would suggest to focus on the network metrics or the info should be used by networks which is the work in IETF,
and leave the placement algorithms for services is not an IETF problem. (take it to other organizations).
[Adrian] Yes, we are doing traffic steering, not choice of location at which to instantiate things.
[Tianji Jiang] Not against. But it seems that the requirements are general, not specific for AI, but for all use case in CATS.
[Qing An] Yes, this is not specific for AI. Maybe unique scale of data and processing for AI. Or may find it all works with other use cases.
Discussion ended because of lack of time.
#4 10:15 30mins Title: Requirements
#4a Presenter: Luis Contreras 15mins
Draft: https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements/
[Luis] Introduce the gap and requirements of CATS
[Rick Taylor] Thank you and great requirements document. Some requirements are defined and met by
other WGs already, please do not invent again, and reuse.
[Adrian] Yes. Will not reinvent. Please read the charter.
[Carlos Bernardos] Good document, I see value. Need to be clearer as to which requirements are requirements on solutions, and which are requirements on this WG.
[Arashmid Akhavain] When you talk about metrics, are schedules part of the metrics as well, or is it just measurements you are sending back?
For example, if a service instance goes down, will you send this as a metrics/measurement?
One comment regarding to the previous presentation (AI use case), in some AI use cases, for example Federated Learning, a requirement of P2MP and MP2P
is introduced for traffic steering.
[Luis] We are cooperating to find out more requirements from use cases. For the first question, if an
instance goes down, it can not be availble in service providing (so yes, the update should be distributed).
[Dirk] Should make the requirements on the requirement level. People should care about the requirement level, such as MUST, SHOULD in the document.
For example, if a service has no access to the network metrics, can it be a MUST requirement to use network metrics?
For example, there is a MUST requirement not to introduce network state. I support this, but people should think about the consequences because it implies the state will be at the end points.
#4b Presenter: Dongyu Yuan 9mins
Draft: https://datatracker.ietf.org/doc/draft-yuan-cats-end-to-end-problem-requirement/
[Dongyu Yuan] Introduce the problem statement and requirement of end-to-end traffic steering in CATS.
[Adrian] Need t understand that we are in the requirements and architecture stage of the WG.
[Dirk] Slightly confused by the document. Need to know what is within the scope and what is out. For example, the problem of determining a service instance beyond a
service contact point is an interesting problemm but it seems out of scope of CATS. We should make that explicit and focus on the tasks within the scope of CATS.
Discussion ended due to lack of time. Please move to list.
#4c Presenter: Guangping Huang 6mins
Draft: https://datatracker.ietf.org/doc/draft-huang-cats-ps-and-requirements-of-l2-cats/
[Adrian] Regarding this document and the previous one, it could be good to write a very concise
use case, and we can see if we can add it into the use case draft and generate requirements
as well. No discussion due to lack of time.
[Mohamed Boucadair] [via chat] For the L2 draft, this is more related to the NERG work within BBF.
As a use case, yes, but as far as the fundamental question goes (see last message of mine), I think it is still interesting.
[Cheng Li] [via chat] I am working in BBF as well, and I have the same feeling with Med.
L2 steering seems irrelevant to CATS, or not important for now. But it MAY have some value in the future
#5 10:45 10mins Title: Framework and Architecture
Presenter: Huijuan Yao 10mins
Draft: https://datatracker.ietf.org/doc/draft-yao-cats-awareness-architecture/
[Adrian] No discussion due to lack of time. We do not want to have two framework drafts, so please work with the authors
of the other framework draft and see what is the difference and what can be added into that draft.
[Dirk] [via chat] Putting the mic comment to the list here: it would be really useful to add proper actor models to the arch
discussions, particularly since we must foresee information that is likely to cross actor boundaries (e.g., from SP to CP).
#6 10:55 20mins Title: Compute Metrics
#6a Presenter: Zongpeng Du 10mins
Draft: https://datatracker.ietf.org/doc/draft-du-cats-computing-modeling-description/
[Adrian] No discussion now due to lack of time. But queue open for end of meeting.
#6b Presenter: Linda Dunbar 10mins
Draft: https://datatracker.ietf.org/doc/draft-dunbar-cats-edge-service-metrics/
[Adrian] Appologies from the chairs: we should have trimmed the slides to get rid of the solution protocol work that is not in scope, and have just left the discussion of metrics.
No discussion due to lack of time, but queue still open.
#7 11:15 10mins Title: Environmental Considerations
Presenter: Jing Wang
Draft: https://datatracker.ietf.org/doc/draft-wang-cats-green-challenges/
[Adrian] This green work is potentially in in scope (AD said at last meeting), but it should not slow down the basic metrics work.
I will also be visiting ALTO later, and we may organise a joint interim meeting to discuss metrics if we need.
#8 11:25 5mins Title: Open Discussion and Next Steps
Presenter: Chairs and All
[Dirk] [And from chat] If we had a good metric for energy (current khW reading of the server I am hanging off
as an instance?), exposing and acting upon a "green metric" should be naturally possible in CATS,
shouldn't it? We discussed this on the list, even using a simple cardinal to outline the energy usage
capability (even changing over time but I assume those not changing at frequent interval). Use a simple
weighted round robin across those service contact points with the energy cardinal being the weight, you
get e-CATS.
Look at CCPP in W3C which is an interesting f/w to allow modeling of compute capabilities.
[Luis] Comment to LInda's presentation, I recommend not using static delays because the delay is changing all the time.
[Julien] See requirements from different use cases. Need better tracking between use cases and requirements (which requirements come from which use cases).
It is hard to see where the requirements are coming from. Some requirements do not seem to have specific use cases. And because the use cases are very
high level, it is hard to create corresponding requirements.