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

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

Hi,
 
I agree that multiple solutions exist here. Some of them do not need to change the routing layer, and work in a higher level.
 
However, in some scenarios, maybe the solution in the routing layer is more efficient. There are some tradeoffs here.
 
IMHO, the main object of the BOF is to clarify that sometimes, we need to consider both the network status and the computing status, and make a better choice in the traffic steering. 
 
Best Regards
Zongpeng Du



[e-mail] & [e-mail]
 
From: Luigi IANNONE
Date: 2022-04-12 15:04
To: Aijun Wang; 'Joel M. Halpern'; [e-mail]; 'dyncast'
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