Re: [p2pi] Information in an ALTO protocol

[David R Oran <[e-mail]>]

On Aug 27, 2008, at 1:18 PM, Lisa Dusseault wrote:

>
> On Aug 27, 2008, at 9:58 AM, David R Oran wrote:
>>
>> 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?
>>>
>
> This helps, and leads to more questions...
>
>> 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.
>
> How does this use case affect protocol design in the short term?   
> Other than the agreed principles of good design, I mean.  An ISP can  
> run any kind of internal protocol and we're a long way away from  
> generalized interoperability between agents deployed within an ISP.
>
Like any middlebox, it's helpful if there's a clean separation between  
the things the middlebox can fool with and the things that get  
integrity protected end-to-end.

>>
>> 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 is a use case I've been talking to people about in a different  
> context, and it's a difficult one.  If the swarm's Alto server can  
> ask as itself for useful information, probably public information,  
> then that's easy.  But if the swarm's Alto server has to ask for  
> information "on behalf of" a swarm member, then we have difficult  
> delegation and permission issues.  I had assumed we wouldn't want to  
> tackle that in the first batch of ALTO work.
I agree this is difficult in general. It's just been my experience  
that adding proxy hooks to a protocol that did not envision them has  
been messy and painful. That's not to say I necessarily believe we  
will need the full generality you talk about below.


> But even if the swarm's Alto server can get information from other  
> places, publically or through delegation, and compile that or  
> forward it, the next thing to bring into question is whether the end  
> consumer of the information needs to know where the information came  
> from originally.  I don't even know what lesson one can draw from  
> HTTP but I'd probably be able to put up a good argument for learning  
> that proxy information is mostly useless.  Most proxy and forwarding  
> information that actually appears in HTTP traffic is ignored by  
> clients, and most traffic does not even go through non-transparent  
> proxies.  IOW, most proxying of HTTP, and all compiling of  
> responses, happens transparently, and does not use the protocol  
> headers that were designed for handling intermediaries.
>
Do you think this was inherent, or because it was a bolt-on?

> As devil's advocate I'm now prepared for my argument to be totally  
> demolished...
>
> Lisa
>
>>
>>
>>
>>>>
>>>>
>>>> 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
>>>
>>>>

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