Interim recap and next steps

Hi folks,

sorry for being late in sending this -- day job got the upper hand.

Here is a brief recap of the next steps for the working group, as agreed
during the last virtual interim meeting. Raw notes from Vijay are attached.

Documents
---------

Requirements: authors have moved the descriptive parts about use cases
and rating criteria to the deployment considerations document. The draft
now contains a short easy-to-read list of requirements and is considered
basically ready for moving forward. Chairs will issue a WGLC very soon
taking care that the document gets accurate reviews, in particular by
authors of other WG documents.

Deployment considerations: the current individual draft is the only
candidate for the charter milestone and people have expressed support
for adopting it both in Beijing and during the interim. Chairs will
issue a last call for adoption on the list.

CDN use case: an individual draft has received significant attention
during the last year and the WG has expressed interest in working on
such a document. Chairs will negotiate with the responsible AD an
additional milestone for the charter.

Interoperability
----------------

There seem to be broad interest in arranging a plugfest in the IETF 81
timeframe. Several implementations are likely to be ready by then. It
seems reasonable to limit the scope of the event to the testing of basic
protocol interoperability -- i.e. client/server interactions and server
discovery. Many other ideas have however been brought up during the
interim, that will be worth discussing on the main ALTO list and keeping
track on a wiki page. Documenting the rather singular experience may
eventually also have value for the whole IETF community. Volunteers for
helping with the organization and documentation of the event are most
welcome: if you think you can dedicate some time to it, please get in
touch with the chairs.

There is also an opportunity for arranging a less structured demo event
in Prague -- most likely a lunch meeting -- to let people show their
ALTO-like/ALTO-related implementations. People that have running code
they consider relevant to the activities of the ALTO WG and want to take
the opportunity of showing it to the broad community, please also get in
touch with the chairs ASAP.

Thank you all for your participation on for the various contributions!

Enrico, Vijay and Jon

Attendees: Vijay, Enrico, Jon, Jan Medved, Sebastian Kiesel
Rich Alimi, Stefano Previdi, Richard Yang, Ye Wang, Rich 
Woundy.

Chair slides, Enrico
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-Agenda.pdf


- Add a milestone for Informational providing guidelines on 
  CDN use case.
Sebastian: Should have a milestone, but cannot comment on
the current version.
Jan: Ditto.
Enrico: Are you planning to change the doc?
Stefano: Right now the document's aim is NOT TO dictate how
ALTO can be used, but give some recommendations and examples
based on experience we have acquired last year.  So, we will
add more details and more examples in the draft.
Jan Medved: Agree with Stefano.  One purpose to document
CDN usage, other is to create requirements on ALTO.
Vijay: Beijing decided to baseline requirements.
Enrico: The idea is to have extensions, not pure requirements.
Sebastian: Can we stay with the req document now and you
document the use case that does not add new reqs.
R. Alimi: Everything we have identified thus far can be done
as an extension.  Let's not delay reqs.
R. Yang: Baseline reqs should move ahead as soon as 
possible.  Extensions in the use case docs should be pulled
out and the use case doc should be simply on the use case.

<Discussion ensued on how to go about making it so that
the extension docs are standard tracks and use case docs
are Informational.>

Reqs doc, Sebastian
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-reqs.pdf

A couple of days ago a new version appeared.
Went through the changes.
3 new reqs added, although they have been around in some
form for a long time.
Authors think they are finished with the doc, no issues
with current protocol specification.  Doc is ready to go.
R. Alimi had a question on one of the requirement (req 7-20)
that was decided to be taken to the list for further 
discussion.

Enrico: We will have the document be reviewed by many
people, including the authors of key documents in the
WG to make sure that the reqs doc is in good shape during
WGLC.

No objections recorded.

Martin Stiemmerling, ALTO deployment considerations
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-depl-cons.pdf


Went through the changes in the slides.
Went through the proposed new structure for -07.
New structure should appear by Prague.
Teaming up with R. Alimi, R. Yang for the new
structure.

Question: Should we adopt this as a WG document?

Enrico: There aren't any other docs towards the
deployment deliverable, so adopting
this after checking on the list seems appropriate.

Enrico Marocco, Interoperability event
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-Interop.pdf


Several independent ALTO client/server implementations
exist.  We are trying to get an interop going by
summer IETF.  We can do something from a lunch-time
demo to something more advanced that requires more time.
Not a strict interop event in the sense of parser
torture tests, etc., but would be good to see
some interop between independent implementations.

Jan Medved: We have an implementation based on -06.
Have an implementation in Python.
Enrico: Maybe Yale has an implementation.
R. Alimi: From Yale's point of view, the running code
has old representation, but should be easy to change.
We also have an ALTO plugin for Vuze.
Enrico: What kind of app do we want to test?  Real swarm?
Simple querying and getting replies?
Sebastian: If interop, we should have several servers
and clients to see if protocol implementation is precise
enough.
Jon: I doubt we will be able to construct or simulate
a test network to test localization benefits.  We'd be
interested in the protocol aspect from the IETF point-of-
view.
R. Alimi: From a spec point of view, knowing some deployment
scenarios from ISP may be useful.  This will serve good
feedback for the spec.
Jon: Agree, we need a couple of motivating use cases.
One of the operators who is interested in this should be
of help.  Comcast?
Rich Woundy: How much of this is going to be reflective
of Comcast's routing tables or how much of this will be
some corner cases of our network.  Don't know yet.
Jon: We probably need to expose some high level cases like
should we do this for CDN or as a Vuze plugin.  That will
be the most help right now.
Richard Alimi, Jan Medved: Focus should now be on encoding, 
how are servers searched, etc.
Rich Woundy: May be interesting to test two different cases,
one using Vuze plugin to optimize a swarm, another one would
be a CDN use case.  Another dimension may be attractiveness
and setting up different priorities --- primary AS, 
secondary and tertiary AS, etc.
Vijay: Server discovery may be another axis to interop.

<More discussion ensued, but seem to converge on the
fact that we need to inerop protocol mechanics in the
first interop rather than swarm dynamics.  The latter
will come later.>

Vijay: Send email to chairs about who is interested in
bringing something to the interop in Quebec City.

Enrico: Possible option to show something in Prague as a
lunch-time demo.
<There was some interest in this from about 2-3 people>

Attendees: Vijay, Enrico, Jon, Jan Medved, Sebastian Kiesel
Rich Alimi, Stefano Previdi, Richard Yang, Ye Wang, Rich 
Woundy.

Chair slides, Enrico
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-Agenda.pdf


- Add a milestone for Informational providing guidelines on 
  CDN use case.
Sebastian: Should have a milestone, but cannot comment on
the current version.
Jan: Ditto.
Enrico: Are you planning to change the doc?
Stefano: Right now the document's aim is NOT TO dictate how
ALTO can be used, but give some recommendations and examples
based on experience we have acquired last year.  So, we will
add more details and more examples in the draft.
Jan Medved: Agree with Stefano.  One purpose to document
CDN usage, other is to create requirements on ALTO.
Vijay: Beijing decided to baseline requirements.
Enrico: The idea is to have extensions, not pure requirements.
Sebastian: Can we stay with the req document now and you
document the use case that does not add new reqs.
R. Alimi: Everything we have identified thus far can be done
as an extension.  Let's not delay reqs.
R. Yang: Baseline reqs should move ahead as soon as 
possible.  Extensions in the use case docs should be pulled
out and the use case doc should be simply on the use case.

<Discussion ensued on how to go about making it so that
the extension docs are standard tracks and use case docs
are Informational.>

Reqs doc, Sebastian
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-reqs.pdf

A couple of days ago a new version appeared.
Went through the changes.
3 new reqs added, although they have been around in some
form for a long time.
Authors think they are finished with the doc, no issues
with current protocol specification.  Doc is ready to go.
R. Alimi had a question on one of the requirement (req 7-20)
that was decided to be taken to the list for further 
discussion.

Enrico: We will have the document be reviewed by many
people, including the authors of key documents in the
WG to make sure that the reqs doc is in good shape during
WGLC.

No objections recorded.

Martin Stiemmerling, ALTO deployment considerations
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-depl-cons.pdf


Went through the changes in the slides.
Went through the proposed new structure for -07.
New structure should appear by Prague.
Teaming up with R. Alimi, R. Yang for the new
structure.

Question: Should we adopt this as a WG document?

Enrico: There aren't any other docs towards the
deployment deliverable, so adopting
this after checking on the list seems appropriate.

Enrico Marocco, Interoperability event
http://www.standardstrack.com/ietf/alto/alto-interim-jan-26-2011/ALTO-Interop.pdf


Several independent ALTO client/server implementations
exist.  We are trying to get an interop going by
summer IETF.  We can do something from a lunch-time
demo to something more advanced that requires more time.
Not a strict interop event in the sense of parser
torture tests, etc., but would be good to see
some interop between independent implementations.

Jan Medved: We have an implementation based on -06.
Have an implementation in Python.
Enrico: Maybe Yale has an implementation.
R. Alimi: From Yale's point of view, the running code
has old representation, but should be easy to change.
We also have an ALTO plugin for Vuze.
Enrico: What kind of app do we want to test?  Real swarm?
Simple querying and getting replies?
Sebastian: If interop, we should have several servers
and clients to see if protocol implementation is precise
enough.
Jon: I doubt we will be able to construct or simulate
a test network to test localization benefits.  We'd be
interested in the protocol aspect from the IETF point-of-
view.
R. Alimi: From a spec point of view, knowing some deployment
scenarios from ISP may be useful.  This will serve good
feedback for the spec.
Jon: Agree, we need a couple of motivating use cases.
One of the operators who is interested in this should be
of help.  Comcast?
Rich Woundy: How much of this is going to be reflective
of Comcast's routing tables or how much of this will be
some corner cases of our network.  Don't know yet.
Jon: We probably need to expose some high level cases like
should we do this for CDN or as a Vuze plugin.  That will
be the most help right now.
Richard Alimi, Jan Medved: Focus should now be on encoding, 
how are servers searched, etc.
Rich Woundy: May be interesting to test two different cases,
one using Vuze plugin to optimize a swarm, another one would
be a CDN use case.  Another dimension may be attractiveness
and setting up different priorities --- primary AS, 
secondary and tertiary AS, etc.
Vijay: Server discovery may be another axis to interop.

<More discussion ensued, but seem to converge on the
fact that we need to inerop protocol mechanics in the
first interop rather than swarm dynamics.  The latter
will come later.>

Vijay: Send email to chairs about who is interested in
bringing something to the interop in Quebec City.

Enrico: Possible option to show something in Prague as a
lunch-time demo.
<There was some interest in this from about 2-3 people>