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

"Y.J. Gu" <guyingjie@huawei.com> Wed, 12 August 2009 09:57 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 2494E3A6977 for <alto@core3.amsl.com>; Wed, 12 Aug 2009 02:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.265
X-Spam-Level:
X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_40=-0.185, J_CHICKENPOX_45=0.6]
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 88BA1slZGHwF for <alto@core3.amsl.com>; Wed, 12 Aug 2009 02:57:03 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [58.251.152.67]) by core3.amsl.com (Postfix) with ESMTP id 500893A6936 for <alto@ietf.org>; Wed, 12 Aug 2009 02:57:03 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO900JYTCQ9CX@szxga04-in.huawei.com> for alto@ietf.org; Wed, 12 Aug 2009 17:51:45 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO9002CPCQ922@szxga04-in.huawei.com> for alto@ietf.org; Wed, 12 Aug 2009 17:51:45 +0800 (CST)
Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO9004PECQ9RF@szxml06-in.huawei.com> for alto@ietf.org; Wed, 12 Aug 2009 17:51:45 +0800 (CST)
Date: Wed, 12 Aug 2009 17:51:45 +0800
From: "Y.J. Gu" <guyingjie@huawei.com>
In-reply-to: <008c01ca1a63$0783e7d0$0f0ca40a@china.huawei.com>
To: 'alto' <alto@ietf.org>
Message-id: <004901ca1b32$80d94d80$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: AcoRI5l7gfCJyM9zTuChHjMI8pdj3gIkB7XwAFwmxmA=
Subject: [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: Wed, 12 Aug 2009 09:57:04 -0000

I'm very glad that at last someone notice redistribution.

I'm not totally agree with some opinions in the draft.

--  "However, there is no mean for the peers to verify whether the
information provided is actually intended
   for their usage nor if the information is actually accurate at their
current topological position in the Internet "

Surely, it's very important to verify the usage and the origination of the
redistributed information.
I don't think accurate information needs to be redistributed.
Actually, there are kinds of general information that are suitable and
helpful to be redistributed.
E.g. kinds of cost between a particular PID and other PIDs is useful to all
the peers in the particular PID. 
What we should do is to guarantee that general information is redistributed
within the PID area(maybe multicast) or to guarantee that peer only request
its PID general information.

---"First of all does this require public/private key pair, where the public
key is known to each peer and a trusted third party is required.  These
requirements are possible to be fulfilled in certain deployments but are not
in the general Internet deployment case, which in turn limits the
applicability of this protocol.  Second, the receiving peer needs to contact
the ALTO server at least once to obtain the public key part, or it does need
to contact another server that provides the public key pair."

First, Redistribution can be an optional part of the protocol, ALTO server
can decide whether redistribution is adopted according to internet
environment. Second, peer can contact CA, instead of ALTO server, to obtain
a public key. In P2PSIP-reload, each peer owns a certificate and every peer
can contact the CA to authenticate the certificate of other peer. Reload
regards this an acceptable workload to CA. I think the frequence of
obtaining public key from ALTO server is much fewer than the authentication
in Reload. So that may be not a probolem.
Whatever, the real workload depends on how we design the redistribution
mechanism. 



Regards

Yingjie Gu