Minutes IETF112: alto
minutes-112-alto-01

IETF-112 alto agenda

Agenda

          Agenda for the ALTO 112 WG Session
          -------------------------------------
          https://datatracker.ietf.org/meeting/112/materials/agenda-112-alto

          Session:

             Wednesday, November 10,2021
             Session III (16:00-18:00 UTC,11:00-13:00 EST, 14:00-16:00 PDT)

          WG Chairs:

             Jan Seedorf  (ietf@j-f-s.de)
             Qin Wu       (bill.wu@huawei.com)

          Available During Session:

             ICS:          
             https://datatracker.ietf.org/meeting/112/sessions/alto.ics
             MeetEcho:     
             https://meetings.conf.meetecho.com/ietf112/?group=alto Audio Only:
                http://mp3.conf.meetecho.com/ietf112/alto/1.m3u Jabber:       
             xmpp:alto@jabber.ietf.org?join

          Available During and After Session:

             CodiMD:        https://codimd.ietf.org/notes-ietf-112-alto
             Slides:       
             https://datatracker.ietf.org/meeting/112/session/alto Drafts
             (PDF): 
             https://datatracker.ietf.org/meeting/112/agenda/alto-drafts.pdf
             Drafts (TGZ): 
             https://datatracker.ietf.org/meeting/112/agenda/alto-drafts.tgz

          Available After Session:

             Recording:     http://www.meetecho.com/ietf112/recordings#ALTO
             Jabber Logs:   https://www.ietf.org/jabber/logs/alto

      Note takers: Adrian Farrel (adrian@olddog.co.uk)
                   Daniel King (d.king@lancaster.ac.uk)

          Introduction

             Chairs (5 minutes)
             Session Intro & WG Status

Qin: Jan is unwell. Med Boucadair has kindly stepped up to help run the meeting.
Qin: Rechartered since last time. Thanks to the AD.

No agenda changes.

          WG Document Status Update:
             ALTO Extension: Path Vector Open Issue Discussion (8 minutes)  Kai
             Gao
Kai Gao presents
Martin Duke (AD): Are these diffs already in the published version?
Kai Gao: Yes. These are in -19
Martin: Nice (but not necessary)if the reviewers respond to the update.
Kai Gao: I see, ok. Thanks.

             ALTO Performance Cost Metrics Open Issue Discussion (5 minutes) 
             Richard YANG

Richard Yang presents
Martin Duke (AD): We talked about the machine-readable thing during AD review.
Ultimately, for this to be useful, you have to write
                             scripts (to say ignore the results, etc.) so would
                             need a registry. This could be in a separate
                             document.
Richard: Yes, agree. We can discuss further in later version.

          Chartered items:
             ALTO OAM Support        (20 minutes)
             https://tools.ietf.org/html/draft-zhang-alto-oam-yang-00
             Discussion Leader: Jensen Zhang/Dhruv Dhody

Jingxuan (Jensen) Zhang presents
Qin: Good summary. This is important charter work. We need protocol work too.
       Need to make clear what is in scope and out of scope. Need to cook the
       draft further

Richard: One complexity is need to compute service maps. But this will often be
algorithmic not using YANG model. What is your plan for this? Jingxuan: We are
not interested in how to store in this model - (ref to slide #4) Richard: You
collect data. Somehow in someway, they should be specified for good management.
Jingxuan: Not sure if data model should cover this part. The OAM systems should
consider how to extract the data and store it.

Qin: Lets continue this discussion on the list.

Martin Duke (AD): On the ALTO client thing: I think that's a good separation
point. Think hard whether that's an actual use case especially
                             when considering the inter-domain, which is not
                             even specified.

From chat window:
Qin: For alto OAM, Regarding data source, I think not all network data are yang
based data, so you also need to consider how to collect data
       from toher data source such as BGP data source, Netflow data source, one
       example is BGP integration with ALTO, which has already been
      documented in RFC8571, unfortunately we haven't get this implemented? I
      hope we can support translation of BGP data into ALTO data?

Luis: @Qin on BGP integration with ALTO -> in current integration exercise in
Telefonica we are handling BGP and BGP-LS information
        integrated with ALTO
Kai Gao: @Qin My understanding of the data source is that it mainly contains
information about how and where to retrieve the data.
               New data sources can probably extend the data model to define
               specific attributes.
Dhruv: Maybe if there are some well-known “algorithm” that can se set
Richard: TLS1.2 is deprecated.
Martin: It is not deprecated -- yet-- but it would be good to not specify TLS
version Martin:  we should just point at TLS and let the tlswg take its course
Richard: RFC 5246 has Obsoleted by: 8446 Richard:  Agree. Not specify the
version Martin:  there is a separate doc that deprecates 1.0 and 1.1.-- it is
distinct from obsoleting Med:  Indeed, but what is deprecated is TLS 1.0 and
TLS 1.1. Please check RFC8996 Martin: Again, not a practitioner -- but I am
skeptical that clients are the kind of thing that have a NETCONF interface
Dhruv: Thank Martin

         ALTO over HTTP2         (15 minutes)
             https://tools.ietf.org/html/draft-yang-alto-http2-transport-01
             Discussion Leader: Richard YANG/Roland Scott

Richard Yang presents.

Martin Duke (AD): Confused on direction of drat, but OK for first version.
Multi-streaming head-aligned block.. don't need to write a spec on
                            how to do this. Instead, look at where you might
                            modify the mechanisms. Maybe "priorities" needs to
                            be mentioned.
Richard: Yes, we do want to use that.
Martin: Sounds like going in the right direction. Focus on what the new APIs
that H2 and H3 give you. Richard: Sure, definitely.

From chat window:
Qin: ALTO/H1 requirements are different from ALTO/H2?
Qin: For HTTP extension, I am not sure extension is application specific
extension, or generic protocol extension, if it is the former,
        I think it is not a good idea to define these HTTP extension.

        Deployment experience Update:
             G2 and ALTO integration  (20 minutes)
             https://tools.ietf.org/html/rfc7971
             Discussion Leader: Kai Gao

Kai Gao presents.

Richard: I think this could be a good use case for deployment.

From Chat window:
Richard:  Link to the work: https://www.reservoir.com/gradientgraph/
Richard:  Their demo: https://www.reservoir.com/gradientgraph/try-it/
Michael Welzl: Sorry, I don't know enough about ALTO, I suppose - but clearly
this bottleneck information is highly dynamic. Is ALTO
                       suitable for sharing such potentially quickly changing
                       information?
Richard:  This is mostly deployed in large scale setting, with hypergiants such
as ESnet Qin:  I think this information can be shared to the SDN conroller,
which can do network optimization Richard: Data transfers can take hours to
days. Michael Welzl: Aha!  This helps, thanks! Qin: @kai,Good presentation,
with G2 and ALTO integration, we can provide various different rich
applications to the client?
        You mention, G2 will be implemented in CERN or Google? Is this a work
        plan? what is the current status?
Adrian:  Is "out of band BGP" the same as BGP-LS?
Richard: @Qin: I will ask the G2 team to clarify the deployment status. They
are clearing the IP and will meet with us soon. Kai Gao:  @Qin: Yes, I think
the service would be able to support more scenarios than peer selection, which
can be useful for large-scale
              data analytics or multi-tenant networks. Regarding the
              deployment, I do not know the current status and we need to
              coordinate with the G2 team.

         Deployment experience update - FlowDirector deployment
             - ALTO experiences with ISP-CDN collaboration (15minutes)
             https://tools.ietf.org/html/rfc7971
             Discussion Leader: Danny Alex Lachos Perez

Danny Alex Lachos Perez presents.

Qin: I think you have advanced this to released product. Thank you for sharing
the implementation experience. Could you bring any questions
       to the list.

Qin: Remaining topics (that are outside the charter) reduced to 7 minutes each

From Chat Windows:
Med:  Good work, Danny. It would be valuable to document the experience.
Martin: Thanks Danny! This information is very valuable for future charters --
particular any further extension needs you see Danny: Sure, thanks Mohamed &
Martin ... we will continue the interactions regarding our
deployment/implementation experiences Adrian: @danny (while you're here). On
your 3rd (?) slide you had "out-of-band BGP". Does that mean BGP-LS? Qin:
@Danny,  I am appreciated very much for  you open your infrastructure and
platform to IETF community, especially ALTO community,
       for evaluation/test environment.
Danny:  "Adrian:@danny (while you're here). On your 3rd (?) slide you had
"out-of-band BGP". Does that mean BGP-LS?" -> in a BGP out-of-band
            session the hyper-giant can announce the prefixes of its servers,
            together with a cluster identifier encoded in the BGP communities
            via BGP.
Danny: 
https://depositonce.tu-berlin.de/bitstream/11303/10442/4/pujol_etal_2019.pdf

         Non-Chartered items:
             Considering ALTO as IETF Network Exposure Function  (~~10~~ 7
             minutes)
             https://datatracker.ietf.org/doc/html/draft-contreras-alto-ietf-nef-00
             Discussion Leader: Luis M. Contreras

Luis M. Contreras presents.

Richard: I strongly support the idea.
Qin: @Luis,When you say internal application, doesn't this mean ALTO server can
be integrated SDN controller or CDN server? Qin: how IETF NEF is different from
3GPP NEF? how they can work together? 3GPP focus on wireless network and core
network
        while IETF NEF focus on transport network?
Luis: @Qin - by internal I mean under the same administrative domain as ALTO.
FOr sure ALTO could be integrated with SDN-like
         frameworks (e.g., ABNO) or CDNs, but noting there could be multiple
         consumers, it is probably more efficient look at it as playing the
         role of network exposure function for IETF network
Luis: @QIN - regarding how to make work together, my view is that both are
complementary. 3GPP has the view of the "overlay"
       while ALTO has the view of the "underlay". So interworking them is
       potentially very powerful. The way of doing that is
        probably something to work in detail.
Med: @Luis: which interface you had in mind to interact with a 3GPP NEF
component? Luis: In principle we can consider ALTO protocol. It is a matter of
work to understand if ALTO as today (with the extensions in
        RFC-to-be) is sufficient or if it requires further extensions.
Med: Thanks, Luis.

             Compute aware network Use Case  (~~10~~ 7 minutes)
             https://datatracker.ietf.org/doc/html/draft-liu-alto-can-usecase-00
             Discussion Leader: Peng Liu

Peng Liu presents.

Qin: No time for questions. Lets take this topic and any questions to the
mailing list.

From chat window:
Qin: Liu peng's work is related to CFN

             Bandwidth Estimation on OpenNetLab (~~10~~ 7 minutes)
             Discussion Leader: Zhixiong Niu

Zhixiong Niu presents.
Yunfei:  You mentioned that the poor call rate - 40% is due to bandwidth
estimates. How is this number calculated? Zhixiong: The user can make a score
at the end of a call, and we map it to our logs of bandwidth use.

Richard: If we want to integerate as a service, but the frequancy of the data
and how much data, is being sent from the client? Zhixiong: Actually, in the
webrtc or similar, we exchange the b/w data in 200ms Richard:  We talking about
several 100ms

From the Chat window:
Richard:  Zhixiong is from Microsoft :-)
Qin:  @Niu If my understanding is correct, ALTO server will be implemented in
the RTC sender while ALTO client will be implemented with RTC Receiver,
         in such case, bandwidth control functionality will be part of ALTO
         server, ALTO client can query ALTO server and get bandwidth estimation
         result, with this results, ALTO client can adjust rate of flow in the
         transport layer, am I correct?

 Wrapup (2 minutes) Chairs

Qin:  Thanks to Med for helping to manage the timing behind the scenes
Thank you minute takers.
From chat window:
Richard:  Thank you, Qin, Med.
Kai:  Thank for everyone!

CLOSED on time