* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Alto Status Pages

Application-Layer Traffic Optimization (Active WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2008-Nov-12 —  

IETF-110 alto minutes

Session 2021-03-12 1530-1630: Room 9 - alto chatroom


minutes-110-alto-00 minutes

          # 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):
          ### 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)
            * 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?

Generated from PyHt script /wg/alto/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -