Re: [Dyncast] CAN BoF issues #7 #17 #32

[Dirk Trossen <[e-mail]>]

I must admit that I got utterly confused on how you see messages flow. See more inline.

Best,

Dirk

From: [e-mail] [mailto:[e-mail]]
Sent: 17 June 2022 14:40
To: Dirk Trossen <[e-mail]>; Peng Liu <[e-mail]>; Linda Dunbar <[e-mail]>; [e-mail]
Cc: RTGWG <[e-mail]>; David R. Oran <[e-mail]>; Jeff Tantsura <[e-mail]>
Subject: Re: Re: [Dyncast] CAN BoF issues #7 #17 #32



________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>

From: Dirk Trossen<mailto:dirk.trossen=[e-mail]>
Date: 2022-06-17 19:58
To: [e-mail]<mailto:[e-mail]>; Peng Liu<mailto:[e-mail]>; Linda Dunbar<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: RTGWG<mailto:[e-mail]>; David R. Oran<mailto:[e-mail]>; Jeff Tantsura<mailto:[e-mail]>
Subject: Re: [Dyncast] CAN BoF issues #7 #17 #32
Hi Zongpeng,

Please see inline in green.

Best,

Dirk

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: 17 June 2022 13:46
To: Dirk Trossen <[e-mail]<mailto:[e-mail]>>; Peng Liu <[e-mail]<mailto:[e-mail]>>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: RTGWG <[e-mail]<mailto:[e-mail]>>; David R. Oran <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
Subject: Re: RE: [Dyncast] CAN BoF issues #7 #17 #32

Hi, Dirk

    Thanks for the reply. Please see inline.



Best Regards
Zongpeng Du

________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>

From: Dirk Trossen<mailto:[e-mail]>
Date: 2022-06-17 17:58
To: [e-mail]<mailto:[e-mail]>; Peng Liu<mailto:[e-mail]>; Linda Dunbar<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
CC: RTGWG<mailto:[e-mail]>; David R. Oran<mailto:[e-mail]>; Jeff Tantsura<mailto:[e-mail]>
Subject: RE: Re: [Dyncast] CAN BoF issues #7 #17 #32
Hi Zongpeng,

Please see inline.

Best,

Dirk

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: 17 June 2022 11:46
To: Dirk Trossen <[e-mail]<mailto:[e-mail]>>; Peng Liu <[e-mail]<mailto:[e-mail]>>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: RTGWG <[e-mail]<mailto:[e-mail]>>; David R. Oran <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
Subject: Re: Re: [Dyncast] CAN BoF issues #7 #17 #32

Hi, Dirk

    Some personal understandings about the route selection:


    Client -----> Ingress node -----> middle nodes----> Egress node1 ----> server instance1 supporting serivceID1 (meanwhile unicast address serverIP1)
                                                                    \
                                                                        \
                                                                                ----> Egress node2 ---->server instance2 supporting serivceID1 (meanwhile unicast address serverIP2)


    In CAN, the first step is that the client tries to access to the service1 via an anycast IP address (serviceID1).
            a) Before the first step, the server instances should announce the route for the serviceID1.
[DOT] What is being announced here? AFAIK, the proposition was to announce a binding IP address (which would be serviceID1). Is this what you mean?
[zongpeng]  I have checked the arch draft. The binding IP address is a unicast IP address.
                        So, I mean it announces an anycast address, i.e. serviceID1. It is called D-SID in the arch draft.


   D-BID:  Dyncast Binding ID, an address to reach a service instance

     for a given D-SID.  It is usually a unicast IP where service

     instances are attached.  Different service instances provide the

     same service identified through D-SID but with different Dyncast
Binding IDs.  [zongpeng]
[DOT] OK, so the service instance announces the D-SID and its own D-BID for the ingress points to create a selection table that allows for mapping an incoming D-SID request to one of the announced D-BIDs. Note that the service instances did not announce a route but their IP address only. So the ingress does not select a route but one of the possibly many IP addresses. This is mode 1 in my original email.

[zongpeng] IMO, the service instance announces D-SID and D-BID for the Ingress.
[DOT] So the ingress now receives some info on S-SID and D-BID. Is this what you mean by ‘announces D-SID and D-BID for the Ingress”?
The Ingress would have two routes now. One for the D-SID (anycast), and one for the D-BID (unicast).
[DOT] What exactly is announced here? You said above to announce a D-SID and a  D-BID. How does this translate into two routes? All I see are announced identifiers to the ingress, where I could possibly relate D-BID to D-SID. What route information do you expect to accompany the announcement of D-SID and D-BID?
When it receives a packet targeting to D-SID, it forwards according the route for the D-SID. When it receives a packet targeting to D-BID, it forwards according the route for the D-BID.
[DOT] What information is used to forward a message addressed to D-SID at the ingress? What you describe above sounds like what any IP forwarding element would do.

