Re: [Dyncast] edge capability feedback

Yes, I concur with Yizhou’s comments below.

Based on the objective that has been laid out by Dyncast initiative, a client intends to find the ‘most suitable’ server for a type of service. The critical use cases and the corresponding deployment settings as specified in Dyncast drafts are most mobile-related edge-computing scenarios. So, considering these together, if we put the server-selection intelligence at an end client (like a UE) itself, then the UE would require significant amount of new logics. 

Moreover, it is always challenging to determine (a) how a UE could do this type of ‘selection intelligence’; (b) what are the “consensus selection criteria’ across numerous UEs; (c) how a service instance (i.e., a server) in an IP domain could signal the update-to-date metrics to UEs, etc. All these would require the involvement of both UEs (like utilizing URSP) and mobile core (saying 5GC), aside from the work in IP domain . IMO, these are way beyond the scope. So, all the *new logics* related to Dyncast would be best addressed in IP network. 

That is why I think the ‘architecture design’ in Dyncast proposals does make sense as the first starting step.

Thanks.

-Tianji

From: Dyncast <dyncast-bounces@ietf.org> on behalf of Liyizhou <liyizhou@huawei.com>
Date: Thursday, March 11, 2021 at 1:48 AM
To: Barry Greene <bgreene@senki.org>, 刘鹏 <liupengyjy@chinamobile.com>
Cc: dyncast <dyncast@ietf.org>, Michael McBride <michael.mcbride@futurewei.com>
Subject: Re: [Dyncast] edge capability feedback

Hi Barry,

Is RFC8782 the one you mentioned as DOTS signaling channel?

AFAIK DOTS signal channel is most likely to report some risky traffic from DOTS client and server.

DOTS signaling channel is more for light weight info exchange regarding what the potential attack is between DOTS client and DOTS server. It is not relevant to where and what are the reachable serving address and also it is hardly the case a single client talking to a number of servers.  

Client and server are pre-determined pair in most cases.

For metrics sync or distribution, a metric agent needs to distribute the metrics to a number of D-Routers so that each can make the own choices when a service demand reaches. 

So DOTS signal channel was not designed for such purpose and it is a bit hard for me to imagine what kind of changes would be required to let it carry those metrics info and make such info flooded out.

Cheers,

Yizhou

From: Dyncast [mailto:dyncast-bounces@ietf.org] On Behalf Of Barry Greene
Sent: Thursday, March 11, 2021 11:34 AM
To: 刘鹏 <liupengyjy@chinamobile.com>
Cc: dyncast <dyncast@ietf.org>; Michael McBride <michael.mcbride@futurewei.com>
Subject: Re: [Dyncast] edge capability feedback

On Mar 10, 2021, at 8:24 PM, 刘鹏 <liupengyjy@chinamobile.com> wrote:

The edge node could inform it's status to the D-routers based on the metric, such as CPU load or other metrics for the specific instance if defined in the furture, then the D-router could choose a suitable edge considering both network and computing or other specific status. We have some experimental verification and functional implementation.

Have you done the due diligence in past work in this area?

What you described above sounds like the signaling in the DOTS work (shifting load based on DDoS). 

It is also should similar to Cisco Distributed Direct Routing Protocol (1997ish), TIDP/TMP (early 2000s), and some other network oriented shifting of edge loads. 

What would be helpful is a review of all the past efforts (go back to the ‘90s) and review what worked and what did not work. 

-- Dyncast mailing list Dyncast@ietf.org https://www.ietf.org/mailman/listinfo/dyncast 