| Slot | Topic | Presenters |
| :-: :-: :-:
| 5 min | Agenda Bashing & Introduction | Chairs |
| 45 min | CATS Use Cases & Requirements | Kehan/Jaehoon/Luis/Tianji |
| 15 min | CATS Framework | Cheng |
| 45 min | CATS Metrics Discussion | Kehan/Jordi |
| 10 min | Flash Teasers | Cuicui/Meiling/Daniel/Cheng |
The slides are available here.
[Chairs Adrian, Med and Peng] Introduce the IETF conduct guideline.
CATS meeting goals:
1) Consolidate use cases.
2) Clarify how the requirements come from use cases.
3) Agree on a plan for the metrics item.
The slides are available here.
[Daniel Huang] (On slide 3) The definition of "computing service" is
clear enough, it would be quite complex if we add transactions related
text to the definition.
[Jeffrey Haas] There's a need for a "forwarding considerations"
section in the requirements. Inconsistent route selection may leed to
forwarding loops. Please avoid. draft-ietf-idr-5g-edge-service-metadata
provides a general mechanism in IDR WG, please take a look.
[Kehan] You mention one of the possible CATS solutions, but no time
for that now. Perhaps discuss on list.
[Peng] If you are working on solutions please consider Jeffrey's
comment.
[Jordi] (slide 11) What the meaning of R6? And R7 talks about
including network metrics - is there a dual for that for compute
metrics?
[Kehan] R6 is a basic prerequisite among all the metric-related
requirements.
[Jordi] Can be reprased as an umbrella requirement.
[Jordi] A PR in github: can use a better name istead of Resource
Model. It must be useful, inplementable in an inter-operable manner.
Better to incorperate these considerations into requirements.
[Daniel Huang] Would be rare to use raw data as input to traffic
steering. Requirements should include the normalization of service
metrics for alignment with network metrics.
[Kehan] Now we try to make the requirements as solution-independent.
Not sure if should we add it or not. Can be discussed offline.
[Peng] Please discuss on the mail list.
Chatbox conversation
[Joel] CATS will make the decision on a single place, which shuold
avoid any forwarding loops. A tunnel will be used for steering the
traffic from the ingress CATS forwarder to the egress CATS forwarder,
also avoid the forwarding loops.
[Jeffrey] Tunneling helps, but it is not a panacea. Please address
this concern before publishing related IDR standards.
[Med] Please share this to the CATS ML for discussion.
[Joel] Using IGP is wrong and already stated in the Charter. Using
overlay protocol like BGP is possible.
[Adrian] The whole point is:
- work out what data
- work out how much data
- work out the churn of the data
- work out where the data needs to get to
Then:- work out how to get it where it needs to be
[John] A mobility question: Considering the stateful service, how to
make sure that the service istance can be seleted after moving.
[Kehan] Use case in Appendix. May need to move context between service
instances.
[John] This is specific for stateful services.
[Kehan] Can discuss on the ML. Not sure the requirement can apply to
all services.
[Ketan] (Slide 11) Want to look at metrics from persective of routing
protocols. What is appropriate to be carried in routing protocol, how
fast they can change, impact on routing stability? Please capture in the
requirements document to guide the metric document.
[Kehan] We need to enrich the description of the impact on the routing
protocols?
[Ketan] Yes. Stablity. Oscillation.
[Jaehoon Paul Jeong] What is instance affinity?
[Kehan] Instance affinity is to make sure the packets can be sent to
the same instance for a transation. To cover session affinity and other
terms.
[Jaehoon Paul Jeong] Need to consider the requirements of supporting
Intelligent transportation system, such as resource placement before
deploying CATS, and based on on object movement.
[Peng] Please move the discussion to your slot, that is related.
[Cheng] We might consider to publish this useful draft as an
informational RFC because it is useful and many people are citing it.
Also, it can encourage the authors and contributors to work harder.
[Adrian] I was struck by the number of comments today and hope the
participants can move your comments to the mail list, and discuss,
contribute to the draft, that can help to move the draft faster.
[Med] Do you want to maintain your document?
[Luis] This document is not only about the requirement, but also the
interface, so we may move the requirements to the use&req document, and
focus on the definition of the interface.
[Med] The priority might not be high, you can maintain the draft, the
top priority for the WG is to move the use&req draft, so please consider
to merge into the use&req draft.
[Luis] Having a formal definition of the interface would help with
liaison with ORAN.
[Tianji] Hope to add the use and reqs in this document into the
use&reqs draft.
[Adrian] A poll:
Do you want to include 5G eEDGE in the use case draft?
Result is：
yes(11)
no(6)
no opinion(9)
57 in the room at the time
[Adrian] Please share your comments on the mail list, especially for
the guys who said "no".
[Med] Do you want to merge the content into use&req draft?
[Jeahoon] I am ok, please authors of use&req draft take a look.
[Kehan] (slide 23) There are some requirements we might use to enhance
the requirements document. We have some use cases and requirements
already, so cannot have too many use cases, we can discuss in the ML to
check if they are aligned, and decide to merge or not.
[Med] Try to focus on the main use cases.
[Jeahoon] The other thing this document does is applicability.
[Med] The only worry is it is too early for applicability statements,
so please help to focus on the existing work.
[Peng] Some text is related to service afinity, so please help on this
discussion as well.
[Adrian] A new poll referring back to Kehan's slide with the simpler
definition of "computing service" now in -04 of the draft.
Are you ok with the simpler definition of definition of computing
service?
Result:
yes(14)
no(2)
no opinion(7)
[Adrian] Looks like a reasonable result. Again, if you are one of the
people not happy, please make a fuss on the list because this is a WG
document.
[Adrian] The "new use case" that Cheng talks about is from me. It is
something I have been hearing from "value-add content providers". It is
a type of service where the compute is performed on a stream that is
being delivered from a source to a destination. This is not on-path
micro-compute the way COINRG talked about. Turns out this is not quite
in our architecture, but is close. I scribbled some ASCII art for this
at the start of the week, and I will share it to the list.
[Dan] What Adrian said comes from a project with the BBC as presented
a few meetings ago - blending content depending on the user or location.
Original CATS architecture the compute is at the end of the path, but
for object-based media the compute is along the path. Is there still
scope to make changes to the architecture?
[Med] Yes. But we need a clear understanding of the motivation and
purposes first.
[Kehan] The definition of the computing service may need some
discussions in the light of this use case.
[Med] Let's understand the use case, see if there is an impact on the
architecture, and then tune the definitions.
[Tianji] Is encrypted traffic a requirement?
[Cheng] Just open for discussion.
[Tianji] From experience in the mobile space, this opens a whole new
dimension in the architecture.
[Cheng] Yes, let's have an open discusison.
The slides are available here.
[Joel] (slide 2) We need to design our metric content and distribution
so it is available for a broad range of use cases. Must not require to
upgrade edge devices to support new use cases. So need one or a small
number of generic use cases.
[Kehan] Will explain in the following slides. A general metric will be
proposed.
[Ketan] (slide 8) You mentioned "encoded in the protocol" - mainly
interested in level 2?
[Kehan] Yes.
[Ketan] How does the score work?
[Kehan] Just a representation of good or bad.
[Ketan] How to aligns with other (existing routing) metrics
[Kehan] Need to coordinate with routing.
[Ketan] We are working on "generic metrics" so that may be something
to consider
[Cheng] We are working on some comments and welcome guys to review and
comment on the mail list.
[Haomian] (slide 6) Normalisation is unidirecitonal between levels, so
we lose information. Yes?
[Kehan] Yes some knowledge of lower level information is lost during
normalisation.
[Hoamian] Need to be careful. When we started abstraction and control
of the network 10 years ago, we got this loss of information and tried
to compact the information, bu we have now found that there is a desire
to access the raw data for some detailed measurement needs (e.g.,
diagnostics).
[Daniel] Document is well structured, but needs to focus on e2e
traffic steering.
[Jordi] Follow up on Haomian. Need metric that is generic and scalable
(Level 2), but if you ever have to go down a level the information is
there. But for the specific use case that is CATS is real-time and so
needs a quick response. One-time deployment can have access to the low
level information.
Chatbox conversation
[Joel] I had thought that the charter was clear that the integration
of CATS server metrics with routing / network measurements was an edge
server local matter. Even if we carry these metrics in a routing
protocol, they are separate metrics from the network metric.
[Cheng] L2 is the preferred one in implementation in the first
stage. L1 might be inplemented. So the proposoal should be L2 is
mandatory and L1 is optional.
[Jeffrey] L2 in the protocol would be lovely. It implies, at least
to me, that the mechanism that is taking the inputs and generating the
result is consistently applied. Other cases where the inputs are
calculated in the the L2-like metric at each ingress becomes an
incremental deployment headache.
[Joel] The servers or the egress as a proxy on behalf of the
servers, calculate the L2 metric and distribute it to the itnerested
ingress edge routers. We need to give implementors enough guidance
that the ingress routers can meaningfully compare the values from
servers implemented by different implementors.
[Jeffrey] Keeping the ingress out of the business of computing that
metric from inputs that may expand over time is what I'd find
beneficial. I have some comments on the 5g metadata draft due to the
same reasons.Chatbox conversation
[Med] @Ketan, can you please share a pointer to the generic "metric"
you mentioned? Thanks.
[Ketan]
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-15.html#section-2[Ketan]
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-generic-metric/
[Adrian] Should focus on the cast definition draft in CATS. For this
draft, it is not in the scope in CATS WG. Let's focus on the metric
definition before discussing protocols to distribute metrics.
[Tianji] L0 metrics is objective. Normalization will introduce
subobjective aspects.
[Med] Two teams will cooperate. For the WG, we will consider to adpte
the ysl-metric-definition draft. for the other draft, will no put
priority on the draft now.
The slides are available here.
[Cheng Li] This is a IDR work, and not in the CATS charter, just to
let you know that we have some work in IDR. Defining two modes: 1) Basic
mode, which reuses the extensions in 5g metatdata draft, 2) Sharing
mode, an enhancement mode, still in the early stage for open disussion.
[Adrian] Do you want to keep it or merge it into the framework draft?
[Yu Fu] We may have further work to do based on this draft, so merging
this into the framework draft as a section might not be mature now. We
need some discussion.
[Adrian] We can discuss this next time.
[Julien] Should focus on the threats in the framework, but some
solutions are added in the draft as well. Too large the scope now, need
to narrow down now. Too complicated to be included into the framework
draft.
[Yu] A early stage of this work.
[Julien] Might be doable to take inspiration to the security
consideration part.
[Yu] Thank you.
[Peng] Suggest to contribute to the framework.
[Julien] This seems a new use case, and do you want to propose a new
metric based on security policy? it may impact the metric document. Need
to discuss this before moving forward.
[Meiling Chen] Not sure that now. We can discuss further via email.
[Luis] Understand the of the idea to expose the OAM info. But who will
be the entity to handle/fix the problem? Who should manage who? The
resposiblity should be discussed.
[Adrian] We may need to add some OAM related requirements into use&req
draft.
[Daniel] Yes, will reach out to authors of use&req
[Kehan] Julien's comment reminds me, will trigger a new discussion on
the list of CATS metric scope.