If an instance is not specified with a fixed network location, then (some network) metrics (from a client to the instance) may be not well defined (or becomes a set or a vector). In k8s, a pod is required to be at a single host. Is there a similar concept of pod in the terminology?
", "time": "2023-07-27T16:48:48Z"}, {"author": "Joel Halpern", "text": "As far as I know, we are not defining, nor using, the term \"pod\" as it is very deployment specific. As I understand it, the entitiy which matters from the point of view of CATS is what this draft calls the \"service contact instance\", and it is the job of advertising the properties of that to take care of internal variation.
", "time": "2023-07-27T16:53:07Z"}, {"author": "Dirk Trossen", "text": "Having had originally some pain on the introduction of the 'service contact point', I do actually now like it, when looking at the system from E2E point of view. It outlines the entity exposed to the CATS system, while still leaving the option of locally further dispatching requests, e.g., using a local dispatcher like a pod in K8S, subject to its own policy. Hence, I am quite supportive of that change.
", "time": "2023-07-27T17:01:18Z"}, {"author": "Mohamed Boucadair", "text": "Richard, Joel is right here.
", "time": "2023-07-27T17:02:42Z"}, {"author": "Cheng Li", "text": "thinking from a object oriented way, it is good to have a service contact instance. But let's make clear of what it is actually.
", "time": "2023-07-27T17:02:43Z"}, {"author": "Eduard V", "text": "Is my assumption right that \"Service Contact\" is in fact \"Service\" for us? We do not care what would happen after this -> real service is not networking business.
", "time": "2023-07-27T17:04:25Z"}, {"author": "Dirk Trossen", "text": "@joel On monolothic, I agree with your point. While capturing that there may well be a notion of composition may be useful, but this is not something that is of concern to CATS, really. Whether I am exposing a monolithic or composite service is irrelevant, following the same 'out of scope' argument (in terms of scheduling a CATS request further across multiple possible service instance) that is applied rightfully when introducing the 'service contact instance'.
", "time": "2023-07-27T17:04:56Z"}, {"author": "Cheng Li", "text": "yes. I think so. from the client's pov, he/she only sees the contact instance
", "time": "2023-07-27T17:04:57Z"}, {"author": "Carlos Bernardos", "text": "The agenda posted in the data tracker does not reflect current meeting agenda, right?
", "time": "2023-07-27T17:05:10Z"}, {"author": "Cheng Li", "text": "but what it is actually in deployment, we should clarify
", "time": "2023-07-27T17:05:16Z"}, {"author": "Renan Krishna", "text": "@Dirk +1
", "time": "2023-07-27T17:06:15Z"}, {"author": "Peng Liu", "text": "Carlos Bernardos, It's same as the agenda in the datatracker.
", "time": "2023-07-27T17:06:51Z"}, {"author": "Cheng Li", "text": "please keep closer to the mike
", "time": "2023-07-27T17:08:00Z"}, {"author": "Cheng Li", "text": "We can not hear very clear remotely
", "time": "2023-07-27T17:08:11Z"}, {"author": "Carlos Bernardos", "text": "@Peng, no it is not
", "time": "2023-07-27T17:10:00Z"}, {"author": "Carlos Bernardos", "text": "there is not Use cases WG document in the agenda. I\u2019m a bit lost following the agenda, to be honest
", "time": "2023-07-27T17:10:24Z"}, {"author": "Cheng Li", "text": "#2 09:35 20mins Title: Discussion of the Terminology
\nPresenter: Med Boucadair
\n(What is a service, service instance, computing service?)
#3 09:55 20mins Title: Problem statement and use cases
\n#3a Presenter: Kehan Yao 10mins
\nDraft: https://datatracker.ietf.org/doc/draft-yao-cats-ps-usecases/
\n#3b Presenter: Qing An 10mins
\nDraft: https://datatracker.ietf.org/doc/draft-an-cats-usecase-ai/
This is what I see from the system, it seems the same
", "time": "2023-07-27T17:11:44Z"}, {"author": "Carlos Bernardos", "text": "it\u2019s not
", "time": "2023-07-27T17:13:03Z"}, {"author": "Dirk Trossen", "text": "Carlos Bernardos said:
\n\n\n@Peng, no it is not
\n
The currently still individual draft on CATS use cases is subject to WG adoption, so it is not yet a WG draft, so this seems correct to me?!
", "time": "2023-07-27T17:13:19Z"}, {"author": "Carlos Bernardos", "text": "Kehan Yao presented a WG document that is not mentioned in the agenda
", "time": "2023-07-27T17:13:27Z"}, {"author": "Carlos Bernardos", "text": "", "time": "2023-07-27T17:14:10Z"}, {"author": "Carlos Bernardos", "text": "this is not in the agenda
", "time": "2023-07-27T17:14:31Z"}, {"author": "Peng Liu", "text": "Carlos Bernardos. Oh,,,Sorry for that, the WG document was posted 3 days before, we changed the agenda in the chair slides but forget to change it in the datatracker.
", "time": "2023-07-27T17:14:45Z"}, {"author": "Dirk Trossen", "text": "indeed, the correct draft for that presentation is https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements
", "time": "2023-07-27T17:15:51Z"}, {"author": "Carlos Bernardos", "text": "and while I agree that Med\u2019s document is very valid, I don\u2019t find a draft in the data tracker yet. I think presentation time should be done first to presentations with I-Ds. Just personal opinion
", "time": "2023-07-27T17:15:53Z"}, {"author": "Wolfgang Beck", "text": "It's a use case, but it's just another load-intensive application
", "time": "2023-07-27T17:17:06Z"}, {"author": "Y. Richard Yang", "text": "there can be potential confusion of introducing service contact instance(s). Since there is the concept of service contact instances, are there non service contact instances, among all instances? Are these non-contact instances in scope? Maybe I need to read more details, but this is what comes to nind.
", "time": "2023-07-27T17:17:29Z"}, {"author": "Eduard V", "text": "AI training is definitely outside of the scope, but AI usage is in the scope.
", "time": "2023-07-27T17:18:07Z"}, {"author": "Wolfgang Beck", "text": "AI is a bit sexier than let's say accounting application at the end of the month
", "time": "2023-07-27T17:18:15Z"}, {"author": "Dirk Trossen", "text": "What is a 'non service contact instance'?
", "time": "2023-07-27T17:18:51Z"}, {"author": "Cheng Li", "text": "@Eduard, I see your point and intend to agree with you
", "time": "2023-07-27T17:23:41Z"}, {"author": "Peng Liu", "text": "Med's presentation is not for a specific draft, but several draft uses the terminology, so Adrian and I think it is useful to have the discussion first. The result may be updated in this draft first https://datatracker.ietf.org/doc/draft-ldbc-cats-framework/
", "time": "2023-07-27T17:25:59Z"}, {"author": "Marco Liebsch", "text": "service continuity is an interesting requirement in the CATS context. Is the service assumed to be sticky and subsequent requests will end up at the same service instance? Or will service instance selection happen for each request?
", "time": "2023-07-27T17:28:46Z"}, {"author": "Cheng Li", "text": "can you guys hear clear?
", "time": "2023-07-27T17:30:26Z"}, {"author": "Cheng Li", "text": "the voice from the mike is low than the ones from online
", "time": "2023-07-27T17:30:49Z"}, {"author": "Dirk Trossen", "text": "Marco Liebsch said:
\n\n\nservice continuity is an interesting requirement in the CATS context. Is the service assumed to be sticky and subsequent requests will end up at the same service instance? Or will service instance selection happen for each request?
\n
affinity is seen from a set of requests, how it is delineated is an interesting aspect, indeed.
", "time": "2023-07-27T17:31:20Z"}, {"author": "Eduard V", "text": "@Cheng, yes, sound is good
", "time": "2023-07-27T17:31:45Z"}, {"author": "Peng Liu", "text": "we can hear well, Cheng.
", "time": "2023-07-27T17:31:52Z"}, {"author": "Cheng Li", "text": "Dirk 's volume is good
", "time": "2023-07-27T17:33:06Z"}, {"author": "Dirk Trossen", "text": "Cheng Li said:
\n\n\nDirk 's volume is good
\n
my sombre tone after days of too much talking!
", "time": "2023-07-27T17:33:42Z"}, {"author": "Cheng Li", "text": "\uff1a0
", "time": "2023-07-27T17:34:19Z"}, {"author": "Cheng Li", "text": "\uff1a\uff09
", "time": "2023-07-27T17:34:21Z"}, {"author": "Dirk Trossen", "text": "Dirk Trossen said:
\n\n\nMarco Liebsch said:
\n\n\nservice continuity is an interesting requirement in the CATS context. Is the service assumed to be sticky and subsequent requests will end up at the same service instance? Or will service instance selection happen for each request?
\naffinity is seen from a set of requests, how it is delineated is an interesting aspect, indeed.
\n
Related to my comment on the mic: delineation of affinity is key. If I get it wrong, sending a (new) request to another instance, the effect may disastrous due to transaction state being lost (maybe I could cope with it in a single K8S pod but across network location, I will need to inter-site transaction state transfer). Hence my comment on the WHERE this delineation is being done, who signals it and how.
", "time": "2023-07-27T17:35:29Z"}, {"author": "Renan Krishna", "text": "@Dirk +1
", "time": "2023-07-27T17:37:06Z"}, {"author": "Cheng Li", "text": "BTW, guys, we are talking notes, but we can not record everything now especially I am joining the discussion in each presentation, it will good if you can check and provide your text in the note. But in any case, we will review the record and fill it out, don't worry.
", "time": "2023-07-27T17:39:36Z"}, {"author": "Adrian Farrel", "text": "@ChengLi Thnx
", "time": "2023-07-27T17:45:06Z"}, {"author": "Dirk Trossen", "text": "the L2 traffic steering draft raises an interesting question in relation to CATS overall: what traffic at what layer do we intend to steer?
", "time": "2023-07-27T17:49:13Z"}, {"author": "Mohamed Boucadair", "text": "For the L2 draft, this is more related to the NERG work within BBF.
", "time": "2023-07-27T17:49:16Z"}, {"author": "Dirk Trossen", "text": "Mohamed Boucadair said:
\n\n\nFor the L2 draft, this is more related to the NERG work within BBF.
\n
as a use case, yes, but as far as the fundamental question goes (see last message of mine), I think it is still interesting.
", "time": "2023-07-27T17:50:52Z"}, {"author": "Cheng Li", "text": "I am working in BBF as well, and I have the same feeling with Med.
", "time": "2023-07-27T17:53:51Z"}, {"author": "Cheng Li", "text": "L2 steering seems irrelevant to CATS, or not important for now. But it MAY have some value in the future
", "time": "2023-07-27T17:54:30Z"}, {"author": "Dirk Trossen", "text": "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).
", "time": "2023-07-27T18:01:11Z"}, {"author": "Renan Krishna", "text": "@Dirk Do you envisage a 1-1 mapping between the mathematical notion of actor and the notion of 'service' in CATS WG?
", "time": "2023-07-27T18:06:56Z"}, {"author": "Dirk Trossen", "text": "Somebody 'owns' (or governs the execution of) the service. Even if composed (which is out of scope for CATS), there is a service exposed by an actor. My concern is more about information (about aspects like service and network), which may need to cross actor boundaries to some decision logic to act on. I cannot assume this information to flow easily or even at all, while boundaries may provide me with ideas for requirements on, e.g., AAA.
", "time": "2023-07-27T18:09:00Z"}, {"author": "Renan Krishna", "text": "@Dirk Got it!
", "time": "2023-07-27T18:12:22Z"}, {"author": "Dirk Trossen", "text": "I appreciate the interest in delay for making TS decisions but its drawback may be the often reactive nature of the metric (unless I have VERY good estimations for the delay of a newly inserted resource), so this penalizes resources that are newly added. What we seem to miss in the CA work are capabilities being used for choice of TS
", "time": "2023-07-27T18:14:27Z"}, {"author": "Dirk Trossen", "text": "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.
", "time": "2023-07-27T18:23:24Z"}, {"author": "Zongpeng Du", "text": "Agree, IMHO, it depends on the optimazation objectives of the TS or the network provider
", "time": "2023-07-27T18:26:36Z"}]