Subject: Re: [p2pi] Information in an ALTO protocol

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 9 Sep 2008 10:38:06 -0400

>> So at least we should discuss whether a user opt-in or opt-out mechanism should be required for user-specific data like this.

> IMHO, that is best left for ISPs and customers to work out themselves.

John,

Since I think this is ultimately a user privacy issue, I really, REALLY think that "letting the ISPs and customers work it out" is a bad idea.

I'm not saying that the IETF should jump into a policy debate. I AM saying that, if we are going to invent a new protocol here, at least there should be a serious 'threat analysis' discussion about the impact to user privacy.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Leslie
Sent: Thursday, August 28, 2008 8:13 PM
To: Woundy, Richard
Cc: [email-masked]
Subject: Re: [p2pi] Information in an ALTO protocol

Woundy, Richard <[email-masked]> wrote:
>
>>> Hmmm ... so I suspect that it is premature to say that last-hop
>>> bandwidth is out of scope?  What do others think?
>
>> For myself, I think we'd be silly to rule it out-of-scope because we
>> don't believe ISPs would agree to provide it. _Any_ question we ask an
>> ISP may well receive a "none-of-your-business" reply.
>
> I might be OK with leaving this in scope. I stated two potential ISP
> issues in a previous email: the marketing concern (the ISP may be
> revealing its mix of regular versus premium customers to competitors)

   This is certainly possible (in which case they won't answer, or will
answer with "noisy" data); but I don't think it would actually reveal
anything terribly useful.

> and traffic concentration concern (traffic may be drawn to fewer ISP
> links with premium customers).

   I would hope that congestion would be noticed before this becomes
a problem.

> My bigger concern, however, is the user privacy concern, about the ISP
> revealing to the general public about its premium/regular/economy
> customers. I agree that in many cases that this information may be
> actively measured, but that would seem to require at least some
> complicity by the end user (e.g. the end user's host needs to respond to
> the measurement traffic).

   Customers could legitimately object to this information being revealed.

> So at least we should discuss whether a user opt-in or opt-out mechanism
> should be required for user-specific data like this.

   IMHO, that is best left for ISPs and customers to work out themselves.

--
John Leslie <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 9 Sep 2008 10:41:35 -0400

>> and traffic concentration concern (traffic may be drawn to fewer ISP links with premium customers).

> I would hope that congestion would be noticed before this becomes a problem.

Let me describe two edge cases to illustrate my concerns. Then, let me describe one potential ALTO solution, and one potential non-ALTO solution.

First, let's imagine an ISP that does not oversubscribe its broadband access network, so ISP network congestion isn't an issue. This ISP hosts an ALTO server that supplies its users' bandwidths. Further suppose, as an extreme illustration, that this ISP has one premium customer with 10 Mbps upstream, and lots of standard customers with 1 Mbps upstream. Wouldn't a typical application instance in the Internet want to leverage this premium customer, in preference to any of the other customers? And wouldn't that tend to funnel much more application traffic to the network link of this premium user? And maybe that concentration of application traffic is not in the best interests of the premium customer? Maybe this would be another disincentive (besides highere monthly subscription fees) to being a premium customer?

Second, suppose there are two large ISPs of roughly the same size. Suppose that ISP A provides customers with 10 Mbps upstream bandwidth, and ISP B provides customers with 11 Mbps upstream bandwidth. Also assume that ISP B has made a proportionally greater investment in its network (110%) than ISP A to support the 11 Mbps upstream. Both ISPs host ALTO servers that supply their respective users' bandwidths. If the typical application instance merely compares the user bandwidth of an ISP A customer and an ISP B customer, it would choose the 11 Mbps of the ISP B customer. If applications consistently chose ISP B customers over ISP A customers, that might double ISP B's application traffic and reduce ISP A's application traffic to zero. So ISP B's greater investment in its infrastructure, and its transparency in its ALTO service, is rewarded with far more application traffic (200%) than its incremental investment (110%) justifies.

Having said this, there are solutions to these problems. One straightforward solution is for the ALTO client to make a peer selection in a randomized way, where the user bandwidth is another bias. For example, all other things being equal between an ISP A customer and an ISP B customer, maybe the ISP B customer is chosen 52.4% of the time, and the ISP A customer is chosen 47.6% of the time, by a conforming ALTO client. That is, the likelihood of choosing an ISP B customer is 10% higher than choosing an ISP A customer.

But my preferred (non-ALTO) solution would be to have a simple access protocol to obtain the available access bandwidth directly from the end host. Here is my rationale:

- The customer always controls whether any bandwidth information is shared at all, and more importantly, with whom the information is shared. Thus, there is no question about ISPs or third parties sharing this information without the customer's permission.

- The real value reported by this mechanism can be redefined to be "how much of the customer's provisioned access bandwidth does the customer allow you to use". As a customer, for example, I can choose to share proportionally more bandwidth within my circle of friends than with strangers. I can choose to share all of my bandwidth, or maybe to share only some of my bandwidth because I anticipate needing some of my bandwidth in the future. These preferences may be difficult to convey to the ISP or to a third party.

The mechanism ought to allow for easy query by the application. If the application can obtain this value fairly quickly, it can be used for the interim selection of peers, prior to the application attempting to measure available bandwidth by probing. Maybe this value could be communicated as part of the initial transport exchange envisioned by the TANA group?

-- Rich

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 09 Sep 2008 09:00:36 -0700

Hello,

Few comments inline..

On 9/9/08 7:41 AM, "Woundy, Richard" <[email-masked]>
wrote:

> Let me describe two edge cases to illustrate my concerns. Then, let me
> describe one potential ALTO solution, and one potential non-ALTO solution.
> 
> First, let's imagine an ISP that does not oversubscribe its broadband access
> network, so ISP network congestion isn't an issue. This ISP hosts an ALTO
> server that supplies its users' bandwidths. Further suppose, as an extreme
> illustration, that this ISP has one premium customer with 10 Mbps upstream,
> and lots of standard customers with 1 Mbps upstream. Wouldn't a typical
> application instance in the Internet want to leverage this premium customer,
> in preference to any of the other customers? And wouldn't that tend to funnel
> much more application traffic to the network link of this premium user? And
> maybe that concentration of application traffic is not in the best interests
> of the premium customer? Maybe this would be another disincentive (besides
> highere monthly subscription fees) to being a premium customer?
> 
> Second, suppose there are two large ISPs of roughly the same size. Suppose
> that ISP A provides customers with 10 Mbps upstream bandwidth, and ISP B
> provides customers with 11 Mbps upstream bandwidth. Also assume that ISP B has
> made a proportionally greater investment in its network (110%) than ISP A to
> support the 11 Mbps upstream. Both ISPs host ALTO servers that supply their
> respective users' bandwidths. If the typical application instance merely
> compares the user bandwidth of an ISP A customer and an ISP B customer, it
> would choose the 11 Mbps of the ISP B customer. If applications consistently
> chose ISP B customers over ISP A customers, that might double ISP B's
> application traffic and reduce ISP A's application traffic to zero. So ISP B's
> greater investment in its infrastructure, and its transparency in its ALTO
> service, is rewarded with far more application traffic (200%) than its
> incremental investment (110%) justifies.

It seems ISP A is still using the same bandwidth as before since all clients
in it needs to download the whole file. The difference is that all those
bits are coming from Inter-domain links. Maybe I am missing something here?
Or maybe you mean ISP A's intra-domain traffic goes almost to zero.

> 
> Having said this, there are solutions to these problems. One straightforward
> solution is for the ALTO client to make a peer selection in a randomized way,
> where the user bandwidth is another bias. For example, all other things being
> equal between an ISP A customer and an ISP B customer, maybe the ISP B
> customer is chosen 52.4% of the time, and the ISP A customer is chosen 47.6%
> of the time, by a conforming ALTO client. That is, the likelihood of choosing
> an ISP B customer is 10% higher than choosing an ISP A customer.
> 
> But my preferred (non-ALTO) solution would be to have a simple access protocol
> to obtain the available access bandwidth directly from the end host. Here is
> my rationale:
> 
> - The customer always controls whether any bandwidth information is shared at
> all, and more importantly, with whom the information is shared. Thus, there is
> no question about ISPs or third parties sharing this information without the
> customer's permission.
> 
> - The real value reported by this mechanism can be redefined to be "how much
> of the customer's provisioned access bandwidth does the customer allow you to
> use". As a customer, for example, I can choose to share proportionally more
> bandwidth within my circle of friends than with strangers. I can choose to
> share all of my bandwidth, or maybe to share only some of my bandwidth because
> I anticipate needing some of my bandwidth in the future. These preferences may
> be difficult to convey to the ISP or to a third party.
> 
> The mechanism ought to allow for easy query by the application. If the
> application can obtain this value fairly quickly, it can be used for the
> interim selection of peers, prior to the application attempting to measure
> available bandwidth by probing. Maybe this value could be communicated as part
> of the initial transport exchange envisioned by the TANA group?

I think this value could be easily exchange as part of PEX, the question is
how a peer A would know if peer B is within his group of friends or not so
he how much bandwidth will be available to him. But then, of that
theoretical available bandwidth, how much is available now and in the near
future? I think there was a mile-long thread about measuring bw some time
ago in this list.

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 11 Sep 2008 13:02:18 -0400

>> If applications consistently chose ISP B customers over ISP A
customers, that might double ISP B's application traffic and reduce ISP
A's application traffic to zero...

> It seems ISP A is still using the same bandwidth as before since all
clients in it needs to download the whole file. The difference is that
all those bits are coming from Inter-domain links. Maybe I am missing
something here? Or maybe you mean ISP A's intra-domain traffic goes
almost to zero.

In this example, I meant that clients *outside* of ISP A and B would be
incented to choose ISP B clients as peers, so ISP A's uploading to
(non-ISP A) clients would drop to zero (in theory). So ISP A's outbound
inter-domain traffic would go to zero (in theory). In practice -- it
would depend on what optimization algorithm the ALTO client uses.

I agree that ISP A clients would presumably download the same amount of
content. And as Stas often reminds us, the aggregate amount of
downloading has to equal the aggregate amount of uploading in any
particular swarm.

> I think this value could be easily exchange as part of PEX, the
question is how a peer A would know if peer B is within his group of
friends or not so he how much bandwidth will be available to him.

Good question. It looks like Vuze already figured out a similar
mechanism: http://faq.vuze.com/?View=entry&EntryID=239. :)

>But then, of that theoretical available bandwidth, how much is
available now and in the near future? I think there was a mile-long
thread about measuring bw some time ago in this list.

This was discussed on this list, and I understood that we agreed that
real-time congestion information does NOT belong in an ALTO protocol.

I am talking about allocation of the provisioned bandwidth for the
customer, which is a far more static value. The provisioned bandwidth
could be used by the client for helping to select a candidate peer list.
It does not eliminate the need for measuring actual throughput and
latency, which would be impacted by network congestion.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reinaldo Penno
Sent: Tuesday, September 09, 2008 12:01 PM
To: Woundy, Richard; John Leslie
Cc: [email-masked]
Subject: Re: [p2pi] Information in an ALTO protocol

Hello,

Few comments inline..

>>> and traffic concentration concern (traffic may be drawn to fewer ISP
links
>>> with premium customers).

It seems ISP A is still using the same bandwidth as before since all
clients
in it needs to download the whole file. The difference is that all those
bits are coming from Inter-domain links. Maybe I am missing something
here?
Or maybe you mean ISP A's intra-domain traffic goes almost to zero.

> of the initial transport exchange envisioned by the TANA group?

I think this value could be easily exchange as part of PEX, the question
is
how a peer A would know if peer B is within his group of friends or not
so
he how much bandwidth will be available to him. But then, of that
theoretical available bandwidth, how much is available now and in the
near
future? I think there was a mile-long thread about measuring bw some
time
ago in this list.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of John
> Leslie