[p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]

[Enrico Marocco <[e-mail]>]

Peterson, Jon wrote:
> The proposal for the ALTO BoF (which roughly covers (3)) is now in the
> BoF tracker. You can read about it at its home page:
> 
> http://alto.tilab.com/
[...]
> we hope that discussions surrounding the BoF could elucidate the proper
> division of labor and approach to this problem.

To follow up on Jon's thoughts and to reflect discussions that happened
during the MIT workshop and on the mailing list, Vijay and I are going
to update the problem statement draft the ALTO BoF proposal is based on
(draft-marocco-alto-problem-statement-00).

As a prelude to focus the ALTO BoF, it would be great to start
coalescing community agreement on ensuring that the scope of the problem
is well defined and understood.

Essentially, the problem that ALTO will attempt to solve is this:
applications (P2P and otherwise) that make intensive use of the network
bandwidth or want to make decisions to optimize some function (see use
cases) may be interested in choosing all or some of their peers based on
recommendations provided by some network entity -- colloquially called
an oracle -- that has more of a global view on the peers in the network,
their topological distances, and their capabilities than the application
itself does.

In thinking about the problem, it may help to consider the following:

+ Use cases: current version of the draft identifies four use cases for
  ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but others
  come to mind (e.g. cache/http-mirror selection, CDN).  At the MIT
  workshop, Ted Hardie coined the term "unattended consequences" of
  peer-to-peer nodes where traffic runs constantly for as long as the
  resources to that node are popular.  Video feeds to remote stations
  were identified as a category.

+ Third-party services: even if topology information is directly
  available to network operators, nothing should prevent third-parties
  to provide peer selection services alternatively to or in competition
  with ISPs.  An incomplete list of proposed solutions for providing
  such services is online at http://alto.tilab.com/resources.html;

+ Type(s) of information that are likely provided by the oracle (note
  that a third-party oracle may not have access to some of this
  information):
  * Given a list of peer candidate IP addresses, sort them according to
    preferences (topological proximity, bandwidth constraints, etc.) and
    return to querying application;
  * Ability for an application to determine its network location and
    proximity to other nodes;
  * Support for cost and charging information for application so that
    applications can make appropriate trade-offs;
  * Capabilities and characteristics of peers (i.e., last hop bandwidth,
    etc.);
  * Network policies;
  * ...

+ Type(s) of information that is provided to the oracle for rendering an
  equitable decision:
  * List of peer candidate IP addresses;
  * Parameter to optimize (cost, delay, ...);
  * ...

This is mainly what we have captured so far; however, feedback,
suggestions and contributions are not only welcome, but at this time
even required for the successful setting of a BOF.

Besides, the draft currently identifies two elements for which
standardization work would be required, namely a discovery mechanisms
for locating oracles and a signaling protocol for querying them.  Do
people think the core solution for ALTO should include anything else?

-- 
Ciao,
Enrico

_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi