Monday, March 26 2012
1300-1500
i2aex BoF, Paris France
Attendees: 130-140 people

Chairs: Vijay K. Gurbani and Spencer Dawkins
Raw notes taken by Sreekanth and Markus Isomaki

List of pertinent drafts:
  http://trac.tools.ietf.org/html/draft-marocco-alto-next 
  http://tools.ietf.org/html/draft-seedorf-i2aex-alto-cdni-perpective-00
  http://trac.tools.ietf.org/html/draft-seedorf-alto-for-cdni-00
  http://trac.tools.ietf.org/html/draft-jenkins-alto-cdn-use-cases-02
  http://trac.tools.ietf.org/html/draft-penno-alto-cdn-03
  http://trac.tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-00
  http://trac.tools.ietf.org/html/draft-dulinski-alto-inter-problem-statement-01
  http://trac.tools.ietf.org/html/draft-medved-alto-svr-apis-00
  http://trac.tools.ietf.org/html/draft-sun-alto-notification-02

Agenda
------

Meeting materials: Slides, MP3 (5m:08s, 2.34MBytes), HTML5 Meetecho Recording

Agenda bashed, no changes.

Vijay provided high level overview of the BoF and what was hoped to
be accomplished at the end of the meeting time.  Essentially, the network
infrastructure maintains volumnious amount of information that is
disseminated among the network infrastructure entities using many 
existing protocols: BGP, IGP, netflow, CLI/SSH, SNMP, etc.  Applications
running outside the network infrastructure (or even in the network
infrastructure) would likely benefit from this information.  So, the
question is: in a fully- and partially-controlled environments, 
how do we disseminate this information to the applications?
Do we need a new protocol for this?  Can we extend ALTO since a lot
of the requirements for this work came into the ALTO WG initially?

Three use cases are presented: Content Delivery Networks (CDNs), Data
Centers (DC) and "large bandwidth" use case.  CDNs are examples of
services running in partially controlled netwoks and DCs are examples
of services in fully controlled networks.

Vijay showed the questions that would be asked at the end of the session
to prep the attendees to think in terms of answering these.  These
questions are: (a) Do CDN and DC operators believe that such an
aggregation/abstraction is needed?  (b) Are the infrastructure operators
willing to provide this information?  (c) Do folks think that existing
protocols without any modifications or extensions are sufficient?
During the presentations, clarifying questions are okay.  Time reserved 
at the end for larger discussion.

Problem statement and background
------

Meeting materials: Slides, MP3 (19m:14s, 8.80MBytes), HTML5 Meetecho Recording (Part 1), HTML5 Meetecho Recording (Part 2)

Enrico presented his slides, including motivation of the work:  To set 
distributed apps free to get smarter. Do this by enabling infrastructures 
to expose useful information. Can be done either by use or extension of 
existing protocols, or creating a new one. Try to keep the scope narrow.

Background: There have been many proposals in ALTO WG around this topic. 
Also Software Driven Networking Initiative at IETF 82, a few data center 
related bar BOFs and mailing lists have been related.

Identify what kind of I2A infrormation would be useful. The resulting 
protocols should be easily usable by apps. Focus on fully/partially 
controlled apps, CDN and datacenters to begin with.

Clarifying questions from Dave Meyer and Bhumip.  Dave asked whether
the information shown on slide 5 is final or a strawman proposal only?
(Strawman).  Bhumip asked to clarify what is meant by "infrastructure".

There are different tools in terms of dynamicity, accuracy, 
confidentiality, scalability, accessibility. ALTO is currently on one 
place on the axis, SNMP etc. exist too. Architecturally there could 
be some kinf of aggregator who uses SNMP, routing protocols, ICMP, SSH 
etc. to collect information from the infrastructure elements, and makes 
it available for apps via some other protocol, that would be the focus of 
this effort. The first question is whether there is a need for another 
protocol for this purpose. ALTO could be a starting point, a few concrete 
proposals already exists. But these are just some of the options.

ALTO is HTTP+REST+JSON, so easy to implement and use. It is intended to 
let network operators to provide info about the more or less preferred 
network destinations, e.g. for P2P apps to use when selecting peers. 
It was initially intended for uncontrolled apps, i.e. apps have 
no relation to the infrastructure. So ALTO would need to be extended 
somewhat to meet the reqs of the more controlled environments.

Questions posed on why we are jumping to solutions before the problem
statement itself is clear.  Enrico clarified that no intention to 
jump to solutions, just to show examples.  

AD (David Harrington) clarified that ALTO has restrictions not to 
infringe on other protocols like SNMP.

ALTO itself would need some modifications at some places if it was to 
support i2aex interactions, for instance, server-to-client notifications, 
server-to-server information exchange, incremental updates, etc.  For 
server-to-client notifications, HTTP polling, websockets or something
else would be needed.

Use case: CDN
------

Meeting materials: Slides, MP3 (13m:41s, 6.26MBytes), HTML5 Meetecho Recording

Jan presented the slides and noted that this use case has been discussed
in ALTO for quite a while.

A CDN request router is a node in CDN that receives end user requests 
and maps them to the most suitable cache. The request router could use 
ALTO or otherwise provided infrastructure information to do its job better. 
Extensions to current ALTO that would help in this use case: Incremental 
updates for ALTO network and cost maps, and server notifications about 
the changes. Pieces of information that would be useful: load on 
caching server, content availability, storage capacity. So it would not be 
only network topoloy information like in ALTO currently, but also 
information about caches.

Besides the canonical use of ALTO in CDNs, another working group
CDNI (CDN Interconnect) has discussed the use of ALTO to facilitate
the selection of a downstream CDN.  There, ALTO is one protocol besides
BGP that is being discussed for this purpose; no agreement yet if ALTO 
will be used. Similar extensions to ALTO as described above would be 
useful for this use case too.

