Subject: Re: [alto] Comments on provisioned bandwidth and ALTO

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 03:52:25 -0400

I agree with you on those two cases. The privacy issues I raised are about third party requests for information.

-- Rich

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Woundy, Richard
Cc: [email-masked] <[email-masked]>
Sent: Thu Mar 18 03:18:11 2010
Subject: Re: [alto] Comments on provisioned bandwidth and ALTO

As you point out, allowing third party to query ALTO servers to determine 
the provisioned bandwidth of *any user* has privacy implications.

However, the same privacy implications do not apply if a user wants to 
query the provisioned bandwidth of the broadband connection it purchased.
There could be access limitations, however. For example, a user 
that is connected to Starbucks WiFi is likely to be limited from querying 
the connection bandwidth.

Also, an application may want to query its gateway or cable modem to 
determine the current load at the modem. Such a mechanism does not require 
querying any ISP managed ALTO server.

It will be helpful to clarify these two issues.

Salman

On Thu, 18 Mar 2010, Woundy, Richard wrote:

> Folks,
>
> I had provided some offline comments about the inclusion of provisioned bandwidth in ALTO. Enrico asked me to re-send them to the mailing list. I can also discuss in next week's ALTO session.
>
> Here are my privacy concerns.
>
> 1. Depending on the ISP's pricing and rollout of bandwidth tiers, there may be relatively few subscribers within a particular tier. Therefore a third party consuming ALTO provisioned bandwidth information can make a good guess about the identity of a subscriber within a "rarely used" bandwidth tier.
>
> 2. Separately, a third party consuming ALTO provisioned bandwidth information may be able to make an informed guess about the economic status of a subscriber based on the bandwidth tier, which may not be desirable to the subscriber.
>
> 3. The subscriber may not intend to use *all* provisioned bandwidth for a particular application (e.g. P2P). For example, perhaps the subscriber intends to use provisioned uplink bandwidth for telecommuting, telepresence, online storage backups, etc. A third party consuming ALTO provisioned bandwidth information should be aware that the subscriber's provisioned bandwidth may be reserved for different applications.
>
> Here are my thoughts on dynamic address re-allocation.
>
> ISPs reallocate IPv4 subnets within their infrastructure from time to time, partly to ensure the efficient usage of IPv4 addresses (a scarce resource), and partly to enable efficient route tables within their network routers. The frequency of these "renumbering events" depend on the growth in number of subscribers and the availability of address space within the ISP. As a result, a subscriber's household device could retain an IPv4 address for as short as a few minutes, or for months at a time or even longer.
>
> Some folks have suggested that ISPs providing ALTO services could sub-divide their subscribers' devices into different IPv4 subnets (or certain IPv4 address ranges) based on the purchased service tier, as well as based on the location in the network topology. The problem is that this sub-allocation of IPv4 subnets tends to decrease the efficiency of IPv4 address allocation. A growing ISP that needs to maintain high efficiency of IPv4 address utilization may be reluctant to jeopardize their future acquisition of IPv4 address space.
>
> Therefore, consumers of per-user ALTO information should assume that subscribers retain IPv4 addresses for only a relatively short period of time, e.g. minutes, and that subscribers of different service tiers will co-exist in some ISP's IPv4 subnets.
>
> -- Rich
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of alto issue tracker
> Sent: Wednesday, February 17, 2010 5:14 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [alto] #4: Provisioned bandwidth
>
> #4: Provisioned bandwidth
> ---------------------------------------------+------------------------------
> Reporter:  enrico.marocco@…                 |       Owner:  Sebastian Kiesel <ietf-alto@…>
>     Type:  enhancement                      |      Status:  new
> Priority:  major                            |   Milestone:
> Component:  reqs                             |     Version:
> Severity:  -                                |    Keywords:
> ---------------------------------------------+------------------------------
> The document should track (and ideally stimulate discussion to reach
> consensus) the arguments about providing information about provisioned
> bandwidth, as it may have non trivial impact on the protocol design. The
> topic was discussed in [wiki:Ietf76 Hiroshima] and previously on the
> mailing list:
> [http://www.ietf.org/mail-archive/web/alto/current/msg00322.html]
> [http://www.ietf.org/mail-archive/web/alto/current/msg00476.html]
>
> --
> Ticket URL: <https://svn.tools.ietf.org/wg/alto/trac/ticket/4>
> alto <http://tools.ietf.org/alto/>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 08:47:37 -0400

>Why should I wait for ALTO if I can do this with reasonable effort by today with today's means?

It is true that you can use a geo-IP mapping database to guess the rough location of a user. But I have found (by looking at ads served to me) that sometimes the database is off by a municipality or two.

My point is, this parameter *might* help a third party figure out who has the highest disposable income within a particular neighborhood.

>You may also get much better data if you get access to some consumer rating agency's database.

As a third party (not the user or ISP), how would you make use of that database? Wouldn't it be indexed by name/personal identity and/or home address? That information seems to be outside the context of regular Internet traffic or ALTO - except for phishing scams and naïve users. :(

>I see the point you are making, but I would opt for including the possibility to query to provisioned bandwidth in the ALTO protocol, but leave it to the discretion of the ISP deploying the service to enable this or not. Including documenting the privacy risks if enabled.

I agree with you here: that is, allow provisioned bandwidth, make it optional, and document the privacy risks.

I understand your use case as well.

-- Rich

----- Original Message -----
From: Martin Stiemerling <[email-masked]>
To: Woundy, Richard; [email-masked] <[email-masked]>
Sent: Thu Mar 18 06:01:45 2010
Subject: RE: [alto] Comments on provisioned bandwidth and ALTO

Hi Rich, 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Woundy, Richard
> Sent: Thursday, March 18, 2010 7:42 AM
> To: [email-masked]
> Subject: [alto] Comments on provisioned bandwidth and ALTO
> 
> Folks,
> 
> I had provided some offline comments about the inclusion of provisioned
> bandwidth in ALTO. Enrico asked me to re-send them to the mailing list.
> I can also discuss in next week's ALTO session.
> 
> 1. Depending on the ISP's pricing and rollout of bandwidth tiers, there
> may be relatively few subscribers within a particular tier. Therefore a
> third party consuming ALTO provisioned bandwidth information can make a
> good guess about the identity of a subscriber within a "rarely used"
> bandwidth tier.
> 
> 2. Separately, a third party consuming ALTO provisioned bandwidth
> information may be able to make an informed guess about the economic
> status of a subscriber based on the bandwidth tier, which may not be
> desirable to the subscriber.

Why should I wait for ALTO if I can do this with reasonable effort by today with today's means?

You can use the geo information provided for a particular IP address out of the whois and combine this with some other available data (google maps/street view) to see if people are living in wealthy area or not. Try this with the IP addresses indicated for this email as smtp sender...( 195.37.70.41). Unfortunately, there is no street view for this location, but in other places this will help even better to determine if the residents are wealthy or not. ;)

http://maps.google.com/maps?q=49.405839,8.684582&num=1&t=h&sll=49.409988,8.699925&sspn=0.006295,0.006295&ie=UTF8&ll=49.406129,8.685808&spn=0.006828,0.012746&z=16&iwloc=A

You may also get much better data if you get access to some consumer rating agency's database. At least in Germany they can tell in most areas house by house the income to be expected. Used by direct marketing...

I see the point you are making, but I would opt for including the possibility to query to provisioned bandwidth in the ALTO protocol, but leave it to the discretion of the ISP deploying the service to enable this or not. Including documenting the privacy risks if enabled. 

My use case for this:
The provisioned bandwidth may be used by p2p streaming systems to rule out peers that will anyway not help in streaming (e.g., an peer with 128kbit/s uplink intended to serve full HDTV streams).

> 
> 3. The subscriber may not intend to use *all* provisioned bandwidth for
> a particular application (e.g. P2P). For example, perhaps the
> subscriber intends to use provisioned uplink bandwidth for
> telecommuting, telepresence, online storage backups, etc. A third party
> consuming ALTO provisioned bandwidth information should be aware that
> the subscriber's provisioned bandwidth may be reserved for different
> applications.

True, this should be documented as an issue, but as said above this is helpful in ruling out peers anyway not useful. Second, the actual usable bandwidth needs to be tested in the following operational steps of the p2p system anyway. 

> ISPs reallocate IPv4 subnets within their infrastructure from time to
> time, partly to ensure the efficient usage of IPv4 addresses (a scarce
> resource), and partly to enable efficient route tables within their
> network routers. The frequency of these "renumbering events" depend on
> the growth in number of subscribers and the availability of address
> space within the ISP. As a result, a subscriber's household device
> could retain an IPv4 address for as short as a few minutes, or for
> months at a time or even longer.
> 
> Some folks have suggested that ISPs providing ALTO services could sub-
> divide their subscribers' devices into different IPv4 subnets (or
> certain IPv4 address ranges) based on the purchased service tier, as
> well as based on the location in the network topology. The problem is
> that this sub-allocation of IPv4 subnets tends to decrease the
> efficiency of IPv4 address allocation. A growing ISP that needs to
> maintain high efficiency of IPv4 address utilization may be reluctant
> to jeopardize their future acquisition of IPv4 address space.
> 
> Therefore, consumers of per-user ALTO information should assume that
> subscribers retain IPv4 addresses for only a relatively short period of
> time, e.g. minutes, and that subscribers of different service tiers
> will co-exist in some ISP's IPv4 subnets.

