IETF Logo Mail Archive

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

"Das, Saumitra" <saumitra@qualcomm.com> Thu, 16 October 2008 08:45 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 F35463A6B64; Thu, 16 Oct 2008 01:45:04 -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 43B923A6B4C; Thu, 16 Oct 2008 01:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 2tKjW4b2W50I; Thu, 16 Oct 2008 01:45:01 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D21853A6B64; Thu, 16 Oct 2008 01:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1224146763; x=1255682763; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Das,=20Saumitra"=20<saumitra@qualcomm.com>|To: =20"p2pi@ietf.org"=20<p2pi@ietf.org>|CC:=20"ietf@ietf.org "=20<ietf@ietf.org>|Date:=20Thu,=2016=20Oct=202008=2001:4 5:50=20-0700|Subject:=20Re:=20[p2pi]=20WG=20Review:=20App lication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20Re:=20[p2pi]=20WG=20Review:=20Applicatio n-Layer=20Traffic=20Optimization=0D=0A=20(alto) |Thread-Index:=20Ackva5czBEUA6wFMRt+cB2Kq3sElUw=3D=3D |Message-ID:=20<4A27D05E36DE7E47B96BCF7DD8F3FD7101D20307C 9@NASANEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5406"=3B=20a=3D"11030202"; bh=sV3j8XBJW9CUvS0sS5SBVujszQmfQyCctPlHVv5HYo4=; b=Pg1K9iU2s93Un/CyKcsrcaZulQfahvXeXd6VY4i0b1bglTZU6MReAbSs M0q3lOT/HtWpYjiXKbJEuGH/6+d7pW4Zag099geNkcglRTxdVTtozF0yL +Nk3ErgGZ2j6ljuodH/YBHB2EMPFTv+3if3O4P/+oC9XKn+A4gLpfD807 E=;
X-IronPort-AV: E=McAfee;i="5300,2777,5406"; a="11030202"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2008 01:45:53 -0700
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9G8jrQ0008364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Oct 2008 01:45:53 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9G8jqqx015024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Oct 2008 01:45:53 -0700
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.78]) by nasanexhc03.na.qualcomm.com ([172.30.33.34]) with mapi; Thu, 16 Oct 2008 01:45:52 -0700
From: "Das, Saumitra" <saumitra@qualcomm.com>
To: "p2pi@ietf.org" <p2pi@ietf.org>
Date: Thu, 16 Oct 2008 01:45:50 -0700
Thread-Topic: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackva5czBEUA6wFMRt+cB2Kq3sElUw==
Message-ID: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D20307C9@NASANEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Citing one of the responses from Vijay on Oct 13 "For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are.  However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from."

I agree ALTO does not determine content location but given a set of content locations by an application would provide a ranked order of "good" peers to download this from. However, a fundamental issue to consider is that simply using ISP information is not enough for a querying peer to determine wisely what to do. Unless there is a performance perspective to the goodness of peers, is there a real incentive for applications to adopt looking up ALTO since they anyway need to do a bunch of performance measurements. Applications typically may be happy simply saturating download bandwidth and not much else. Providing more information in ALTO could be a path to incentivising the users of the service. What this more information is should be up for debate.

We should also consider the more general question of when we are designing something for peer selection we are only designing a small piece of an information plane for the Internet. In this context, it may be useful to have information that can be aggregated across various applications and simply because specific BitTorrent clients may implement some such mechanisms does not mean that is a good design choice to leave it out of ALTO. An information plane (see the U Wash IPlane paper) of some kind may be something to consider given that we seem to solving only one part of the puzzle. Instead of each application building their own proprietary and application-specific information plane which is redundant and wasteful, such an information plane could potentially be something ALTO provides and can be reused across a wide range of services.

Thanks,
Saumitra Das
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

v2.23.0 | Report a Bug | By Email