Re: [ppsp] Call for Comments on Usage of PPSP

"Mi Zhang" <13120174@bjtu.edu.cn> Fri, 19 December 2014 09:08 UTC

Return-Path: <13120174@bjtu.edu.cn>
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 B6F521A6EE0 for <ppsp@ietfa.amsl.com>; Fri, 19 Dec 2014 01:08:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.178
X-Spam-Level: ****
X-Spam-Status: No, score=4.178 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 UI-201mwxkEt for <ppsp@ietfa.amsl.com>; Fri, 19 Dec 2014 01:08:22 -0800 (PST)
Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 500071A6F01 for <ppsp@ietf.org>; Fri, 19 Dec 2014 01:08:05 -0800 (PST)
Received: by ajax-webmail-Jdweb2 (Coremail) ; Fri, 19 Dec 2014 17:06:42 +0800 (GMT+08:00)
Date: Fri, 19 Dec 2014 17:06:42 +0800
From: Mi Zhang <13120174@bjtu.edu.cn>
To: rachel.huang@huawei.com, ppsp@ietf.org
Message-ID: <1f9ebc10.110a.14a61cc8917.Coremail.13120174@bjtu.edu.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_15914_718096743.1418980002069"
X-Originating-IP: [211.71.67.158]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20140513(27092.6055.6128) Copyright (c) 2002-2014 www.mailtech.cn bjtu
X-SendMailWithSms: false
X-CM-TRANSID: M55wygCHj_ui6pNUANcBAA--.1065W
X-CM-SenderInfo: artrjiarxuquxmwxhvlgxou0/1tbiAgQDB1Ryp1GbYwABsr
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: http://mailarchive.ietf.org/arch/msg/ppsp/eyt_mByDiG6ullviPGAqubo95U0
Subject: Re: [ppsp] Call for Comments on Usage of PPSP
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: Fri, 19 Dec 2014 09:08:28 -0000

Hi,Rachel


    Thanks for your nice and kind review. Sorry for my late response. I would like to answer your questions 1-6 firstly and prepare more information for the others.
    Please see in line~


BR
Mi Zhang
-----原始邮件-----
发件人: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
发送时间: 2014年12月15日 星期一
收件人: "Mi Zhang" <13120174@bjtu.edu.cn>, ppsp <ppsp@ietf.org>
抄送:
主题: RE: [ppsp] Call for Comments on Usage of PPSP



Hi Mi,

 

I have reviewed this draft and have following comments:

 

1.       Section 3.1, point 1, “In the same swarm, peers MUST use the same chunk addressing method and the same encoding type to ensure that peers can communicate with each other smoothly”. In the newest version, tracker protocol uses text encoding and peer protocol uses binary encoding. So there’s no need to mention the same encoding type here.




[Mi]  Right, we will update it soon.




2.       Section 3.2, paragraph 10, “For that purpose, the Peer B needs to connect and login a service Portal with peer ID and transaction ID to get the MPD file of the selected swarm x”. Transaction ID is not obtained from the portal. It’s from the tracker.




[Mi]  Yes, Transaction ID has nothing to do with portal. It is set in request and response in tracker protocol.




3.       Section 3.2, paragraph 14. I think sending PER_REQ message to get other peers’ information is optional, right?




[Mi]   Yes, PEX message is an OPTIONAL feature.

          Section 3.2, paragraph 14, Peer B could use another way (sending PER_REQ message to Peer A) to update PeerList. 

          Using “MAY” instead of “could” is more reasonable.




4.       Section 3.2 “Meanwhile, Peer B SHOULD use FIND or CONNECT message to log out and eliminate its state machine in tracker”. FIND message cannot let a peer to log out from a swarm or tracker. FIND message is only used to update the peer list. Use “STAT_REPORT” message instead.




[Mi]  Right, in the older tracker protocol, we uesd to think FIND was quite similar with CONNECT, due to the same C-like syntax. So we wrote log out by FIND was another option, which is outdated and wrong. We will fix it.




5.       Section 3.2, “Peer B MAY use FIND or CONNECT message to join a new swarm, such as swarm y or z in Figure 1”. FIND message cannot let a peer to join a new swarm.




[Mi]  Same question to 4. We will fix it.




6.       Section 4.1, If these values are reasonable, they should be incorporated into the tracker protocol.




[Mi]  Fair enough. If some values are accepted as default values, they may be defined in tracker protocol. At that time, we will ask more people for their advice.




7.       Section 5, issue 1, tracker protocol has an attribute in PeerGroup to indicate by what kind of access the peer is connecting. It’s kind of extending the P2P system in mobile and wireless environments. Of course we can extend the tracker protocol to include the packet loss rate and battery status. However, I’m not sure about it because these two parameters are not general enough, especially battery status.

8.       Section 5, issue 2, I think it depends on the implementations. For applications that will be supervised by ISPs, tracker protocol and peer protocol without searching peers should be used.

9.       Section 5, issue 3, I don’t understand why the tracker could only use PeerMode to choose the PeerList? For tracker protocol, I think both Leech and Seed can be included in the Peerlist.

10.   Section 5, issue 4. This is addressed in the extended tracker protocol.

11.   Section 5, issue 5. What’s the intention?

12.   Section 5, issue 6. Message exchanging frequency is not issue for base tracker protocol, because there’s only a little signaling data delivered by tracker protocol. The most frequent message is STAT_REPORT message which may be 1 minute interval if setting Track_timeout to 3 minutes.

 

 

BR,

Rachel

 

From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of Mi Zhang
Sent: Monday, December 01, 2014 9:10 AM
To: ppsp
Subject: [ppsp] Call for Comments on Usage of PPSP

 

Deal all:

    We have updated a new version of PPSP Usage. Your review and further comments are well appreciated.

    More importantly, we would like to know whether the current overall framework is reasonable and meets the WG item. Please let us know if something is missing.

    Thanks.

 

BR

Mi Zhang