Re: [Dyncast] edge capability feedback

If the UE had a way to ask an informed server, there would be no need 
for the UE to have a "significant amount of new logics".
And we would not have to worry about overloading routing with behavior 
and data that it does not need.  And we would naturally get the needed 
stickiness.

Yours,
Joel

On 3/11/2021 8:06 PM, Tianji Jiang wrote:
> 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
>     <mailto: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
> 
> 