You mentioned “many IP addresses”, which means many D-BIDs. Do you mean when we received a packet targeting to D-SID, we need to select a D-BID to replace the D-SID in the destination address?
However, I do not suggest to do this change of the target IP on the Ingress, and maintain the mapping statuses on the Ingress. Just forwarding according to the D-SID is also ok here.
[DOT] How is forwarding according to the D-SID done that is any different from what any IP router would do?
I suggest to bind the D-SID and the D-BID on the client and the sever, not on the Ingress. It is simpler.
[DOT] What is this binding doing? If I had a certain D-SID but different D-BIDs that have been announced to me for that given D-SID, you are also suggesting that any information to perform the binding to the most appropriate D-BID is available at the client? In that case, there is no need for an ingress (since I don’t understand what, apart from forwarding packets destined to an IP address, the ingress is doing) and what you describe is a client-based service instance selection, is it not?
[zongpeng]

            b) The Ingress node should have established tunnels to Egress1 and Egress2, and keep measuring the delay for the tunnels.
            c) The Ingress node should also receive load information updates from the server instances.
               d) The Ingress maintains a route for the serviceID1. It may be the tunnel to Egrees1 or the tunnel to the Egrees2.
   In the second step, the Ingress forwards the packet targeting to serviceID1 into a proper tunnel.

            Therefore, the server instances do not care about the path. The path selection happens on the Ingress node.
            There may be several paths between the Ingress and Egress1, but which path to use in CAN should have be decided before the first step. The underlay technology, such as SRv6, should be able to provide a low-latency path to the Egress1.

            For the underlay routing, the route for the serviceID1 on the Ingress is changed in CAN.
[DOT] I am struggling how this change of routing to serviceID1 would work. If serviceID1 is indeed the binding IP address (as called in the arch draft), then changing the routing to an IP address is only possible by influencing the routing that determines the path to that IP address. This is mode 2 in email.

[zongpeng] I think we have not change the route for D-BID, i.e. serverIP1 and serverIP2.
                    I mean we have changed the route for D-SID, i.e. serviceID1. [zongpeng]
[DOT] I do not understand what ‘changing the route for D-SID’ means. You are picking D-BID1 or D-BID2, that is it. If there are n routes to D-BID1, it is not up to the ingress to pick any of those available routes, the underlay routing has done that already! So you can somewhat ‘change the route for D-SID’ but only to the extent that you select the “better route” to D-BID1 over the “better route” to D-BID2, if you happen to use some combination of compute and network metric to make such decision. But again, this is just what I described as mode 1. Since you do not impact the selection of possible routes to any of the D-BIDs, you do not touch the routing system. Isn’t that right?
  [zongpeng] As said before, I don’t think we need to select a D-BID on the Ingress. We only need to have the information related to the server marked as D-BID on the Ingress. What we need to do is just to select an Egress for the D-SID according to the information mentioned before. [zongpeng]

Traditionally, it is decided by BGP route selection methods. In CAN, the route is decided by a more complicated procedure. However, in the forwarding plane, it keeps the same, i.e. forwarding according to the routing table.
[DOT] So you are suggesting that CAN uses mode 2 in my email and thereby impacts the routing system?

[zongpeng] There may be multiple paths between the Ingress and Egress1/2. However, the job of selecting path is the duty of the underlayer.
                        We only need the information of the selected path on the Ingress to influce the route for serviceID1.
    [zongpeng]
[DOT] You seem to confirm what I described as mode 1, i.e., no path selection to a single service instance is done (this remains the job of the underlay). But you seem to call the selection between D-BID1 and D-BID2 as “…to influence the route for D-SID”. This ‘routing challenge’ is one of instance selection of the endpoints to paths that the underlay constructed. If we can agree on that, we end up at CAN doing mode1.

 [zongpeng] As said before, I don’t think we need to select a D-BID on the Ingress. The table is just used for the collection of information. What we have selected is actually a tunnel/policy to one Egress.[zongpeng]

Best Regards
Zongpeng Du




________________________________
[e-mail]<mailto:[e-mail]> & [e-mail]<mailto:[e-mail]>

