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

"Songhaibin (A)" <haibin.song@huawei.com> Sun, 29 June 2014 01:29 UTC

Return-Path: <haibin.song@huawei.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 266CA1A01E8 for <alto@ietfa.amsl.com>; Sat, 28 Jun 2014 18:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 YoOnIJOF-tE8 for <alto@ietfa.amsl.com>; Sat, 28 Jun 2014 18:29:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858D31A01E6 for <alto@ietf.org>; Sat, 28 Jun 2014 18:29:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGP13558; Sun, 29 Jun 2014 01:29:16 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 29 Jun 2014 02:29:14 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sun, 29 Jun 2014 09:29:12 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "Vijay K. Gurbani" <vkg@bell-labs.com>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
Thread-Index: Ac+RJTazVMjh2LvzQcGqxQ7WMlmuvQAALOvAADEBmYAAADpqgAAq4ASQ///czAD//pofUA==
Date: Sun, 29 Jun 2014 01:29:11 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F6511860A@nkgeml501-mbs.china.huawei.com>
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>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.26.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/alto/um5ohyHpmh9q_01MN2dUp5Lf-Xw
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: Sun, 29 Jun 2014 01:29:22 -0000

Hi Reinaldo,

Right. This kind of configured fixed bandwidth cap is useful, and we could also collect that information as an Endpoint property. 

Configuration can be in several different ways. When an endpoint sets its percentage of bandwidth for this particular application, in this case, the bandwidth is dynamic, due to in peak hours, the ISP may not guarantee bandwidth for the subscribers (at least it is true for the ISPs in China, during the evening hours). And an endpoint can also configure one type of application with having higher priority than other types, for example, web browsing has priority over p2p. In this case, the available bandwidth is also dynamic for p2p.

BR,
-Haibin

-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] 
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.

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