[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
- [alto] ALTO Server Discovery Matthias Waehlisch
- [alto] Is there meeting minutes for ALTO, IETF 75? Y.J. Gu
- Re: [alto] Is there meeting minutes for ALTO, IET… Enrico Marocco
- Re: [alto] Is there meeting minutes for ALTO, IET… Y.J. Gu
- Re: [alto] ALTO Server Discovery Song Haibin
- [alto] [ALTO] Comments on [draft-stiemerling-alto… Y.J. Gu
- Re: [alto] [ALTO] Comments on [draft-stiemerling-… Jan Seedorf
- Re: [alto] [ALTO] Comments on [draft-stiemerling-… Richard Alimi
- Re: [alto] [ALTO] Comments on [draft-stiemerling-… Y.J. Gu
- Re: [alto] [ALTO] Comments on[draft-stiemerling-a… Jan Seedorf
- Re: [alto] [ALTO] Comments on [draft-stiemerling-… Jan Seedorf