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

"Narayanan, Vidya" <vidyan@qualcomm.com> Fri, 24 October 2008 01:46 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 B81853A6AF4; Thu, 23 Oct 2008 18:46:33 -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 435383A6AC5; Thu, 23 Oct 2008 18:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.293
X-Spam-Level:
X-Spam-Status: No, score=-105.293 tagged_above=-999 required=5 tests=[AWL=1.306, 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 qiv3ye3u3K4v; Thu, 23 Oct 2008 18:46:31 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1A56B3A67A3; Thu, 23 Oct 2008 18:46:31 -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=1224812871; x=1256348871; 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: =20Yu-Shun=20Wang=20<Yu-Shun.Wang@microsoft.com>,=20IESG =20IESG=20<iesg@ietf.org>|CC:=20"p2pi@ietf.org"=20<p2pi@i etf.org>,=20"ietf@ietf.org"=20<ietf@ietf.org>|Date:=20Thu ,=2023=20Oct=202008=2018:47:43=20-0700|Subject:=20RE:=20[ p2pi]=20WG=20Review:=20Application-Layer=20Traffic=20Opti mization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review: =20Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFf NfAAFNViIA=3D=3D|Message-ID:=20<BE82361A0E26874DBC2ED1BA2 44866B9284E791E@NALASEXMB08.na.qualcomm.com>|References: =20<20081006203532.B1D673A68AF@core3.amsl.com>=0D=0A=20<B E82361A0E26874DBC2ED1BA244866B9284E7855@NALASEXMB08.na.qu alcomm.com>=0D=0A=20<43AEA9A9F7768B42A89F554F0EBF7ED82D17 8EC446@NA-EXMSG-C102.redmond.corp.microsoft.com> |In-Reply-To:=20<43AEA9A9F7768B42A89F554F0EBF7ED82D178EC4 46@NA-EXMSG-C102.redmond.corp.microsoft.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,5413"=3B=20a=3D"11347675"; bh=F9Pfl0YYEc6u5SzeqBug4xk1Qxrzb6aSKdjw3wyqPTM=; b=SAIa2abhK9zOdFG9pRMCCqdZF6x6zWvI+PM2LP50l+BhjYLEjH/uo9Ah sNoLS48uQnoRht5ZSfaVB6O9E0QsApvAWKtodOugKTv9ymcb2ZFY9Wh9w lk3M4mmD5WHTPAUjh72q+QfPhEH8xN38yQLSQEblGo6jznFIQmy9OfLdq o=;
X-IronPort-AV: E=McAfee;i="5300,2777,5413"; a="11347675"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2008 18:47:50 -0700
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9O1loL7015868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 18:47:50 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9O1looB011779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Oct 2008 18:47:50 -0700
Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 18:47:49 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 23 Oct 2008 18:47:49 -0700
Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 23 Oct 2008 18:47:49 -0700
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: Yu-Shun Wang <Yu-Shun.Wang@microsoft.com>, IESG IESG <iesg@ietf.org>
Date: Thu, 23 Oct 2008 18:47:43 -0700
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfAAFNViIA==
Message-ID: <BE82361A0E26874DBC2ED1BA244866B9284E791E@NALASEXMB08.na.qualcomm.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9284E7855@NALASEXMB08.na.qualcomm.com> <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.com>
In-Reply-To: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446@NA-EXMSG-C102.redmond.corp.microsoft.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@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

Hi Yushun, 

<snip>

> >
> > Add: "Peer selection is also a problem that has many different 
> > applications in p2p systems - e.g., identifying the best peer to 
> > download content from, identifying the best super peer to 
> contact in a 
> > system, using the best relay for NAT traversal, identifying 
> the best 
> > next hop for a query based on several criteria (e.g., quality, 
> > reputation, semantic expertise, etc.), etc."
> 
> I actually think the proposed addition is somewhat redundant, 
> and could easily lead into ratholes on what are the metrics 
> for "best" and whether it is even possible to get the best. 
> The current charter tries to avoid that by saying 
> "better-than- random" selection gating mostly on getting 
> better performance and lowering the costs (as two examples). 
> Also, what's the "best" depends heavily on whom you ask. 
> ISP's notions of "best"
> may not align with those of the end users.
> 
> I am fine with the examples (targets for selections), but 
> let's try to avoid the debates on "best" again.
> 

I'm fine with that.  I agree that "best" is a relative word and causes confusion at best :) 

<snip>

> 
> > > Other usages will be considered as extensions to the charter once 
> > > the work for the initial services has been completed.
> >
> > I think we should delete the sentence above.
> 
> While it may seem redundant, I don't see anything wrong with 
> that. It just means we may have a narrow scope now, but we 
> will think about new extensions once we are done.
> 

I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG.  

<snip>

> 
> I read the list below somewhat differently. These are not for 
> relative importance of the information, but kind of a min bar 
> for what we want to do. While some may need re-wording, the 
> intent is fine, IMO.
> 

I'm not so sure.  Basically, it is a question of what usage these are evaluated based on.  Let's take a couple of examples.  Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset.  But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information.  Similarly, whether some information is useful to a client is totally contextual to the application as well. 

> > > - Can the ALTO service technically provide that information?
> > > - Is the ALTO service willing to obtain and divulge that 
> information?
> > > - Is it information that a client will find useful?
> > > - Can a client get that information without excessive privacy
> > >   concerns(e.g. by sending large lists of peers)?
> > > - Is it information that a client cannot find easily some 
> other way?
> > >
> > > After these criteria are met, the generality of the data will be 
> > > considered for prioritizing standardization work, for example the 
> > > number of operators and clients that are likely to be able to 
> > > provide or use that particular data.
> >
> > The above again gets into our evaluation of what is 
> important based on 
> > what we know today and is limiting.
> 
> This point does need some clarification and rewording.
> 
> Thanks,
> yushun
> 
> 
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi