Re: [p2pi] Refining the ALTO problem statement

Laird Popkin <laird@pando.com> Fri, 27 June 2008 14:31 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 A44073A699A; Fri, 27 Jun 2008 07:31:18 -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 E80AE3A699A for <p2pi@core3.amsl.com>; Fri, 27 Jun 2008 07:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Level:
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
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 J0EyO4K1fMau for <p2pi@core3.amsl.com>; Fri, 27 Jun 2008 07:31:14 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 124633A6861 for <p2pi@ietf.org>; Fri, 27 Jun 2008 07:31:12 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 60729E10B17; Fri, 27 Jun 2008 10:31:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0y-qT9tD+Qy; Fri, 27 Jun 2008 10:30:59 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1D641E10AFB; Fri, 27 Jun 2008 10:30:59 -0400 (EDT)
Date: Fri, 27 Jun 2008 10:30:59 -0400
From: Laird Popkin <laird@pando.com>
To: Lars Eggert <lars.eggert@nokia.com>
Message-ID: <762072025.443831214577059088.JavaMail.root@dkny.pando.com>
In-Reply-To: <112114914.443811214576908025.JavaMail.root@dkny.pando.com>
MIME-Version: 1.0
X-Originating-IP: [71.187.207.81]
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Refining the ALTO problem statement
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


- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Lars Eggert" <lars.eggert@nokia.com>
To: "ext Laird Popkin" <laird@pando.com>
Cc: p2pi@ietf.org, "ext Stanislav Shalunov" <shalunov@bittorrent.com>
Sent: Friday, June 27, 2008 9:00:41 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Refining the ALTO problem statement

Hi,

On 2008-6-27, at 15:41, ext Laird Popkin wrote:
> I think that we're all in violent agreement in the distinction  
> between long-term network status (e.g. topology, capacity, distance,  
> cost) and transient status (e.g. congestion).

I think we are, although I'd question whether capacity is long-term  
status. If you mean capacity as in "the potential capacity of the  
bottleneck link along a path", then probably yes, but if you mean  
"currently available bottleneck capacity", then likely not.

LP: I was thinking of "capacity that an ISP wants to direct P2P through", which would be a combination of typical available capacity and business policies (e.g. run p2p through peering links to balance traffic, keep p2p downloads off of links intended for VOIP). This information would be slowly changing, perhaps varying by time of day (e.g. daytime and nighttime traffic are different) or as network physical infrastructure is deployed (or links go down, etc.).

> I believe that there is also value in exposing "last mile" link  
> status (and capacity, quotas, etc.) to applications to assist them  
> in making better decisions (e.g. avoiding 'last mile' link  
> congestion, avoiding running consumers over their quotas, etc.). So  
> while arguably last-mile link congestion is a "transport layer"  
> issue, if it's not addressed elsewhere, perhaps ALTO should address  
> it?

ALTO, as a BOF targeted at the RAI and APP areas, is not the right  
place to discuss these issues. Transport area topics do need to be  
discussed in transport area meetings.

The original proposal for the transport-area TANA BOF, which came out  
before there was public information about ALTO, had a similar work  
item, because it seemed likely after the P2PI workshop that folks  
would want to discuss mechanisms related to transient network status.  
When the ALTO proposal was submitted, the ADs decided it would make  
more sense to split the work items identified at the P2PI workshop  
into things for TANA and things for ALTO, but it was at least my  
understanding that this split came with an agreement that obviously  
transport-related topics would be out of scope for ALTO.

LP: Thanks, this is very helpful. I wasn't clear on the distinction between ALTO and TANA BOF's - the descriptions in the email archives seem to overlap somewhat. Is there a list of which items from the P2Pi Workshop are ALTO and which are TANA?

Is there a TANA BOF meeting scheduled? If both TANA and ALTO are on the agenda in Dublin, that'd be convenient. :-)

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