Meeting notes from ALTO WG meeting, IETF-81, Quebec City, Canada Tuesday, 
July 26 2011, 1300-1500

100-110 attendees

This report has been distilled from the detailed meeting notes taken
by Greg Bernstein and Robert Varga.

Chairs: Vijay K. Gurbani, Enrico Marocco and Jon Peterson.

Agenda

Meeting materials: slides

External resources: audio for session (6 min, 4 sec @ 2.77 MBytes)
                    HTML5 video+slides+jabber

Agenda presented and bashed.  Four chartered items will be discussed
first, and following that the remaining time will be divided equally
among the other work that folks want to bring to the attention of
the working group.

1st ALTO interoperability event held on Monday, July 25, 2011.
Seven implementations; two client-only and five client/server.
Interoperability was based on versions -08 and -09 of the protocol.
An interoperation document with 20 test cases was socialized on
the mailing list, and used to drive the interoperation event.

Action items resulting from the interoperability event:

  1) Pay attention to MIME types in requests and responses.
  2) The protocol document should bound the length of the vtag
     in some manner.  At the interoperability event, vtag lengths
     varied from 1 byte to tens of bytes (cryptographic hashes).
  3) Some sort of special return value should be put in the
     protocol document for cases where the ALTO server cannot 
     determine an answer, or for cases where it is guessing at an
     answer.

Complete notes on the interoperability events are archived here.





Requirements

Meeting materials: slides, draft

External resources: audio for session (7 min, 25 sec @ 3.39 MBytes)
                    HTML5 video+slides+jabber

Martin Stiemerling presented the requirements draft status.

After Prague IETF, it was decided to delay publication of the document
to ensure that existing requirements will not harm the CDN use case
work.  It appears that the document can now proceed.

Changes from -08 to -11 discussed.

New requirement (ARv10-48) added to give the ALTO client an opportunity
to present content identifiers to the ALTO server if it so desires.
Originally, this property could lead to application profiling under the
P2P file sharing use cases, but with CDN use cases now becoming important,
it helos to identify content.  The new requirement does not standardize
application profiles, but leaves it to the client to present a content
identifier if it so desires.  An ALTO server is to be prepared to deal
with requests that do not contain such identifiers.

ARv11-31 (Overload and error handling) is deemed rather verbose.  Editors 
of the requirements document believe that it suffices in its capacity of 
a technical requirement, but there has been discussions on shortening this 
from the community.  Martin polled the room to see if any objections on
leaving the text as is; there were no objections.  Ben Niven-Jenkins
indicated that he may be prepared to provide a short overload section,
but if the working group is satisified with the current one, then he
can live with that.

  
    Next steps for this draft: Send to IESG.
  




ALTO Protocol

Meeting materials: slides, draft

External resources: audio for session (25 min, 41 sec @ 11.70 MBytes)
                    HTML5 video+slides+jabber

Richard Alimi presented the changes to the protocol to make it RESTful,
including changes from -08 to -09.

A set of changes that are proposed to go in were discussed (slide 10).
It was pointed out that incremental updates do not appear on this slide.
The general feeling regarding incremental updates appears to be that
it will be good to have them, but not enough discussion has taken place
on the list to render a concrete resolution on whether this should be
an extension or part of the base protocol document.  There is no current
draft on incremental updates as of now.

Discussion ensued on server returning IP addresses in a different
format than the one presented in the request by the client.  Some working
group participants feel that forcing the client to deal with the
complexity of re-interpreting the IP address is not a conducive way to
spur adoption of the protocol.  The document authors feel that allowing
the server to canonicalize the IP address enables it to scale to a large
number of requests rather than preserving the format it got in the
request.  To take to the mailing list for further discussions.

Enrico posed a question on the mailing list about which services should 
remain optional and which ones should be mandatory?  This is important
because some resource constrained devices may not be able to do filtering
services or cost services locally and would prefer that the server itself
implement these optional services.  Discussion ensued.  Richard Yang noted
that an ALTO server could offer all services, even those that are marked
optional today, but simply indicate an invalid value for services that
it is not willing to provide.  Alternatively, a system of proxies, coupled
to the ALTO server, could be deployed that fill in the missing services.
Vijay Gurbani noted that the bar to provide these services is low, and
anyone offering an ALTO server will provide these services anyway (as a
case in point, during the bakeoff a majority of the servers provided all
of these services, not only the mandatory ones).  Robert Varga went to
the other end of the spectrum and wants to make all services optional.
The Information Resource directory is there to discover which ones are
available, anyway.  David Harrington, in his role as an AD, posits that
making most things optional is not conducive to standardization.  His
recommendation would be to consider making much of this required for
better interoperability.  Further discussions to be moved to the list.




ALTO server discovery protocol

Meeting materials: slides, draft

External resources: audio for session (6 min, 53 sec @ 3.15 MBytes)
                    HTML5 video+slides+jabber

Martin Stiemerling presented the server discovery protocol.  This draft
was adopted as a working group document after the Prague IETF.  Authors
have asked for an expert review of the draft since it touches DNS
issues.  Some minor changes need to be done on the draft, mostly
editorial in nature.

Vijay Gurbani wants the draft to clarify how is the Information Resource
directory URI presented to the client during discovery.  The text around
this may well be in the current draft, but it is not immediately obvious
from the discussion in the draft on whether the URI returned by the
U-NAPTR resolution is that of an Information Resource directory or 
something else.




Deployment considerations

Meeting materials: slides, draft

External resources: audio for session (3 min, 14 sec @ 1.47 MBytes)
                    HTML5 video+slides+jabber

Martin Stiemerling presented changes: two new sections --- (a) deployment
considerations for ISPs and (b) monitoring ALTO.  Authors expect some comments
on the mailing list on these newly added sections, including feedback from
implementers and ALTO operators.

Stefano Previdi asked if the interest was limited to P2P context or also
for CDN use cases (answer is both, or even other use cases).  Enrico Marocco
noted that the high-bandwidth cases could be applicable to this work.




ALTO for CDN use case

Meeting materials: slides, draft

External resources: audio for session (16 min, 48 sec @ 7.69 MBytes)
                    HTML5 video+slides+jabber

Ben Niven-Jenkins presented the draft, starting off with differences between
P2P use case and the CDN use cases.  The authors see ALTO as providing value
to the CDN, it decouples the CDN application from the network.  This draft
contains use cases extracted from draft-penno-alto-cdn, although this
draft remains at a higher level than draft-penno-alto-cdn.

Discussion ensued on various items.  Richard Alimi was concerned that
exposing raw topology may change the existing ALTO model since it is
designed to keep network somewhat opaque and only present it in terms of 
PIDs.  Ben concurred and noted that he is still investigating this in the
background to see what would be a good medium where raw topology can be
exposed while keeping privacy needs intact.  Stefano Previdi noted that
confidentiality issue is less critical in CDN use case since the CDNs
will be owned by the same entity running the ALTO server.  

Enrico Marocco noted (as an individual) that this document is useful and
can provide deployment guidance to CDN operators on how to use ALTO.  Ben 
noted that his intention was not to give deployment guidance, but as a
CDN practitioner he sees value in how ALTO can be used to provide information
in a straightforward manner to optimize CDN operations.

Stefano Previdi contrasted this work to the original draft-penno-alto-cdn
document and noted the draft-penno-alto-cdn was primarily driven by 
deriving requirements for the CDN use case.  That said, he also thinks
that draft-jenkins-alto-cdn-use-cases work could be applicable to the 
deployment draft as well.  Ben agreed that his draft describes use cases
and there is a need for a CDN use case requirement document, but there isn't
any on the table yet.  Regarding draft-jenkins-alto-cdn-use-cases being
applicable to the deployment draft, Ben thought it too early to put the 
work in deployment draft since there does not appear to any deployment
experience of using ALTO in CDNs.  Stefano indicated that there are real
deployments of ALTO and CDNs.  Ben noted that it would be good to document 
these deployments.




