Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt

[Dirk Trossen <[e-mail]>]

Hi Tianji,

Many thanks for the comments; please see inline for responses.

Best,

Dirk

From: Dyncast [mailto:[e-mail]] On Behalf Of Tianji Jiang
Sent: 23 February 2021 01:01
To: [e-mail]
Subject: Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt

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 :

1.     [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"
o   Dyncast:    Dynamic Anycast, taking the dynamic nature of computing resource metrics into account to steer an anycast routing decision.
o   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.
[DOT] Thanks for pointing this out and clarification is needed. In short, I had included your service-specific metrics into my understanding of computing metrics but this will need correction to clarify this. So yes, service-specific metrics (in your view) are used for the routing decision.
-        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.
[DOT] I understand your view and, as said above, we will need to clarify this.

2.     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.
[DOT] Many thanks for this suggestion and it makes a lot of sense to me as a revision of the section title.

3.     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).
[DOT] I do agree with you on affinity not being a Dyncast-unique problem and we didn’t mean to suggest this. We merely intended to point out that the affinity is an input into the routing decision, also for current mechanisms (as we also point out in the respective section), and needs to be considered. Of course, affinity is important for a number of other aspects but this is not the scope of the dyncast work. We will try to make this clearer in the next revision.

BR,

-Tianji










    发件人: internet-drafts <mailto:[e-mail]>
    时间: 2021/02/01(星期一)18:15
    收件人: Dirk Trossen <mailto:[e-mail]>;Peng Liu
    <mailto:[e-mail]>;Peter Willis
    <mailto:[e-mail]>;
    主题: 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<http://tools.ietf.org>.

The IETF Secretariat
-- Dyncast mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/dyncast