Re: [Dyncast] CAN BoF issues #4 #15 #36

[Dirk Trossen <[e-mail]>]

Hi Daniel,

Let me try to tease the claim apart, i.e., “to make this connection stable when it would be otherwise as the service instance shifts without CAN scheme”.

Now if we assumed service instances S_1, …, S_n of service S being deployed at possibly several network location, I would want to understand how a transport link would be stable if CAN selects S_1 at t1 and S_2 at t2, assuming that the conditions of the chosen CAN metrics changed between t1 and t2?

My main problem, to explain further, is that any service transaction, involving thus transport, transport security and application aspects, will create ephemeral state (e.g., transport state machines, security contexts, app-dependent state of any sort), which would need to be accessible to S_2 after the change from S_1 for any transaction to proceed seamlessly, right?

Also, I don’t understand your comment on referring to “…as the service instance shifts without CAN scheme”. Isn’t the point of CAN to allow for selecting service instances based on metrics, so that they indeed would shift. True, this shift is done associated to the service identifier against which all instance bind, but still the instance does possibly change. However, the current drafts assume that this change observes the possible affinity of the transaction, thereby won’t happen mid-transaction to avoid the need for explicit context transfer.

Now I think we can think a lot about how CAN may help the problem of transaction mobility, something like a ‘value-added service’.

Best,

Dirk

From: Dyncast [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 22 June 2022 03:33
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Dyncast] CAN BoF issues #4 #15 #36


Linda，

Let's instantiate the service in CAN as a rendering algorithm (RA), CAN is employed to select a proper RA instance among many of them across mupltiple sites according to the computing status asscociated with RA. RA identification in the CAN data plane is thus phiscal position independant, and CAN routing nodes play the role of switching RA service among different instances when necessary. when it comes to the L4 connection such as TCP connection which is the "service link" you quoted from my sentence, it's conveniently possible to make this connection stable when it would be otherwise as the service instance shifts without CAN scheme.



Regards,

Daniel Huang









黄光平 huangguangping



架构团队/有线规划部 Wireline architecture team./Wireline Product R&D Institute


[cid:[e-mail]4D400]

[cid:[e-mail]4D400]
南京市雨花区软件大道50号中兴通讯2号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: [phone]<tel:+86%2013770311052>
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>

原始邮件
发件人：LindaDunbar
收件人：黄光平10039714;[e-mail];
抄送人：[e-mail];[e-mail];[e-mail];[e-mail]<mailto:[e-mail];[e-mail];[e-mail];[e-mail]>;
日 期 ：2022年06月21日 22:49
主 题 ：Re: [Dyncast] CAN BoF issues #4 #15 #36
--
Dyncast mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dyncast
Daniel,

What does service link mean in your sentence? Can you give an example?
“it's determined at CAN ingress through "routing" of the service identification which actually could also be used to establish the service link at layer 4…”

Thank you very much,

Linda
From: rtgwg <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, June 21, 2022 4:53 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re:[Dyncast] CAN BoF issues #4 #15 #36


Hi Peng,

as far as issue 36 is concerned, here's  a distinctive perspecitve I would like to bring up CAN architecture in terms of its potential benefits against the ongoing solutions such as DNS & GSLB which would inherently bring extra messages and thus latency. When it comes to service instance selection process, it's done by DNS & GSLB or its equivalent node, while it's determined at CAN ingress through "routing" of the service identification which actually could also be used to establish the service link at layer 4, therefore the service link would remain intact when the service end node shifts through CAN routing policies.

in case of service node changing in service transaction, CAN routing logically plays the role of DNS & GSLB and there would be no extra messages incurred other than extra state brought in CAN nodes when necessary.



Best regards,

Daniel Huang













黄光平 huangguangping



架构团队/有线规划部 Wireline architecture team./Wireline Product R&D Institute


[cid:[e-mail]4D400]

[cid:[e-mail]4D400]
南京市雨花区软件大道50号中兴通讯2号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: [phone]<tel:+86%2013770311052>
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zte.com.cn%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125690629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qMEWhuiNfbk2jakPdTWbwoH4zKjnuJ0RtvaOiuhl7M8%3D&reserved=0>

原始邮件
发件人：[e-mail]<mailto:[e-mail]>
收件人：dyncast;
抄送人：rtgwg;jgs;Tony Li;cjbc;
日 期 ：2022年06月21日 17:27
主 题 ：[Dyncast] CAN BoF issues #4 #15 #36
--
Dyncast mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dyncast
Dear All,

Here are the responses to issues #4 #15 #36, which are related to the requirements of mobility, latency and flow affinity. Any comments are welcome.

This email is 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%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125690629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z76VEj%2BLQrGOrkipeD0kMWYLe0%2BaqJNaWAOxj338cNM%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%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125690629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z76VEj%2BLQrGOrkipeD0kMWYLe0%2BaqJNaWAOxj338cNM%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%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zqBjDeKgLvTB4vv9jZwFTws2XcVfgI5jR%2FhQg3Ya0cQ%3D&reserved=0>, hope for further suggestions and confirmations. Thanks.

#4 Do the mobility issues and associated protocols are also in scope? There are scenarios where routing alone would not be sufficient. <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F4&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bb9tSVIyqMVQ0JCOE3luJgWtNAHL8VSAZo41ZDjvXCA%3D&reserved=0>
Might need routing+mobility solutions. From the routing side, the service affinity are needed.
Supporting the affinity to a particular service instance while moving as a client will need a solution (which will depend on the realization of such affinity).
Supporting mobility across service instances, i.e. the moving from one service instance to another mid-way of an ongoing transaction, will need extra precaution, likely as a solution at the application layer but possibly supported through the CAN infrastructure.

#15 It seems impossible to satisfy that requirement simultaneously with the latency requirement. <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F15&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gWxyMTjhnyADc6ys72guboNj99Hl3mgSsLg4hc9SoSs%3D&reserved=0>
Fulfilling the session persistence (or affinity) requirement together with any latency requirement may indeed be a challenge, e.g., when long running sessions occur across varying compute conditions at smaller timescale. In this case, CAN may support session mobility from the possibly overloaded serving service instance to a new, better suitable, one (see also issue #4) during the ongoing session to mitigate the otherwise negative impact on latency. The methods with which CAN may support this are in scope of CAN’s proposed work

#36 Need to understand if there are requirement to avoid extra messages or 1ms of latency.<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCAN-IETF%2FCAN-BoF-ietf113%2Fissues%2F36&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W9MwFABIVwU8tX%2FgjQ4Bc5q37PoYUUAvxeo3LlHELxM%3D&reserved=0>
Extra messages, such as incurred in off-path systems like DNS, lead to possibly significant latency, particularly when incurred frequently in scenarios where possible service endpoints may need to change frequently. The use cases attempted to cover this. Generally, avoiding extra messages in any solution CAN may develop is a standard requirements for any engineering solution, following the simplification principle.

Any detailed discussion is expected to be only within dyncast mailing list. You can also check and 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%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P9%2FIiiN3etrv3C5XjDiFRYgMw6CCLVw%2F0Y%2FQU0w%2Bgpc%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%7Ca66a9eac1ee4463cde9208da536be384%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637914020125846352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e2SrQokN1k5RaPMwxWpfIm7v0KmBm8SdHPCS%2B7PNog8%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

§ 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

§ 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

§ 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<null>

§ 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