Re: [Dyncast] How to expose "Computing Capability"?

["[e-mail]" <[e-mail]>]

Hi Dirk,

We didn't use "the reverse of ALTO" in the reply to ALTO WG after rethinking about it, you can find it in the mailing list.

I guess the original 'reverse' means the ways of different components(d-router or alto server-application) to collect the computing information and make the decision to which service instance.

Regards,
Peng


[e-mail]
 
From: Dirk Trossen
Date: 2022-05-25 13:50
To: [e-mail]; linda.dunbar; Jens Finkhaeuser; Dirk Trossen
CC: dyncast
Subject: Re: [Dyncast] How to expose "Computing Capability"?
Hi Peng & Linda,
 
The basis for decision making is indeed a weighted round robin on (rather longer lived) compute capabilities, while the decision making itself is performed on-path, similar to using a frequent reporting based basis for decision making. I’m not sure in which way this is reverse to ALTO since these two aspects (algorithm for decision making and the mapping process itself) matter. As mentioned in a separate reply, CAN outlines an on-path approach in its arch draft, while ALTO would constitute an off-path approach (similar to GSLB). What basis you are using to make the actual decision is irrelevant here; you can use the same algorithm in both (on/off-path) approaches.  The most interesting question to me is what the impact would be to use the same basis for decision but either on- vs off-path frameworks; that is something we are working on right now to quantify.
 
Best,
 
Dirk
 
From: [e-mail] [mailto:[e-mail]] 
Sent: 14 May 2022 04:17
To: linda.dunbar <[e-mail]>; Dirk Trossen <[e-mail]>; Jens Finkhaeuser <[e-mail]>; Dirk Trossen <dirk.trossen=[e-mail]>
Cc: dyncast <[e-mail]>
Subject: Re: Re: [Dyncast] How to expose "Computing Capability"?
 
Hi Linda,
 
Yes, I think it should be the reverse of ALTO. It looks like proposed a weighted round robin methods for the ingress nodes to select the  service instance, using the obfuscated computing information.
 
Regards,
Peng


[e-mail]
 
From: Linda Dunbar
Date: 2022-05-14 00:45
To: Dirk Trossen; Jens Finkhaeuser; Dirk Trossen
CC: [e-mail]
Subject: Re: [Dyncast] How to expose "Computing Capability"?
Dirk, 
 
Your description sounds like having CAN to identify various measurements for service instances including the hosting environment, get them normalized together with network metrics for ingress nodes to  choose the service instances?  Almost like the reverse of the ALTO (ALTO is for network to expose its path characters to application controller)?
 
Thanks, Linda
 
From: Dirk Trossen <[e-mail]> 
Sent: Friday, May 13, 2022 1:56 AM
To: Jens Finkhaeuser <[e-mail]>; Dirk Trossen <dirk.trossen=[e-mail]>
Cc: Linda Dunbar <[e-mail]>; [e-mail]
Subject: RE: [Dyncast] How to expose "Computing Capability"?
 
Hi Jens,
 
Not off-topic at all ;-) and a good question/comment, really. 
 
In fact, the paper simply utilizes a numeral, indeed. No semantics is attached when conveying this to the ingress node for decision making. We use in our simulations the relation of this value to ‘compute unit’, as expressed in, e.g., # cores or threads assigned to a service instance. You could also include, as Linda suggested to, things like storage speed, connectivity speed. We were even looking into assigning the energy costs spent per request to that value, turning the “CArDS” (which stands for compute-aware distributed scheduling) mechanism in the paper into an “EArDS” (energy-aware distributed scheduling) mechanism. 
 
This assignment of meaning is indeed entirely left to the application. The ingress merely acts on said numeral in weighted round robin fashion (which is easy to implement). So please don’t be confused by the focus on compute unit in the paper (since we want to tie some semantic to the algorithm for evaluation). My intention for raising awareness for this work is that you may well go beyond that and indeed address the points you outline below, i.e., no need to leak semantics to the net operator, simpler realization, simpler protocol probably, …
 
Best,
 
Dirk
 
From: Dyncast [mailto:[e-mail]] On Behalf Of Jens Finkhaeuser
Sent: 13 May 2022 08:32
To: Dirk Trossen <dirk.trossen=[e-mail]>
Cc: Linda Dunbar <[e-mail]>; [e-mail]
Subject: Re: [Dyncast] How to expose "Computing Capability"?
 
Hi all,
 
maybe a tad off-topic, but I still think that "compute capability" is best application defined, and CAN should just offer a function for publishing an application specific value, where routers pick the best (aka highest/lowest; and/or maybe combine that with path awareness). That requires the least protocol engineering, the least computation on the router, and gives applications every flexibility in defining how to come by this value. Plus, it leaks the least amount of data one might not want to expose.
 
I say off-topic because I don't know what's in that paper!

Jens
------- Original Message -------
On Thursday, May 12th, 2022 at 09:00, Dirk Trossen <dirk.trossen=[e-mail]> wrote:


Hi Linda,
 
Apologies for that. I had hoped the links are coming online quicker but they’re not yet there. I don’t want to send the PDF on the list directly but can provide it for anybody who drops me an email. Once I have the link, I’ll add it to the github issue.
 
Best,
 
Dirk
 
From: Dyncast [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: 11 May 2022 20:33
To: [e-mail]
Subject: [Dyncast] How to expose "Computing Capability"?
 
 
The answer to the CAN issue #10 (Is computing resource measurable? https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/10 ) states:
 
o   See IFIP Networking 2022 paper on how to simply expose “computing capability” and achieve better steering with such simple measure.
 
Does anyone have the link to the IFIP Network 2022 paper on how to simply expose “Computing Capability”? 
Thank you
Linda