Re: [alto] [Dyncast] Fw: Re: CAN BoF issues #1 #5 #6
Hi Dirk, Thanks. Looks better. I wonder if more comments from Luis and others. Regards, Peng liupeng...@chinamobile.com From: Dirk Trossen Date: 2022-05-25 14:06 To: Linda Dunbar; liupeng...@chinamobile.com; luismiguel.contrerasmurillo; alto CC: dyncast Subject: RE: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Hi Peng & Linda, To fold the separate discussions and points made (by Luis and others) about on/off-path solutions, may I suggest the following wording: “CAN is a network layer solution, performing on-path service instance selection decisions with the possibility to adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). ALTO solves the problem of service instance selection as an off-path solution, which can be seen as an alternative way of addressing the problem space of CAN at the Application Layer. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Key here is the signaling latency and signaling load that the service instance selection will incur, both in on- as well as off-path solution. This is turn may impact the frequency with which applications will query ALTO server(s), especially when UEs are roaming among different cell sites (gNBs) triggering different network paths. As a result, off-path systems, e.g., ALTO, replies for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information.” Best, Dirk From: Dyncast [mailto:dyncast-boun...@ietf.org] On Behalf Of Linda Dunbar Sent: 24 May 2022 19:24 To: liupeng...@chinamobile.com; luismiguel.contrerasmurillo ; alto Cc: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Peng, Your new version looks very good. Linda From: liupeng...@chinamobile.com Sent: Monday, May 23, 2022 11:02 PM To: Linda Dunbar ; luismiguel.contrerasmurillo ; alto Cc: dyncast Subject: Re: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Hi Linda, Thanks. So the current answer can be described as follows to see if there are any other comments: CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). ALTO tries to solve the problem by exposing information that applications/services can consume before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from the Application Layer. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Compared to the on-path routing solution, since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-24 05:09 To: liupeng...@chinamobile.com; luismiguel.contrerasmurillo; alto CC: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Peng, The following sentence seems not a complete sentence: “While ALTO tries to solve the problem by exposing information that can be consumed by applications/services before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from Application Layer.” How about the following? “ALTO tries to solve the problem by exposing information that applications/services can consume before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from the Application Layer” Linda From: liupeng...@chinamobile.com Sent: Monday, May 23, 2022 4:33 AM To: Linda Dunbar ; luismiguel.contrerasmurillo ; alto Cc: dyncast Subject: Re: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Thanks, some revisions based on Linda's reply: CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Compare
Re: [alto] [Dyncast] Fw: Re: CAN BoF issues #1 #5 #6
Hi Linda, Thanks. So the current answer can be described as follows to see if there are any other comments: CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). ALTO tries to solve the problem by exposing information that applications/services can consume before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from the Application Layer. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Compared to the on-path routing solution, since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-24 05:09 To: liupeng...@chinamobile.com; luismiguel.contrerasmurillo; alto CC: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Peng, The following sentence seems not a complete sentence: “While ALTO tries to solve the problem by exposing information that can be consumed by applications/services before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from Application Layer.” How about the following? “ALTO tries to solve the problem by exposing information that applications/services can consume before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from the Application Layer” Linda From: liupeng...@chinamobile.com Sent: Monday, May 23, 2022 4:33 AM To: Linda Dunbar ; luismiguel.contrerasmurillo ; alto Cc: dyncast Subject: Re: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Thanks, some revisions based on Linda's reply: CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Compared to the on-path routing solution, since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-19 01:43 To: LUIS MIGUEL CONTRERAS MURILLO; liupeng...@chinamobile.com; alto CC: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Luis has good points. Maybe the Relationship to ALTO (Issue #5) should be explained this way? ALTO can be seen as an alternative way of addressing the problem space of computing-aware networking from Application Layer. Since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. [PL] CAN may not support all applications. If there is a specific way for ALTO to solve this problem, and also can be proved to be effective, we can see it as a potential solution. CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). While as ALTO tries to solve the problem by exposing information that can be consumed by applications/services before traffic delivery. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. My two cents, Linda From: Dyncast On Behalf Of LUIS MIGUEL CONTRERAS MURILLO Sent: Wednesday, May 18, 2022 9:52 AM To: liupeng...@chinamobile.com; alto Cc: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Hi Peng, In my view, ALTO can be seen as an alternative (maybe complementary) way of addressing the p
Re: [alto] [Dyncast] Fw: Re: CAN BoF issues #1 #5 #6
Thanks, some revisions based on Linda's reply: CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). While ALTO tries to solve the problem by exposing information that can be consumed by applications/services before traffic delivery, which can be seen as an alternative way of addressing the problem space of CAN from Application Layer. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. Compared to the on-path routing solution, since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. So, more details are needed of ALTO including some extension to support multi-deployment, quick interaction, integrate more performance metric information. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-19 01:43 To: LUIS MIGUEL CONTRERAS MURILLO; liupeng...@chinamobile.com; alto CC: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Luis has good points. Maybe the Relationship to ALTO (Issue #5) should be explained this way? ALTO can be seen as an alternative way of addressing the problem space of computing-aware networking from Application Layer. Since not all applications will query ALTO server(s), especially when UEs roaming among different cell sites (gNBs) triggering different network paths, the ALTO reply for applications/services before traffic delivery might not be optimal or valid after the handover. [PL] CAN may not support all applications. If there is a specific way for ALTO to solve this problem, and also can be proved to be effective, we can see it as a potential solution. CAN is a network layer solution, trying to solve the problem from on-path forwarding-based decisions and can adapt to different ingress routers caused by UEs roaming among different cell sites (gNBs & UPFs). While as ALTO tries to solve the problem by exposing information that can be consumed by applications/services before traffic delivery. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. My two cents, Linda From: Dyncast On Behalf Of LUIS MIGUEL CONTRERAS MURILLO Sent: Wednesday, May 18, 2022 9:52 AM To: liupeng...@chinamobile.com; alto Cc: dyncast Subject: Re: [Dyncast] [alto] Fw: Re: CAN BoF issues #1 #5 #6 Hi Peng, In my view, ALTO can be seen as an alternative (maybe complementary) way of addressing the problem space of computing-aware networking. The CAN proposition at RTG tries to solve the problem from on-path forwarding-based decisions, while ALTO try to solve the problem by exposing information that can be consumed by applications/services before traffic delivery. So in that respect, even targeting a common problem, both provide different approaches, then imposing different needs but also taking different assumptions on how applications and networks interact. For more detailed comments, please see my answers in-line Bets regards Luis De: alto En nombre de liupeng...@chinamobile.com Enviado el: miércoles, 18 de mayo de 2022 15:46 Para: alto CC: dyncast Asunto: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6 Hi ALTO WG, There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which is to steer the traffic among multiple edge sites considering both network and computing resource statues. The progress was also presented briefly in ALTO WG meeting. In the BoF, some people cared about the relationship between CAN and ALTO. We collected this issue and got the response from the proponents, also would like to post the clarification to see if there are more comments from the WG. Thanks! #5 What is the relation between CAN and ALTO? (issue #5) ALTO architecture has a central ALTO server pulling network status periodically to help managing deployment of the application and computing resource. But it is difficult for ALTO server to promptly assist many ingress nodes in choosing the optimal path based on the dynamic traffic conditions and computing resources at multiple locations because: 1) single point of bottleneck for all ingress routers to query application status; [Luis>>] I think that this is rather a matter of scalable design, than an actual limitation in the sense that different instances of ALTO server could be put if actually needed. 2) time taken for ingress routers to get the responses from the ALTO serv
[alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6
Hi ALTO WG, There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which is to steer the traffic among multiple edge sites considering both network and computing resource statues. The progress was also presented briefly in ALTO WG meeting. In the BoF, some people cared about the relationship between CAN and ALTO. We collected this issue and got the response from the proponents, also would like to post the clarification to see if there are more comments from the WG. Thanks! #5 What is the relation between CAN and ALTO? (issue #5) ALTO architecture has a central ALTO server pulling network status periodically to help managing deployment of the application and computing resource. But it is difficult for ALTO server to promptly assist many ingress nodes in choosing the optimal path based on the dynamic traffic conditions and computing resources at multiple locations because: 1) single point of bottleneck for all ingress routers to query application status; 2) time taken for ingress routers to get the responses from the ALTO server upon flows arrival; 3) ALTO server may not know the instantaneous congestion status of the network, all link bandwidths, all information about the actual routing and whether the candidate endpoint itself is overloaded according to RFC7971 CAN is to identify various measurements for service instances including the hosting environment, get them normalized together with network metrics for ingress nodes to choose the service instances. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-18 05:46 To: liupeng...@chinamobile.com; dyncast CC: rtgwg Subject: Re: [Dyncast] CAN BoF issues #1 #5 #6 Peng, The resolution for Issue 2 “Relation to ALTO” can add more on why ALTO “can’t really help to the service request”. How about the following? Relation to ALTO (issue #5) ALTO architecture has a central ALTO server pulling network status periodically to help managing deployment of the application and computing resource. But it is difficult for ALTO server to promptly assist many ingress nodes in choosing the optimal path based on the dynamic traffic conditions and computing resources at multiple locations because: 1) single point of bottleneck for all ingress routers to query application status; 2) time taken for ingress routers to get the responses from the ALTO server upon flows arrival; 3) ALTO server may not know the instantaneous congestion status of the network, all link bandwidths, all information about the actual routing and whether the candidate endpoint itself is overloaded according to RFC7971 CAN is to identify various measurements for service instances including the hosting environment, get them normalized together with network metrics for ingress nodes to choose the service instances. Almost like the reverse of the ALTO. My two cents, Linda From: Dyncast On Behalf Of liupeng...@chinamobile.com Sent: Monday, May 16, 2022 6:24 AM To: dyncast Cc: rtgwg Subject: [Dyncast] CAN BoF issues #1 #5 #6 Dear All, Based on the categories of the CAN BoF issues, here are the responses to the following issues #1 #5 #6, which clarifies the relationship to ITU-CNC, 3GPP-UPF and ALTO. Any comments are welcome. We will post the responses to more issues involved in BoF for more comments (https://github.com/CAN-IETF/CAN-BoF-ietf113/issues). You can also add your comments to any of them. Thanks! 1. What is ITU-CNC and the relationship with CAN #1 CNC focus on the vision, scenarios, requirements, architecture and network function enhancements for future mobile core network and the telecom fixed, mobile, satellite converged network, but not for internet or routing area. CAN Aims at computing and network resource optimization by steering traffic to appropriate computing resources considering not only routing metric but also computing resource metric and service affiliation. 2. Relation to ALTO #5 ALTO has the potential opportunity to help to the deployment of the application and computing resource but can't really help to the service request because the ALTO service may not know the instantaneous congestion status of the network, all link bandwidths, all information about the actual routing and whether the candidate endpoint itself is overloaded according to RFC7971. Moreover, Alto is an indirection-based method, contrasting with the on-path solution advocated by CAN. 3. Relation to 3GPP UPF #6 The CAN dyncast work is to depend on the network device to steering traffic other than the UPF. Virtualized UPFs in 5G have a similar issue: multiple UPFs instances can serve a group of gNB nodes. Selecting the UPF instance not only needs UPF load condition but also need network conditions. Regards, Peng liupeng...@chinamobile.com From: Linda Dunbar Date: 2022-05-11 06:11 To: dync...@ietf.org Subject: [Dyncast] Categories of the CAN BoF issues CAN BoF proponents: Many
Re: [alto] Call for adoption: draft-zhang-alto-oam-yang
Hi WG, I support the adoption. Regards, Peng liupeng...@chinamobile.com From: mohamed.boucad...@orange.com Date: 2022-04-04 18:13 To: alto@ietf.org; draft-zhang-alto-oam-y...@ietf.org CC: alto-cha...@ietf.org Subject: Re: [alto] Call for adoption: draft-zhang-alto-oam-yang Hi all, This is a reminder that this call for adoption is still running. Cheers, Qin & Med De : mohamed.boucad...@orange.com Envoyé : mercredi 23 mars 2022 14:45 À : alto@ietf.org; draft-zhang-alto-oam-y...@ietf.org Cc : alto-cha...@ietf.org Objet : Call for adoption: draft-zhang-alto-oam-yang Hi all, As discussed during the IETF#113 meeting, this message initiates the call for adoption of draft-zhang-alto-oam-yang to meet the following ALTO WG milestone: == Dec 2022ALTO OAM Document/YANG Model == Please reply to this message indicating your support or objection to adopt the document. The call will run till 08 April 2022. Thank you Qin & Med _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