Use cases for high-bandwidth query and control of core networks

Meeting materials: slides, draft

External resources: audio for session (21 min, 4 sec @ 9.64 MBytes)
                    HTML5 video+slides+jabber

Greg Bernstein presented the work; authors are motivating the need for
the application layer to fully and efficiently utilize the capacities
of 40-50 Gbps networks.  

Discussion ensued on various items.  Martin Stiemerling pointed out that 
this work may be in conflict with the current ALTO charter with respect 
to knowing the instantaneous bandwidth available.  Richard Alimi further 
qualified that the reason instantaneous bandwidth was ruled out of scope 
was that the beginning use cases for ALTO dealt with home subscribers.  
Devices operated by these would typically not know the bandwidth and could 
not make any assumptions even if they knew it.  Greg agreed that the use 
case here is not home susbcribers but links between large data centers, 
where the bandwidth does not fluctuate and it can be managed.  Stefano 
Previdi foresaw that the ALTO protocol in its current format will not 
work since it originally concerned the network layer and the application 
layer, whereas this work, in a sense, provides information of even deeper 
layers --- optical layer --- to the application.  Here, we are essentially 
using demand engineering to increase the capacity as needed.  But in doing 
so what is the effect on all the layers between the application layer 
(running a CDN application) and the optical layer?  Volker Hilt asked how
does a rather abstract topology map based on PIDs get translated to a 
physical path between routers/nodes connecting the PIDs so that the links
connecting the PIDs can benefit from a larger bandwidth?  Young Lee
confirmed that this is more of a research work item than a concrete
engineering proposal right now.  Richard Yang wanted to get a sense of
dynamics --- consider a link between NY and Chicago of 60 Gbps (example).
How frequently will that information change, especially in case of
a disaster?  Greg mentioned that such situations arise when they do
restoration, but here they do not flood OSPF information too rapidly
(updating every 15-30s is fine).  Young Lee mentioned that optical networks
can adjust quickly than IP networks.




Inter-ALTO communication problem statement

Meeting materials: slides, draft

External resources: audio for session (7 min, 33 sec @ 3.45 MBytes)
                    HTML5 video+slides+jabber

Piotr Wydrych presented the draft, covering updates since the Prague
IETF.  Authors want more feedback from the working group to make sure
that the problems described in the draft accurately represent work that
is of interest to the working group.

Yunfei Zhang wanted to know whether there is specific information that
can be provided to CDN providers by mobile devices that is different
than when CDNs work with fixed devices?  Piotr noted that there may be
issues that arise when multiple high-quality streams are destined towards
the mobile users.  Maybe the CDN can optimize the streaming if the
devices are incapable of handling high-quality streams.





Multi-cost ALTO

Meeting materials: slides, draft

External resources: audio for session (14 min, 45 sec @ 6.75 MBytes)
                    HTML5 video+slides+jabber

Sabine Randriamasy presented the draft, highlighting changes from the
last version.  This work has been socialized in the past and there appears
to be a some consensus on supporting multi-cost transactions.

When multiple cost types are requested, the cost mode SHOULD be
numerical.  Discussion ensued on whether the normative language should be 
MUST or SHOULD.  Authors prefer a MUST, but the draft currently contains
SHOULD primarily becuase there has not been a broader discussion on the
list about this.

Richard Alimi noted that the list discussion reflects that this work should
proceed.  The question (posed to the chairs) was where does it get done?  
In a separate draft, treated as an extension, or in the core protocol draft?
Vijay Gurbani (as chair) noted that the chairs remain unsure and will have
to figure out what is the best way to move the work forward, given that there
appears to be interest in doing so.





Odds and ends

Jon Peterson steps down from being a chair.  Jon was instrumental in 
getting the working group started.  The chairs, on behalf of the
working group, noted Jon's contributions and thanked him for being a
crucial part of ALTO.