Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Fri, 12 July 2013 01:55 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C721F9F17 for <ppsp@ietfa.amsl.com>; Thu, 11 Jul 2013 18:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.028
X-Spam-Level:
X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Rqq1Q6vGQ2 for <ppsp@ietfa.amsl.com>; Thu, 11 Jul 2013 18:55:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 446E321F9EC2 for <ppsp@ietf.org>; Thu, 11 Jul 2013 18:55:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY03988; Fri, 12 Jul 2013 01:55:33 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:55:07 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 02:55:30 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 09:55:23 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: 邓灵莉/Lingli Deng <denglingli@chinamobile.com>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt
Thread-Index: AQHOfh4bDtsUZalPb06dD4Omw8RdkplgOurw
Date: Fri, 12 Jul 2013 01:55:22 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4584126D@nkgeml501-mbs.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB45841007@nkgeml501-mbs.china.huawei.com> <016001ce7e1e$18291fb0$487b5f10$@com>
In-Reply-To: <016001ce7e1e$18291fb0$487b5f10$@com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.104]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 12 Jul 2013 01:55:40 -0000

Hi lingli,

Thank you for the review. Please see my reply inline.

Best regards,
Rachel

-----Original Message-----
From: 邓灵莉/Lingli Deng [mailto:denglingli@chinamobile.com] 
Sent: Thursday, July 11, 2013 6:05 PM
To: Huangyihong (Rachel); ppsp@ietf.org
Subject: 答复: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel,

I found some inconsistencies in the new revision as follows for you to
consider: 

1, There are inconsistent description about DISCONNECT messages: On Page 5,
in Section 4.1.2, paragraph #2, it is stated that "The DISCONNECT Request
message is used when the peer intends to no longer participate in *all*
warms." However, On page 6, in Section 4.2, paragraph #1, it goes "the peer
DISCONNECTs from the corresponding swarm (swarm_b) while still sharing the
first content (swarm_a)". Subsequent relevant texts all seem to be comply
with the first one.

[Rachel]: Yes, that's an error description of section 4.2. DISCONNECT message only has the ability to leave all the swarms the peer joined. I don't think DISCONNECT should have a same meaning of CONNECT (LEAVE). So this is one place that I omitted to modify. Thank you for pointing out.

2, There are inconsistent description about the exemplified session in
Section 4.2 between the text and the Figure 1. For the figure does not catch
the status of ""the peer DISCONNECTs from the corresponding swarm (swarm_b)
while still sharing the first content (swarm_a)".

[Rachel]: See above. Figure is consistent with the description of section 4.1.2.

3, Mino typo: on page 9, paragraph labeled with "7)", the last sentence
should be "..., and transitions to TERMINATE s*t*ate for that Peer-ID."

[Rachel]: Okay.

A few questions about the protocol design:

1, What's the objective behind the "init-timer" scheme?

[Rachel]: Previously, init-timer was used to wait for other messages after a peer has sent a "REGISTER" message to the tracker. And the "PEER REGISTERED" state was not transient at that time. But now, we have abandoned the "REGISTER" message and  "PEER REGISTERED" state is transient, so I think we don't need init-timer anymore. 

2, How would a peer be "joining the swarm with invalid Swarm_Id"?

[Rachel]: My fault. It's a wrong description.  I think my intension is to say receiving a FIND message with a invalid Swarm_Id is considered a error condition.

3, In section 4.5, since there are extended messages with newly introduced
fields (e.g. contentgroup), you may also need to handle cases with "Unknown
fields" as well as "Unknown Messages".

[Rachel]: Good point. Thanks.

4, In case a peer specifies the peergroup S (a subset of all the segments)
it's currently interested in with a FIND message, does it make sense for a
tracker to return a peer with only a subset S' of S to the requestor?

[Rachel]: I think yes. why not?

Lastly, as for the arrangement of contentgroup, it could be rather
bit-consuming if a peer is FINDing a scattered group of segments. I have
been proposing to use compression method to mitigate this matter.
http://datatracker.ietf.org/doc/draft-deng-ppsp-bfbitmap/ 
I would like to hear any feedback or comments from you TR guys about it:-)

[Rachel]: Yes. I'm aware of it. I'm working on some ietf documents these days. I'll get you some responses in a few days.

BR
Lingli

-----邮件原件-----
发件人: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] 代表
Huangyihong (Rachel)
发送时间: 2013年7月11日 9:46
收件人: ppsp@ietf.org
主题: [ppsp] FW: New Version Notification for
draft-huang-ppsp-extended-tracker-protocol-03.txt

Dear all,

We have just submitted a new version of
draft-huang-ppsp-extended-tracker-protocol. This update is just some
editorial changes. No significant modification. Comments are highly
appreciated. 

Best regards,
Rachel


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Thursday, July 11, 2013 9:29 AM
To: Mario Serafim Nunes; Rui Santos Cruz; Rui Sant Cruz; Zongning; Mario
Sera Nunes; Huangyihong (Rachel); Joao P. Taveira
Subject: New Version Notification for
draft-huang-ppsp-extended-tracker-protocol-03.txt


A new version of I-D, draft-huang-ppsp-extended-tracker-protocol-03.txt
has been successfully submitted by Rachel Huang and posted to the
IETF repository.

Filename:	 draft-huang-ppsp-extended-tracker-protocol
Revision:	 03
Title:		 PPSP Tracker Protocol--Extended Protocol
Creation date:	 2013-07-11
Group:		 Individual Submission
Number of pages: 26
URL:
http://www.ietf.org/internet-drafts/draft-huang-ppsp-extended-tracker-protoc
ol-03.txt
Status:
http://datatracker.ietf.org/doc/draft-huang-ppsp-extended-tracker-protocol
Htmlized:
http://tools.ietf.org/html/draft-huang-ppsp-extended-tracker-protocol-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-huang-ppsp-extended-tracker-protocol-
03

Abstract:
This document specifies an extended Peer-to-Peer Streaming Protocol -
Tracker Protocol, which is a new extension protocol complementing the
basic core messages and usages specified in the base tracker protocol
for the exchange of meta information between trackers and peers, such as
initial offer/request of participation in multimedia content streaming,
content information, peer lists and reports of activity and status. It
extends the base tracker protocol to include new optional messages
providing new usages in the communications between peer and tracker. The
extension protocol is retro-compatible with the base tracker protocol.


 



The IETF Secretariat

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp