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 <[email protected]> on behalf of Sabine Randriamasy (Nokia) <[email protected]> Sent: Tuesday, June 13, 2023 12:48 To: IETF ALTO <[email protected]> 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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
