# Agenda for the ALTO 110 WG Session Session 2 (15:30-16:30 UTC, 16:30-17:30 CET, 10:30-11:30 EST) WG Chairs: Jan Seedorf (ietf@j-f-s.de) Qin Wu (bill.wu@huawei.com) Vijay Gurbani (vijay.gurbani@gmail.com) Slides (PDF): https://datatracker.ietf.org/meeting/110/agenda/alto-drafts.pdf ### Introduction * Session Intro & WG Status Chairs (5 minutes) ### Recharter Discussion: * Update of ALTO deployments Collection Chairs (5 min) **Chairs**: If people are interested, there are presentations available on some of these implementations. ***Farni*** No deployment at Sprint * ALTO Draft Recharter Discussion (30 min) Charter proposal overview Chairs (5 min) o https://mailarchive.ietf.org/arch/msg/alto/FxRoRoesddhOhgkYhzQOyHjghPc/ * Proposed Charter item Use Case discussion All proponents (25 min) o Generic Protocol Extension for policy attribute definition Sabine&Gang (5 min) o Protocol Extension for Pub Sub mechanism Chunshan&Gang (5 min) o Operation Automation Data model Dhruv (5 min) o Multi-Domain Setting Richard&Ingmar (5 min) o ALTO deployment for Operation Automation Luis (5 min) ***Question Re:*** Use Case 2 Cellular Network Information Exposure ***Martin:*** Is this a real requirement from 3GPP? What is standardised already in 3GPPP for real-time indicators, and is ALTO required, if so what is the use case? A liaison would be useful, to avoid speculative ALTO work. ***Sabine:*** (?)ALTO would benefit from real-time indicators(?) * Open Discussion on Charter: All (15 minutes) Wrap up: (5 minutes) ***Richard*** Lack of clarity and definition for the term "pub/sub" used in the recharter text. ***Martin*** Several comments, ALTO is Req/Resp protocol and the concept of "pub/sub" is more push-based protocol paradigm. Second... Third, not seeing a lot of individual contributions that match the charter proposal and use cases. Finally, finding it a little hazy to understand the actual deployments. ALTO has been around for a while... ***Martin*** If we're proposing pub/sub, is that really ALTO anymore? Or is this a whole different protocol? ***Gang*** pub/sub is a another way to obtain network information. Compare to request/response, pub/sub is more efficent, because in many scenarios, only one subscripton is needed,and the notifcations would be triggered when some condition is satisfied. Since pub/sub is triggered by events, it is helpful to reduce signaling overhead compared to continous reporting. I believe if this ALTO extension is accepted, it would make ALTO more useful and applicable to more scenarios. ***Vijay*** (Missed response(?) ***Qin*** Various discussions on list, do we need to extend pub/sub, do we need new transport mechanisms. ***Richard*** There are a number of drafts already, some of these problems are documented. ***Ahmed*** Is this group looking at standardisation of application signallng to the network its qos requirements? ***Chunshan*** No, we expect to extend the policy to inlcude the QoS requiremnent and alternative QoS requirements. ***Sebastian*** The original design idea was that alto would convey information from the network (topology, ...) to some sort of application overlay, so that better decisions could be made there. ***Kai*** Also in the ALTO framework, the direction of information flow is from the network to the application. The application can then make decisions based on that information. I believe Use case 1 is mostly showing that some QoS-related metrics collected from the network can help application make better decisions. ***Chunshan*** Yes, the ALTO Client only requests the network to notify which QoS can be supported instead of continuous reporting the QoS status. ***Phil*** I haven't followed list discussions. I don't think the charter proposal motivates well the re-chartering - can it be clearer about the problem that will be solved? I also found the presentations were suggesting lots of ideas, I wonder if it would be better to focus on the key one or two?