Meeting notes from ALTO Working Group meeting, IETF73, Minneapolis
November 18, 2008, 13:00-15:00.

About 180 attendees

This report is a distillation of the detailed meeting notes taken by
Jan Seedorf and Volker Hilt.

Chairs: Jon Peterson, Vijay Gurbani and Enrico Marocco


Agenda Bashing
--------------

Vijay Gurbani presented the agenda, asking if there are any objections
to the agenda.

No questions nor comments.


Status of the WG
----------------

Lisa Dusseault presented the history of the WG (P2Pi workshop). Since
IETF-72 scope has been narrowed down (now basically focused on making
better than random selection decisions), chartered as WG before
IETF-73. Current work is problem statement, requirements, and solution
space. ALTO service can come from any different places, not only
ISP. P2PRG being rechartered to cover also alto-related topics (P2P
pricing, getting information from routers, etc); if WG is not certain
about something, go to RG. Vijay, Enrico, Jon will be WG chairs.

Aaron Falk talked about IRTF P2PRG. Volker Hilt and Stefano Previdi
have put together a new charter (still draft) to cover a wide range of
topics. A wiki page is being maintained. Model will be: IRTF partner
with WGs in IETF - things that are not baked for standardization sent
to IRTF to come back to IETF.

Questions/comments:

  Vijay Gurbani: feel free to talk to the chairs or to Aaron if you
  have interest in topics fitting in the IRTF RG.


Problem Statement
-----------------

Enrico Marocco presented version 03 of the problem statement draft,
which reflects all comments from Dublin. Problem is to provide
applications with information to perform better-than-random peer
selection. Main changes include: do better than random (vs. optimal),
optimization may be localization but can also be something else,
replaced term "oracle". Added a Terminology section. Added solutions
considerations section discussing potential ALTO service providers,
user privacy, topology hiding, coexistence with caching solutions, and
protocol extensibility.

Questions/comments:

  Jon Peterson: is this going into the right direction?

  Vidya Narayanan: solutions considerations should not be part of the
  problem statement, what are the privacy consideration exactly? ALTO
  is voluntary, no one can force users to disclose information if they
  do not want to. Enrico: if we define an interface that requires
  disclosure of sensible information, clients won't use it.

  Roni Even: like the document, but would move solution considerations
  into requirements.

  Yushun Wang: document includes not only problem statement but also
  applicability issues, suggests to rename the document accordingly.

  Eric Rescorla: requirements should be in the requirements document,
  not in the problem statement. Jon: problem statement should set the
  scope, while requirements will have like REQ1, REQ2, REQ3.


Requirements
------------

Sebastian Kiesel presented the changes from previous version:
terminology has been aligned with problem statement draft, more
precise wording, removed implicit assumption of a "sorting oracle"
solution. Still to be done: section on overload control. Clients may
not send queries very often - possibly overengineerd. Requirements are
very general, should be confined more in the future; definition of an
extensible "core set" of attributes for expressing preferences.

Questions/comments:

  Leslie Daigle: are there specific requirements for transport
  protocol. Is XML over HTTP ok? Sebastian: no requirements for
  transport protocol at this time.

  Vidya: concerns about the process of requirements being presented a
  week after the WG has been accepted. This is an individual draft,
  what's the point of this discussion? Jon: not uncommon to propose an
  individual draft to see if it could meet a charter milestone. Vidya:
  there's been no time to read the document, and the presentation
  talks about deltas. Jon: asks how many people have read the
  document. Shows of hand are "more than expected" (in Jon's
  words). There is sort of an obligation to read the drafts being
  presented. Vidya: is there an assumption that everything but the
  deltas is agreed? Jon: no, it's not as WG item.

  Hannes Tschofenig: time on requirements documents is wasted
  time. Important are solution discussions. Can't treat requirements
  separate from solution. Group should build solution.

  Ted Hardie: document needs some work. Lots of things are
  implicit. One area is overload mechanisms. E.g. dropping messages
  places implicit requirements on transport protocol which is not
  good. Consider real requirements of transport protocols. Make all
  requirements explicit. Sebastian: due to history - draft assumed a
  specific solution. Let's postpone discussion until we know more.

  Dave Crocker: interesting topic. Good that there is attempt to make
  progress. But there needs to be effort people are in sync. Concerns
  about having 1st meeting talking about deltas. Culture everyone to
  basic requiremts. Requirements get our heads in wrong place. Too
  little experience. Actually only few people read and understood it
  and discussed it. Rethink how approach. Jon: need to come to common
  understanding.

  ??: requirements documents are ok to structure problem but it's too
  early to give it authority.

  Hannes: requirements don't provide any additional help to reader -
  basic requirements. What are the really challenging aspectis -
  usually 3-5. Consider architecture.

  ??: difficult is to define problem to be solved. What is the
  problem. Requirements fall out once you understand the problem. Jon:
  we have requirements in the charter. I agree that requirements are
  sometimes not entirely useful, but this seems a chartering issue.

  Vijay: hands - who has been in MIT workshop (couple). Most important
  question: how can you be more specific. Give requirements more
  teeth. Now we have depoloyments - author should talk to these people
  - what are their requirements.

  Daryl Malas: like requirements docs - helps to frame the immediate
  needs of WG. People will want add ons and solution will be
  delayed. Vendors will do own solutions. Agree on set of immediate
  requirments. Avoids creep.

  Stanislav Shalunov: sequencing of work. Requirements before solution
  or with solution. We should iterate between requirements and
  solutions.

  Jon: more discussion needed of this document. Maybe need to do a
  tutorial.


P4P Design and Implementation
-----------------------------

Richard Yang presented P4P portal mainly consisting of two services:
location portal service and pDistance portal service.  Location portal
service allows an ISP to aggregate the internet address space; uses
PID to denote a set of network locations. PDistance portal service
allows an ISP to define the pDistance for any given pair of network
locations; there can be different types of pDistance (e.g., ordinal,
numerical).

Questions/comments:

  ??: does each ISP have to define own PIDs? Richard Y.: each ISP
  defines own view on PID.

  ??: one AS is assigned to particalr 16 but for traffic engineering
  purposes the part is turned over to someone else. AS would have to
  disaggregate announcement. Some of the announcemed routes are only
  true if you know the hole punching routes of someone else. Richard
  Y.: You can do traffic engineering.

  Anja Feldmann: who would use such a service? Richard Y.: so far
  envisioned to be used by application trackers and clients.

  Ted: suggests to use existing mechanisms for a "looking glass" on
  the Internet.


Comcast's Experiences In a P4P Technical Trial
----------------------------------------------

Rich Woundy presented results from last summer's P4P tial. Results:
P4P improved download speeds, was effective in reducing inter-domain
traffic and no increase in upstream congestion. Comcast believes P4P
has merit and will continue working on this. Pando clients were made
to download a 20 Mb file and four swarms have been analyzed, each with
different principles: unbiased, proprietary optimization, fine grained
P4P model (1180 PIDs) and course grained P4P (22 PIDs). Best results
with course grained model - can't explain why. Reduction on ingress
traffic 80% and usually more traffic coming in than going out --
interesting savings. Does not solve last mile problem.

Questions/comments:

  ??: does Pando schema use P4P technology? Rich: no, but acts in
  similar way.

  ??: did you compare to other peer selection strategies (other than
  random)? Rich: Pando does not do random selection, it does its best
  to make optimal choices.


ALTO Information Export Service
-------------------------------

Satish Raghunath presented infoexport service: ISP prepares ALTO
information, application díscovers the service URL and uses http to
fetch ALTO information from service (discovery mechanism out of
scope). Data format is: type designator (ASN or CIDR) and priority
value. Key concept is that P2P application should not choose peers
solely from the preferred set from the ALTO service (e.g. 50% from
preferred and the rest from default set). There are different
approaches for mapping IP addresses to ASNs and there are different
BGP looking glasses available in the internet which may return
different results.

Questions/comments:

  Richard Barnes: check out work done in SIDR WG which work on
  verifyable mapping.

  Anja Feldmann: do you want to download the routing tables? How much
  info does client send? Satish: client does not send any
  information. Anja: how much info would the client have to download?
  Satish: up to the ISP. Stanislav: an important thing is the
  capability for incremental updates, the amount will depend on the
  ISP, expects a quantity of about 1000 records, 50 bytes each.

  Leslie: what kind of information is needed to share is important
  rather than the format.

  Rich: had examples in slides. E.g. 210000 for find grained.


Routing Proximity
-----------------

Stefano Previdi presented a proximity service based on the idea of
leveraging information in the routing layer. Routing databases are
well-known and have good properties for computing localization.

Questions/comments:

  Jon: is there a draft? Stefano: no, maybe in the future.

  Ruediger Volk: from the operators point of view probably some
  additional information is relevant.

  Rich: the routing topology changes over time, the information should
  be smoothed over time. Stefano: don't pass network info to clients,
  instead just use it to compute proximity. Algorithms that leverage
  real info of infratstructure for computation are powerful.

  Igor Faynberg: what is meant by routing layer? Do you assume
  interation of application servers with routers? Stefano: plenty of
  possibility. Here is important to agree what is the signaling
  needed. Could try to come to agreement on how service is implemented
  but may not need to go down that path. Igor: recommend group to look
  at FORCES WG. Useful information can get there.

  Anja: two different approaches to the whole problem, a) is to give
  the client information without considering network dynamics, b) is
  to consider network dynamics. Info missing: congestionn information
  This would me made available to the server. Stefano: routing is only
  one source of information, others can be used. Jon: remember charter
  text on congestion.


A Multi Dimensional Peer Selection Problem
------------------------------------------

Saumitra Das presented slides about various aspects of peer selection
optimization. Need to define a common framework to allow information
provided by both ISPs and peers. Peer input only is not enough to
optimize transfer performance. ISP input only is not enough as some
info needed is not available to ISPs (only interested in minimizing
congestion and interdomain traffic). ALTO query and response should be
extensible to enable a variety of peer selection services.

Questions/comments:

  Stanislav: the ability to publish information into an ALTO service
  is not necessarily an incentive for deployment.

  ??: You argue we should be build an interface but not describe info
  at all. You have deferred the hard part. Saumitra: also solve the
  hard part, but there may be pieces of info we don't know about
  yet. ??: You are suggesting to build a protocol that is extensible
  and not talk about info? Saumitra: no.

  Jon: must be at least one interesting piece of information.