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

stefano previdi <sprevidi@cisco.com> Fri, 13 June 2008 08:52 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEBF3A6B3B; Fri, 13 Jun 2008 01:52:22 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBC83A6B3B for <p2pi@core3.amsl.com>; Fri, 13 Jun 2008 01:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGhkXTK8lUEE for <p2pi@core3.amsl.com>; Fri, 13 Jun 2008 01:52:19 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4F1083A69BA for <p2pi@ietf.org>; Fri, 13 Jun 2008 01:52:19 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5D8qna06804; Fri, 13 Jun 2008 10:52:49 +0200 (CEST)
Received: from [144.254.189.71] (dhcp-rom2-144-254-189-71.cisco.com [144.254.189.71]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5D8qnA10647; Fri, 13 Jun 2008 10:52:49 +0200 (CEST)
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Fri, 13 Jun 2008 10:52:29 +0200
From: stefano previdi <sprevidi@cisco.com>
To: Enrico Marocco <enrico.marocco@telecomitalia.it>, "p2pi@ietf.org" <p2pi@ietf.org>
Message-ID: <C47801ED.68DB8%sprevidi@cisco.com>
Thread-Topic: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]
Thread-Index: AcjNMs9MDdaZfzkmEd2gXAAX8vOM8g==
In-Reply-To: <48516BE2.2080901@telecomitalia.it>
Mime-version: 1.0
Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin]
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Enrico,

I mostly agree mostly with everything below. My suggestion (as a routing guy
more than an apps guy) is also to scope what could be extended/enhanced in
routing protocols in order to improve localization mechanisms (whatever they
are). 

As an example, we have extended ISIS routing protocol in order to carry some
application related information (at this stage is an empty container) and
probably these kind of enhancements may have a use in localization/oracle
services.

s.


> From: Enrico Marocco <enrico.marocco@telecomitalia.it>
> 
> 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
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi


_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi