Subject: [ppsp] 答复: Call for Comments on Usage of PPSP

From: Zongning <[email-masked]>
Date: Mon, 8 Dec 2014 08:20:24 +0000

Hi, Mi,

I noticed that in Section 4, you listed the parameters adopted by Tracker Protocol & Peer Protocol. It’s ideal that you could further give some benchmarking data as the results of your PPSP system. For example, you could run a P2P live streaming test and report the results under your settings.

Thanks.

-Ning

发件人: ppsp [mailto:[email-masked]] 代表 Mi Zhang
发送时间: 2014年12月1日 9:10
收件人: ppsp
主题: [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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 15 Dec 2014 09:52:58 +0000

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.

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.

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

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.

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.

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

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:[email-masked]] 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:

BR
Mi Zhang