Agenda for the IETF#113 ALTO WG Session ------------------------------------- https://datatracker.ietf.org/meeting/113/materials/agenda-113-alto Session: Wednesday, March 23,2022 Session I (09:00-11:00 UTC,04:00-06:00 EST, 07:00-09:00 PDT,17:00-19:00 Beijing Time) WG Chairs: Jan Seedorf (ietf@j-f-s.de) Mohamed Boucadair (mohamed.boucadair@orange.com) Qin Wu (bill.wu@huawei.com) Minutes Taker: Richard Yang Daniel King Available During the Session: ICS: https://datatracker.ietf.org/meeting/113/sessions/alto.ics MeetEcho: https://meetings.conf.meetecho.com/ietf113/?group=alto Audio Only: http://mp3.conf.meetecho.com/ietf113/alto/1.m3u Jabber: xmpp:alto@jabber.ietf.org?join Available During and After the Session: CodiMD: https://codimd.ietf.org/notes-ietf-113-alto Slides: https://datatracker.ietf.org/meeting/113/session/alto Drafts (PDF): https://datatracker.ietf.org/meeting/113/agenda/alto-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/113/agenda/alto-drafts.tgz Available After the Session: Recording: http://www.meetecho.com/ietf113/recordings#ALTO Jabber Logs: https://www.ietf.org/jabber/logs/alto Introduction (Chairs) (5 minutes) Session Intro & WG Status - No Agenda Changes Socializing ALTO Luis: We could socialize ALTO activity across other working groups. Richard (via Chat): All are welcome to atend the weekly informal meeting. Med (via Chat):To volunteer to help building a tutorial, just drop an email to the chairs and we will see how to organize ourselves. Richard (via Chat): Some of us (jordi, I) have ALTO tutorials that we presented recently, A more formal tutorial is a great idea and we will be happy to work with chairs. Med (via Chat): making them easily available is also something we are looking for Richard(via Chat):Good idea, hosting at https://github.com/ietf-wg-alto/ Chartered Items ALTO OAM Support (20 minutes) https://tools.ietf.org/html/draft-zhang-alto-oam-yang-02 Discussion Leaders: Jensen Zhang/Dhruv Dhody Discussion Points Q1 Qin: The proposal works for Q1, but we should check with YANG-Doctors Richard: There could be some complexity, so we need to understand the impact. Med (via Chat): The main advantage of relying upon an IANA registry is that new values are supported for free without having to define an augment /etc. Dhruv (via Chat): agreed to that Med: Otherwise, each time a new metric is supported you need to define a new identity for it. We don’t need that as the IANA-maintained module will be generated each time a new value is assigned. Q2 Qin: Do we have a standard algorithm? Also we need to agree a set of basic parameters. Jensen: (missed comment about algorithm). RE: parameters, yes Q3 Martin: You are asking the right questions. Strive to reduce scope where possible. If no strong support for specific features, then they should be omitted. Richard: Good comments from Martin. An interesting issue is how to configure ALTO clients. Qin: I agree with Richard, we need some configuration for ALTO clients. Dhruv: If we develop RESTCONF/YANG mechanisms for ALTO, will existing clients support the function. Med: A data model will allow for consistent configuration/management features nindependently of which “channel” is used to touch that part Jordi: Additional use case includes Proxy or Load Balancers that could benefit from an ALTO client. Chairs: Overall, we see the authors have made good progress and we can proceed with an adoption call on the list. ALTO over New Transport (20 minutes) https://tools.ietf.org/html/draft-schott-alto-new-transport-00 Discussion Leaders: Roland Scott Qin (via Chat): For alto new transport in page 25,is there any out of order delivery issue for streaming management? Richard: We expect a lot of concurrent streams, we were careful to ensure there is not out of order delivery. 1. PUSH packets are sent in order, in a single stream. 2. Built-in mechanism to include seq number to incremental updates. These are two methods to avoid out of order delivery. Qin (via Chat):How reciever set functionality works with other new functionalities introduced? So no new extensions are required. Richard? Yes. We will use http/2 for stream management. Qin: For the alto functionalities describe, are these all mandatory, or will some be optional Richard: Mandatory, but you can turn off the incremental updates. [Missed the comment about application] Med (via Chat): Can we claim that the design follows recos in draft-ietf-httpbis-bcp56bis? Richard: Good question. We have not checked but will. Thanks for the suggestion. Martin: What is the impact of http/3 for alto stream managment. It is fine for initial versions of the proposal to support http/2, but we should analyse use of http/3, its due diligence. Roland: Our main focus was http/2. but I’m happy to investigate http/3. Deployment experience Update ALTO Code bases and Deployment (20 minutes) https://github.com/ietf-wg-alto/wg-materials Discussion Leaders: Jordi Ros Giralt/Kai Gao/Sruthi Yellamraju Martin: Impressive. Good to see multiple drafts incorporated. Prior to this project, did Rucio have alto support? Kai/Jordi: [will need to check audio] Non-Chartered items Supporting Bottleneck Structure Graphs in ALTO: Use Cases and Requirements (20minutes) https://tools.ietf.org/html/draft-giraltyellamraju-alto-bsg-requirements/ Discussion Leader: Jordi Ros Giralt Qin (via Chat): @Jordi, can alto provide sufficient information to build bottleneck structure graph? is there data translation needed? in the scope of your draft or not? Richard (via Chat): There are two interpretations to this question: (1) build bottleneck structure on top of alto and (2) make bottleneck structure a (new) service provided by alto. For (1), we need some modifications; I think the focus here is (2). Jordi? Qin: Lets move this discussion to the list. Misc (10 minutes) ALTO activities related to compute-aware networking (Luis) Qin: Using alto could be good for compute aware networking. Please take this discussion to the list. Wrap-up (5 minutes) Chairs