Meeting notes from ALTO WG meeting, IETF 83, Paris, France
Thursday, March 29, 9:00-11:30

About 100 attendees

This report has been distilled from the detailed meeting notes taken
by Dave McDysan and Sreekanth Madhavan

Chairs: Enrico Marocco and Vijay Gurbani.

Agenda
------

Meeting materials: slides, MP3 (5m:04s, 2.32 MBytes)

Enrico presents the agenda for the meeting.

  No questions nor comments.

Martin Stiemerling will be the new responsible area director. Welcome,
and thanks to Dave Harrington for his help in the past two years.

  Martin: will be responsible for the WG and for all docs, except for
  those I am co-author.


ALTO protocol
-------------

Meeting materials: slides, MP3 (14m:32s, 6.65 MBytes)

Rich Alimi presents the latest version of the protocol document that
should address all outstanding issues. Most changes are to add
extensibility.

  Enrico: would like to hear from extension proposers if extension
  capabilities are sufficient for their cases.

  Sabine Randriamasy: change from Number to JSON Value is
  good. Multicost is not covered, but is OK for the base
  protocol. Will be challenging to extend base protocol without
  changing media types. Rich: could be addressed by adding another
  capability for an array in the extension, or define another MIME
  type. Martin: are these extensions to ALTO or clarifications of data
  type? Sabine: would like more generality in the encoding. Enrico:
  are options Rich mentioned appropriate for multi-cost? Wish to avoid
  complexity. Sabine: I need to write down how to do this. If defining
  arrays is too complex and want to avoid adding MIME types. Enrico:
  conditionally call this issue closed unless Sabine can make a
  concrete compelling case on the mailing list by next week.

  Martin: can an extension be added easily? Rich: other methods
  exist. A JSON Value means that an array can be encoded. Issue with
  server not supporting all cost types in a multi-cost scenario.
  Martin: Propose leaving this out for this version. Discuss other
  means of how to achieve desired function.

  Enrico: issue WG last call at end of next week. Call for review
  volunteers. Vijay: base/benchmark document for alto wg. Emphasizes
  the call for review volunteers.


ALTO server discovery protocol
------------------------------

Meeting materials: slides, MP3 (17m:57s, 8.22 MBytes)

Martin presents the updated version of the server discovery draft.

  Rich: "Cannot redirect" means forbidden or should not? Stefano
  Previdi: some ALTO servers redirect clients to other alto
  servers. For example, in a CDN context. Statement is too extreme.
  Martin: the document needs to be general. Will reword statement.

  Haibin Song: need to make "closest" term clearer.

Open issue for obtaining host name from IP address. Reverse DNS lookup
has too many problems to be used.

  Rich: do current alto implementers use DNS? Is there a solution
  approach without DNS?  Martin: ALTO client sits on end system,
  tracker is not directly on the client and need to find server for a
  specific client. Jari Arrko: reconsider his draft from last meeting?
  Jon Peterson: surprised if ALTO client in CDN request router needs
  to discover ALTO server. P2P is different, but what we are seeing is
  that there is not a lot of market drive for P2P. Infrastucutural use
  cases do need server discovery. Martin: extensions for DHCP and PPP
  appear promising. Stefano: don't need discovery for controlled
  environments. Only needed at bootstrap, not critical, does not
  require standardization. Vijay: agree with prior points. Do DNS Ops
  objections stop this approach. Martin: woud be good to document the
  DNS Ops objections. Rich: revisit earlier approach ALTO client
  discover server and pass this information to the tracker. Jon:
  emergency services analogy for a similar problem. Would need an
  inter-area BoF. Works only sometimes.


Deployment considerations
-------------------------

Meeting materials: slides, MP3 (2m:12s, 1.00 MBytes)

Martin presents the updated version of the deployment considerations
draft. No comments even though much new text. If no interest, then
possibly remove as wg item. Please review and comment on the list!

  Stefano: deployment only beginning and this could be reason there is
  little discussion. Closing this draft now would be premature.


Incremental updates
-------------------

Meeting materials: slides, MP3 (15m:37s, 7.14 MBytes)

Vijay presents the draft dealing with possible mechanisms for
incremental updates on behalf of the authors that couldn't make it to
the meeting. More discussion on the list is needed.

Proposal for new MIME type is not mentioned in the draft. (It
should be added).

  Rich: JSON Patch. Would like to see how large a JSON patch needs to
  be and how much compression this provides.

  Stefano: an option is missing - implementing BGP LS draft to
  advertise an alto topology. May be worth investigating. Could be
  used client-server, server-server. Often clients do not need
  topology information. Vijay: Requested that Stefano post this draft
  and initiate discussion on list. Stefano: ALTO server uses BGP, IGP,
  other data to create network and cost maps. Vijay: using BGP between
  alto servers makes sense. Concern with client-server use of
  BGP. Stefano: base protocol works well for ECS -- does not work well
  for maps. Jon: not giving up on idea that something (easier) than
  BGP could be used as being discussed in cdni as well. Jan Medved:
  tried ALTO and BGP-LS and ended up using BGP-LS. BGP-LS best for
  partial updates. Vijay: encourages list discussion.


Caching and subscription
------------------------

Meeting materials: slides, MP3 (11m:14s, 5.43 MBytes)

Sreekanth presents a new draft dealing with caching of ALTO
information.

  Rich: agree with Martin's suggestion to determine addresses for each
  PID via an additional identifier. Works with existing
  infrastructure. Sreekanth: becomes more complex on server since each
  additional identifier has additional URI.


Cost schedule
-------------

Meeting materials: slides, MP3 (9m:57s, 4.55 MBytes)

Sabine presents a new draft (previously incorporated in the multi-cost
draft) about and ALTO protocol extension for cost schedule.

  Rich: why is timezone needed? Why doesn't UTC work?  Sabine: UTC
  could be used. Agree. Martin: UTC better to use in event of Daylight
  Savings Time. Rich: suggested review with DTN application
  developers, e.g., Dirk Kutscher.


Multi-cost ALTO
---------------

Meeting materials: slides, MP3 (18m:20s, 8.39 MBytes)

Sabine presents the new version of the multi-cost draft, from which
the cost schedule part was extracted.

  Rich: how do constraints work with multi-cost? Sabine: have not
  thought about in great detail. Will need to play with arrays of
  constraints. May constrain how many cost types a client may request.
  Rich: If non-trivial changes to constraints are needed, then this
  possibly should be a separate MIME type since this is quite
  different.

  Lars Eggert: will all of this information be needed by
  operators? Enrico: discussed during i2aex BoF. At least in
  controlled environments of CDN and DC very accurate info could be
  used. In P2P or between operators concerns about trust and privacy.

  Martin: note there is an IPR declaration on this draft. Can you
  clarify? Sabine: there is IPR -- not competent to answer - see alto
  status page. IPR on ALTO status page applies to both multi-cost
  and/or cost-schedule mechanisms.

  Martin (as AD): good that people looking at extensions, but not
  enough people are reviewing and getting the base version completed.
  Enrico: 80/20 problem, much interest earlier and people are bored
  with the base and looking to extensions and the future. Jan Seedorf:
  have a draft proposing use of ALTO in cdni and decision was made to
  advance tat work in that WG. Some of the proposed extensions are
  quite useful. Enrico: Jan sounds like he's candidating himself as a
  WGLC reviewer, to speed up the publication process. Jan: couldn't
  hear the last comment from the chairs, room is noisy.

  Rich: what about scheduling another interop event as a way of
  finalizing the base ALTO protocol spec?


i2aex BoF considerations
------------------------

Meeting materials: slides, MP3 (38m:46s, 17.70 MBytes)

Vijay presented a recap of the i2aex BoF.

  Enrico (as individual): significant interest. ALTO to be more real
  time. Other proposals (BGP, XMPP) and will be handled by ADs, out
  of scope for alto. Write down concrete proposals. altoex mailing
  list.

  Lars: not at i2aex. Originally, ALTO intended to expose
  meta-stable information over longer time scales. Information
  returned would be the same for each client. Starting to look like
  ADA or a kitchen sink of capabilities.

  Jon: positive response at BoF doing this in alto. Communicating
  information of protocols outside of ALTO and using ALTO to deliver
  this information.

  Jan: Trust is a key component as mentioned in the BoF.

  Ying Ge: Chinese DC enterprise has a system to do much of this, she
  is requesting they participate in ia2ex.

  Dave: i2aex DC preso in Bof involves a non-IP name space, PID
  concept of alto may be useful. Often some administrator modifies
  infrastructure (not the application) and there is a need for
  application to be informed of this change (not requiring the app to
  poll). The problem is a distributed database with incremental
  updates with a range of possible keys. Need to rename BGP NLRI, it
  is now a Normative List of Related Info -- not Network Layer
  Reachability Info. Stefano: suggest doing requirements analysis for
  a range of applications instead of starting with a narrow focus of
  p2p. Approach in more systematic way.

  Lars: another WG doing this PAWS. Suggest folks looking at extending
  alto to solve PAWS problems.

  Jan M.: topology and ease of access (HTTP) and data model should be
  separated. Similar to netconf model - base protocol and detailed
  data model in netmod.

  Stefano Picconi: what is overlap with i2aex and a cloud (eg. DC
  resources, P2P, etc) broker application? Want to find most suitable
  cloud meeting these characteristics.  Enrico: Yes, beside the term
  "cloud" not many here like, there seem to be some overlap.

  Rich: incremental updates and notifications are technical changes
  needed to alto. Alternative PID definitions may be needed for DCs,
  and this work could be separated.

  Martin (as AD): discussion expands from network-related information
  but now includes computing-resources as well.

  Dave: mentioned NetStitcher/ Sabine's summary as a good example of
  joint usage of network and copmpute/storage current and predicted
  future state. Agreed with Stefano to approach in systemic way.

  Rich: not all use cases need not be done in alto. Suggested that
  problem statement, use cases, requirements could be done.

  Martin (as AD): good to see interest, and operators standing up at
  the mike. Could see some CDN related things being done in alto. On
  the DC side there may be something in alto, he will need to think
  about it. Encourage folks to contribute to i2aex mailing list.