Re: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-00]

"Y.J. Gu" <guyingjie@huawei.com> Thu, 13 August 2009 03:59 UTC

Return-Path: <guyingjie@huawei.com>
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5803A6897 for <alto@core3.amsl.com>; Wed, 12 Aug 2009 20:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.088
X-Spam-Level:
X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 T0bwO8pxJWgi for <alto@core3.amsl.com>; Wed, 12 Aug 2009 20:59:55 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AB5AF3A6B0D for <alto@ietf.org>; Wed, 12 Aug 2009 20:59:21 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOA00BY9QY4BF@szxga03-in.huawei.com> for alto@ietf.org; Thu, 13 Aug 2009 11:56:28 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOA00DQGQY4S4@szxga03-in.huawei.com> for alto@ietf.org; Thu, 13 Aug 2009 11:56:28 +0800 (CST)
Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOA00GUPQY49Y@szxml04-in.huawei.com> for alto@ietf.org; Thu, 13 Aug 2009 11:56:28 +0800 (CST)
Date: Thu, 13 Aug 2009 11:56:28 +0800
From: "Y.J. Gu" <guyingjie@huawei.com>
In-reply-to: <B94940C43117794C9432FF5FF0CCB506BE506E@VENUS.office>
To: 'Jan Seedorf' <Jan.Seedorf@nw.neclab.eu>, 'alto' <alto@ietf.org>
Message-id: <002f01ca1bca$094ee6b0$400ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcoRI5l7gfCJyM9zTuChHjMI8pdj3gIkB7XwAFwmxmAADkh3cAAYN9BA
Subject: Re: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-00]
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2009 03:59:56 -0000

Hi Jan,
See in line pls.

Regards

Yingjie Gu

 

> -----Original Message-----
> From: Jan Seedorf [mailto:Jan.Seedorf@nw.neclab.eu] 
> Sent: Wednesday, August 12, 2009 11:15 PM
> To: Y.J. Gu; alto
> Subject: RE: [alto] [ALTO] Comments on 
> [draft-stiemerling-alto-info-redist-00]
> 
> Dear Yingjie,
> 
> I think the problem of redistributed ALTO-information is not 
> so easy, some comments below.

> Agreed, there may be certain use-cases where redistribution 
> may not be problematic. But consider the case where certain 
> information provided by an ALTO-server is _relative_ to that 
> ALTO-server's location in the network. If such information 
> gets redistributed, an ALTO-client not being aware of the 
> original ALTO-server's location may misinterpret this 
> information. In other words, by redistributing guidance 
> information, its original semantic might be disguised. I 
> think this is the problem being addressed in Martin's draft 
> and specifically in the quote above.
> 

I think "Redistribution" should not be unlimited. 
First of all, not all information is redistributed. 
Second, redistributed information must include accurate ALTO SERVER
INFORMATION, e.g. network position or name, and what kind of information it
is, so that client can judge the usage of the information.
Last but not least, client must cognize his ALTO SERVER INFORMATION and
share a unified information description language among all clients, at least
those in one application swarm.
Richard Alimi gave excellent examples in his email. Of course, there maybe
other methods.
By this mean, client can find suitable redistributed information.

> Indeed, a CA-hierarchy is the technical solution. However, 
> practically it is not always the case that two hosts on the 
> Internet share a trusted third party, and certainly there is 
> no overall Internet-wide CA hierarchy trusted by all hosts. 
> In P2PSIP-RELOAD, the assumption is that there is an 
> enrollment server, i.e., a certificate authority which 
> certifies identities in the P2P-network (DHT). In other 
> words, any peer who wants to join the P2PSIP network has to 
> enroll with this identity certification service. I do not 
> think that is a reasonable assumption for ALTO and I think 
> this was the point in the quote above.
> 
>  - Jan

Instead of an overall trusted third party, a dedicated CA for a particular
network position, neither too small nor too big, will work. Applications can
make their clients cognize the dedicated CA as they notice clients about
dedicated ALTO servers.