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

Philip Levis <pal@cs.stanford.edu> Tue, 14 October 2008 22:05 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 AADC23A6C26; Tue, 14 Oct 2008 15:05:05 -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 2AC8A3A6C11; Tue, 14 Oct 2008 15:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 pvM3RO-3IfLm; Tue, 14 Oct 2008 15:05:03 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2E48D3A6BBB; Tue, 14 Oct 2008 15:05:03 -0700 (PDT)
Received: from dnab4222f5.stanford.edu ([171.66.34.245]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1Kps1g-0004mY-5k; Tue, 14 Oct 2008 15:06:00 -0700
Message-Id: <25551223-3B5A-419D-A514-037B8C7E7391@cs.stanford.edu>
From: Philip Levis <pal@cs.stanford.edu>
To: Ye WANG <wangye.thu@gmail.com>
In-Reply-To: <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 14 Oct 2008 15:05:58 -0700
References: <20081006203532.B1D673A68AF@core3.amsl.com> <48EEE549.1080208@qualcomm.com> <48EF477E.4080708@telecomitalia.it> <48EF706C.9050508@qualcomm.com> <48EFA0BE.1040809@alcatel-lucent.com> <ca722a9e0810101221yb84ac3ar8ff0f267718c88c9@mail.gmail.com> <48EFD2BC.8050706@qualcomm.com> <48F000FD.5000302@telecomitalia.it> <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com> <E20CF38C-D14A-4900-8784-7486EBDEBF85@icsi.berkeley.edu> <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com>
X-Mailer: Apple Mail (2.929.2)
X-Scan-Signature: 2c21b60125577a2cbf52524016395bed
Cc: p2pi@ietf.org, IESG IESG <iesg@ietf.org>, "ietf@ietf.org" <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

On Oct 14, 2008, at 1:07 PM, Ye WANG wrote:

> On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu 
> > wrote:
>
> On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote:
>
> FYI, there's at least one more proposal in this space: the Ono stuff  
> from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html 
> ). There was a paper at SIGCOMM this year, and their system has the  
> interesting feature that it simply freeloads of Akamai's DNS entries  
> in order to determine who's close to whom. No "ALTO boxes" needed.
>
> Basically, this is freeloading on the akamai DNS infrastructure to  
> create a "topology oracle": which nodes are close in terms of  
> network topology as a common proxy for bandwidth.
>
> It doesn't need "ALTO boxes" only because someone else has colleced  
> that information, and that there is a separation between the query  
> replying infrastructure (through DNS) and the measurement  
> infrastructure.
>
> However, it does bring up a good point:  DNS games allow the ability  
> to divorce the measurement infrastructure from the reporting  
> infrastructure, and to create a reporting infrastructure that can  
> always work both with and without ISP cooperation.
>
> This is a very good comment on the architecture on "ALTO box".    
> Just to
> clarify on a risk of building an Internet infrastructure based on a  
> hack of
> using the Akamai DNS infrastructure to create a "topology oracle".
> You may already know it, but some others may not. So I would like to
> point it out.
>
> Akamai DNS redirection considers not only topology, but also  
> Akamai's own
> server state, and Akamai's own redirection policy.  To illustrate  
> this,
> consider a simple example where Akamai temporarily (e.g., during  
> maintenance,
> or misconfiguration, or under attack, or whatever reason) redirects  
> users
> from distant geographic locations to the same set of servers. This  
> may result
> in these users being deemed "close together" when in fact they are  
> not.
>
> This is not limited to Akamai. DNS redirection typically considers not
> only topology, but also the state and policy of whoever controls it.
>

To be fair, I don't think anyone was recommending Ono, merely noting  
it was one that has been proposed and so should be included in the  
list. While a cute systems hack that might make something work better  
today, it's pretty clearly not a good interoperable and long-term  
solution.

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