Re: [p2pi] Information in an ALTO protocol

>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: p2pi-bounces@ietf.org <p2pi-bounces@ietf.org>
To: Lisa Dusseault <ldusseault@commerce.net>
Cc: p2pi@ietf.org <p2pi@ietf.org>
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
>>> _______________________________________________
>>> p2pi mailing list
>>> p2pi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2pi
>>
>> _______________________________________________
>> p2pi mailing list
>> p2pi@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>>
>

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi