Re: [p2pi] Information in an ALTO protocol

[Laird Popkin <[e-mail]>]

Keep in mind that ALTO cannot control a p2p network, just provide guidance to it. P2P networks optimize for performance. So while an ISP might try to discourage use of peers on its network as seeds, the p2p network can freely ignore that guidance if they get better performance by using them anyway, as discovered through all of the other p2p mechanisms (tracker, DHT, PEX, etc.).

The other issue is that ALTO is anticipated to be used by ISPs to provide guidance to their own users. ALTO can't provide guidance to customers of other ISPs. So ISP A cannot tell the rest of the internet to pull data from ISP B but not ISP A.

- Laird Popkin, CTO, Pando Networks
  mobile: [phone]

----- Original Message -----
From: "Richard Woundy" <[e-mail]>
To: "Reinaldo Penno" <[e-mail]>, "John Leslie" <[e-mail]>
Cc: [e-mail]
Sent: Thursday, September 11, 2008 1:02:18 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] Information in an ALTO protocol

>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
Reinaldo Penno
Sent: Tuesday, September 09, 2008 12:01 PM
To: Woundy, Richard; John Leslie
Cc: [e-mail]
Subject: Re: [p2pi] Information in an ALTO protocol

Hello,

Few comments inline..


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

>>> 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.

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.

> 
> -- Rich
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of John
> Leslie
> Sent: Thursday, August 28, 2008 8:13 PM
> To: Woundy, Richard
> Cc: [e-mail]
> Subject: Re: [p2pi] Information in an ALTO protocol
> 
> Woundy, Richard <[e-mail]> 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 <[e-mail]>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi
> 
> 
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi

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