Jan noted that ALTO maps can grow large, so it is necessary to have
incremental updates supported in the base protocol.  Furthermore,
minor changes in ALTO maps may be of interest to the client, so some
form of asynchronus communication from server to client would be
beneficial as well.  The alternative is to use the ECS (Endpoint Cost 
Service).

Huilan Lu expressed an interest in server-to-server communications
across domains.

Use case: Data centers
------

Meeting materials: Slides, MP3 (16m:30s, 7.55MBytes), HTML5 Meetecho Recording

David presented the slides and noted that his use cases are limited
to components that could be deployed in DC.  These include compute
elements, stoarge elements, middleboxes, external clients.  Some sort
of an aggregation service could reduce application complexity.  There
are many challenges of infrastructure information exposure: Information
exchanged between infrastructure and applications is highly dynamic
and may be private (not to be exposed across administrative domains),
interdomain dependencies, heterogrneity (diverse infrastructure technologies
and complexity structure).

Dave presented several use cases and discussed their relation to ALTO:
Hadoop/MapReduce, hybrid cloud bandwidth on demand, DC hosted virtual
desktop, network QoS awareness, inter-DC bulk transfer and cloud
resource monitoring.

Some discussion ensued on what network infrastructure is included (switches,
routers, hypervisors, etc.), whether or not existing APIs (OpenStack) 
will be used (depends, some information is available through these
APIs, but not all), and that the original intent of ALTO was less
concerned about security, but the DC data center case, security and
privacy are paramount.

Use case: Large bandwidth
------

Meeting materials: Slides, MP3 (21m:38s, 9.90 MBytes), HTML5 Meetecho Recording
 
Young presented the use cases for large bandwidth: end systems
aggregation (video on demand), express lanes with assured service
quality, DC-DC communication links, etc.  All these require 
infrastructure to application exchanges about capacity, latency, and
other attributes.  Expected increase in use of network: VoD --- lots
of customers with ~1.5 Mbps, whereas HDTV pushes that to ~10Mbps.  10 Gbps
pipes eaily filled with application data backup, live VM migration, 
etc.

Some discussion ensued on whether ALTO should be used for reserving
bandwidth (no) but it could be useful for resilience (using graph
structure).  Some reservations also expressed that if the information
changes too rapidly, is it useful to share such information with
applications (oscillations).

Open mic discussion followed by summary
------

Meeting materials: Slides (see slides 5-8), MP3 (39m:07s, 17.90 MBytes), HTML5 Meetecho Recording

The discussion was opened up to the larger working group participants 
to share their insights.  Answers to three questions were sought:

   1. Do CDN and DC operators belive that such an aggregation/abstraction 
      is needed?
   2. Are the infrastructure operators willing to provide this information?
   3. Do folks think that existing protocols without any modifications 
      are sufficient?

Dave Harrington (as AD) cautioned hat he is interested in getting feedback
from operators and not ALTO developers.

Ben Jenkins: Answers to 1 and 2 are yes.  ALTO is a good abstraction
layer between the network guys and application guys.
Martin Stiemmerling: The answer to 2 appears to be yes since the network
folks typically do not like to provide raw information to the application
folks.  ALTO provides a way to present this information in a more
controlled manner.
Enrico Marocco: (Speaking as an operator) The answer to question 2 is yes;
I want my Cisco routers to provide information to my Huawei CDN.  The
trust level is important, but for the use cases being discussed currently,
I do not see a problem.
Jon Peterson noted that the actual protocol changes to ALTO would be
cosmetic, any protocol can convery the information sought.  The bigger
point is what is this information and who is it exposed to.
Dave McDysan noted that getting information from network infrastructure
is useful and ALTO is not the only way.  But it has some advantages
given that it runs over HTTPS.  Many other people (Ted Hardie, Dirk
Kutcher) agreed that there is a lot of data that is useful, but there
will be a need to agree what that information would be and what the
trust model would be for sharing that information.
Rich Woundy agreed and said that as an operator, his company would be
willing to provide the information but the lawyers would have to be
involved on what information to give out, etc.  Regarding the choice
of a protocol, don't quite know what will be used.  Could be ALTO, but
something else as well.
Yunfei noted that China Mobile would like to share network-related
information through i2aex.  Example: base station load, etc. can be
provided in real time.  SNMP cannot be used here as it is not quite
real-time in nature.
Diego Lopez from Telefonica noted that one of his assignments was to
foster discussion between the network and DC folks.  There is a lot
of intra-domain data that can be passed; inter-domain is a tricker
case.  Management is not too keen to give SNMP access for this data.
Stefano Previdi noted that if better information from the network is
what is needed, then IGP/BGP may be better options.
Chris Liljenstolpe noted that when he was in the operator role, he would
have been willing to provide information about the infrastructure.
He would be worried about oscillation as some of this information
changes quickly.

As the open mic time wound down, the chairs summarized the discussion.
Vijay noted the following as a summary:

- Operators are willing to expose info modulo security and trust.
- Application writers would be willing to get the info.
- Information should be secured.
- ALTO provides a good abstraction.
- There is a choice of application protocols: BGP, SNMP, ALTO, something 
  new.
- ALTO is critically missing publish-subscribe mechanism.

Spencer noted that there may be some commonality between the use cases
discussed here.  People working on these use cases individually should
correspond with each other to discover common areas: what information
is needed and at what timescales, etc.

David Harrington closed the session by noting that SNMP may serve as a
protocol since it is mature and has an extensive security model.  While
he is not pushing for SNMP, he does see advantages in using it.

Meeting adjourned at 1500.