Re: [alto] Potential topics for Proposal #3: Support ALTO Extensions for the New Industry Needs

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi all,

Some additional comments from my side, in this case regarding B and C.

In B there is for sure space for the operational matters related with ALTO, some of them identified so far. This would be certainly the case of security of ALTO as a production component within networks. But also related to maintenance of ALTO we can consider aspects such as the extension to using BGP communities, for instance. That is, progress on ALTO protocol and framework for making it more "operational" oriented, once we are gaining experience on it and identifying further needs.

In the case of C, my way of looking to it, is that ALTO can become the enabler of new services by means of the exploitation of properties associated to the network and cost maps. Trustness is a very relevant property, and certainly it can be a new service provided by ALTO, but additional properties could be also considered as we commented during the interims. So this would open a new dimension of ALTO which is working on properties associated to the topology and cost information (some examples commented during the interim were providing information about keys for being used in a communication, providing information about encryption support, etc). In summary, enabling services by leveraging on the exposure of properties, not only costs. Trusted topologies can be an initial work in this line.

Thanks Sabine and Jordi for your explanations. Hope this can serve as complement to yours.

Best regards

Luis

De: alto <[e-mail]> En nombre de Jordi Ros Giralt
Enviado el: jueves, 15 de junio de 2023 12:09
Para: Sabine Randriamasy (Nokia) <sabine.randriamasy=[e-mail]>; IETF ALTO <[e-mail]>
Asunto: Re: [alto] Potential topics for Proposal #3: Support ALTO Extensions for the New Industry Needs

Thanks Sabine for summarizing our conversation and initiating this thread.

Various members of the ALTO WG are taking leadership on each of these topics to continue productive conversations during the next weeks as we approach IETF 117. Between now and then, the plan is to discuss the topics and then convey our recommendations to the Future ALTO Direction document: https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md

I would like to add comments on topics A and D.

Regarding A (new data sources), a key need is to extend the ALTO protocol to incorporate compute information. ALTO has a long history of exposing communication state information to the application starting with P2P networks and then CDNs. But as we move into edge computing applications, the reality is that communication information alone is not enough. The applications are now working at the intersection of compute and communication, and so to optimize service placement, both pieces of information are needed. A key use case is the transition to AI. As hyperscalers are running at capacity, it is expected that a fraction of AI inference workloads (and even a fraction of the training) will need to be offloaded to the edge devices. Some additional drivers for this offloading include (1) leveraging unutilized compute power available at the edge, (2) energy savings to lower CO2 emissions, (3) latency, (4) reliability and performance, and (5) privacy, security and personalization.

>From an architecture standpoint, ALTO being positioned as an API to expose system information to the application is a natural fit. The group has important historical expertise in this domain so it is also well positioned. The group has also been hoping to add this capability on the new charter for a while. For instance, the service edge draft (https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/) which proposes to extend ALTO with compute information to assist the selection of the service edge deployment locations was initiated in late 2019, with the last updates to this document presented in IETF 116. Among the other efforts, the group plans to update this document in the next weeks and present it during IETF 117 to help drive the conversation about compute data source extensions, which fits under topic A. There is also interest in the group to work with open source platforms (in particular, the Linux Foundation) to plugin ALTO RFCs into running code production stacks (with edge computing being also a relevant driving use case) leveraging an open source implementation of ALTO (e.g., OpenALTO).

Regarding D, in particular, the scope of work in comparison with CATS, I think there are two elements here: (1) gaps and (2) common ground.

(1) There is work around covering gaps that are not addressed in the CATS charter. CATS is focusing on in-network exposure of communication and compute conditions to help the network operator optimize the steering of flows. The gap we are interested in covering from ALTO is (1) the ability to expose network and compute conditions to the application and (2) to support other use cases such as optimizing the placement of application services in the edge.

(2) There is also work around coordinating the common ground between CATS and ALTO to enhance alignment. For instance, while the layer of information exposure and the use cases might differ, some of the compute and communication metrics that need to be exposed can be common. It is in the interest of all that we avoid (a) reinventing the wheel and (b) reduce maintenance efforts by working in coordination with CATS to make sure common metrics are not duplicated. For instance, the ALTO Performance Cost Metrics document (https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/) provides extensions to ALTO metrics that can be socialized as common ground metrics for both WGs.

We continue to work via the I-Ds and group conversations to position these topics.

Thanks,
Jordi
________________________________
From: alto <[e-mail]<mailto:[e-mail]>> on behalf of Sabine Randriamasy (Nokia) <sabine.randriamasy=[e-mail]<mailto:sabine.randriamasy=[e-mail]>>
Sent: Tuesday, June 13, 2023 12:48
To: IETF ALTO <[e-mail]<mailto:[e-mail]>>
Subject: [alto] Potential topics for Proposal #3: Support ALTO Extensions for the New Industry Needs


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi ALTOers,



I am sending this e-mail on behalf of the group, who during the last ALTO WG sync up meeting (June 6th 23), further discussed the different options listed by our chairs for the potential future directions of the ALTO WG.

The possible directions are listed here (1) and the discussion thread "[alto] Discussion on the future of ALTO WG" initiated by Med can be found here (2)

---- (1) https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md

---- (2) https://mailarchive.ietf.org/arch/msg/alto/YixgT0_QF6f5l8mlj21lGnaODDg/



The discussion in the last sync up meeting focused on Proposal #3: Support ALTO Extensions for the New Industry Needs.

We agreed to start discussion threads on the topics relating to Proposal #3 and listed below, on which you are invited to provide your expression of interest and insights and plans to engage on these topics once the threads will be started. The feedback of our chairs and area director will also provide a valuable guidance.



- A. Integration of new data sources and their exposure: this could include information such as compute and energy. A list of potential data sources of interest was started in (A1), and integration of compute is  approached in (A2)

---- (A1) : https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0.

---- (A2): https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/



- B. Maintenance of ALTO protocol: in particular adressing operational security matters plus other aspects that could be identified.

- C. Trusted related ALTO properties (trust of ALTO topology elements and trust of ALTO information)

Some initial views and contributions have been exposed during the ALTO interim meeting #5, see (BC3)

---- (BC3) https://datatracker.ietf.org/meeting/interim-2023-alto-05/session/alto



- D. New architectural extensions : such as multi-domain ALTO exposure, ALTO as NEF  input to  CATS components. Problem statement and gap analysis to define future work once A, B and C have been completed.

---- (D5) https://datatracker.ietf.org/doc/draft-yang-alto-multi-domain/

---- (D4) https://datatracker.ietf.org/doc/pdf/draft-contreras-alto-ietf-nef-01



If you feel there is a missing topic you consider highly appropriate for the ALTO WG to investigate, please feel free to voice up.



Best regards,

The ALTO sync-up team

________________________________

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 seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o
________________________________

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telef?nica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relaci?n establecida con el destinatario o con la entidad a la que est? vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]<mailto:[e-mail]>. Puede consultar informaci?n adicional sobre el tratamiento de sus datos en nuestra Pol?tica de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telef?nica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]<mailto:[e-mail]>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o respons?vel pelo tratamento dos seus dados ? a entidade do Grupo Telef?nica vinculada ao remetente, a fim de manter o contato professional e administrar a rela??o estabelecida com o destinat?rio ou com a entidade ? qual esteja vinculado. Voc? pode entrar em contato com o respons?vel do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]<mailto:[e-mail]>. Voc? pode consultar informa??o adicional sobre o tratamento do seus dados na nossa Pol?tica de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.