Minutes IETF98: alto
minutes-98-alto-00

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.