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

From: "Mi Zhang" <[email-masked]>
Date: Fri, 19 Dec 2014 17:06:42 +0800 (GMT+08:00)

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)" <[email-masked]>
发送时间: 2014年12月15日 星期一
收件人: "Mi Zhang" <[email-masked]>, ppsp <[email-masked]>
抄送:
主题: 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:[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:

    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, 22 Dec 2014 08:18:07 +0000

Hi Tianming,

Thanks for replying. You omitted one comment regarding issue 2^^. And please see my further comments inline.

BR,
Rachel

From: 赵天明 [mailto:[email-masked]]
Sent: Monday, December 22, 2014 3:02 PM
To: Huangyihong (Rachel); [email-masked]
Subject: Re: [ppsp] Call for Comments on Usage of PPSP

Hi,Rachel

    Thanks for your nice and kind review. Sorry for my late response. I would like to answer your questions 7-12.
    Please see in line~

BR
Tianming Zhao

I think usage in mobile environment should consider handover between base stations and switch between WIFI & Telecom Operator. Also, as data transmission uses power (and the power especially used in upload is sometimes considered as wasted by selfish users), I think we should consider that.

[Rachel]: Maybe we could put these parameters in as optional ones. It that okay for everyone?

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.
It makes sense. Different application scenarios could set the specific coordinated method of updating PeerList.
But we think if PPSP provides some efficiently way, it will be better for implementers and users.

[Rachel]: What kind of efficient way are you suggesting? IMHO, the protocols in PPSP already have the flexibility to deal with different application scenarios.

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

Yes, we write our protocol based on the two active Internet-Drafts, they haven’t mentioned it.

We agree with your point in extend tracker protocol. But our current Usage of PPSP is based on the base-tracker protocol and peer protocol, so we take this gap out.

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

First, by splitting a large swarm, we can shorten the time used in searching & connecting. Second, users under different ISPs (Internet Service Provider) might face higher delay when connect with each other. So I think it would be better if we could adjust size of swarm according to QoS.

[Rachel]: I think it’s an implementation issue rather than a protocol issue.
11.   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.

               That’s true. But the point we are trying to give is thatwe should take bandwidth into consideration to adjust the video definition and other parameters.
[Rachel]: I’m not sure I understand your point. The sentence in RFC6972 says
“The tracker (peer) protocol MUST take the frequency of message
      exchange and efficient bandwidth use into consideration when
      communicating chunk availability information (chunk information).
” IMO, the tracker protocol has already satisfied such requirement, just as I explained before. But you are say “the user may want to adjust the video
      definition based on the bandwidth (or user demand)
      automatically (or manually).
”I think this is not issue for tracker protocol, because peers report their bandwidth to the tracker which is already been included in current tracker protocol, and it is possible for a peer to leave a swarm firstly and then join another one (like you said based on user’s demard). So what kind of other abilities do you want the tracker protocol to have?