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

Karl Auerbach <karl@cavebear.com> Tue, 21 October 2008 20:28 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 8AB3128C1C2; Tue, 21 Oct 2008 13:28:31 -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 8E0D13A6862; Tue, 14 Oct 2008 11:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9CNUlqFbjFpX; Tue, 14 Oct 2008 11:16:42 -0700 (PDT)
Received: from lear.cavebear.com (lear.cavebear.com [64.62.206.88]) by core3.amsl.com (Postfix) with ESMTP id 91C273A67F8; Tue, 14 Oct 2008 11:16:42 -0700 (PDT)
Received: from hari-seldon.cavebear.com (dsl-63-249-89-222.cruzio.com [63.249.89.222]) (authenticated bits=0) by lear.cavebear.com (8.14.2/8.14.2) with ESMTP id m9EIGi8c015668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 11:16:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cavebear.com; s=04142008; t=1224008222; bh=epirsfWnlQP87xZrmV32qmXSF0QdzoOmMgrJIK 9THEw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=a Q6Kc+ebUJQ64CdR5/+rTuam9tVK9E31ThXA65lcrmN7QhYCTXdqVo/pBLuOMKBdftMI 5NDz/vhaqBSF4qR3g+hdCcsTupMu4uKpLZfcXXWN6fFWJZlzcBVpRqrO+DGsmsjTkF8 Jg6A5OWL7uyBSRkCREvo6PNlEOdnXDQ+JWps=
Message-ID: <48F4E20B.8000609@cavebear.com>
Date: Tue, 14 Oct 2008 11:16:43 -0700
From: Karl Auerbach <karl@cavebear.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <48EEB19C.4000303@bbn.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>
In-Reply-To: <3C654581-ABA5-45B9-A36D-E0BD9B52366B@nokia.com>
X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700
Cc: "p2pi@ietf.org" <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"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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.

Since you mentioned DNS as a proximity tool, I thought I'd go slightly 
awry and point out a bit of work I did a while back that, while not at 
itself at the application level, did try to address some application 
layer optimizations concerns that we had when I was working on binding 
video clients to video services.

The main idea was that neither hop count, asn-path length, ICMP-Echo 
time, DNS answer time, nor TCP-connect-time are very good indicators of 
internet proximity for the purposes of applications that are going to 
make different kinds of demands and need different levels of service. 
And because such proximity questions are likely to be asked frequently, 
the cost of asking the question, and the delay incurred in asking that 
question, ought to be low.

So what I did was to try to blend the notions of potential bandwidth and 
packet size dynamics (from the old integrated services work) with some 
ideas from the old multicast mtrace protocol.  What I came up, and it 
was far, far from complete, was something that needed to live inside the 
router infrastructure, although not on any fast-path part of any router. 
  I called the thing the "Fast Path Characterization Protocol".

(The name may be misleading, the implementation was intended to find a 
path quickly, *not* that it would sit in any router fast-path switching 
logic.)

So, here it is, 8+ years old: 
http://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html

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