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 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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
