Re: [Dyncast] [Can] Comments on the BOF

[Peng Liu <[e-mail]>]

Hi Xuewei,

Thanks for your interests on this work. CAN won't put rich computing based decision algorithm in the routing layer, but considering the computing resource status will help to do the joint optimization for the traffic steering. It is better to do something in the ingress router (I think it is same with 'gateway router' you said). 

There are also some differences when considering the solution or standardization. From the function or solution perspective, the coordination with upper layer might be needed. For the work of CAN, we want to position it at routing area. That is, to find out what could routing area do. The proponents have been working on this, and you can find the early reply of it in the mailing list. So I want to know your comments on that first.

For the traffic loop you mentioned, please know that CAN won't influence every routers as mentioned above. Then if the 'router B' you said refers to the egress router, I suggest to create another thread to discuss it, maybe to the co authors of draft-li-dyncast-architecture. Though CAN won't talk about the solutions at this stage, the mailing list is open for any CAN related issues.

Thanks again~
Peng


[e-mail]
 
From: 王雪伟1
Date: 2022-12-21 10:33
To: Jari Arkko
CC: [e-mail]
Subject: Re: [Can] Comments on the BOF
Hi, Jari and all 
I am very agree with your point about "it will be painful to put in a rich decision algorithm in the routing layer. This doesn’t mean that there aren’t possible collaboration opportunities between the routing system and the applications in making the best decisions.". 
Putting the rich decision algorithm(plus computing metric) into all the routing layer do not only bring the heavy burden for the routing device but also maybe introduce some extra issues, especially the traffic loop when the computing information is changing, for example router A routes the traffic to route B based on the rich decision algorithm(networking metric plus computing metric), and when route B received the traffic the computing metric has changed becaused of the computing load is changed, router B will reroute the traffic back to router A because the computing information directly connected to route A is best, and due to the session sticky route A will insist on routing it to route B, now the traffic loop is happening. 

Due to computing information are dynamic, just like network information, even more dynamic, this characteristics of dynamic will introduce some extra issues, just like the dynamic network information have aroused, for example the traffic micro loop. 

So maybe we can consider some collaboration between the routing system and the applications, perhaps we can get a new start. 
Where we can introduce some kind of gateway routers, which act as joint nodes to do the complicated  rich decision algorithm, and translate the applications stuff to the routing stuff, and routing layer remains the pure networking decision and avoid the computing stuff. 
From: "Jari Arkko"<[e-mail]> 
Date:  Thu, Nov 10, 2022, 23:26 
Subject:  [Can] Comments on the BOF 
To: "[e-mail]"<[e-mail]> 
As IAB members, we are asked to provide feedback on BOFs, and we do this, but it should be noted that the feedback is a personal opinion and has no particular standing or endorsement from IAB or anyone else. I should also say that I’m a generalist and not an expert on this particular area, plus I had to step out for a while to have a presentation in other meeting. In other words, here’s some feedback, hopefully it is helpful, feel free to do what you want with it, including ignoring it :-) 

I usually write longer reviews, but maybe focusing the key thing here is useful. And many people said similar things in the room far more eloquently than I can. Cullen, for instance, framed it nicely. 

Anyway, I think there’s a real opportunity here. We *can* take multiple factors into account and make better load balancing decisions than if we were only using a single factor (like server load). And we should do that for better user experience! 

However, the discussions become lengthy because there’s a disagreement where such decisions should be done, and where should information flow. The proposals in the group have mostly started from the point of view of the routing system. But, this may not be the only or the best place to perform these functions. In fact, one of the issues with the problem description is that it seems to classify information in two categories, compute and networking. But just like networking is more complex than one utilization number, compute is way more complex than just a single load level number. What’s the schedule of the server in the next period? Is the needed software image loaded? Is the user-specific data object for this fraction of the meta verse loaded in? The resistance  that we’re seeing to the CAN proposal is that it will be painful to put in a rich decision algorithm in the routing layer. This doesn’t mean that there aren’t possible collaboration opportunities between the routing system and the applications in making the best decisions. 

So, my advice is: 
(1) extend problem description to encompass larger view than the routing problem 
(2) figure out a set of people who can address this — should include apps & routing at least 
(3) see if there are things we can do beyond what apps do today, e.g., in terms of better information sharing between the routing and apps layers 

I think it might be useful to try to avoid the impression that there’s a routing vs. application area conflict or choice. Or what area is ”right”, as one of the questions in the BOF put it. Something is possibly needed, but if something is needed it might need collaboration. Even if routing-layer-does-this-on-its-own is in my opinion not a realistic choice, this still leaves two feasible options: 
- the application layer handles all this (and measures connectivity properties), this is what we do today 
- the application layer and routing layer work together (e.g., routing layer provides information to application layer) 

Jari 
-- 
Can mailing list 
[e-mail] 
https://www.ietf.org/mailman/listinfo/can