Re: [p2pi] Information in an ALTO protocol

On Aug 27, 2008, at 10:25 AM, David R Oran wrote:

>
> On Aug 27, 2008, at 1:18 PM, Lisa Dusseault wrote:
>
>>
>> On Aug 27, 2008, at 9:58 AM, David R Oran wrote:
>>>
>>> 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.

I agree we agree... :)  I guess we'll see how this plays out in  
protocol design, and it will be at least amusing and perhaps useful to  
do an exercise imagining how an ALTO base protocol can or should be  
extended before it's baked.

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

This I do not know.  I have a gut feeling it's inherent.  Perhaps meta- 
information isn't as useful as we programmers usually think it is?   
There's definitely a pattern across protocols, whether the meta- 
information is provided initially or as a bolt-on, of that being less  
used than anticipated.  This might be random rather than a pattern --  
just a natural product of designing a bunch of stuff and being wrong  
about a random selection of features being useful.   It's too loose to  
nail down, at least for me.

Lisa

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