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

"Ye WANG" <wangye.thu@gmail.com> Tue, 14 October 2008 20:07 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 18F3B3A6B31; Tue, 14 Oct 2008 13:07:40 -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 5EF143A6B31 for <p2pi@core3.amsl.com>; Tue, 14 Oct 2008 13:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 nhat3j3iMx1i for <p2pi@core3.amsl.com>; Tue, 14 Oct 2008 13:07:39 -0700 (PDT)
Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 076AB3A6B2C for <p2pi@ietf.org>; Tue, 14 Oct 2008 13:07:38 -0700 (PDT)
Received: by gxk9 with SMTP id 9so5809417gxk.13 for <p2pi@ietf.org>; Tue, 14 Oct 2008 13:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=K0VCXhKXJzwdGiGZlvZSo5EoHbHv9M0t1f3gSP4+ZF8=; b=NDk1yxvjVn1jN+Pn7i7BnhSpjj4Z2lvg+5LhHo+QXjfHvlaUm3dSLxIt1e0gKT6sCj ChbOKXFvrQcObtTG8MAheesubokH6qlsowlN+3nMkRnrFXdD7Y4ZAbI/+Fc5tphng1JX m1VgmoNwfS4eoCx5aqGKe3L9H7g5gQw2zUORw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=YUG7xLoBBrEyHqg3aO2o8HiqXuAIvGC6to5pwETOYyVEXJZ2WmcV3Vnluab289sEvM IshM5TYMpMpAD28AP+88aHy2gvpURFeyhZcGRDbcn0LK+LRy4ASDTRmbPP3AYw0PDAHI KG1zPlnRUQdiNBMq3le8DkCMMD3MuCBPLai/E=
Received: by 10.102.228.10 with SMTP id a10mr57334muh.109.1224014844667; Tue, 14 Oct 2008 13:07:24 -0700 (PDT)
Received: by 10.103.52.9 with HTTP; Tue, 14 Oct 2008 13:07:24 -0700 (PDT)
Message-ID: <2574b1d30810141307s21f3131dn88f58836c674417f@mail.gmail.com>
Date: Tue, 14 Oct 2008 16:07:24 -0400
From: Ye WANG <wangye.thu@gmail.com>
To: p2pi@ietf.org
In-Reply-To: <E20CF38C-D14A-4900-8784-7486EBDEBF85@icsi.berkeley.edu>
MIME-Version: 1.0
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>
Cc: 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-Type: multipart/mixed; boundary="===============0088147335=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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.

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