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

From: Laird Popkin <[email-masked]>
Date: Tue, 12 Aug 2008 10:45:32 -0400 (EDT)

Many p2p networks already do this sort of thing, and I can't think of any way that the ISP could prevent it - any p2p app can measure throughput and report it. For example, see http://www.speedtest.net/global.php. Of course, this is only based on users that installed the agent, which may not be representative, and doesn't different between classes of users (since the agent can't tell whether they're on a DOCSIS 1/2/3 cable modem, etc.).

The advantage of getting link capacity info from the ISP rather than by measurement is that it's a bit faster and more consistent, and saves a little bandwidth by not doing the test.

The other alternative is to use commercial IP mapping databases (e.g. MaxMind's netspeed database), which is fast and cheap, but these databases not as accurate or precise as an ISP could be. For example, MaxMind differentiates between dial, broadband and corporate, but not between classes of broadband.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Nicholas Weaver" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>, "Richard Woundy" <[email-masked]>, [email-masked]
Sent: Tuesday, August 12, 2008 10:28:03 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Information in an ALTO protocol

On Aug 12, 2008, at 7:12 AM, Laird Popkin wrote:

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

No, you're not.  Its not paranoia when they are out to get you.

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

My company-X P2P business model includes an agent I control on the  
user's computer, no?

So if its valuable, Company-X can use company-X's customers to mine  
the data.  This would especially be useful because you could do a  
direct increase in performance by feeding back the data to the  
tracking infrastructure.

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

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 12 Aug 2008 12:26:14 -0400

I don't disagree that you can measure a user's throughput, and in fact this is necessary for certain applications that negotiate codecs, eg iChat. But with speedtest servers and application-based measurement, there is an explicit or implicit opt-in by the user.

I suppose the ISP's ALTO service could also enable opt-in for the customer's provisioned speed to be reported, but I wonder how many customers would be incented to do this, and would that re-enforce any traffic concentration effects that I mentioned before (because few users opt in).

I suspect that knowing the link speed doesn't really enable the application to avoid testing for the actual available bandwidth, given that other applications may be consuming bandwidth.

-- Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 27 Aug 2008 14:31:02 -0400

>1. my ISP runs a redirector to their "transparent" ALTO server so I can't get directly to the one I want to get to.

I'm not sure I understand the motivation or rationale for an ISP to run a "transparent ALTO server".

First, my understanding is that ISPs would not require users to make ALTO queries for usage. So if the ISP intercepts ALTO messages, then users could stop sending ALTO messages altogether, and/or send 'alt-ALTO' messages that are not intercepted by the ISP and are processed by the alt-ALTO server desired by the user. So it would seem that ISP interception of ALTO messages would be self-defeating for the ISP.

Second, ALTO clients may include P2P clients and trackers, among other entities. ALTO requests from (typically off-net) P2P trackers would be difficult if not impossible for the ISP to intercept.

The premise of the ALTO protocol is that both the user and ISP benefit from its usage, right? So why would a 'transparent ALTO server' even be necessary for the ISP?

I am not opposed to the concept of the non-ISP ALTO server, I just don't understand why the ISP would be incented to intercept those requests.

-- Rich

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Aug 27 12:58:09 2008
Subject: Re: [p2pi] Information in an ALTO protocol

On Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote:

>
> On Aug 25, 2008, at 12:25 PM, David R Oran wrote:
>>
>> Many client/server protocols are were initially designed to be
>> strictly two party, with no architectural support for proxies or  
>> other
>> stateful intermediaries (HTTP and RTSP come to mind...there are  
>> likely
>> many others).
>>
>> It may behoove us to build proxy capability into ALTO from day 1,
>> since it will almost inevitably have to be added later at some level
>> of pain, perhaps large, and almost assuredly some undesirable  
>> security
>> tradeoffs.
>
> You're making the assumption now, that ALTO will need to add proxies  
> or intermediaries ("will almost inevitability").  I don't really  
> have evidence that you're wrong about that, but I also don't see the  
> use cases right now.  Do you have anything specific in mind?
>
Yeah:
1. my ISP runs a redirector to their "transparent" ALTO server so I  
can't get directly to the one I want to get to.
2. My P2P "community" wants to cache and do lookaside stuff to provide  
more globally optimized swarm spreading. So, I use their Alto "proxy"  
and let them help decide who needs to be asked for what.

>>
>>
>> This probably involves at least the following:
>> - separating our end-to-end from ho--by hop (transport layer?)  
>> security
>> - clear data model separation between things used to "route" requests
>> and things used to interpret queries.
>> - a flexible addressing model
>> - a way to aggregate and summarize in responses
>
> These are good architectural principles to remember while writing  
> and reviewing drafts, assuming they can be followed without falling  
> into the trap of designing the be-all and end-all system.
>
> -- Lisa
>
>>
>>
>> and likely a bunch of other considerations I'm missing in the above.
>>
>> DaveO.
>>
>>> Thanks,
>>>
>>> - vijay
>>> -- 
>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
>>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>>> WWW:   http://www.alcatel-lucent.com/bell-labs