IETF 98, ALTO WG Meeting, Fri Mar 31, 2017 0900-1130, US-CDT Audience: 15 people in the room, 11 on Meetecho Meeting note taker: Qiao Xiang, Jensen Zhang and Chan Dawn. Meeting notes edited by: Vijay K. Gurbani Jabber Scribe: Jan Seedorf ====Chair Slides, Jan Seedorf and Vijay K. Gurbani==== Chair presented slides and bashed agenda. Steady progress on all milestones, but behind schedule. Added a new deliverable (ALTO service for CDNI FCI objects). This is leftover work from CDNI WG that was agreed to. Will be finished in ALTO unless the WG has any objections. WG page has been updated with new milestone dates (see https://datatracker.ietf.org/wg/alto/about/) Chairs have been in touch with Sebastian Kiesel regarding submitting draft-kiesel-alto-xdom-disc as a WG document that goes towards the deliverable of an alternate server discovery document. Sebastian has submitted a WG -00 version. Summary of hums taken during the meeting: 1) Hum taken to adopt draft-yang-alto-path-vector as the deliverable towards the network graph format deliverable. 2) Hum was taken to adopt draft-roome-alto-unified-props-new as the deliverable towards the endpoint property extension document. 3) Hum was taken to adopt draft-seedorf-cdni-request-routing-alto as the deliverable towards a new milestone: ALTO service for CDNI FCI objects. (This deliverable has to be added to ALTO milestones.) ====ALTO Performance Cost Metrics, Qin Wu==== draft: datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-performance-measurement-cost-metrics-00.pdf The draft has fixed the confusion with IPPM registry. The draft does not intend to create a new registry for new performance metrics. It only uses the ALTO cost metric registry defined in RFC7285. The ALTO cost metric registry is not for new performance metric but for new ALTO cost metric type. The next step of this draft includes considering metric aggregation and abstraction and metrics for cellular networks. Richard asks about if abstract network element proposed in the path-vector draft should be added as a new cost-metric in this draft. Sabine comments that ane is not a performance metric. Vijay comments that Qin should draft the work for the WG to discuss if we need new ALTO identifiers for cellular networks; if we do, the WG should move quickly to document such identifiers. ====ALTO Contextual Cost Values, Sabine Randriamasy==== draft: datatracker.ietf.org/doc/draft-randriamasy-alto-cost-context slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-cost-context-01.pdf This draft proposes to extend cost information specified in RFC7285 by providing several possible cost values for the same cost metric where each value depends on qualitative criteria as opposed to quantitative criteria such as time. Some use cases in cellular networks and wireless networks are given, where providing different values for the same cost metric can help in optimizing the application path selection. The design in this draft is to introduce "cost-context" member in IRD capabilities, which specifies cost type names and a list of possible context parameter combinations. By logically combining several sets of context parameters, the set of conveyed parameters combinations and metrics can be more specified in a fine-grained way. Richard asks why context is announced in IRD and comments that it is not flexible. Sabine responses that this is to avoid too many context parameters, but agrees more discussion on this issue is needed. Lyle: 1) Given the CUDU splits (?) in 5G, the way we are representing cells as PIDs is correct; but we should make sure. 2) In use case in unattended data we need to be sure that the network does not bar the ALTO application as unattended data. 3) Care must be taken such that on privacy concerns of cost context may worth a deeper look. Jan comments that context should not be changed too often. Lyle and Vijay comment that how often context changes in wireless networks is significantly different from wired networks and requires more discussion through the mailing list. For example, 200ms in cellular networks implies many scheduling decisions have been made across the continental networks. ====ALTO Cost Calendar, Sabine Randriamasy draft: datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-cost-calendar-02.pdf Updates since IETF96 are summarized, including wording, clean-up, refactoring and backward compatibility. When ALTO client and server both support multi-cost, a "cost-type" field with the value set to '{}‘ in server responses for Filtered/Cost Map and ECS is added. Updates in the next version are proposed, including aligning the example of cost metrics with [draft-ietfalto-performance-metrics] and update/cleanup of cost calendar attributes. No comment is raised at the meeting but discussion will continue in the mailing list. ====Multi-Cost ALTO, Sabine Randriamasy draft: datatracker.ietf.org/doc/draft-ietf-alto-multi-cost slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-multi-cost-00.pdf Changes in each version after IETF96 are summarized, most of which are wording and clarification. Secdir review asks about the additional dDOS risk and the authors respond that it will not cause any additional risk compared to RFC7285. Version 08 with secdir recommended language/grammar update will be posted soon. ====ALTO Extension: Path Vector Cost Mode, Dawn Chen and Richard Yang draft: datatracker.ietf.org/doc/draft-yang-alto-path-vector slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-extension-path-vector-01.pdf Three design issues left from IETF96 are reviewed, namely how to encode path-vector in cost map, what the query format should look like and how to provide path-vector based network element property (nep). For issue 1, a new cost type "path-vector" and a new cost metric "ane" is defined. The cost value of path-vector is encoded into an array. For issue 2, a new object called PDIFlowFilter is introduced in the request format to support more flexible flow queries. For issue 3, a stateful query & response mode is proposed, where a query ID is provided to associate the path-vector cost map and the network element property map. Vijay asks the question how the ALTO server maintains query ID since it is temporal. Dawn and Richard response that it depends on implementation. One option proposed in the slides is to use time-to-live (TTL). Further discussion includes that an error code should be introduced to indicate the expiration of a query ID, A hum was taken to decide if the WG should adopt this as a WG item. Results of the hum indicated that those in the room has the consensus to adopt it. ====Traffic Optimization for ExaScale Science Applications, Qiao Xiang draft: datatracker.ietf.org/doc/draft-xiang-alto-exascale-network-optimization slides: www.ietf.org/proceedings/98/slides/slides-98-alto-traffic-optimization-for-exascale-science-applications-02.pdf A pre-production prototype of the exascale dataset transfer component of ExaO has been implemented and demonstrated since IETF96. In version 01, new components such as resource abstraction agents and multi-resource orchestrator are introduced to support exascale data analytic applications in multi-domain data center networks. The resource abstraction agents are deployed at each data center, which uses ALTO EPS and ALTO path-vector based property service to retrieve application-specific resource information. Such information is then encoded into a single ane (short for abstract network element) and sent back to the multi-resource orchestrator, which makes efficient, optimal job scheduling decisions. The author proposes to investigate the feasibility and benefits of designing ALTO abstraction services and the potential privacy leakage brought by such abstractions. Vijay comments that the new design of ExaO has significant differences from version 00. Lyle comments that abstraction has been visited a few times in the past few IETF meetings and has drawn the interests of multiple WG members, hence propose to further look into the possibility of including abstraction as one of WG next milestones. Vijay, Richard, Sabine, Qiao and etc. agree and will continue the discussion through the mailing list. Sabine asks about the possible use case of ALTO cost calendar in ExaO. Qiao gives a quick example of encoding varying electricity costs in the calendar to minimize the electricity cost of data analytics. Concrete examples will be discussed through the mailing list. ====ALTO Extension: Flow-based Cost Query, Jensen Zhang draft: datatracker.ietf.org/doc/draft-gao-alto-fcs slides: www.ietf.org/proceedings/98/slides/slides-98-alto-flow-based-cost-query-01.pdf The draft integrates the designs of the ECS-flow draft and the version 00 FCS draft as the basic flow-based query and the advanced flow-based query. Design issues such as flow encoding, query format and multipath are proposed. Options for each issue is discussed and will be addressed before next IETF meeting. During the presentation, Jensen proposes the option of integrated the design of FCS into path vector. Richard comments that it would complicate the design of path vector, hence probably not a modular design. ====Extensible Property Maps for the ALTO Protocol, Richard Yang draft: datatracker.ietf.org/doc/draft-roome-alto-unified-props-new slides: www.ietf.org/proceedings/98/slides/slides-98-alto-extensible-property-maps-for-the-alto-protocol-00.pdf This draft aims to generalize the endpoint properties to provide properties of entities, including but not limited to endpoints, network elements and abstract network elements. Several key design points are discussed. Entities are categorized into global entities (e.g., ipv4), per-resource entities (e.g., pid) and dynamic entities (e.g., ne). The design allows aggregation for better scalability. Property names are in a global namespace to enforce global, consistent usage. Issues to resolve in each section of the draft are listed and will be addressed in the next IETF meeting. A hum was taken to decide if the WG should adopt this as a WG item. Results of the hum indicated that those in the room has the consensus to adopt it. ====CDNI Footprint and Capabilities Advertisement, Jan Seedorf draft: datatracker.ietf.org/doc/draft-seedorf-cdni-request-routing-alto slides: www.ietf.org/proceedings/98/slides/slides-98-alto-alto-service-for-cdni-fci-objects-00.pdf The CDNI working group proposes to design a new ALTO service to transport the CDNI FCI objects. The draft has been around for a while. A strawman text for server response encoding was proposed. What needs to be changed from RFC7285 will be updated in the next version of the draft. Lyle notes there was a relate implementation at Sprint before (name of the project is not caught.) No objection to adopting the draft was raised during IETF96 and mailing list discussion afterwards. A hum was taken to decide if the WG should adopt this as a WG item. Results of the hum indicated that those in the room has the consensus to adopt it.