Meeting notes from ALTO WG meeting, IETF 87, Berlin, Germany.
Monday, July 29 2013

About 73 attendees in room + 7 in Jabber session.

This report has been distilled from the detailed meeting notes taken
by Michael Scharf and Jan Seedorf.

Chairs: Vijay Gurbani and Enrico Marocco.

Agenda
------

Meeting materials: 
  slides, 
  MP3, 
  Meetecho recording (HTML5) 

Vijay presented the agenda, agenda bashed.  

He noted that the ALTO protocol should be moved forward expeditiously but 
without compromising the quality of the protocol.  Last few weeks have
witnessed list discussions on the protocol that have been beneficial. 
Richard Yang will present more details on the protocol changes.

ALTO discovery is in post-WGLC.  Sebastian to update the WG.

Reminder about the ad-hoc meeting to be held on Wednesday.  (Notes on the
ad-hoc session can be accessed here.

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

Meeting materials: 
  slides, 
  MP3, 
  Meetecho recording (HTML5)

Richard Yang presented.  He noted that there is agreement on a number of
issues and he has a proposal timeline on getting the work to the IESG.

Richard went through the changes from -16 to -17. The chairs had posted a
summary to the WG on the ALTO protocol document.  Minor changes have been
addressed.  Some major items include revising the introduction and security
consideration section based on WG comments; the introduction of Resource ID 
as a component in the IRD to better handle multiple resources.  Each resource 
(cost map, network map) will have a unique Resource ID.  Richard and 
the editor team believe that this change has made the protocol extensible 
in a sensible manner.

Richard went through the proposed changes serially (see slides 4-8).  The
changes that elicited some discussion at the mic follow.  All other 
changes were accepted and will be folded into -18 after the Berlin IETF.
Most of the changes are clustered around the IRD.

On the change regarding the default map (slide 7), Sabine R. asked whether 
it was possible to represent dependencies between two network maps.  Richard
indicated that the idea is not to represent dependencies, instead it is to
provide multiple representations (coarse, medium, fine) of the same map.

On the change regarding ECS must not specify that it uses a particular
map (slide 8) elicited some discussion.  Reinaldo asked whether this
means that ALTO can be used as some sort of distance computing protocol
that does not use maps anymore, something akin to a raw routing protocol? 
Richard indicated yes, that would be the interpretation.  Reinaldo asked
that if we do not use a network and cost map to query, then is the
resulting protocol still ALTO?  Richard indicated that you still use endpoint
properties, etc. and that we are not trying to limit the protocol.

Sebastian noted that we should state that ECS may not instead of must not
specify that it uses a particular map.  Richard agreed.

Lingli asked whether it was possible to indicate that the network/cost map 
is/are omitted.  Richard indicated the protocol provides flexibility to the
server on whether it wants to provide the maps or only provide services that
will do the computing for the client and return a cost.

Reinaldo asked that the client can download a network and cost map, compute
the costs locally and verify by querying the ALTO ECS for the same information.
Richard indicated that yes, if this is possible.

The last issue (slide 9) resulted in much discussion.  Essentially, with
the inclusion of multiple network maps in the same IRD queries that resulted
in authoritative answers before (when there was only one network and cost
map) are no longer authoritative.  The resolution of the query now depends on
the specific network/cost map.  So, how do we represent this dependency?
Slide 9 contains two options.  Sabine R. asked if an IRD contained, say,
five maps, and a client wants to know its PID, could it be the
case that five different PIDs were returned?  Richard indicated that this
could be a third option that has not been considered so far.   Vijay (at
mic) indicated that this issue could be esoteric enough that not many
people have thought about this.  If the risk of going with the simple
Option 1 is an increased IRD size, we should just go with Option 1.  
Richard A. also indicated support for Option 1.  The general consensus
seemed to be that we will go with Option 1 unless there is any opposition 
on the mailing list.

Richard presented a proposed timeline that sends the document to IESG in
September.  Enrico exhorted the WG to raise any pertinent issues now.  Jan
S. noted that as the protocol moves along, there will be some minor issues
that pop up.  However, we should not wait until all issues have been 
uncovered.  It is a good thing that people are implementing the protocol
and raising issues, but we cannot hold the document hostage to every issue.
There are ways of dealing with updating the document once it becomes an
RFC.  At this time, the protocol has been looked at enough that we should
finalize the base protocol and start looking at extensions that are pending.

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

Meeting materials: 
  slides, 
  MP3,
  Meetecho recording (HTML5)

Sebastian Kiesel provided an overview of ALTO server discovery documents,
including two drafts --- one is a chartered item (draft-ietf-alto-server-
discovery) and the other remains an independent submission (draft-kist-alto-
3pdisc).

The chartered item saw a WGLC on version -08, including Gen-ART and SecDir
reviews.  The issues uncovered have been fixed an -09 has been submitted.  
The changes have been socialized with the affected reviewers and the
changes have blessed in -09.

Sebastian believes that the draft is ready to be moved forward.  Current
token is now with Document Shepherd (Vijay).

Sebastian then talked about 3rd party server discovery.  Sebastian believes
that this is a missing piece in the WG since the requirements calls for
3rd party server discovery but no draft has been allocated towards that
requirement.  Sebastian noted that the draft has been shared with the
DNS directorate and while they did not issue a ringing endorsement of it,
they also did not issue any dire pronouncements that the Internet will
melt if the draft was put into action.  There is still work to be done and
Sebastian asked the chairs for next steps.

Enrico noted that the document was presented in Orlando although the work
started much before.  During the Orlando meeting, the WG had agreed that
the work has merit and should be adopted as a WG item.  We decided to
postpone the call for adoption on the mailing list and issue it after the
ALTO protocol document was sent to the IESG, but that has not happened yet.
That said, we will once again check with our new AD whether we should issue 
a call for adoption for this work as well as the Anycast work that was 
presented in Orlando for adoption before the protocol document is seen through 
IESG.

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

Meeting materials: 
  slides, 
  MP3 (recording is incomplete, last 20s are missing), 
  Meetecho recording (HTML5)

Michael Scharf presented the deployment document and noted that he is now
an author of the draft based on his extensive review of previous versions.

Michael highlighted the recent updates.  Generally overt reliance on p2p-
type of terminology has been excised as this is not the only use case
in ALTO now.  New text (S2.2) on design space for ALTO deployments, new
text on limitations of map-based approaches (S7.1), etc.  Michael noted that
the text has not been updated for a while so many editorial changes are
needed.

Michael would like to solicit some thoughts on whether he should expand
the use cases in the draft?  Currently the draft contains p2p and CDN
as the two use cases.  He sees referencing the current crop of extensions
in the deployment draft as it matures.  Also possible could be lessons
learned from existing implementations.  Finally, Michael noted that the
ALTO protocol document refers to specific section numbers in the deployment
draft and these numbers may change as the deployment draft evolves.

Some discussion ensued between Michael and Richard Y. on how to synchronize
the protocol document and the deployment draft.  Michael indicated that
one way to sync-up would be to have the protocol draft refer to section
headlines instead of section numbers and the deployment draft will keep
the same section headlines as new sections are added.  This seems agreeable
to all concerned.

Meeting adjourned.

Wednesday night side meeting
--------------------------------------------------

Wednesday, July 31 2013 side meeting.
Attendees: About 17 people present in the room and 1 on Skype.

Minutes were taken by Victor Lopez and Skype monitored by Michael Scharf.

An additional meeting was held on Wednesday, July 31, 2013 2000 - 2200 to
come up with 4-5 extensions that the participants feel are important
enough to tackle as soon as the protocol draft is submitted for
publication.  

The format of the meeting was that new -00 extension documents were given 
5-7 minutes of introduction time.  The older extension documents that 
were discussed in the Orlando IETF side meeting were not provided any 
presentation time at this side meeting, however, discussion about these 
was encouraged to see if the group could arrive at some manner of 
taxonomy on the important extensions to pursue.  The group did arrive
at a taxonomy that is presented below.

The -00 drafts that were given presentation time were:

 - Considerations for ALTO with network-deployed P2P caches
  Lingli presented the motivation behind this work as using bidirectional
  p2p caches to reduce the traffic on the WLAN network.  Discussion
  ensued on understanding the motivation behind this extension.  Richard
  Y. mentions that he is playing in this space but outside of ALTO.

 - JSON format extensions for traffic engineering (TE) in ALTO IRD
  Qin Wu presented an extension on defining new cost metrics beyond hopcount
  and routingcost and the ability to represent link-related information in
  the ALTO IRD.

  Some discussions ensued on whether the charter should be modified every
  time a new cost extension is proposed.  The thinking in the room was that
  the charter should not require any modification, however, if the new
  cost extension was to be used in a constraint filter, then the schema
  may have to be modified.  The group will look one step deeper into how
  to support cost extensions transparently.

 - ALTO topology considerations
  Richard Y. presentation provided some context on how to represent different
  topologies in ALTO.  The current topology can be thought of as a "single-
  switch" representation, however, other applications (VPN) may require a
  deeper knowledge of the network topology representation (see also the 
  draft by Michael Scharf on VPN use case in ALTO).

  Bhumip K. asked whether this would be in the domain of i2rs.  The general
  feeling by participants (Richard Y., Diego L. and Victor L.) was that 
  the topology abstraction being discussed here was distinct from i2rs.

 - Extension use cases and requirements for ALTO
   Haibin Song presented some use cases as ALTO extensions.  Discussions
   ensued on whether there was some commonality among the use cases that could
   be taken advantage of to define an ALTO framework of some sort.

At the end of the presentation period, the participants deliberated on how
to taxonomize the extensions.  By and large, the following taxonomy emerged
on how to categorize the various extensions:

 1. The Pub/Sub model, including incremental updates.
 Having some form of asynchronous notification was felt to be a "must do" 
 extension.  The use cases for the pub/sub model included, at the very 
 least, having the server send incremental updates about network topology
 to interested clients.  Some discussion ensued on whether websockets is
 the right tool for a pub/sub model.  But everyone agreed to the importance
 of this extension.

 2. Topology reasoning.
 Representing different topologies for uses cases like VPN and CDN as well
 as using TE metrics was considered an important extension.  This extension
 was also considered important, more so since different network maps can
 now be represented in the base ALTO protocol's IRD.

 3. Filtering mechanisms.
 Extensions related to mulicost and other cost-related drafts would go under
 this category.  Some brief discussion on using regexp for constraint
 specification, but largely, the attendees agreed that support for filtering
 mechanism would be good to handle as an extension.

 4. Endpoint property extensions.
 The attendees expressed support for additional endpoint properties besides
 PID.  Richard Y. indicated interest in having a mutable EP property 
 service (e.g., a p2p peer tells the tracker it is not interested in
 serving content for a while).  The folks in the meeting felt that this
 may be out of scope for now at least, but interest was expressed for
 having a richer EP propery representation.

Meeting adjourned shortly after 2200.