Re: [p2pi] Refining the ALTO problem statement
Lars Eggert <lars.eggert@nokia.com> Fri, 27 June 2008 13:01 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 2655E3A6846; Fri, 27 Jun 2008 06:01:39 -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 5BF553A67A7 for <p2pi@core3.amsl.com>; Fri, 27 Jun 2008 06:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 SDRIRouCmwpD for <p2pi@core3.amsl.com>; Fri, 27 Jun 2008 06:01:36 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 43C673A63EC for <p2pi@ietf.org>; Fri, 27 Jun 2008 06:01:36 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5RD0xxR000366; Fri, 27 Jun 2008 16:01:09 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 16:00:47 +0300
Received: from net-99.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 16:00:46 +0300
Message-Id: <D9139090-88A4-48EE-8EF9-4C20E9660061@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Laird Popkin <laird@pando.com>
In-Reply-To: <1896440527.443251214570511993.JavaMail.root@dkny.pando.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Fri, 27 Jun 2008 16:00:41 +0300
References: <1896440527.443251214570511993.JavaMail.root@dkny.pando.com>
X-Mailer: Apple Mail (2.924)
X-OriginalArrivalTime: 27 Jun 2008 13:00:47.0466 (UTC) FILETIME=[D14244A0:01C8D855]
X-Nokia-AV: Clean
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org
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. > 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. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Vijay K. Gurbani
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Laird Popkin
- Re: [p2pi] Refining the ALTO problem statement Lars Eggert
- Re: [p2pi] Refining the ALTO problem statement Stanislav Shalunov