From: Dirk Trossen<mailto:dirk.trossen=[e-mail]>
Date: 2022-06-17 16:21
To: [e-mail]<mailto:[e-mail]>; linda.dunbar<mailto:[e-mail]>; dyncast<mailto:[e-mail]>
CC: rtgwg<mailto:[e-mail]>; David R. Oran<mailto:[e-mail]>; jefftant.ietf<mailto:[e-mail]>
Subject: Re: [Dyncast] CAN BoF issues #7 #17 #32
Hi Peng,

Please see inline.

Best,

Dirk

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: 17 June 2022 10:13
To: Dirk Trossen <[e-mail]<mailto:[e-mail]>>; linda.dunbar <[e-mail]<mailto:[e-mail]>>; dyncast <[e-mail]<mailto:[e-mail]>>
Cc: rtgwg <[e-mail]<mailto:[e-mail]>>; David R. Oran <[e-mail]<mailto:[e-mail]>>; jefftant.ietf <[e-mail]<mailto:[e-mail]>>
Subject: Re: RE: [Dyncast] CAN BoF issues #7 #17 #32

Hi Dirk,

For mode 1, CAN is only aware of computing information, because the basic routing could select the 'best' path naturely.
[DOT] In mode 1, I can well observe path-related metrics, say latency, and pick IP1 over IP2 (both realized over different paths, hence likely experiencing different network metrics).This is the ‘indirect’ manner I mentioned. But the path themselves to IP1 and IP2 is not something that CAN here impacts since they are created entirely separately by the underlay. More, as explained in mode 2, there may be a choice of two or more path to IP1, but it’s the network that makes the selection here which to use, while CAN only chooses IP1 over IP2, tied to the choice of path that the underlay made.

For mode 2, CAN could also know more about the network path when the computing node selection is done, for instance, SR policy, network slicing, detnet, etc. and then utilize them. I don't think it will influence the underlay routing, some apps could require for the specific routing policy/strategy even there is no CAN service.
[DOT] How can it not impact the underlay? In the way I describe it, if you want to jointly optimize the path constructed to a single instance IP address, you will need to do this in the underlay routing, akin to other policy-based decisions.

CAN aims to provide the joint optimization service to specific applications. The difference is that whether to select the 'best' resource all the time, or just select the 'appropriate' one based on more awareness and decision making.
[DOT] I don’t quite see how this relates to my modes since both aim for what you call the ‘appropriate’ choice. I am not sure I understand the difference to ‘best’ though unless ‘best’ is limited to network decisions without compute awareness here, which is a limited view. I would argue that we want to extend ‘best’ to include both.

Regards,
Peng
________________________________
[e-mail]<mailto:[e-mail]>

From: Dirk Trossen<mailto:[e-mail]>
Date: 2022-06-17 15:01
To: Linda Dunbar<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; dyncast<mailto:[e-mail]>
CC: rtgwg<mailto:[e-mail]>; David R. Oran<mailto:[e-mail]>; jefftant.ietf<mailto:[e-mail]>
Subject: RE: [Dyncast] CAN BoF issues #7 #17 #32
Hi Linda, Peng, all,

Let us tease apart what “include the path selection” may mean since the nature of this inclusion may be significant in difference.

For this, let us assume a service instance S_1 as one of possibly several ones for service S. S_1 may be reachable over a number of network paths, the selection of some of which would significantly impact any compute-aware selection of S_1 over the other available service instances for S. I can see two modes of ‘including path selection”:


1.      S_1 exposes two (or more) IP addresses, where each IP address reflects a path from the client to the exposed address. IP addresses may be exposed across more than one network operator, multi-homing the service instance. Now here, ‘path selection’ is indirectly done by picking one IP address over all others, including the IP addresses of other service instances, and indeed, such indirect path selection may well be done through a metric that measures against (at least one) crucial path-related metric. But ultimately, the CAN provider selects one of possibly many IP address still, right? More importantly, it remains the task of the underlay routing infrastructure (again, which could include more than one network operator) to determine what it deems as the ‘best’ path to each of the IP addresses (including the multi-homed S_1 addresses).

2.      Let’s stick with one IP address to S_1 now though but there are still at least two possible paths to it, where the selection of one over any of the other possible ones could well impact the compute-aware suitability of S_1 over any of the other service instances. Problem here is that ‘including the path selection’ would mean to impact the routing to the single S_1 IP address in a manner that that routing decision takes the compute-awareness into account. The path selection here is not indirect but direct, together with the IP address (i.e., service instance endpoint) selection. What is required here is that CAN provider and underlay somehow work together in selecting one path over another (to the same IP address), which in turn would mean to impact the overall routing decision for S_1’s IP address, which in turn would mean to impact the underlay routing infrastructure since the resulting (compute-aware) path configuration, in the form of suitable forwarding entries, needs distribution in the underlay infrastructure.

I think we have to be clear which of the two options we see in the CAN scope but also if I may have missed options here. As we can see already from those two options, they  have a significant impact on the architecture we may envision for CAN but also for its solution adoption. From my side, I have seen CAN mainly as an endpoint selection problem, so understood ‘path selection’ as an indirect one in the manner described in item 1. I just want to throw the options out here to solicit feedback from the community on this so that we get a good understanding moving forward.

Best,

Dirk

From: Dyncast [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: 15 June 2022 23:07
To: [e-mail]<mailto:[e-mail]>; dyncast <[e-mail]<mailto:[e-mail]>>
Cc: rtgwg <[e-mail]<mailto:[e-mail]>>; David R. Oran <[e-mail]<mailto:[e-mail]>>; jefftant.ietf <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Dyncast] CAN BoF issues #7 #17 #32

Peng,

For Issue #32, you said: “CAN does not compute path, it selects endpoints.”

If CAN means Computing Aware Networking, it should include the path selection. Maybe CAN is about  Selecting (or computing) the optimal paths based on the combination of network conditions and the end point computing available resources?

My two cents,

Linda

From: Dyncast <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Monday, June 13, 2022 10:00 PM
To: dyncast <[e-mail]<mailto:[e-mail]>>
Cc: rtgwg <[e-mail]<mailto:[e-mail]>>; David R. Oran <[e-mail]<mailto:[e-mail]>>; jefftant.ietf <[e-mail]<mailto:[e-mail]>>
Subject: [Dyncast] CAN BoF issues #7 #17 #32

Dear All,

Here are the responses to issues #7 #17 #32, any comments are welcome!  The issues and responses are also copied to the questioner (<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-113-can%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HA8ebRR0zU586fKOEn%2BX245pVB5wQ51BBnJjXYWD4dw%3D&reserved=0>https://datatracker.ietf.org/doc/minutes-113-can/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-113-can%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HA8ebRR0zU586fKOEn%2BX245pVB5wQ51BBnJjXYWD4dw%3D&reserved=0>)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-113-can%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HA8ebRR0zU586fKOEn%2BX245pVB5wQ51BBnJjXYWD4dw%3D&reserved=0>, hope for further suggestions and confirmation. Thanks!

#7 This seems to assume conventional non-distributed applications just running at the edge. What about modern frameworks like Sapphire? and Ray? <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F7&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DpLlwOTLZ8V7gF%2B2JvSBIbXUnEqpEdpVWfYzv9IgRzA%3D&reserved=0>
It would be good to understand the multi-site requirements of such frameworks, which seems to mainly run in single DCs.

#17 Whether the interests of the organization deploying the application and the organization providing the network connectivity are aligned. Google doesn't worry about this because they are both.<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F17&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4%2B%2FmX48%2FoHZRp8m7xVV9kOitmL6pmfb56M%2F8bGPNNDM%3D&reserved=0>
The question is more what the scope and semantic of information is that will need to cross organizational boundaries. This needs further study, in particular when assuming stakeholder division between service and network provider.

 #32 How to effectively compute paths? Shall we put CPUs into account? <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F32&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pEZtXQ54gaT4Bx4gwrKyJWyBLM6YImEwnSpg%2B5m%2FiO4%3D&reserved=0>
CAN does not compute path, it selects endpoints. Path selection (to a given endpoint) is subject to the routing at the IP underlay. For selecting endpoints, CPU information may be taken into account to achieve the 'compute-awareness' that CAN strives for.

You can also add your comments to any of them(https://github.com/CAN-IETF/CAN-BoF-ietf113/issues<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C2YRche0EjTbxhZWVwHSvYhN8OA7SCcfXhLSFA%2Bqnbk%3D&reserved=0>).

Regards,
Peng

________________________________
[e-mail]<mailto:[e-mail]>

From: Linda Dunbar<mailto:[e-mail]>
Date: 2022-05-11 06:11
To: [e-mail]<mailto:[e-mail]>
Subject: [Dyncast] Categories of the CAN BoF issues
CAN BoF proponents:

Many thanks for creating the CAN BoF issues tracking  in the Github: https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/created_by/CAN-IETF?page=1&q=is%3Aopen+is%3Aissue+author%3ACAN-IETF<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2Fcreated_by%2FCAN-IETF%3Fpage%3D1%26q%3Dis%253Aopen%2Bis%253Aissue%2Bauthor%253ACAN-IETF&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C4067359765a3464eebd408da4db152f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637907721259352014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZqH4%2FI1csqsOVjpnw1TmFJJzMX86fCfPzgjbjfAnJHY%3D&reserved=0>

I went through the issues captured in the Github and characterized them into groups. Some issues can be lumped together for the discussion. There are quite a few issues related to the requirements, which need to be clarified.

Best Regards, Linda


Issues associated with Applications vs. Underlay networks:

•        Consider not to load underlay network with application details. #35

•        We have multiple upper layer application. Do we have additional needs for routing(e.g. WG?) or we are using those applications and won't need such new WG? #30

•        It needs application information too, so it can't just make a decision at the network layer. #23

•        This is not striked as a routing problem; it's all service discovery that can be done in higher layers. #21

•        3GPP and URSP solve this based on UPF selection. It uses both endpoint + application. #20

•        One overlay plane per application. Resources/metric specific to the plane. #19

•        How does the application layer or the transport layer learn the network status to steering traffic? #16

Need more clear requirements for CAN (to be addressed by draft-liu-dyncast-ps-usecases):

•        Need to understand if three are requirement to avoid extra messages or 1ms of latency #36

•        Regarding the flow affinity, is it from network perspective or from application/computation perspective? #33

•        How to effectively compute paths? Shall we put CPUs into account? #32

•        What happens when the user moves? If so we also need to move application context. #25

•        It can only move the services around as fast as it can update the routing plane. which comes back to the point about service discovery (waiting for convergence/distribution as opposed to just updating the SD server) #24

•        Whether the interests of the organization deploying the application and the organization providing the network connectivity are aligned. Google doesn't worry about this because they are both. #17

o   The question is more what the scope and semantic of information is that will need to cross organizational boundaries. This needs further study, in particular when assuming stakeholder division between service and network provider.

•        It seems impossible to satisfy that requirement simultaneously with the latency requirement. #15

•        It wasn't clear that how hard of a requirement session persistence is. #13

o   A session usually creates ephemeral state. If execution changes from one (e.g., virtualized) service instance to another, state/context needs transfer to another. Such required transfer of state/context makes it desirable to have session persistence (or instance affinity) as the default, removing the need for explicit context transfer, while also supporting an explicit state/context transfer (e.g., when metrics change significantly).

•        Should it select UPF based on the application? Steering is done per user? or per application? #9

•        This seems to assume conventional non-distributed applications just running at the edge. what about modern frameworks like Sapphire? and Ray? #7

o   It would be good to understand the multi-site requirements of such framework, which I have understood to mainly run in single DCs.

•        Relation to 3GPP UPF #6

•        Relation to ALTO #5

•        Do the mobility issues and associated protocols are also in scope? There are scenarios where routing alone would not be sufficient. #4

•        What is the position in the edge location regarding to UPF? #3

•        Is there some sort of authorization model so that an edge can indicate whether or not it will provide compute services? #2

•        What is CNC and the relationship with CAN #1


Measurement of the Computing Resources (to be addressed by draft-du-computing-resource-representation):

•        It is hard to use existing work to measure the computation, but we can optimize the latency through the performance monitoring. We have performance/measurement matrix over there. #34

•        Clarifications on the computing resource, its requirements and characteristics would be helpful. #27

•        Each application may have a different definition of "resources" these then have to be boiled down into a single topology Network Aware Computing (NAC! :) does scale #14

•        Is computing resource measurable? #10

o   It is, and how to use the measurement would be solution related. See IFIP Networking 2022 paper on how to simply expose “computing capability” and achieve better steering with such simple measure.

•        Why compute resource is different with other resources? #8

•
Load Balance based solutions:

•        The point is that we need a standardized LB protocol #18

•        The LB as part of the application itself is superior (part of the distributed application itself is to obtain and keep updating the "best" unicast location to use). #22

•        If there is anything missing from current lbs that would prevent their use as-is? other than there is for market reasons no interop standard between different lbs? #12

•        For the load balance, should it learn the network’s status? #11

•
Dyncast based Solution issues:

•        For Dyncast, when the time is short, is it possible for the router to decide the routing? It is too fast. #31

•        Is dyncast proposed to encapsulate? #29

•        Will CAN dyncast impact each and every router? How to avoid loops? #28

•        What's the assumed scale of a D-router? 10 ^ 6 sessions? 100^ 8? What's the assumed update rate? !Gb? 1Tb? #26