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

"Huangyihong (Rachel)" <> Mon, 15 December 2014 09:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2159C1A02F1 for <>; Mon, 15 Dec 2014 01:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yiYP8oher1L1 for <>; Mon, 15 Dec 2014 01:53:13 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79B271A1A9B for <>; Mon, 15 Dec 2014 01:53:11 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BQB21898; Mon, 15 Dec 2014 09:53:09 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 15 Dec 2014 09:53:07 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Mon, 15 Dec 2014 17:52:58 +0800
From: "Huangyihong (Rachel)" <>
To: Mi Zhang <>, ppsp <>
Thread-Topic: [ppsp] Call for Comments on Usage of PPSP
Thread-Index: AQHQDQOrh7tgTcLPj06C6EMT5k2CAJyQbHzA
Date: Mon, 15 Dec 2014 09:52:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB8629D51Fnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] Call for Comments on Usage of PPSP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Dec 2014 09:53:16 -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.


From: ppsp [] 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.

Mi Zhang