Meeting notes from ALTO WG meeting, IETF 85, Atlanta, GA (USA).
Wednesday, November 7 2012 1440-1540

About 100 attendees

This report has been distilled from the detailed meeting notes taken
by Young Lee and Haibin Song.  Ted Hardie monitored the Jabber room.
Thanks, guys!

Chairs: Enrico Marocco and Vijay Gurbani.

Agenda
------

Meeting materials: 
  slides, 
  MP3 (5m:43s, 2.7 MBytes), 
  Meetecho recording (HTML5) 

Agenda bashed.  No changes.

Enrico kicked off the session; would like to close the latest and last 
set of issues from the protocol document.  The document has also 
been reviewed by the AD.

Requirements are done!  A new RFC on the way --- RFC6708.  Yay!

Vijay presented the results from the 2nd ALTO Interoperability
test that was held on Monday, November 5 2012.  There were 4
servers, 2 clients and 21 test cases.  These resulted in 8 pairings
and most of the pairings passed the test cases.  Vijay went through
the reasons why some test cases failed --- a major reason was the
absence of map-vtag in responses.  This needs to be clarified in
the protocol document.  Essentially, whenever the server returns a
PID, the map-vtag is mandatory.

Vijay also mentioned the need to have a companion document that
will contain hints for implementors.  Such a companion document
can be crafted by adding a section on implementor hints in the
I-D that currently describes the test cases.

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

Meeting materials: 
  slides, 
  MP3 (13m:03s, 6.5 MBytes), 
  I-D, 
  Meetecho recording (HTML5)

Reinaldo Penno, ALTO Protocol Changes

There were a number of comments from the AD (Martin Stiemerling).

 - Many editorial changes resulted.  
 - In addition, a new section, Section 11 (Manageability Considerations) 
   has been added.
 - Support for SSL/TLS a MUST (Ben Niven-Jenkins later notes that the 
   current draft still has this as a MAY, but it will be changed in 
   a later revision).
 - ...

and others listed on slide 3 of the presentation.

Outstanding issues: will add an ALTO Error Code Registry table and plan
to add services and parameters that are mandatory to implement by an
ALTO server.

There has been a list discussion on how to handle non-conforming servers
and clients.  Where should we handle the behaviour of these?  In the
protocol document or an alternate document?

There was some discussion at the mic that the specific examples shown
on slide 5 can go into the protocol document.

Another outstanding issue uncovered by the AD review was what are the
semantics associated with a degenerated map filtering service.  For
instance, if the client specified an empty filter, does that mean that
it wants the entire cost map?  Or is that an error?  Martin clarified
that both outcomes are entirely possible but the protocol document
should provide guidance on what is the expected outcome.

Yet another issue is whether we need a registry for endpoint properties
(connection type, speed, etc.)?  There isn't any registry in use today.
Martin S. noted that having such a registry is helpful for bounding
the use of free-form fields cause problems later on.  So, it may be
helpful to think of a format and provide some guidance (though not to
the nth degree).  Need some feedback from the WG on the list.

A final outstanding issue is whether we should unify cost-mode and cost-
type. Opinions are solicited on the mailing list.

Martin S. exhorts the WG to post feedback on the above issues on the
list.

Reinaldo asked whether we need to impose some order on the vtag?  Should
we leave it as an opaque identifier or should we impose some order that
allows one vtag to be compared against another to derive a temporal
ordering.

Server discovery
-------------------

Meeting materials: 
  slides, 
  MP3 (15m:17s, 7.3 MBytes), 
  WG server discovery I-D, 
  3rd party server discovery I-D, 
  Meetecho recording (HTML5)

Sebastian Kiesel, ALTO Server Discovery

Sebastian went through the differences between first-party and third-
party discovery.  These documents have gone through a cycle of merge
and split.  Earlier, the first-party discovery and third party 
discovery were two separate drafts.  These were merged into one draft
that became a WG draft (draft-ietf-alto-server-discovery).  However, it
appears that they are splitting back again, with the third-party
discovery going into an individual draft since it appears to be more
difficult to tackle than originally envisioned.  In the end, this 
appears to be a good compromise since it allows us to proceed the WG
document expeditiously.

Sebastian thinks that draft-ietf-alto-server-discovery-05 is in a 
stable state and can benefit from a WGLC.  

Diego Lopez noted that there is a new draft in the apps-general list
called simple web discovery that could be applicable to ALTO to avoid
the need for NAPTR lookup.

Jon Peterson noted that this the simple web discovery is still a draft,
and furthermore there appears to be nothing broken with the current
strategy with draft-ietf-alto-server-discovery.  So why not continue
with what we have and know.

Some more discussion ensued on what can go inside the DHCP option ---
a domain name only or a URL of some sort --- before the U-NAPTR
resolution is done.  It turns out that the domain name is the only
artifcat that can be passed through in DHCP.

The chairs asked further discussion on the topic of whether the simple
web discovery draft helps in ALTO server discovery to the list.

Sebastian continued to his 3rd-party ALTO server discovery draft.

Sebastian notes that this fulfills requirement 33 from the Requirements
RFC.  A flow-chart is presented in slide 15 of Sebsastian's slide
deck, but the textual description has not been updated.  Furthermore,
doing PTR lookups remains controversial in the community.  So, the
fate of this draft remains uncertain.  Requirement 33 came from the
P2P side of ALTO, and to a certain extent, the P2P use case is no longer
as urgent as it once was.

Enrico asked for opinions.  None forthcoming at the mic.

Cost schedule and Multi-Cost ALTO
-------------

Meeting materials: 
  Cost-schedule slides, 
  Multi-Cost slides, 
  MP3 (9m:11s, 4.4 MBytes), 
  Cost schedule I-D, 
  Multi-cost I-D, 
  Meetecho recording (HTML5)

Sabine Randriamasy, Multi-cost ALTO and Cost Schedule

Sabine went through the genesis of the Multi-cost ALTO draft, followed
by differences from previous versions.  

A big change from previous version is related to using both a logical
AND and a logical OR (current ALTO protocol draft uses only a logical
AND).

Haibin asked how does a client rank the results when using the logical "OR" 
to retrieve different cost types?  Some discussion ensued between Haibin
and Sabine that did not reach a conclusion and was decided to be taken on
the list.

There was no more time left to discuss ALTO Cost Schedule.  All discussions
on this should be taken to the list.

ALTO and DECADE integration
-------------

Meeting materials: 
  slides, 
  MP3 (6m:16s, 3.0 MBytes), 
  I-D, 
  Meetecho recording (HTML5)

Haibin Song, ALTO and DECADE integration

Haibin talked about the general idea and the message flow of the
integration example. Application tracker gets the corresponding ALTO
servers for the peers, App tracker also needs to get the DECADE
server address for each peer. Lookup the cost between the source node
and the destination DECADE servers, and return the best peers based
on that.

Martin noted that he would like to see a draft on a more detailed
writeup before we move further on this work.  Otherwise, it may be
hard to understand the problem uniformly.

Ted Hardie channeling Jabber asked if this use case requires third-
party discovery.

Haibin noted that there are two ways to get to the ALTO server, one
of which does indeed require third-party discovery.

No more questions on this draft.  Since time ran out, the meeting was
adjourned.