Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Lars Eggert <lars.eggert@nokia.com> Tue, 14 October 2008 14:36 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 E33FE3A6B36; Tue, 14 Oct 2008 07:36:25 -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 70AA43A6B2F; Tue, 14 Oct 2008 07:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 1Zy8zdlptSxE; Tue, 14 Oct 2008 07:36:20 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 5727C3A659A; Tue, 14 Oct 2008 07:36:19 -0700 (PDT)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9EEb7ug052911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 17:37:08 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <1140F101-0D0C-4586-880C-EA486A52781A@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Marshall Eubanks <tme@multicasttech.com>
In-Reply-To: <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 14 Oct 2008 17:37:07 +0300
References: <20081006203532.B1D673A68AF@core3.amsl.com> <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Scanned: ClamAV 0.94/8423/Tue Oct 14 15:36:14 2008 on fit.nokia.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 14 Oct 2008 17:37:14 +0300 (EEST)
Cc: p2pi@ietf.org, iesg@ietf.org, IETF Discussion <ietf@ietf.org>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
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-10-10, at 15:00, ext Marshall Eubanks wrote:
>> considered for prioritizing standardization work, for example the
>> number of operators and clients that are likely to be able to provide
>> or use that particular data.  In any case, this WG will not propose
>> standards on how congestion is signaled, remediated, or avoided, and
>
> Does this mean that congestion is not an issue to consider ?
>
> If the closest peer to me was totally congested and had no available  
> bandwidth, isn't that something that I would want to know ?

I think the intent here is actually fine. ALTO attempts to improve the  
initial peer selection over simply choosing peers randomly by making  
some information available before this selection happens.

The information provided through ALTO can't - in my opinion - include  
very detailed or timely load or congestion information, because I  
remain unconvinced that the ALTO system could actually obtain and  
maintain this information on the timescales it would need to.

But there's other information that could be useful, such as some  
coarse-grained "this peer is not totally on the other side of the  
planet"-like information. Assuming that throughput and distance are by  
and large inversely proportional, preferring closer peers should often  
be better than choosing totally randomly. Other kinds of useful  
information could be "talking to this peer doesn't count towards your  
bandwidth quota", etc.

Now, once you actually establish and use a transport connection with  
the ALTO-recommended peer, you may well find that throughput is low.  
So you ditch the peer and try another one, which P2P systems already  
do. The intent here isn't that ALTO would pick the globally optimal  
peers for you, the intent is that it'll help an application reach a  
good set of peers a bit more quickly.

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