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

Philip Levis <> Fri, 10 October 2008 04:44 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6CB7F3A6AA4; Thu, 9 Oct 2008 21:44:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C518C3A6843 for <>; Thu, 9 Oct 2008 21:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jU3-XXYfsSbY for <>; Thu, 9 Oct 2008 21:44:48 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU []) by (Postfix) with ESMTP id 0F51D3A69CD for <>; Thu, 9 Oct 2008 21:44:48 -0700 (PDT)
Received: from [] (helo=[]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <>) id 1Ko9sP-00049s-VE; Thu, 09 Oct 2008 21:45:22 -0700
Message-Id: <>
From: Philip Levis <>
To: Richard Barnes <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 9 Oct 2008 21:45:21 -0700
References: <> <> <>
X-Mailer: Apple Mail (2.929.2)
X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

On Oct 9, 2008, at 6:36 PM, Richard Barnes wrote:

> On the contrary, I perceived pretty strong agreement at the BoF that  
> the ALTO problem, as expressed in the documents and presentations,  
> as an important one to solve.  There was some disagreement about  
> solutions, but there seemed to be agreement about the general idea  
> that it would be useful to create an ALTO service that could help  
> peers optimize their peer selection.
> The question of "service" versus "server" in the text is a complete  
> non-issue, purely a matter of wording.  In all of the "ALTO service"  
> scenarios Vidya describes, there is ultimately a single host that  
> provides ALTO information, which you might as well call an "ALTO  
> server".
> Since it addresses an important problem, and a problem that many  
> people agree is important, I support moving forward with this work.

I agree. This is such a pressing problem that blocking on terminology  
disputes which can be easily reconciled seems ill-advised. There was  
an excellent technical discussion on the list after the last IETF, and  
I think we reached at least rough consensus on the important points. I  
support moving forward.

p2pi mailing list