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