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

"liupengyjy@chinamobile.com" <liupengyjy@chinamobile.com> Sat, 14 May 2022 02:15 UTC

Return-Path: <liupengyjy@chinamobile.com>
X-Original-To: dyncast@ietfa.amsl.com
Delivered-To: dyncast@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398AFC20D682 for <dyncast@ietfa.amsl.com>; Fri, 13 May 2022 19:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.786
X-Spam-Level:
X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j75t0L-U7c9L for <dyncast@ietfa.amsl.com>; Fri, 13 May 2022 19:15:46 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 363EDC20D683 for <dyncast@ietf.org>; Fri, 13 May 2022 19:15:44 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.97]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee7627f1005e2f-551f7; Sat, 14 May 2022 10:12:22 +0800 (CST)
X-RM-TRANSID: 2ee7627f1005e2f-551f7
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[120.244.192.167]) by rmsmtp-syy-appsvrnew09-12034 (RichMail) with SMTP id 2f02627f1004903-97c2c; Sat, 14 May 2022 10:12:22 +0800 (CST)
X-RM-TRANSID: 2f02627f1004903-97c2c
Date: Sat, 14 May 2022 10:16:53 +0800
From: "liupengyjy@chinamobile.com" <liupengyjy@chinamobile.com>
To: "linda.dunbar" <linda.dunbar@futurewei.com>, "dirk.trossen" <dirk.trossen@huawei.com>, Jens Finkhaeuser <jens@interpeer.io>, Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
Cc: dyncast <dyncast@ietf.org>
References: <CO1PR13MB4920E1DF2F12914C8F39173D85C89@CO1PR13MB4920.namprd13.prod.outlook.com>, <a2583f12d6cd4387b28ad701d9e7e638@huawei.com>, <oQfMkYgoGRN0CleHUbPQf0cA2SzZRh-5pd5Ab375MfBlYp42xq9-0sx0WVDsHeExkBGCeg_-GAOkf2yka_G_aAz_gpGdExGdhILNY1C8lTk=@interpeer.io>, <860843c126224ac7a5f55362403f8349@huawei.com>, <CO1PR13MB4920E36B0B591AE45BA1821785CA9@CO1PR13MB4920.namprd13.prod.outlook.com>
X-Priority: 3
X-GUID: 9F20EC09-3CA7-45D7-A7F9-E3D4877666C2
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <2022051410165260938557@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart683284408178_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/npC-jWkYDx2jrQgEec9PWwgMpkk>
Subject: Re: [Dyncast] How to expose "Computing Capability"?
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Dynamic Anycast <dyncast.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dyncast>, <mailto:dyncast-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dyncast/>
List-Post: <mailto:dyncast@ietf.org>
List-Help: <mailto:dyncast-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dyncast>, <mailto:dyncast-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2022 02:15:48 -0000

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


liupengyjy@chinamobile.com
 
From: Linda Dunbar
Date: 2022-05-14 00:45
To: Dirk Trossen; Jens Finkhaeuser; Dirk Trossen
CC: dyncast@ietf.org
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 <dirk.trossen@huawei.com> 
Sent: Friday, May 13, 2022 1:56 AM
To: Jens Finkhaeuser <jens@interpeer.io>; Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>; dyncast@ietf.org
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:dyncast-bounces@ietf.org] On Behalf Of Jens Finkhaeuser
Sent: 13 May 2022 08:32
To: Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>; dyncast@ietf.org
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=40huawei.com@dmarc.ietf.org> 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:dyncast-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 11 May 2022 20:33
To: dyncast@ietf.org
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