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 protected] [mailto:[email protected]] On Behalf Of alto 
issue tracker
Sent: Wednesday, February 17, 2010 5:14 AM
To: [email protected]; [email protected]
Cc: [email protected]
Subject: [alto] #4: Provisioned bandwidth

#4: Provisioned bandwidth
---------------------------------------------+------------------------------
 Reporter:  enrico.maro...@…                 |       Owner:  Sebastian Kiesel 
<ietf-a...@…>         
     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 protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to