I will reply to this in a separate email.

Thanks,

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 19:43:04 -0400

>The ALTO reqs draft already says:

Oops I should have known that. :(

----- Original Message -----
From: Sebastian Kiesel <[email-masked]>
To: Woundy, Richard
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 18 19:19:52 2010
Subject: Re: [alto] Comments on provisioned bandwidth and ALTO

On Thu, Mar 18, 2010 at 06:54:13PM -0400, Woundy, Richard wrote:
> How about:
> 
> (Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) 

better. :) though getting BW info for all peers might be unrealistic

> Or here's a totally different idea. The client states a bandwidth
> floor and the server/service eliminates peers without at least that
> much provisioned bandwidth??? 

The ALTO reqs draft already says:

5.3.  Performance-related rating criteria

   o  The minimum achievable throughput between the resource consumer
      and the candidate resource provider, which is considered useful by
      the application (only in ALTO queries), or

   o  An arbitrary upper bound for the throughput from/to the candidate
      resource provider (only in ALTO replies).  This may be, but is not
      necessarily the provisioned access bandwidth of the candidate
      resource provider.
...

   The ALTO client MUST be aware, that with high probability, the actual
   performance values differ significantly from these upper and lower
   bounds.  In particular, an ALTO client MUST NOT consider the "upper
   bound for throughput" parameter as a permission to send data at the
   indicated rate without using congestion control mechanisms.

...

   Nevertheless, these rating
   criteria may provide a useful shortcut for quickly excluding
   candidate resource providers from such probing, if it is known in
   advance that connectivity is in any case worse than what is
   considered the minimum useful value by the respective application.

-- Sebastian