Minutes IETF110: alto
minutes-110-alto-00

Meeting Minutes Application-Layer Traffic Optimization (alto) WG
Title Minutes IETF110: alto
State Active
Other versions plain text
Last updated 2021-03-17

Meeting Minutes
minutes-110-alto

# 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?