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

["Y. Richard Yang" <[e-mail]>]

On Sun, Jun 29, 2014 at 10:27 PM, 邓灵莉/Lingli Deng <
[e-mail]> wrote:

>
>
> > -----Original Message-----
> > From: alto [mailto:[e-mail]] On Behalf Of Reinaldo Penno
> > (repenno)
> > Sent: Saturday, June 28, 2014 7:55 PM
> > To: Songhaibin (A); Vijay K. Gurbani; [e-mail]
> > 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?
>
>
It makes sense to me. The draft should make it clear that it is configured
cap by the network, which is an upper bound, and can be lowered by others.
As an example use case, suppose ALTO provides the bound. Then a utorrent+
may configure the cap to be, say 60%, of the network cap.

Richard


> > A utorrent client will never use more than that amount of bandwidth, no
> > matter your provisioned bandwidth.
> >
> > ________________________________________
> > From: Songhaibin (A) [[e-mail]]
> > Sent: Friday, June 27, 2014 11:09 PM
> > To: Reinaldo Penno (repenno); Vijay K. Gurbani; [e-mail]
> > 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:[e-mail]] On Behalf Of Reinaldo Penno
> > > (repenno)
> > > Sent: Saturday, June 28, 2014 1:33 AM
> > > To: Vijay K. Gurbani; [e-mail]
> > > 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" <[e-mail]> 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} / [e-mail]
> > > >Web: http://ect.bell-labs.com/who/vkg/  | Calendar:
> http://goo.gl/x3Ogq
>