Re: [p2pi] Information in an ALTO protocol

[Laird Popkin <[e-mail]>]

Interesting points. I'm not paranoid enough. :-)

How about if this is exposed only to the ISP's customers?

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

----- Original Message -----
From: "Richard Woundy" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Sent: Tuesday, August 12, 2008 9:58:55 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Information in an ALTO protocol

>but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan.

I see three potential problems for the ISP.

First, there is the user privacy issue. I could imagine an ecommerce portal that varies its prices based on the ISP plan of the user that it dsicovers via ALTO. If this is true, this would be a certain showstopper.

Second, there is the ISP marketing concern about revealing the mix of regular versus premium customers. The ISP that reveals this information would be at a competitive disadvantage to the ISP that does not; the second ISP could tune their prices, advertising messages, etc.

Third, the ISP premium customers would become much more popular targets for swarm selection algorithms. That *may* serve to concentrate traffic on fewer ISP links. Probably more likely is a lot of TCP connection *attempts* to premium customers, because even premium customers have finite upstream capacity. But if there happens to be aggregate 'capacity slack' in the swarm, then there may be more traffic concentration than is desired by either the premium customer or the ISP.

-- Rich


----- Original Message -----
From: [e-mail] <[e-mail]>
To: Vinay Aggarwal <[e-mail]>
Cc: [e-mail] <[e-mail]>
Sent: Mon Aug 11 21:16:44 2008
Subject: Re: [p2pi] Information in an ALTO protocol

This might be workable and interesting, but here are a few concerns:

1. For this to be useful, an ISP would need to provide an unobfuscated  
third-party service that will tell the world what service plan I  
bought.  As a user, I'd have a bit of discomfort with it, but the ISP  
would probably be a lot more concerned about telling its competitors  
the fraction of its customers whom they upsold on a premium plan.  I  
suspect this might be a real show-stopper.

2. Nominal provisioned bandwidth on DSL is only an upper bound for the  
actual negotiated bandwidth.  The negotiation takes a few seconds  
after the modem starts and routinely results in lower-than-nominal  
rates for longer distances to CO.

3. While it's obvious that an individual peer will, in the current  
world, do better trading with fat-uplink partners, I'm skeptical of  
possibility of substantial increases in swarm throughput, which  
determines the average outcome.  Consider the measure of swarm  
efficiency: total transfer rate divided by total upload capacity.  I  
posit that swarm efficiency is usually quite high, and the only real  
slack is on super-fast peers in colos and such.  Home connection  
uplinks are so narrow that it does not take much to saturate them.

-- Stas



On Aug 11, 2008, at 7:35 AM, Vinay Aggarwal wrote:

> Hello,
>
> Regarding what information the ALTO service can provide:
>
> I think an estimate of "last-hop bandwidth" can be an interesting  
> metric
> of information for peer selection.
> It has been shown that selecting peers with high last-hop bandwidth  
> lead
> to improvements in download performance. And this is information  
> that is
> rather hard for peers to find out themselves. As far as I can see, it
> also satisfies all the bars set up by the ALTO service.
>
> Any thoughts?
>
> Thanks,
> Vinay.
>
> -----------------
> Vinay Aggarwal
> Deutsche Telekom
> Germany.
>
>
> On Thu, Aug 07, 2008 at 09:14:19PM +0200, Enrico Marocco wrote:
>> As some people suggested, it may be useful to try to understand what
>> kind of information will be provided by an ALTO service.
>>
>> Current version of the charter lists four pieces of information:
>> + routing preferences and priority values. The network operator is
>>  usually the only entity in possession of such information, but it is
>>  in its interests to share at least part of it with applications, in
>>  order to reduce traffic on critical links. On the other hand, if
>>  following such preferences leads to better-than-random choices, it  
>> is
>>  also in applications' interest to follow them;
>> + AS numbers and approximate geographic locations. Such information  
>> is
>>  today (partially) available and, in fact, is in some cases already
>>  used for peer selection. However, since there is no standard way to
>>  obtain it, it is not easy for applications to switch from an
>>  information provider to another.
>>
>> The charter does not preclude any other kind of information entirely,
>> but it sets the bar pretty high, requiring that:
>>
>>  When the WG considers standardizing schemas, measures or other
>>  information that the ALTO service could provide, the following
>>  criteria are important to ensure real feasibility.
>>  - Can an ALTO service technically provide that information?
>>  - Is the ALTO service willing to obtain and divulge that  
>> information?
>>  - Is it information that some client will find useful?
>>  - Can that client get that information without excessive privacy
>>    concerns (e.g. by sending large lists of peers)?
>>  - Is it information that clients cannot find easily some other way?
>>
>> Thoughts?
>>
>> -- 
>> Ciao,
>> Enrico
>
>
>
>> _______________________________________________
>> p2pi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi

--
Stanislav Shalunov



_______________________________________________
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