IETF Logo Mail Archive

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

"Narayanan, Vidya" <vidyan@qualcomm.com> Fri, 10 October 2008 20:22 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 C7D1B3A69C3; Fri, 10 Oct 2008 13:22:13 -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 D3F533A69C3; Fri, 10 Oct 2008 13:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.71
X-Spam-Level:
X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, 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 PLF+cdcswpt6; Fri, 10 Oct 2008 13:22:10 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B6DB13A691F; Fri, 10 Oct 2008 13:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223670178; x=1255206178; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to: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"Narayanan,=20Vidya"=20<vidyan@qualcomm.com>|To: =20Marshall=20Eubanks=20<tme@multicasttech.com>,=20"iesg@ ietf.org"=20<iesg@ietf.org>|CC:=20"p2pi@ietf.org"=20<p2pi @ietf.org>,=20IETF=20Discussion=20<ietf@ietf.org>|Date: =20Fri,=2010=20Oct=202008=2013:22:53=20-0700|Subject:=20R E:=20[p2pi]=20WG=20Review:=20Application-Layer=20Traffic =20Optimization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Re view:=20Application-Layer=20Traffic=20Optimization=20(alt o)|Thread-Index:=20Ackq0DfXnzmU9Ls6RN+pW3hXEk6yDgAQ/KMA |Message-ID:=20<BE82361A0E26874DBC2ED1BA244866B927637480@ NALASEXMB08.na.qualcomm.com>|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=20<C27FC19F-A2AC-46D2 -97F8-E45FF54FB377@multicasttech.com>|In-Reply-To:=20<C27 FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10541314"; bh=BLrlP/j3PuE4eaiYuJW+SAfECP79WEHA5CeZB36YOq4=; b=ryDUl6vrhTTv6z4q/EL82PwQN81YSqmLV4cskH+AZ7l7b6DayG/Hu+kv tM1Cs85C+2iMOKIMl9OefkgMaJ7VSVwcj1A3129UaAY3/B5ssdvcrbEgf 2lhdY+bdC1M5LD1oaYPnhYd+8VHHUR/z08wm88SJwIX5H55kW15DJp7p3 4=;
X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10541314"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2008 13:22:56 -0700
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKMtP0030602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Oct 2008 13:22:56 -0700
Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9AKMtx9020248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Oct 2008 13:22:55 -0700
Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 13:22:55 -0700
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 13:22:54 -0700
Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 10 Oct 2008 13:22:54 -0700
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: Marshall Eubanks <tme@multicasttech.com>, "iesg@ietf.org" <iesg@ietf.org>
Date: Fri, 10 Oct 2008 13:22:53 -0700
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackq0DfXnzmU9Ls6RN+pW3hXEk6yDgAQ/KMA
Message-ID: <BE82361A0E26874DBC2ED1BA244866B927637480@NALASEXMB08.na.qualcomm.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
In-Reply-To: <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.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: "p2pi@ietf.org" <p2pi@ietf.org>, IETF Discussion <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

Marshall makes some excellent points.  Some additional thoughts on a few of his observations.

<snip>

>
> Some comments in the charter below. This document clearly
> needs some more work. As a overall comment, I think it is
> premature to discuss ALTO "servers" and would keep the
> charter focused on describing the ALTO "service." I do not
> see consensus at this moment as to a central service solution
> versus a distributed solution.
>

I fully agree.  And, I see some discussions almost collapsing the two saying that eventually, there is a "server" that an ALTO client is talking to.  That is incorrect in a distributed system and pre-supposing that will get us on the wrong solution path with a narrow view.

<snip>

>
> >
> > - Is the ALTO service willing to obtain and divulge that
> information?
>
> Do computers have free will ?
>
> More seriously, it seems very odd to assume that a P2P
> service will not do something that the owners of the peers
> want it to do. In my opinion that drives P2P adoption much
> more than the efficiencies of bandwidth sharing.
>

Absolutely!  This also goes back to some of the responses on sharing uplink/downlink bandwidth information having privacy issues.  If a peer is willing to share a piece of information, that makes that information viable to be shared.  Building distributed systems within the confines of what may administratively be the best types of information to share doesn't automatically produce the best systems.

<snip>

>
> Does this mean that congestion is not an issue to consider ?
>
> If the closest peer to me was totally congested and had no
> available bandwidth, isn't that something that I would want to know ?
>

I do think this type of information is needed, but, I suspect ALTO is not the place for this.  Peers may do measurement-based selection that eventually decides the best ranking of peers and the input from the ALTO service may just be one data point.

Regards,
Vidya
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

v2.23.0 | Report a Bug | By Email