Re: [Dyncast] CAN BoF issues and the next steps

["[e-mail]" <[e-mail]>]

Hi Tony,

I think CAN has it's own worked scope of the network and considers the frequency of synchronization at same time.

The method of UE to pick the instance from the broker is simple but thought to cause more messages and latency compared to the in-path solution, and need the broker to learn all the network status. 

Regards,
Peng


[e-mail]
 
From: Tony Li
Date: 2022-04-13 11:27
To: Aijun Wang
CC: dyncast; liupengyjy; Luigi IANNONE
Subject: Re: [Dyncast] CAN BoF issues and the next steps
 
Hi Aijun,
 
My understanding of the requirements was that a particular UE was supposed to be bound to a server for the lifetime of a ’transaction’ and that includes across the UE rehoming to a different source. Thus, the entire network needs to make a consistent and fixed decision per UE. Doing so in a dynamic environment would seem to be most challenging: you would need to synchronize forwarding state across the entire network instantly.
 
Making a single decision at the ingress and propagating that state seems somewhat easier.
 
And easier still is Joel’s proposal: have the UE pick one (from a centralized broker?) and then rely on unicast. :-)
 
Regards,
T
 
 
> On Apr 12, 2022, at 7:59 PM, Aijun Wang <[e-mail]> wrote:
> 
> Hi, Joel:
> If you use binding address behind the ANYCAST address, it is possible. But if you use the ANYCAST address directly, you can't.
> For my understanding, the latter scenario is more popular.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: Joel M. Halpern <[e-mail]> 
> Sent: Wednesday, April 13, 2022 10:55 AM
> To: Aijun Wang <[e-mail]>; 'Luigi IANNONE' <luigi.iannone=[e-mail]>; [e-mail]; 'dyncast' <[e-mail]>
> Subject: Re: [Dyncast] CAN BoF issues and the next steps
> 
> If the ingress edge does the calculation, makes the determination, and tunnels the traffic to the right place then the underlay routing system does not need to know anything about these metrics or the decision processes made by the edge.
> 
> Yours,
> Joel
> 
> On 4/12/2022 10:52 PM, Aijun Wang wrote:
>> Hi, Luigi:
>> Why only the ingress need such decision? I think all the routers 
>> in-path need such information(routing metric +compute metric), to 
>> achieve the optimal "instance selection".
>> 
>> Best Regards
>> 
>> Aijun Wang
>> China Telecom
>> 
>> -----Original Message-----
>> From: [e-mail] <[e-mail]> On Behalf Of 
>> Luigi IANNONE
>> Sent: Tuesday, April 12, 2022 3:04 PM
>> To: Aijun Wang <[e-mail]>; 'Joel M. Halpern'
>> <[e-mail]>; [e-mail]; 'dyncast'
>> <[e-mail]>
>> Subject: Re: [Dyncast] CAN BoF issues and the next steps
>> 
>> Hi,
>> 
>>> But, with the placement of the ANYCAST application servers closing to 
>>> the users in different sites, the bottleneck to influence the E2E 
>>> application performance is not only the network metric, the metric 
>>> for the application servers play a major role now.
>>> It is time to consider both the network metric and application server 
>>> metric together to achieve such goals.
>> 
>> I think that Joel is not against the above (routing metric +compute 
>> metric = instance selection).
>> I think that he is more inline with Dirk's position, meaning that it 
>> is not necessarily the routing layer that has to be "enhanced" with 
>> compute metrics.
>> Rather, an in-path decision based on both metrics should be made by 
>> some (CAN ) element.
>> My personal take is that the ingress is well suited for that (since 
>> for sure it is in-path).
>> Then you have the choice of various ways on how to steer the traffic.
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>> 
>> 
>> --
>> Dyncast mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dyncast
>> 
> 
> -- 
> Dyncast mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dyncast
 
-- 
Dyncast mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dyncast