Re: [alto] [Cats] DMDTF and CATS Metrics
Hi Luis, Thanks for the references. They proposed the compute related metrics which could be considered for cats(may also for alto). https://www.rfc-editor.org/rfc/rfc7666.html uses CPU, memory, storage and NIC as the metrics. https://www.ietf.org/archive/id/draft-contreras-alto-service-edge-07.txt takes CNTT as an example, including _Type of instance, _Interface Option, _Compute flavor（virtual CPU, RAM, disk, and bandwidth）,_Optional storage extension，and _Optional hardware acceleration characteristics. For different use cases, whether and how to uses those metrics should be discussed more, considering the balance between the availability and efficiency. Regards, Peng liupeng...@chinamobile.com From: LUIS MIGUEL CONTRERAS MURILLO Date: 2023-04-12 13:25 To: adr...@olddog.co.uk; 'Dean Bogdanovic' CC: c...@ietf.org; 'alto@ietf.org' Subject: Re: [Cats] DMDTF and CATS Metrics (Adding ALTO in cc since discussion on metrics is also relevant for that WG) Hi Adrian, Dean, Another reference work we can consider is https://www.rfc-editor.org/rfc/rfc7666.html. This RFC provides several metrics as part of the MIB definition that could be leveraged on. Apart from that, I think we need to look at what current cloud / VI managers provide nowadays in terms of metrics (i.e., OpenStack, Kubernetes, etc) since the metrics that we could handle will be generated most probably for those non-IETF components. So a good exercise to start with would be to check and compare what kind of metrics these kind of sustems provide nowadays, and derive from that a common / abstract set of metrics that could be consumed by both CATS and ALTO. In https://www.ietf.org/archive/id/draft-contreras-alto-service-edge-07.txt there is reference as well to CNTT and Anuket efforts, which probably need to be revisited and updated. All in all, an exercise of collecting different sources is needed, and from that select relevant metrics for the purposes of ALTO and CATS. Best regards Luis De: Cats En nombre de Adrian Farrel Enviado el: viernes, 7 de abril de 2023 20:17 Para: 'Dean Bogdanovic' CC: c...@ietf.org Asunto: Re: [Cats] DMDTF and CATS Metrics Ah, thanks Dean. Interesting coincidence of acronyms. This work does, indeed, look relevant. Cheers, Adrian From: Dean Bogdanovic Sent: 07 April 2023 19:01 To: Adrian Farrel Cc: c...@ietf.org Subject: Re: DMDTF and CATS Metrics Hi, I was referring to the work that is being done by Redfish and has been presented at IETF 98 by Joe White (https://datatracker.ietf.org/meeting/98/materials/slides-98-rtgwg-yang-device-profile-for-redfish-network-management-draft-wbl-rtgwg-baseline-switch-model-draft-wbl-rtgwg-yang-ci-profile-bkgd-00). This work didn’t continue within the IETF, but Redfish has published and keeps developing and maintaining their data model (https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2022.2.pdf]. They did lot of compute resource modeling and taking a loot at their work is very useful IMO. DMTF folks know lot about compute, so it might be worth even rekindling the joint work. Dean On Apr 7, 2023, at 12:34 PM, Adrian Farrel wrote: Hi all, In the meeting in Yokohama, Dean Bogdanovic mentioned a presentation from IETF-98 that might be relevant to our metrics works. I did some digging and found the presentation by the IEEE 802.3cf - YANG Data Model Definitions Task Force. The purpose of that work was to migrate relevant MIB modules to YANG. The slides for that session are at https://datatracker.ietf.org/meeting/98/materials/slides-98-netmod-sessa-iee e-8023cf-yang-data-model-definitions-task-force-00 The presentation is at https://youtu.be/hUSx_Ua3MnY?t=3326 and the presenter was Rob Wilton who would, I'm sure, be responsive to questions. I'm not clear how much this is relevant. Dean, was that the presentation you were referring to? Cheers, Adrian Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e
[alto] CAN key Q
Dear All, According to the progress and long discussion of CAN, we believe we have reached some consensus of the following three important issues. More detailed clarification of those issues could be found in https://github.com/CAN-IETF/CAN-BoF-ietf113/blob/main/CAN-Key-Q%26A.doc. 1. What is the relationship between CAN and ALTO? There were some discussions and the responses in https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/5. After discussion in mailing list, IETF meetings with people interested in CAN and ALTO, we get the conclusion: CAN aims to provide a possible on-path solution for efficiently steering traffic to one of possible many service instances. The on-path solution requires to make the decision on the ingress node of the network based on network and other metrics. These kind of metrics may be distributed through extensions to routing protocols. ALTO is by inquiry and response, i.e., off-path, mechanism, which is different from the on-path approach proposed in CAN. 2. What is the relationship between CAN and TSV Area? We had presented CAN work in TSVWG in IETF114 and get the conclusion from TSV WG: CAN is a Routing Area work item, people can keep following TSV to see what is needed in transport protocols. 3. What is the relationship between CAN and Load Balancer? There are several types of Load Balancer, L7/L4/L3 load balancers. CAN aims to provide L3/L3.5 solution for selecting better instance, therefore CAN could act similar to the role of L3/L3.5 load balancer, but not limited to it. Any comments or suggestions are welcome. Regards, Peng liupeng...@chinamobile.com ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] charter-ietf-alto-04-01
Hi all, Indeed, Amin's speech in sigcomm NAI 2021 inspired me a lot. I hope ALTO can be rechartered to cover more networking use cases, such as our computing aware networking use case and requirements. we really want to investigate how ALTO can be integrated into our work and serve as one of key components in our framework. Yes, we are looking for more help and input on this topic. Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com From: Y. Richard Yang Date: 2021-08-24 22:42 To: Lars Eggert CC: IETF ALTO; alto-cha...@ietf.org; Qin Wu; The IESG Subject: Re: [alto] charter-ietf-alto-04-01 Hi Lars, I saw your comment and have to chime in. I have to respectfully disagree with your assessment: "Overall, I remain unconvinced that there is sufficient work/interest in this space to warrant a chartered WG." I am not sure if you attended the NAI@SIGCOMM'21 Workshop yesterday. There was clearly a huge interest and work in the space. The title of Amin Vahdat's talk is "Application-Defined Networking", as "It now opens the next wave of opportunities toward Application-Defined Networking, Where application efficiency metrics drive network control configuration policy, Integration into compute and storage infrastructure→ job placement, replication, Visibility into distributed systems structure, including Load Balancing, Thread Scheduling, RPCs, RDMA, and Collectives", using the sentences from the keynote. Now, let's go more specific to ALTO and to engineering. The work of Flow Director, in the scope of ALTO, was reported in CoNEXT'19 (https://gsmaragd.github.io/publications/CoNEXT2019/). Luis mentioned ongoing deployment efforts at Telefonica; there is the on-going deployment of ALTO at the Greater Bay Network, which is a large, among the most-advanced networks covering Shenzhen, Hong Kong; there is the ongoing MoWIE work, based on and the need to extend ALTO, by China Mobile and Tencent... I agree that ALTO is far far far from taking over the world, but I have a totally different assessment. If when you say that there is not sufficient work, you mean that *the charter* does not include sufficient work. This is by design and good guidance: the WG substantially limits the scope of the recharter to consolidate the WG in the short term, and there was a huge disappointment from many industry parties on the removing of their work from the charter discussions---not sure if you attended some of the recharter discussions, there was a large amount of proposed work but they were mostly removed. Please see below. On Tue, Aug 24, 2021 at 9:29 AM Lars Eggert wrote: Hi, On 2021-8-24, at 16:07, Qin Wu wrote: > Thank you for reviewing the proposed re-charter of the ALTO working group. > > It's not clear to me why this effort would need a chartered WG vs. just a > > mailing list and/or a wiki. A chartered WG has many benefits. As one example, multiple participants spend huge efforts on the ALTO work and bring "human resources" to IETF; an informal mailing list/wiki will be harder to justify the efforts. I assume that many IETF WGs can also operate mostly as a mailing list/wiki; then the participation can be lower, it will be harder to maintain scope, to meet deadlines. We feel that the WG recharter has wonderful guidance to be focused, to be timely. > >> o Develop operational support tools for ALTO. > > See above. > > I'm not aware of any larger-scale product deployments of ALTO - do some > > exists? See some examples above. > > Otherwise, I question whether operational tools can effectively be developed > > without relevant operational experience. > There is big suggestion that the reason for no larger-scale product > deployment of ALTO is because missing operational support tools. > It is big mistake to make protocol without operational support. > We saw this happen many times with OAM added much later. It make the > protocol hard to use and is bad for operator. Would you point me at a discussion where this lack of operational support was brought up by a potential large-scale deployer as a reason to not deploy ALTO? The issue of lacking operational support was not proposed by academics, but by people from the operator sides, during ALTO meetings, e..g., by Lyle Bertz (T-Mobile), Luis (Telefonica). The main complexity discussed by the Steering Giants report was mostly operational. > >> o Support for modern transport protocols. ALTO only uses the capabilities > >> of > >> HTTP version 1. Since then, the IETF has developed HTTP/2 and HTTP/3. The > >> working group will develop any necessary protocol extensions and guidance > >> to > >> support the use of
Re: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments
Hi Qin, Thanks. These issues really deserve further consideration. Please see inline. Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com 发件人: Qin Wu 时间: 2021/07/23(星期五)21:31 收件人: LUIS MIGUEL CONTRERAS MURILLO;Peng Liu;alto; 主题: RE: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments Hi Peng, Thanks for sharing. Looking at the figure of the CAN framework I can see depicted multiple components interacting with the ALTO server: Service Orchestration, Computing OAM, Routing Management and Resource Management. This brings to my mind a number of questions: - Do you foresee an individual interaction per component with the ALTO Server? If so, what would be the specific interaction per component and to what extend such interaction would imply some extension? [Qin Wu] Good question, let me ask authors in a different angle 1. Can we have one single protocol to collect both network information and compute information [PL] Yes, extending BGP may be an option, or the network probe packet carrys computing information. Both require the service node to expose the corresponding information to the gateway. 2. or we still use different protocol to collect network information and compute information but, we could use one single protocol e.g., ALTO protocol to expose both network information and compute information to the application? The problem, how we can make sure the network information and compute information are synchronized if these information change over time? [PL] If the network and computing information are colleted to Alto through different protocols, it is difficult to maintain absolute synchronization unless time stamps and other information are added, but this may require time synchronization of all the network nodes and the service nodes, which will cause some additional expenses. The accuracy of synchronization will affect the quality of service, and the demands of applications should also be considered. - Would not be more practical to consider a single ALTO Client as part of the Computing and Network Management Layer aggregating all the requests towards the ALTO Server? This also could decouple the solution from a specific CAN architecture - In the scheduling section, you mention the possibility of retrieving real time information. How far the information could be “real-time”? I mean, in the way ALTO works (i.e., collecting information from protocols such BGP with certain timers) the notion of “real-time” could be relative. Would the aging of that information sufficient to ensure the “real-time” needs? Would it be needed any other mechanisms to shorten the period of information refreshment? Best regards Luis De: alto En nombre de Peng Liu Enviado el: miércoles, 21 de julio de 2021 5:39 Para: alto Asunto: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments Hi All, A new draft draft-liu-alto-can-usecase-00 has been submitted（https://www.ietf.org/archive/id/draft-liu-alto-can-usecase-00.txt） Since some work of computing related service deployment and routing have been proposed in IETF and ITU, this draft describes a new network scenario and architecture considering computing-related properties, and assumes that Alto could be used to help realize the deployment of services, and to assist in the selection of service nodes. Any comments are welcome. Regards, peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou
Re: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments
Hi Luis, Thanks for the question and comments, please see inline. Regards, Peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com 发件人: LUIS MIGUEL CONTRERAS MURILLO 时间: 2021/07/21(星期三)23:36 收件人: Peng Liu;alto; 主题: RE: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments Hi Peng, Thanks for sharing. Looking at the figure of the CAN framework I can see depicted multiple components interacting with the ALTO server: Service Orchestration, Computing OAM, Routing Management and Resource Management. This brings to my mind a number of questions: - Do you foresee an individual interaction per component with the ALTO Server? If so, what would be the specific interaction per component and to what extend such interaction would imply some extension? [][ [PL] I think Alto has the potential to do some management work. Each component interacts with specific information, and may also make corresponding expansion. But I don't mean that every component has to interact with Alto(Maybe it's a misunderstanding of the graph). An alternative way is to have a unified agent to interact with Alto. On the one hand, it needs to consider the specific implementation of functions, on the other hand, it depend on whether alto could or want. - Would not be more practical to consider a single ALTO Client as part of the Computing and Network Management Layer aggregating all the requests towards the ALTO Server? This also could decouple the solution from a specific CAN architecture [] [PL] It is a good way, thank you! Maintaining a certain degree of decoupling is also conducive to the realization, which we will consider in detail later. - In the scheduling section, you mention the possibility of retrieving real time information. How far the information could be “real-time”? I mean, in the way ALTO works (i.e., collecting information from protocols such BGP with certain timers) the notion of “real-time” could be relative. Would the aging of that information sufficient to ensure the “real-time” needs? Would it be needed any other mechanisms to shorten the period of information refreshment? [PL] I agree with that the notion of “real-time” could be relative. The real-time performance may affect the result of scheduling. If it is good, the scheduling can be more accurate and better meet the application requirements; If the real-time performance is not good, the network or node state may change when the flows arrive, resulting in the demand can not be met. BGP is an option but may not be satisfied for the application with very high delay requirements, so we are also studying how to improve the performance of BGP or announce the corresponding information through other ways. Best regards Luis De: alto En nombre de Peng Liu Enviado el: miércoles, 21 de julio de 2021 5:39 Para: alto Asunto: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments Hi All, A new draft draft-liu-alto-can-usecase-00 has been submitted（https://www.ietf.org/archive/id/draft-liu-alto-can-usecase-00.txt） Since some work of computing related service deployment and routing have been proposed in IETF and ITU, this draft describes a new network scenario and architecture considering computing-related properties, and assumes that Alto could be used to help realize the deployment of services, and to assist in the selection of service nodes. Any comments are welcome. Regards, peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou
[alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments
Normal 07.8 磅 0 2 false false false EN-US ZH-CN X-NONE MicrosoftInternetExplorer4 Hi All, A new draft draft-liu-alto-can-usecase-00 has been submitted（https://www.ietf.org/archive/id/draft-liu-alto-can-usecase-00.txt） Since some work of computing related service deployment and routing have been proposed in IETF and ITU, this draft describes a new network scenario and architecture considering computing-related properties, and assumes that Alto could be used to help realize the deployment of services, and to assist in the selection of service nodes. Any comments are welcome. Regards, peng Peng Liu | 刘鹏 China Mobile | 移动研究院 mobile phone：13810146105 email: liupeng...@chinamobile.com___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
