Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

邓灵莉/Lingli Deng <denglingli@chinamobile.com> Mon, 30 June 2014 02:27 UTC

Return-Path: <denglingli@chinamobile.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F106A1A00D7 for <alto@ietfa.amsl.com>; Sun, 29 Jun 2014 19:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.67
X-Spam-Level: **
X-Spam-Status: No, score=2.67 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p2XW-DUrC0x for <alto@ietfa.amsl.com>; Sun, 29 Jun 2014 19:27:10 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 3DE7D1A00C9 for <alto@ietf.org>; Sun, 29 Jun 2014 19:27:09 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee353b0cafb9aa-2b9aa; Mon, 30 Jun 2014 10:27:07 +0800 (CST)
X-RM-TRANSID: 2ee353b0cafb9aa-2b9aa
Received: from cmccPC (unknown[10.2.43.183]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea53b0caf72bb-d4345; Mon, 30 Jun 2014 10:27:07 +0800 (CST)
X-RM-TRANSID: 2eea53b0caf72bb-d4345
From: 邓灵莉/Lingli Deng <denglingli@chinamobile.com>
To: "'Reinaldo Penno (repenno)'" <repenno@cisco.com>, "'Songhaibin (A)'" <haibin.song@huawei.com>, "'Vijay K. Gurbani'" <vkg@bell-labs.com>, alto@ietf.org
References: <53ADA961.80206@bell-labs.com> <CFD2F7F5.CAD0%repenno@cisco.com>, <E33E01DFD5BEA24B9F3F18671078951F65117498@nkgeml501-mbs.china.huawei.com> <45A697A8FFD7CF48BCF2BE7E106F06040BE434A6@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040BE434A6@xmb-rcd-x04.cisco.com>
Date: Mon, 30 Jun 2014 10:27:09 +0800
Message-ID: <00b701cf940a$cb5edf90$621c9eb0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPkiz+UneLYxSpbEKUwFBAz6/OR5uFFfgAgAFIfwCAAAw/R4AChQvg
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/alto/rgZBzU6I6qXdfP3eIS9PLvzwOs8
Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 02:27:13 -0000


> -----Original Message-----
> From: alto [mailto:alto-bounces@ietf.org] On Behalf Of Reinaldo Penno
> (repenno)
> Sent: Saturday, June 28, 2014 7:55 PM
> To: Songhaibin (A); Vijay K. Gurbani; alto@ietf.org
> Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> 
> I'm not talking about on-demand "available" bandwidth,
> 
> It is the bandwidth configured in the application. It is a configured value. Just
> take a look at any utorrent client.
[邓灵莉/Lingli Deng] I am a little bit confused here. If the cap is configured in the app, then why would the app's tracker bother to query a ALTO server for this value?
It seems to me that ALTO should be providing more general information that would assist a group of applications, rather than a single one. Make sense?
> 
> A utorrent client will never use more than that amount of bandwidth, no
> matter your provisioned bandwidth.
> 
> 
> ________________________________________
> From: Songhaibin (A) [haibin.song@huawei.com]
> Sent: Friday, June 27, 2014 11:09 PM
> To: Reinaldo Penno (repenno); Vijay K. Gurbani; alto@ietf.org
> Subject: RE: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> 
> Hi Reinaldo,
> 
> Thank you and I think you raised a very good question. I totally agree that
> available bandwidth is more useful than provisioned bandwidth. But available
> bandwidth is rather dynamic, and it is very hard to measure it and provide the
> real-time status to ALTO clients.
> 
> With providing provisioned bandwidth, it can be seen with a high probability a
> client can select a "better" peer. It is better than random IMO. But if there is
> an easy method to rank the available bandwidth of a peer list, I will be very
> interested.
> 
> BR,
> -Haibin
> 
> > -----Original Message-----
> > From: alto [mailto:alto-bounces@ietf.org] On Behalf Of Reinaldo Penno
> > (repenno)
> > Sent: Saturday, June 28, 2014 1:33 AM
> > To: Vijay K. Gurbani; alto@ietf.org
> > Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> >
> > Another point is how¹s the provisioned access bandwidth really help decide
> > which peers are better. Today most P2P software allow caps to be put for
> > upload/download and people use it. Some come with a default based on the %
> > of the detect access speed. So, saying a user has 1Gb/s does not really mean
> > you will get better performance when connecting to him(er). I mean, it would
> > more inline with better than random to get the actual bandwidth allowed.
> >
> >
> > On 6/27/14, 10:26 AM, "Vijay K. Gurbani" <vkg@bell-labs.com> wrote:
> >
> > >[Still as individual.]
> > >
> > >On 06/26/2014 05:10 AM, Songhaibin (A) wrote:
> > >> Sebastian gave an idea that we can use relative numbers to indicate
> > >> the endpoint's provisioned bandwidth instead of access type, which is
> > >> similar to what we have used to indicate the cost in the alto
> > >> protocol.
> > >
> > >The difference, of course, being that the ISP in some manner consented
> > >to having a normalized value of cost to be distributed in order to
> > >allow for better than random selections to improve network performance.
> > >
> > >In the case under discussion, the issue is does the subscriber consent
> > >to having their provisioned bandwidth be part of ALTO calculations?
> > >
> > >Remember, if the WG decides to go ahead and use provisioned bandwidth
> > >anyway, it could always do so.  But then we'd better be prepared to
> > >deal with the eventuality on when (and if) the IESG challenges us on
> > >this privacy leak.  If that happens, we'd better have a good response.
> > >
> > >Perhaps a midway could be to see if we can use the provisioned
> > >bandwidth for a set of (anonymous) subscribers instead of singleton
> > subscribers.
> > >That way, the larger herd provides some modicum of anonymity to an
> > >individual subscriber who is part of the herd.
> > >
> > >Cheers,
> > >
> > >- vijay
> > >--
> > >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> > >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> > >Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> > >
> > >_______________________________________________
> > >alto mailing list
> > >alto@ietf.org
> > >https://www.ietf.org/mailman/listinfo/alto
> >
> > _______________________________________________
> > alto mailing list
> > alto@ietf.org
> > https://www.ietf.org/mailman/listinfo/alto
> 
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto