Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt
Tianji Jiang <tianjijiang@chinamobile.com> Tue, 23 February 2021 00:03 UTC
Return-Path: <tianjijiang@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 C12FD3A256A for <dyncast@ietfa.amsl.com>; Mon, 22 Feb 2021 16:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUxEE3WtjiNd for <dyncast@ietfa.amsl.com>; Mon, 22 Feb 2021 16:03:12 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2ED3A25FC for <dyncast@ietf.org>; Mon, 22 Feb 2021 16:01:46 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee6603445d6091-eed67; Tue, 23 Feb 2021 08:01:29 +0800 (CST)
X-RM-TRANSID: 2ee6603445d6091-eed67
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from [10.0.0.136] (unknown[73.231.199.189]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5603445d48f4-f07ac; Tue, 23 Feb 2021 08:01:29 +0800 (CST)
X-RM-TRANSID: 2ee5603445d48f4-f07ac
User-Agent: Microsoft-MacOutlook/10.10.1b.201012
Date: Mon, 22 Feb 2021 16:01:19 -0800
From: Tianji Jiang <tianjijiang@chinamobile.com>
To: "dyncast@ietf.org" <dyncast@ietf.org>
Message-ID: <DA88A9F1-D1A9-4BAC-9F97-CA52D3E6BA40@chinamobile.com>
Thread-Topic: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt
References: <C7704C30-BB5E-439F-A6EF-144C827AAD79@chinamobile.com>
In-Reply-To: <C7704C30-BB5E-439F-A6EF-144C827AAD79@chinamobile.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3696854488_65550073"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/zsqAK39TEaAnecUVvvzOuErTbUg>
Subject: Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Tue, 23 Feb 2021 00:03:23 -0000
Hi, Good day. I read thru the latest Dyncast IETF draft (https://www.ietf.org/archive/id/draft-liu-dyncast-ps-usecases-00.txt) and have some questions to discuss : [Quoted] “Distributing a service request to a specific service having multiple instances attached to multiple edge computing sites, while taking into account computing as well as service-specific metrics in the distribution decision, can be seen as a dynamic anycast (or "dyncast" for short) routing problem Here, my question is : do you imply to have a routing decision based on the following three(3) orthogonal metrics? (commonly-referenced) networking metrics; could be comprised of BW, delay, loss, MTU, load, etc., on a wider scope Computing metrics (i.e., characteristics of service instances, like server-spec, etc.) Service-specific metrics (i.e., Apps traffic or flow- specification, or even APP-aware stats) But, from reading your IETF-draft, my understanding is the intention depends only on 2 metrics, i.e., networking and computing metrics. For example, in the 2nd-chapter "Definition of Terms" Dyncast: Dynamic Anycast, taking the dynamic nature of computing resource metrics into account to steer an anycast routing decision. Anycast: An addressing and routing methodology that assign an "anycast" address for one or more network locations to which requests to an "anycast" address could be routed. Reading thru the draft, I understand that, on a big picture, its intention is to consider the factors from both the ‘public and shared land’ and the ‘closed and proprietary domain’. While networking metrics belong to the 1st, the computing metrics fall in the 2nd. However, in my thought, computing metrics themselves do not reflect the holistic view of an App server (or a service instance in the draft’s nomenclature) since they are focusing on the system spec. It would be better off if the service-metric (i.e., the flow-spec) could be integrated. In section-4: "Shortcomings of Existing Solutions": It states that 'As a key takeaway from Section 3, we observe that a service request should be dynamically routed to the most suitable service instance in real time among the multiple edges in which service instances have been deployed. Existing mechanisms use one or more of the following ways and each of them has issues associated. In my thought, I would rather *not* call them 'existing solutions', especially for the traditional anycast, EIGRP, etc., since these existing mechanisms or protocols were/are *not* originally targeting for the same problem context as what the draft is defining. They are not partial or deficient ‘solutions’ at all. So, here is a subject I could think for ‘those schemes’: Feasibility of current Mechanisms’ –. ‘Feasibility : to indicate that the draft has done investigation over various existing mechanisms; the objective is to examine the practicability of them. Though sort of inferential and being neutral, it does imply the ‘deficiency’ of them ‘Mechanism’ accommodates both concrete and abstract things; can be a process, a design, a system, and a piece of machinery, etc. Moreover, it bears the neutrality of expression and does not show a perference. In section-5.2 "Instance Affinity" – this problem is *not* unique to Dyncast. Actually, this should be a common problem even for the traditional anycast routing, should a service request, i.e., transaction, consisting of multiple data packets be handled. For example, in an Internet core router, if load-balance is expected, then different packets from the same session might go thru different routing path, which could lead to 'affinity-oriented' issue. For example, some vendors’ routers can be configured as per-packet-load-balance. Therefore, the affinity-related issue is an end-2-end problem, not just on the edge-domain (i.e., only considered at ‘headend’). It should be more profound than on the surface (since it would be impacted by routing more extensively). BR, -Tianji 发件人: internet-drafts <mailto:internet-drafts@ietf.org> 时间: 2021/02/01(星期一)18:15 收件人: Dirk Trossen <mailto:dirk.trossen@huawei.com>;Peng Liu <mailto:liupengyjy@chinamobile.com>;Peter Willis <mailto:peter.j.willis@bt.com>; 主题: New Version Notification for draft-liu-dyncast-ps-usecases-00.txt A new version of I-D, draft-liu-dyncast-ps-usecases-00.txt has been successfully submitted by Dirk Trossen and posted to the IETF repository. Name: draft-liu-dyncast-ps-usecases Revision: 00 Title: Dynamic-Anycast (Dyncast) Use Cases and Problem Statement Document date: 2021-02-01 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/archive/id/draft-liu-dyncast-ps-usecases-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-dyncast-ps-usecases/ Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-dyncast-ps-usecases Htmlized: https://tools.ietf.org/html/draft-liu-dyncast-ps-usecases-00 Abstract: Service providers are exploring the edge computing to achieve better response time, control over data and carbon energy saving by moving the computing services towards the edge of the network in 5G MEC (Multi-access Edge Computing) scenarios, virtualized central office, and others. Providing services by sharing computing resources from multiple edges is an emerging concept that is becoming more useful for computationally intensive tasks. Ideally, services should be computationally balanced using service-specific metrics instead of simply dispatching the service in a static way, e.g., to the geographically closest edge since this may cause unbalanced usage of computing resources at edges which further degrades user experience and system utilization. This draft provides an overview of scenarios and problems associated with realizing such scenarios. The document identifies several key areas which require more investigations in terms of architecture and protocol to achieve balanced computing and networking resource utilization among edges providing the services. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Dyncast mailing list Dyncast@ietf.org https://www.ietf.org/mailman/listinfo/dyncast
- [Dyncast] Fw: New Version Notification for draft-… 刘鹏
- Re: [Dyncast] Fw: New Version Notification for dr… Joel M. Halpern
- Re: [Dyncast] New Version Notification fordraft-l… liupengyjy
- Re: [Dyncast] New Version Notification fordraft-l… Joel M. Halpern
- Re: [Dyncast] New Version Notification fordraft-l… 刘鹏
- Re: [Dyncast] New Version Notification fordraft-l… Tianji Jiang
- Re: [Dyncast] New Version Notification fordraft-l… Dirk Trossen