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:repe...@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.s...@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-boun...@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" <v...@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.gurb...@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