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

["Huangyihong (Rachel)" <[e-mail]>]

Hi Tianming,

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

BR,
Rachel

From: 赵天明 [mailto:[e-mail]]
Sent: Monday, December 22, 2014 3:02 PM
To: Huangyihong (Rachel); [e-mail]
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


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.

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?