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

[Karl Auerbach <karl at cavebear.com>]

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-EFrom ietf-bounces at ietf.org  Tue Oct 14 11:16:44 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 823663A69CD;
	Tue, 14 Oct 2008 11:16:44 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at 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 at cavebear.com>
Date: Tue, 14 Oct 2008 11:16:43 -0700
From: Karl Auerbach <karl at cavebear.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert at nokia.com>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
References: <20081006203532.B1D673A68AF at core3.amsl.com>		<BE82361A0E26874DBC2ED1BA244866B9276373BA at NALASEXMB08.na.qualcomm.com>		<48EEB19C.4000303 at bbn.com>	<48EEE549.1080208 at qualcomm.com>		<48EF477E.4080708 at telecomitalia.it>	<48EF706C.9050508 at qualcomm.com>		<48EFA0BE.1040809 at alcatel-lucent.com>	<ca722a9e0810101221yb84ac3ar8ff0f267718c88c9 at mail.gmail.com>	<48EFD2BC.8050706 at qualcomm.com>
	<48F000FD.5000302 at telecomitalia.it>
	<3C654581-ABA5-45B9-A36D-E0BD9B52366B at nokia.com>
In-Reply-To: <3C654581-ABA5-45B9-A36D-E0BD9B52366B at nokia.com>
Cc: "p2pi at ietf.org" <p2pi at ietf.org>, IESG IESG <iesg at ietf.org>,
	"ietf at ietf.org" <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at 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--
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


cho 
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--
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf