# Application-layer Traffic Optimization (ALTO) Meeting : IETF 106 2019-11-21 Location: Room VIP A, Raffles City Convention Center, 15:50 - 17:20 Meeting video: https://www.youtube.com/watch?v=En64HisRFoQ Chairs: - Vijay K. Gurbani (vijay.gurbani@gmail.com) - Jan Seedorf (jan.seedorf@hft-stuttgart.de) Acting Chairs: - Sabine Randriamasy (sabine.randriamasy@nokia-bell-labs.com) - Borje Ohlman (borje.ohlman@ericsson.com) Minutes: - Kai Gao (kaigao@scu.edu.cn) - Y. R. Yang (yry@cs.yale.edu) - Edited by Vijay K. Gurbani Q - Questions or comments from the audience A - Response from the speaker ## AGENDA [v 01](https://datatracker.ietf.org/meeting/106/materials/agenda-106-alto-01) > 1550 - 1600 10" Chair slides / Agenda bash Chairs > 1601 - 1616 15" ALTO performance metrics [1] R. Yang > 1617 - 1632 15" Unified properties for ALTO [2] S. Randriamasy > 1633 - 1648 15" ALTO Extension: Path vector [3] K. Gao > 1649 - 1659 10" CDNI footprint and capabilities [4] R. Yang > 1700 - 1709 9" Using ALTO to determine service edge [5] L. Contreras > 1710 - 1720 10" Extending ALTO by using BGP communities [6] L. Contreras > [1] https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/ > [2] https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > [3] https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ > [4] https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ > [5] https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/ > [6] No draft yet ## Meeting Report ### 0. Meeting Administrivia Kai Gao and Richard Yang volunteered as minutes scribe. Kai Gao volunteered as jabber scribe. ### 1. Chair Slides - Drafts discussed * [draft-ietf-alto-xdom-disc-06](https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/) * [draft-ietf-alto-cost-calendar-14](https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/) * [draft-ietf-alto-incr-update-sse-17](https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/) * [draft-ietf-alto-performance-metrics-08](https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/) * [draft-ietf-alto-cdni-request-routing-alto-08](https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/) * [draft-ietf-alto-path-vector-09](https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/) * [draft-ietf-alto-unified-props-new-10](https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/) * [draft-contreras-alto-service-edge](https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/) - Application-Network Integration (ANI) side meeting - Finalize and close WG items ASAP (finish WGLC before IETF 107) - Two volunteers to review the SSE draft, WGLC expired at Dec 8, 2019 ### 2. Performance Metrics Draft: [draft-ietf-alto-performance-metrics-08](https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/) **Meeting prose** - IETF 105 WG feedback and issue - remaining issue: consistency and realiability - Issue: there can be mulitpel sources/types of guidance, even for the same metric - Solution: allow mutliple types of guidance specified by "cost-source" - an optional field of "cost-type" - decoupled from IPPM - Backward compatibility issue - Solution: default option "estimation" - Remaining issue - 3 types instaed of 2 types (sla, estimation, nominal) Q: Which cost source value is default? A: Estimation is the default Q: For nominal type, is the value average or mean? A: SLA is "guarantee", estimation is statistical, nominal is normal value. For example, extracted from a link label. Q: Norminal seems more useful than estimation. It should be taken as the default. Q: What the time scale is for the measurement seems like a problem. Does the draft say anything about it? For estimation, especially A: The optional description field may contain information about how the metrics are collected and what the time scale is. The decision is to give high-level guidance. Q: What are the expected time scale here? A: Months and days. Q: So the values are relatively stable. Should be mentioned in the draft Q: Nominal refers to bw. Is percentile considered as nominal or what? A: To think on that. If we don't know how to define the meaning of nominal meaning for some metrics, put in future documents **Action items** - Discuss with IPPM - Update by mid Dec ### 3. Unified properties for ALTO: updates [draft-ietf-alto-unified-props-new-10](https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/) **Meeting Prose** - Current status - Very complicated - Major change is on simplification and clarification - Opted for a didactic approach - Issues and solutions - Ambuity of entities and properties - Endpoint with multiple entity id will be seen as different entities - Compose entity domain with resource Id to uniquely identify an entity - Mapping mbiguity issue was raised in 2018 - New member in the capaiblity: expose list of applicalb eproperties - Some sections do not provide protocol specifications - Clarify and move to annex Q: Currently it's getting very long because of many examples. Does clean-up mean removing the examples? A: Keep/Add the examples. They help to identify ambuity issue. Simplify the wording. **Action Items** - Fix typos and errors - Clarify - Last check on IANA section - Propose for WGLC ### 4. ALTO Extension: Path vector [draft-ietf-alto-path-vector-09](https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/) Kai provided a quick summary of the I-D. Kai noted that the information provided by this draft is of interest to other organizations: 5G, UPF, MEC, etc. This draft has introduced a new cost type: ane-path. Kai went through the negotiation process and other related information to the working of this new cost type. There are some remaining issues to be worked out before the draft is considered complete: (1) there is a dependency on the unified-properties draft, (2) there is also a dependency on SSE draft, (3) some thoughts needed on whether ANEs should be homogeneous or heterogeneous. The draft needs input from the WG. The authors will like to see a WGLC by IETF 108. Some discussion ensued between Richard Yang and Kai on dependencies (nothing decided, will take to mailing list) and how heterogeneous ANEs may be extended. Sabine noted that the metrics conveyed by performance metrics draft are path metrics, whereas path vector conveys element metrics, so they are distinct. Sabine noted that this draft opens a design pattern for any abstract network element. The chair asked for someone to review the draft; Luis Miguel Contreras Murillo volunteered for the review. ### 5. CDNI footprint and capabilities [draft-ietf-alto-cdni-request-routing](https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/) **Meeting Prose** - Most changes are text edits - Make terms consistent with the same and with other documents Q: Do we need reviewers from the working group? A: This draft is closely related to CDNI WG and is expecting reviews from there. **Action Items** - Waiting for comments from CDNI WG - WGLC request ### 6. Using ALTO to determine service edge [draft-contreras-alto-service-edge](https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/) **Meeting Prose** - Problem statement - Deploy distributed computing environgments in the network - Data centers of different sizes across the network with distinct dimensioning - Role of ALTO - Assist in the selection of the more convenient edge - Expressing computing needs - Structured as bundles of CPU, RAM, storage - Same approach followed by Common Network Function Virtualization - Infrastructure Telecom Taskforce (CNTT) - Flavors - Type of instance (T) - Interface option (I) - Compute flavor (F) - ... - Example of flavors exposed in unified property map - Three potential solutions - service function aware topology model - extend BGP-LS - combine information from NFVI PoP Q: Support computing capability, support storage or compute as well? A: Compute as a general term including computation and storage Q: It involves SDN and NFV. There are some open issues with SDN/NFV. May need to talk with SDN/NFV to address the open issues A: There are flavors (Remark: certain kind of standard) provided (e.g., by CNTT) already. Q: Interdomain or some information aggregation? A: The initial is for intra domain Q: IBM tried to use ALTO but had problem in a multidomain case. Information aggregation can lead to problems Q: In the context of DC, consider back-haul that goes into the DC. Leverage the idea in ZSM **Action Items** - Elaborate on mapping to UP - Alternatives for association of compute capabilities to network topology - Collect interest from ALTO WG ### 7. Extending ALTO using BGP communities No draft **Meeting Prose** - Background: BGP communiteis - BGP attribute used to group destinations - First half is AS number - Second half is ISP-specific - BGP Comm is a way to put together destinations for different purposes - The usage of BGP Comm can simplify the process by - Reducing the number of queries - Smmothly absorbing the natural change in prefixes for a given node Q: Clever proposal. Could be an alternative to PID to aggregate endpoints A: The current is using aggregations of IP prefixes. BGP communities are more flexible Q: We can try to test open and flexible the PV and UP are in this scenario **Action Items** - Alaborate on the proposal - Collect interest from ALTO WG alto-ietf-106-meeting-minutes.md Displaying alto-ietf-106-meeting-minutes.md.