Re: [p2pi] Information in an ALTO protocol

Lisa Dusseault <ldusseault@commerce.net> Wed, 27 August 2008 17:18 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB4A3A6B38; Wed, 27 Aug 2008 10:18:58 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF483A6A76 for <p2pi@core3.amsl.com>; Wed, 27 Aug 2008 10:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.004
X-Spam-Level:
X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m+3mJK0rJwG for <p2pi@core3.amsl.com>; Wed, 27 Aug 2008 10:18:56 -0700 (PDT)
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id 643AB3A6B2F for <p2pi@ietf.org>; Wed, 27 Aug 2008 10:18:56 -0700 (PDT)
Received: from gateout02 (gwsmtp.usa.net [165.212.65.102]) by gateout02.mbox.net (Postfix) with ESMTP id ED55F4BDA7E; Wed, 27 Aug 2008 17:18:52 +0000 (GMT)
Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02 via smtad (C8.MAIN.3.45S) with ESMTP id XID360mHARs27488Xo2; Wed, 27 Aug 2008 17:18:52 -0000
X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET
X-USANET-MsgId: XID360mHARs27488Xo2
Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 11:18:52 -0600
Message-Id: <3D7E15E8-C27C-4B12-9A6B-627EA6767627@commerce.net>
From: Lisa Dusseault <ldusseault@commerce.net>
To: David R Oran <oran@cisco.com>
In-Reply-To: <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Wed, 27 Aug 2008 10:18:51 -0700
References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <E3361EDE-EDC6-4EF0-9249-B87B6C2D349C@nokia.com> <df9ced400808110837n57c79866se83369300812975e@mail.gmail.com> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <BEEA9A6E-26F6-4314-B4B5-EB6396BA3DCF@cisco.com> <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com>
X-Mailer: Apple Mail (2.928.1)
X-OriginalArrivalTime: 27 Aug 2008 17:18:52.0742 (UTC) FILETIME=[FA669E60:01C90868]
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Information in an ALTO protocol
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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.

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

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.

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
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi