Re: [ppsp] Review of draft-huang-ppsp-extended-tracker-protocol-07

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Tue, 09 December 2014 02:24 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C637C1A026C for <ppsp@ietfa.amsl.com>; Mon, 8 Dec 2014 18:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO13c3D7HOqw for <ppsp@ietfa.amsl.com>; Mon, 8 Dec 2014 18:24:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612A51A016A for <ppsp@ietf.org>; Mon, 8 Dec 2014 18:24:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPV26048; Tue, 09 Dec 2014 02:24:06 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Dec 2014 02:24:05 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 9 Dec 2014 10:24:02 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Roni Even <ron.even.tlv@gmail.com>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] Review of draft-huang-ppsp-extended-tracker-protocol-07
Thread-Index: AdAP1CIibKYMgCkuTdaU6dvHwtMKPgDItXAw
Date: Tue, 09 Dec 2014 02:24:01 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862939BA@nkgeml501-mbs.china.huawei.com>
References: <079601d00fd5$18ba2f10$4a2e8d30$@gmail.com>
In-Reply-To: <079601d00fd5$18ba2f10$4a2e8d30$@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.214.40.254]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB862939BAnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ppsp/_hHyuuS4ZMni-SoZKs_-Gbsh6do
Subject: Re: [ppsp] Review of draft-huang-ppsp-extended-tracker-protocol-07
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp/>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 02:24:19 -0000

Hi Roni,

Thank you for the review. See my replies inline.

BR,
Rachel

发件人: ppsp [mailto:ppsp-bounces@ietf.org] 代表 Roni Even
发送时间: 2014年12月4日 23:15
收件人: ppsp@ietf.org
主题: [ppsp] Review of draft-huang-ppsp-extended-tracker-protocol-07

Hi,
I reviewed the draft and in general it looks OK, some comments


1.       In section 5.3 in the first case it says that the peer will now if the tracker supports the extension based on the error response why cannot the peer know it based on the ppsp_tp_versions value
[Rachel]: Because there’s no negotiation in the whole tracker protocol design. So the first message sent from the peer is the CONNECT message. Only when the tracker responds,  the peer know if the tracker supports the extension.


2.       In section 5.4 why not say that if a tracker support version 01 it MUST support the same chunk addressing method as the peers. This will be in line with section 4 of peer protocol that says “All peers in a swarm MUST use the same chunk addressing method.“

[Rachel]: But a tracker could serve multiple swarms. What if different swarms chooses different chunk addressing methods? Actually the principle in the extended tracker protocol is consistent with the peer protocol. See section 5.4 : “Multiple chunk addressing methods could be used in this document to present content information. But only one of them MUST be used for
one swarm when a peer communicating with a tracker.”


Thanks
Roni Even