Minutes IETF112: alto
minutes-112-alto-01
| Meeting Minutes | Application-Layer Traffic Optimization (alto) WG | |
|---|---|---|
| Title | Minutes IETF112: alto | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2021-11-14 |
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