Subject: [ppsp] PPSP problem statemnet draft

From: "zhangyunfei" <[email-masked]>
Date: Tue, 10 Mar 2009 09:38:32 +0800

Hi,folks,
   The updated version of ppsp problem statement draft has been uploaded:
            Problem Statement of P2P Streaming Protocol (PPSP) 
                 draft-zhang-ppsp-problem-statement-01.txt 
http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt
Abstract 

   This draft proposes to develop an open p2p streaming protocol, namely 
   PPSP. We survey the current practice of p2p streaming applications, 
   analyze the incentive to develop PPSP and its applying scenarios. 
   Then we introduce the PPSP interaction process and state the problem 
   of PPSP and its scope. In the last section we also analyze the 
   relationship between PPSP and P2PSIP as well as RTSP.  

All comments are welcome.

                                        Yunfei

zhangyunfei
2009-03-10

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 10 Mar 2009 16:13:39 +0800

Hi Yunfei,
 
This version looks much better than the one you issued days ago. But
there are still some little comments from me.
 
As a problem statement, the most important thing is to answer why we
need this brand new protocol. You did it in the section 2 of the draft. 
 
Firstly, you named this part as "Incentive of an open P2P streaming
Protocol". Both Sherry and me think "Incentive" is not a good expression
here. It has the meaning of "Something, such as the fear of punishment
or the expectation of reward, that induces action or motivates effort".
Maybe, "Motivation" is a better word used here. 
 
Secondly, the order of some content in this section may need be
adjusted. In page 4, you firstly introduced client/server streaming and
answered why P2P. Then, you mentioned common underlying design and
similar architecture of current P2P streaming protocol (ppstream,
pplive...) to explain the possibility to develop an open P2P streaming
protocol: 
"To the best of our understanding, current p2p streaming 
   protocols have common underlying design principles. According to our 
   measurement work[11], existing p2p streaming systems like pplive, 
   ppstream and uusee deploy a similar architecture and signaling 
   transaction process. Therefore it's possible to develop an open p2p 
   streaming protocol to integrate existing p2p streaming protocols."
In my opinion, these part should be put at the end of Section 2. The
whole logic of the section should be: 
why P2P (the limits of client/server and benefits of p2p) --> why new
protocol (the necessary modification to current protocol like RTSP,
MMS,PNA...) -- > why open standard ( the limits of current proprietary
P2P streaming protocols and benefits from open one) --> the possibility
to integrate existing P2P streaming protocols (which is described
above).  
So, the above part should be introduced after analysing the necessity of
open standard. 
 
Thirdly, in page 5, you analysed the disadvantages of proprietary p2p
streaming protocols. It could be better to organize them into two main
problems: no interoperability (system, provider, content and user
interoperability) and protocol unknown (ISP management, hardware
production issues ). In the paragraph "What's more, an open p2p
streaming protocol has more benefit under the following scenarios.",
it's better to change "what's more" to "therefore" to express its
causality with the content in previous paragraph. 
 
In scenario 4) you mentioned its usage in mobile communication. However,
I do not think it can give any explanation to why using a open standard,
because a refined proprietary protocol , which cooperate with a
operator, can also achieve the purpose. It's has nothing to do with if
the protocol is open or not. Actually, this part well describes the
additional requirement scenario for PPSP to support mobile
communication, which should be discussed in a separate draft or another
section which talk about what ppsp will do, but not why ppsp should be
studied. 
 
Another small edit problem is in section 4, "2)" appears twice. And in
section 5.2 you use a term "PPSP control protocol", I think you may
wanna say "PPSP signaling protocol", right?
 
Best Regards
Xiao Lin

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext zhangyunfei
Sent: Tuesday, March 10, 2009 9:39 AM
To: [email-masked]
Subject: [ppsp] PPSP problem statemnet draft

Hi,folks,
   The updated version of ppsp problem statement draft has been
uploaded:
            Problem Statement of P2P Streaming Protocol (PPSP) 
                 draft-zhang-ppsp-problem-statement-01.txt 
http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-0
1.txt
Abstract 

 
                                        Yunfei

________________________________

zhangyunfei
2009-03-10

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 11 Mar 2009 14:39:37 +0800

Thanks so much,Lin,
   I totally agree with your comments.It's very valuable for modifying the drafts to make it better understood.
   Thanks so much for your sincere contributions.
                             Yunfei

zhangyunfei
2009-03-11

发件人： Xiao, Lin (NSN - CN/Beijing)
发送时间： 2009-03-10 16:14:08
收件人： ext zhangyunfei; [email-masked]
抄送： 
主题： RE: [ppsp] PPSP problem statemnet draft

Hi Yunfei,

This version looks much better than the one you issued days ago. But there are still some little comments from me.

As a problem statement, the most important thing is to answer why we need this brand new protocol. You did it in the section 2 of the draft. 

Firstly, you named this part as "Incentive of an open P2P streaming Protocol". Both Sherry and me think "Incentive" is not a good expression here. It has the meaning of "Something, such as the fear of punishment or the expectation of reward, that induces action or motivates effort". Maybe, "Motivation" is a better word used here. 

Secondly, the order of some content in this section may need be adjusted. In page 4, you firstly introduced client/server streaming and answered why P2P. Then, you mentioned common underlying design and similar architecture of current P2P streaming protocol (ppstream, pplive...) to explain the possibility to develop an open P2P streaming protocol: 
"To the best of our understanding, current p2p streaming 
   protocols have common underlying design principles. According to our 
   measurement work[11], existing p2p streaming systems like pplive, 
   ppstream and uusee deploy a similar architecture and signaling 
   transaction process. Therefore it's possible to develop an open p2p 
   streaming protocol to integrate existing p2p streaming protocols."
In my opinion, these part should be put at the end of Section 2. The whole logic of the section should be: 
why P2P (the limits of client/server and benefits of p2p) --> why new protocol (the necessary modification to current protocol like RTSP, MMS,PNA...) -- > why open standard ( the limits of current proprietary P2P streaming protocols and benefits from open one) --> the possibility to integrate existing P2P streaming protocols (which is described above).  
So, the above part should be introduced after analysing the necessity of open standard. 

Thirdly, in page 5, you analysed the disadvantages of proprietary p2p streaming protocols. It could be better to organize them into two main problems: no interoperability (system, provider, content and user interoperability) and protocol unknown (ISP management, hardware production issues ). In the paragraph "What's more, an open p2p streaming protocol has more benefit under the following scenarios.", it's better to change "what's more" to "therefore" to express its causality with the content in previous paragraph. 

In scenario 4) you mentioned its usage in mobile communication. However, I do not think it can give any explanation to why using a open standard, because a refined proprietary protocol , which cooperate with a operator, can also achieve the purpose. It's has nothing to do with if the protocol is open or not. Actually, this part well describes the additional requirement scenario for PPSP to support mobile communication, which should be discussed in a separate draft or another section which talk about what ppsp will do, but not why ppsp should be studied. 

Another small edit problem is in section 4, "2)" appears twice. And in section 5.2 you use a term "PPSP control protocol", I think you may wanna say "PPSP signaling protocol", right?

Best Regards
Xiao Lin

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Tuesday, March 10, 2009 9:39 AM
To: [email-masked]
Subject: [ppsp] PPSP problem statemnet draft

Hi,folks,

                                        Yunfei

zhangyunfei
2009-03-10

---

From: Mayuresh Bakshi <[email-masked]>
Date: Mon, 16 Mar 2009 14:35:50 -0700

Hi,

It¹s certainly nicely written and comprehensive draft. Section 2 on
³Motivation to use PPSP² is well covered for convincing use cases.

On section 4, can you please clarify more on following 2 statements:

    -> One to many 
   communication is different from one to one communication where there
   is known destination to visit. In one to many communications, the
   destinations are unknown and the concrete data are stored piece by
   piece in different peers and the key is to find those data and
   reassemble them.

  -> Because there are lot of
   peer candidates in PPSP, NAT transversal is not as important as that
   in P2PSIP and public peers can be found with higher probability

        -> Does this mean that protocol will work only with peers having
public IP. IMHO, to extend the reach and build robust network it¹s necessary
to reach peers with private IP

BTW, is the time (8-10 pm on Monday 23rd) confirmed for the meet.

Thanks,

-Mayuresh

On 3/9/09 5:38 PM, "zhangyunfei" <[email-masked]> wrote:

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 17 Mar 2009 11:13:13 +0800

Hi，Mayuresh，
   Thanks for your comments.
1)One to many communcation primitive or data centric communication primitive refers to the p2p streaming envirnment where the centric thing is data(chunk) instread of the object storing data(the traditioanl terminal in end-to-end commuciation).There are multiple nodes storing the same data chunk,therefore once one node retrieves a specific data chunk, it may has multiple alternatives to communicate with. The requesting node doesn't care which node it connects with.Rahter it cares where it can download the data. This is so called one to many communcation.
It leads to a different design idea compared to one-to-one communication,e.g.,the architecture of one-to-many communication is usaully meshed in order to loacte the data as soon as possible; peers need to exchange what they have periodically to ensure the searching efficiency.
2)Maybe I don't express the meaning explicitly.I want to stress that it's not so impendent to solve NAT traversal in p2p streaming compared to p2psip.In P2PSIP this is a mandatory requirement to support NAT tranversal since the end-to-end communication is not ensured otherwise.In p2p streaming even if there are quite many nodes with private IP,it doesn't necessarily find another node with private IP to connect with for a specific data chunk.But it doesn't mean that we needn't NAT tranversal function at all.I agree with you that it’s necessary to reach peers with private IP
to extend the reach and build robust network.
3)As for the bar bof place,I just receive the confirmation from the IETF seceratary.The time is 2000-2200 Monday and the place is Continental 3.
I will post the agend of the bar bof right now in PPSP mailing list.

zhangyunfei
2009-03-17

发件人： Mayuresh Bakshi
发送时间： 2009-03-17 05:38:14
收件人： zhangyunfei; [email-masked]
抄送： 
主题： Re: [ppsp] PPSP problem statemnet draft

Hi,

It’s certainly nicely written and comprehensive draft. Section 2 on “Motivation to use PPSP” is well covered for convincing use cases. 

    -> One to many 

        -> Does this mean that protocol will work only with peers having public IP. IMHO, to extend the reach and build robust network it’s necessary to reach peers with private IP

Thanks,

-Mayuresh

Hi,folks,

 
                                        Yunfei

zhangyunfei
2009-03-10

---

From: Song Haibin <[email-masked]>
Date: Tue, 17 Mar 2009 11:25:18 +0800

Hi Mayuresh,

 -> Does this mean that protocol will work only with peers having public IP.
IMHO, to extend the reach and build robust network it's necessary to reach
peers with private IP

I agree that the peers with private IP should also contribute to the system.
We can assume that in some scenarios, most peers probably access the network
through residential gateways which act as NATs, and the available processing
resources of these peers should be utilized.

However, setting up a connection with a NATed peer usually needs more
transactions than that with a peer of public IP. For the latency sensitive
streaming application, perhaps it is better to contact those publicly
available peers first (if they have the ability to contribute more to the
system) and then try to setup connections with the NATed peers.

I guess it is reasonable to assume there are a little portion of peers which
only acquire service from the system without any contribution, due to
various reasons.

My 2 cents.

Best Regards,
Haibin
Skype: alexsonghw

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mayuresh Bakshi
Sent: Tuesday, March 17, 2009 5:36 AM
To: zhangyunfei; [email-masked]
Subject: Re: [ppsp] PPSP problem statemnet draft

Hi,

It's certainly nicely written and comprehensive draft. Section 2 on
"Motivation to use PPSP" is well covered for convincing use cases. 

    -> One to many 

        -> Does this mean that protocol will work only with peers having
public IP. IMHO, to extend the reach and build robust network it's necessary
to reach peers with private IP

Thanks,

-Mayuresh

Hi,folks,
   The updated version of ppsp problem statement draft has been uploaded:
            Problem Statement of P2P Streaming Protocol (PPSP) 
                 draft-zhang-ppsp-problem-statement-01.txt 
http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.tx
t
Abstract 

 
                                        Yunfei

  _____  

zhangyunfei
2009-03-10

  _____

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 17 Mar 2009 08:58:02 -0700

Hello,

Comments inline...

On 3/16/09 8:13 PM, "zhangyunfei" <[email-masked]> wrote:

> 1)One to many communcation primitive or data centric communication primitive
> refers to the p2p streaming envirnment where the centric thing is data(chunk)
> instread of the object storing data(the traditioanl terminal in end-to-end
> commuciation).There are multiple nodes storing the same data chunk,therefore
> once one node retrieves a specific data chunk, it may has multiple
> alternatives to communicate with. The requesting node doesn't care which node
> it connects with.Rahter it cares where it can download the data. This is so
> called one to many communcation.
> 
> [RP] It certainly cares which node is connects. Nodes with more upload
> capacity and/or with lowest cost are usually preferred. Unless the new
> protocol you are proposing does not differentiate between peers, which would
> be surprising, given the fact that the current P2P streaming protocols such as
> a Bittorrent DNA/Pando/Others have such peer preference algorithms as an
> integral part of their workings.
> 
> Moreover, smart trackers can also optimize or rank peers when sending
> information to clients.
> 
> It leads to a different design idea compared to one-to-one
> communication,e.g.,the architecture of one-to-many communication is usaully
> meshed in order to loacte the data as soon as possible; peers need to exchange
> what they have periodically to ensure the searching efficiency.
> 2)Maybe I don't express the meaning explicitly.I want to stress that it's not
> so impendent to solve NAT traversal in p2p streaming compared to p2psip.In
> P2PSIP this is a mandatory requirement to support NAT tranversal since the
> end-to-end communication is not ensured otherwise.In p2p streaming even if
> there are quite many nodes with private IP,it doesn't necessarily find another
> node with private IP to connect with for a specific data chunk.But it doesn't
> mean that we needn't NAT tranversal function at all.I agree with you that it’s
> necessary to reach peers with private IP
> [RP] Solving the NAT traversal problem should not be part of the protocol
> core, but the protocol should definitely work through NATs and allow
> bi-directional communication between v4(private)<->v4(public), etc. There are
> many large deployments where most of the client are behind residential
> gateways. 
> 
> 3)As for the bar bof place,I just receive the confirmation from the IETF
> seceratary.The time is 2000-2200 Monday and the place is Continental 3.
> It’s certainly nicely written and comprehensive draft. Section 2 on
> “Motivation to use PPSP” is well covered for convincing use cases.
> 
> public IP. IMHO, to extend the reach and build robust network it’s necessary

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Mar 2009 20:27:51 -0700

Let me try here:

(1) Peers selection vs. Peer gossiping: PPSP addresses efficient data
exchange between peers. In this case, each peer can reach to several peers
in close proximity (hopefully), detect each other's content through
gossiping, and exchange data in chunks/piece/sub-piece... Peer discovery and
selection are not the key here, and should not be the key here. Rather, each
peer depends on the Tracker Manager making the smart decision. If P4P gets
its way, sure, let the Tracker Manager gives the peering list to the peers
to trigger chunk exchange.

(2) NAT and Client Interface: It seems that PPSP can be very efficient in
dealing with P2P data exchange within core/metro/access networks. I would
hope it stays at way. Imagine, if one uses PPSP to cache data a local
server, the users can then get the data through many means, including
getting data from port 80. Then do we need to worry about NAT at all?

Finally, I would not consider this as a new protocol, as millions have been
using it for years. What's new here is that it finally has gathered enough
incentive to be open. :-)

Regards,

- Ping

2009/3/17 Reinaldo Penno <[email-masked]>

> 1)One to many communcation primitive or data centric communication
> primitive refers to the p2p streaming envirnment where the centric thing is
> data(chunk) instread of the object storing data(the traditioanl terminal
> in end-to-end commuciation).There are multiple nodes storing the same data
> chunk,therefore once one node retrieves a specific data chunk, it may has
> multiple alternatives to communicate with. The requesting node doesn't care which
> node it connects with.Rahter it cares where it can download the data. This
> is so called one to many communcation.
>
> be surprising, given the fact that the current P2P streaming protocols such
> as a Bittorrent DNA/Pando/Others have such peer preference algorithms as an
> meshed in order to loacte the data as soon as possible; peers need to
> exchange what they have periodically to ensure the searching efficiency.
> 2)Maybe I don't express the meaning explicitly.I want to stress that it's
> not so impendent to solve NAT traversal in p2p streaming compared to
> p2psip.In P2PSIP this is a mandatory requirement to support NAT tranversal
> since the end-to-end communication is not ensured otherwise.In p2p streaming
> even if there are quite many nodes with private IP,it doesn't necessarily
> find another node with private IP to connect with for a specific data
> chunk.But it doesn't mean that we needn't NAT tranversal function at all.I
> agree with you that it’s necessary to reach peers with private IP
> bi-directional communication between v4(private)<->v4(public), etc. There
> are many large deployments where most of the client are behind residential
> gateways.
>
> ------------------------------
> zhangyunfei
> 2009-03-17
> ------------------------------
> *发件人：* Mayuresh Bakshi
> *发送时间：* 2009-03-17 05:38:14
> *收件人：* zhangyunfei; [email-masked]
> *抄送：*
> *主题：* Re: [ppsp] PPSP problem statemnet draft
>
>
> Hi,
>
> ------------------------------
> zhangyunfei
> 2009-03-10
>
>
> ------------------------------
> ------------------------------

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 17 Mar 2009 22:59:30 -0700

Hello, 

Comments inline...

On 3/17/09 8:27 PM, "Ping Pan" <[email-masked]> wrote:

> Let me try here:
> 
> (1) Peers selection vs. Peer gossiping: PPSP addresses efficient data exchange
> between peers. In this case, each peer can reach to several peers in close
> proximity (hopefully), detect each other's content through gossiping, and
> exchange data in chunks/piece/sub-piece... Peer discovery and selection are
> not the key here, and should not be the key here. Rather, each peer depends on
> the Tracker Manager making the smart decision. If P4P gets its way, sure, let
> the Tracker Manager gives the peering list to the peers to trigger chunk
> exchange.
> 
> [RP] I think I’m missing something. Your premises do not correspond to how P2P
> protocols work today. P2P protocols do not depend on the tracker to perform
> peer selection today. The tracker chooses a set of 50 –100 peers at random and
> the client is the one that chooses the best ones from that set by probing.
> So, if the PPSP client does not choose the best peers as you mention and the
> tracker also does not it, who does it? Are you saying that peer selection is
> random (based purely on content availability) ? That seems quite a departure
> to what is already deployed today in millions and millions of hosts.
> 
> dealing with P2P data exchange within core/metro/access networks. I would hope
> it stays at way. Imagine, if one uses PPSP to cache data a local server, the
> users can then get the data through many means, including getting data from
> port 80. Then do we need to worry about NAT at all?
> 
> [RP] IMO every protocol or use of a certain protocol nowadays need to worry
> about NAT.  There are v4/v4, v4/v6, v6/v6 NATs. At a minimum some section
> saying how peers behind NAT can be contacted or contact other peers is needed.
> Do you need an ALG? Do you rely on rendezvous hosts? Do you carry IP addresses
> in the payload that might need to be translated? , etc, etc
> 
> [RP] That’s fair, but even then NAT considerations should be in place.
> 
> Regards,
> 
> - Ping
> 
> 
>> On 3/16/09 8:13 PM, "zhangyunfei" <[email-masked]
>> <http://[email-masked]> > wrote:
>> 
>>> Hi，Mayuresh，
>>> refers to the p2p streaming envirnment where the centric thing is
>>> data(chunk) instread of the object storing data(the traditioanl terminal in
>>> end-to-end commuciation).There are multiple nodes storing the same data
>>> multiple alternatives to communicate with. The requesting node doesn't care
>>> which node it connects with.Rahter it cares where it can download the data.
>>> This is so called one to many communcation.
>>> 
>>> 收件人： zhangyunfei; [email-masked] <http://[email-masked]>
>>> 抄送： 
>>> On 3/9/09 5:38 PM, "zhangyunfei" <[email-masked]
>>> <http://[email-masked]> > wrote:
>>> 
>>>> Hi,folks,
>>>> [email-masked] <http://[email-masked]>
>>> [email-masked] <http://[email-masked]>

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Mar 2009 23:22:18 -0700

First, I would not count on the current P2P practice as the Holy Grail. :-)
Second, as shown in the other drafts, PPSP seems to query the tracker
manager for peerlist. I would assume that the tracker manager would have
some good ideas about peers and locality etc.. I also recall that P4P
introduces some mechanism that uses Trackers to direct user requests.

As for the NAT comment, I think the original message was that it would NOT
the emphasis. Nevertheless, NAT was described and measured in PPlive's
Sigcomm paper (http://ccr.sigcomm.org/online/?q=node/404)<http://ccr.sigcomm.org/online/?q=node/404>

>From your description, how is that relevant to PPSP? It's a general problem,
no?

- Ping

On Tue, Mar 17, 2009 at 10:59 PM, Reinaldo Penno <[email-masked]> wrote:

> [RP] I think I’m missing something. Your premises do not correspond to how
> P2P protocols work today. P2P protocols do not depend on the tracker to
> perform peer selection today. The tracker chooses a set of 50 –100 peers at
> random and the client is the one that chooses the best ones from that set by
> probing.  So, if the PPSP client does not choose the best peers as you
> mention and the tracker also does not it, who does it? Are you saying that
> peer selection is random (based purely on content availability) ? That seems
> quite a departure to what is already deployed today in millions and millions
> of hosts.
>
> saying how peers behind NAT can be contacted or contact other peers is
> needed. Do you need an ALG? Do you rely on rendezvous hosts? Do you carry IP
> addresses in the payload that might need to be translated? , etc, etc
>
> On 3/16/09 8:13 PM, "zhangyunfei" <[email-masked] <
> http://[email-masked]> > wrote:
>
> Hi，Mayuresh，
> *收件人：* zhangyunfei; [email-masked] <http://[email-masked]>
> *抄送：*
> On 3/9/09 5:38 PM, "zhangyunfei" <[email-masked] <
> http://[email-masked]> > wrote:
>
> Hi,folks,

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 18 Mar 2009 14:17:54 +0800

zhangyunfei
2009-03-18

发件人： Reinaldo Penno
发送时间： 2009-03-18 00:00:38
收件人： zhangyunfei; Mayuresh Bakshi; [email-masked]
抄送： 
主题： Re: [ppsp] PPSP problem statemnet draft

Hello,

Comments inline...

Hi，Mayuresh，

[RP] It certainly cares which node is connects. Nodes with more upload capacity and/or with lowest cost are usually preferred. Unless the new protocol you are proposing does not differentiate between peers, which would be surprising, given the fact that the current P2P streaming protocols such as a Bittorrent DNA/Pando/Others have such peer preference algorithms as an integral part of their workings. 

Moreover, smart trackers can also optimize or rank peers when sending information to clients. 

I agree with your point.The very meaning is that a peer doesn't know the destination peer in advance or by default.Even a peer has preference in selecting which one to connect with,it doesn't know that peer before finishing search by PPSP process.

[RP] Solving the NAT traversal problem should not be part of the protocol core, but the protocol should definitely work through NATs and allow bi-directional communication between v4(private)<->v4(public), etc. There are many large deployments where most of the client are behind residential gateways. 
I agree with your point.

zhangyunfei
2009-03-17

发件人： Mayuresh Bakshi

Hi,

    -> One to many 

Thanks,

-Mayuresh

Hi,folks,

 
                                        Yunfei

zhangyunfei
2009-03-10

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 17 Mar 2009 23:39:30 -0700

On 3/17/09 11:22 PM, "Ping Pan" <[email-masked]> wrote:

> [RP] Sure, but you cannot just brush aside such a strong and proven de facto
> standard. 
> 
> Second, as shown in the other drafts, PPSP seems to query the tracker manager
> for peerlist. I would assume that the tracker manager would have some good
> ideas about peers and locality etc..
> 
> [RP] They do not. Current Bittorrent trackers choose peers at random and
> bittorrent makes up the absolute majority of  P2P traffic. Clients are the
> ones that perform peer selection.
> 
> I also recall that P4P introduces some mechanism that uses Trackers to direct
> user requests.
> 
> [RP] Yes, but none of the major bittorrent clients support P4P.
> 
> As for the NAT comment, I think the original message was that it would NOT the
> emphasis. Nevertheless, NAT was described and measured in PPlive's
> Sigcomm paper (http://ccr.sigcomm.org/online/?q=node/404)
> <http://ccr.sigcomm.org/online/?q=node/404>
> 
> [RP] thanks for the reference.
> 
> [RP]  It is relevant in a sense that should be taken into consideration in the
> design and/or choice of protocol. The more NAT friendly, the better chance to
> get widely deployed. SIP, for example,  is still struggling with NAT traversal
> after a stack of RFC/drafts have been written on the subject.
> 
> - Ping
> 
> 
>> On 3/17/09 8:27 PM, "Ping Pan" <[email-masked] <http://[email-masked]> >
>> wrote:
>> 
>>> Let me try here:
>>> 
>>> 2009/3/17 Reinaldo Penno <[email-masked] <http://[email-masked]> >
>>>> Hello,
>>>> 
>>>> Comments inline...
>>>> 
>>>> 
>>>> 
>>>> 
>>>> <http://[email-masked]>  <http://[email-masked]>
>>>> > wrote:
>>>> 
>>>>> Hi，Mayuresh，
>>>>> primitive refers to the p2p streaming envirnment where the centric thing
>>>>> is data(chunk) instread of the object storing data(the traditioanl
>>>>> terminal in end-to-end commuciation).There are multiple nodes storing the
>>>>> same data chunk,therefore once one node retrieves a specific data chunk,
>>>>> it may has multiple alternatives to communicate with. The requesting node
>>>>> doesn't care which node it connects with.Rahter it cares where it can
>>>>> download the data. This is so called one to many communcation.
>>>>> 
>>>>> protocol you are proposing does not differentiate between peers, which
>>>>> would be surprising, given the fact that the current P2P streaming
>>>>> protocols such as a Bittorrent DNA/Pando/Others have such peer preference
>>>>> algorithms as an integral part of their workings.
>>>>> 
>>>>> communication,e.g.,the architecture of one-to-many communication is
>>>>> usaully meshed in order to loacte the data as soon as possible; peers need
>>>>> to exchange what they have periodically to ensure the searching
>>>>> efficiency.
>>>>> since the end-to-end communication is not ensured otherwise.In p2p
>>>>> streaming even if there are quite many nodes with private IP,it doesn't
>>>>> necessarily find another node with private IP to connect with for a
>>>>> specific data chunk.But it doesn't mean that we needn't NAT tranversal
>>>>> function at all.I agree with you that it’s necessary to reach peers with
>>>>> private IP
>>>>> <http://[email-masked]>
>>>>> public IP. IMHO, to extend the reach and build robust network it’s
>>>>> <http://[email-masked]>  <http://[email-masked]>
>>>>> > wrote:
>>>>> 
>>>>>> Hi,folks,
>>>>>> [email-masked] <http://[email-masked]>  <http://[email-masked]>
>>>>> [email-masked] <http://[email-masked]>  <http://[email-masked]>

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Mar 2009 23:58:07 -0700

On Tue, Mar 17, 2009 at 11:39 PM, Reinaldo Penno <[email-masked]> wrote:
>
> Second, as shown in the other drafts, PPSP seems to query the tracker manager for peerlist. I would assume that the tracker manager would have some good ideas about peers and locality etc..
>
> [RP] They do not. Current Bittorrent trackers choose peers at random and bittorrent makes up the absolute majority of  P2P traffic. Clients are the ones that perform peer selection.
>

Let's separate the applications that PPSP is trying to address from
the applications using BitTorrent. Both PPlive and PPstream address
streaming video in a more controlled environment. They use some of the
P2P techniques for data transport, but that's where the similarity
ends, I hope.

> I also recall that P4P introduces some mechanism that uses Trackers to direct user requests.
>

I thought that's why we are here. :-)

> [RP]  It is relevant in a sense that should be taken into consideration in the design and/or choice of protocol. The more NAT friendly, the better chance to get widely deployed. SIP, for example,  is still struggling with NAT traversal after a stack of RFC/drafts have been written on the subject.

:-) I have issues with this statement at multiple levels, but none is
relevant wrt PPSP. Yes, I agree PPSP needs to take NAT Traversal/STUN
into consideration.

Regards,

- Ping

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 18 Mar 2009 17:12:46 +0800

Comments inline again:)

zhangyunfei
2009-03-18

发件人： Reinaldo Penno
发送时间： 2009-03-18 14:02:20
收件人： Ping Pan
抄送： zhangyunfei; Mayuresh Bakshi; [email-masked]
主题： Re: [ppsp] PPSP problem statemnet draft

Hello, 

Comments inline...

Let me try here:

(1) Peers selection vs. Peer gossiping: PPSP addresses efficient data exchange between peers.?In this case, each peer can reach to several peers in close proximity (hopefully), detect each other's content through gossiping, and exchange data in chunks/piece/sub-piece... Peer discovery and selection are not the key here, and should not be the key here. Rather, each peer depends on the Tracker Manager making the smart decision. If P4P gets its way, sure, let the Tracker Manager gives the peering list to the peers to trigger chunk exchange.

[RP] I think I’m missing something. Your premises do not correspond to how P2P protocols work today. P2P protocols do not depend on the tracker to perform peer selection today. The tracker chooses a set of 50 –100 peers at random and the client is the one that chooses the best ones from that set by probing.  So, if the PPSP client does not choose the best peers as you mention and the tracker also does not it, who does it? Are you saying that peer selection is random (based purely on content availability) ? That seems quite a departure to what is already deployed today in millions and millions of hosts. 
PPSP doesn't exclude the possibility of using tracker directly for peer selection,I think.It's an alternative to today's practice.

(2) NAT and Client Interface: It seems that PPSP can be very efficient in dealing with P2P data exchange within core/metro/access networks. I would hope it stays at way. Imagine, if one uses PPSP to cache data a local server, the users can then get the data through many means, including getting data from port 80. Then do we need to worry about NAT at all?

[RP] IMO every protocol or use of a certain protocol nowadays need to worry about NAT.  There are v4/v4, v4/v6, v6/v6 NATs. At a minimum some section saying how peers behind NAT can be contacted or contact other peers is needed. Do you need an ALG? Do you rely on rendezvous hosts? Do you carry IP addresses in the payload that might need to be translated? , etc, etc

Finally, I would not consider this as a new protocol, as millions have been using it for years. What's new here is that it finally has gathered enough incentive to be open. :-)
Thank you,it was really a difficult process to get to today's progress:)Thanks for all of your contribution.

Regards,

- Ping

Hello,

Comments inline...

On 3/16/09 8:13 PM, "zhangyunfei" <[email-masked] <http://[email-masked]> > wrote:

Hi，Mayuresh，
???Thanks for your comments.
1)One to many communcation primitive or data centric communication primitive refers to the p2p streaming envirnment where the centric thing is data(chunk) instread of the object storing data(the traditioanl terminal in end-to-end commuciation).There are multiple nodes storing the same data chunk,therefore once one node retrieves a specific data chunk, it may has multiple alternatives to communicate with. The requesting node doesn't care which node it connects with.Rahter it cares where it can download the data. This is so called one to many communcation.

Moreover, smart trackers can also optimize or rank peers when sending information to clients. ?

zhangyunfei
2009-03-17

发件人： Mayuresh Bakshi

Hi,

????-> One to many 
???communication is different from one to one communication where there 
???is known destination to visit. In one to many communications, the 
???destinations are unknown and the concrete data are stored piece by 
???piece in different peers and the key is to find those data and 
???reassemble them. 

??-> Because there are lot of 
???peer candidates in PPSP, NAT transversal is not as important as that 
???in P2PSIP and public peers can be found with higher probability

????????-> Does this mean that protocol will work only with peers having public IP. IMHO, to extend the reach and build robust network it’s necessary to reach peers with private IP

Thanks,

-Mayuresh

On 3/9/09 5:38 PM, "zhangyunfei" <[email-masked] <http://[email-masked]> > wrote:

Hi,folks,
???The updated version of ?ppsp problem statement draft has been ?uploaded:
????????????Problem ?Statement of P2P Streaming Protocol (PPSP) ?
?????????????????draft-zhang-ppsp-problem-statement-01.txt ?
http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.txt
Abstract ?

???This draft proposes to develop an open p2p streaming ?protocol, namely 
???PPSP. We survey the current practice of ?p2p streaming applications, 
???analyze the incentive to ?develop PPSP and its applying scenarios. 
???Then we ?introduce the PPSP interaction process and state the problem ?
???of PPSP and its scope. In the last section we also ?analyze the 
???relationship between PPSP and P2PSIP as well ?as RTSP. ?

All comments are ?welcome.
?
????????????????????????????????????????Yunfei
?
?

zhangyunfei
2009-03-10

?

ppsp ?mailing ?list

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 18 Mar 2009 07:38:59 -0700

Hello,

A few comments inline...

> P2P techniques for data transport, but that's where the similarity

I'm okay with this except for the 'controlled' part. Can you elaborate on
that? 

> I thought that's why we are here. :-)

Okay, I guess I see where you are going so let me try a different way. Is
tracker based peer selection/guidance a pre-requisite and/or an integral
part of the PPSP architecture? If no, how clients choose peers on their own,
if yes, that's great and reference appropriate specs.

My suggestion is then to specify in the doc that tracker guidance is a
pre-requisite (or not) for the proper workings of the PPSP. If it is not a
pre-requisite, then discuss how clients could fall back into a client driven
discovery (such as DHT) and peer selection.

> 
>> [RP]  It is relevant in a sense that should be taken into consideration in
>> the design and/or choice of protocol. The more NAT friendly, the better
>> chance to get widely deployed. SIP, for example,  is still struggling with
>> NAT traversal after a stack of RFC/drafts have been written on the subject.
>

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 19 Mar 2009 09:54:54 +0800

Please see inline for the reply.

zhangyunfei
2009-03-19

发件人： Reinaldo Penno
发送时间： 2009-03-18 22:41:42
收件人： Ping Pan
抄送： zhangyunfei; Mayuresh Bakshi; [email-masked]
主题： Re: [ppsp] PPSP problem statemnet draft

Hello,

A  few  comments  inline...

On  3/17/09  11:58  PM,  "Ping  Pan"   <[email-masked] >  wrote:

>  On  Tue,  Mar  17,  2009  at  11:39  PM,  Reinaldo  Penno   <[email-masked] >  wrote:
> >  
      It does in PPSP.We'll add some extra node inforation like locality,node stability,node capability,etc..besides current p2p streaming 
     protocols.
> >  bittorrent  makes  up  the  absolute  majority  of  燩2P  traffic.  Clients  are  the

I agree with this.In ppsp the first task we listed is to discuss the architecture of PPSP systems.
We take tracker-based architeture a starting point of the discussion.However we don't exclude the possiblity of using DHT or other means
for node discovery.But in the first view,trackerless architecture is not suitable for real-time streaming for search efficiency.It may be used in 
VoD senarios.

>  
> >  [RP]  營t  is  relevant  in  a  sense  that  should  be  taken  into  consideration  in
> >  chance  to  get  widely  deployed.  SIP,  for  example,  爄s  still  struggling  with

---

From: zongning 63316 <[email-masked]>
Date: Thu, 19 Mar 2009 19:54:08 +0800

Please see inline.

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em
ail immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: Reinaldo Penno <[email-masked]>
日期: 星期三, 三月 18日, 2009 下午10:42
主题: Re: [ppsp] PPSP problem statemnet draft
收件人: Ping Pan <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

> >> bittorrent makes up the absolute majority of ?P2P traffic. 
> Clients are the
> tracker based peer selection/guidance a pre-requisite and/or an 
> integralpart of the PPSP architecture? If no, how clients choose 
> peers on their own,

[Ning Zong] IMO, peer selection is not in the focus of PPSP at this moment. At stated in current PPSP documents, the core of PPSP would help peers to discover which chunks are in which peers with an efficient way. Peer selection mechanism will leave to the application. They are two questions, one is where is the content, another is how to choose better-than-random content fetch. 

> > 
> >> [RP] ?It is relevant in a sense that should be taken into 
> consideration in
> >> chance to get widely deployed. SIP, for example, ?is still 
> struggling with
> > relevant wrt PPSP. Yes, I agree PPSP needs to take NAT 
> Traversal/STUN> into consideration.
> > 
> > Regards,
> > 
> > - Ping
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 19 Mar 2009 05:01:38 -0700

Agree.
Further, it is not clear to me if we should standard the interface between
the tracker managers and the peers initially. At least, that work should be
a separated work item from the inter-peer communication.

Also, it is not clear to me how DHT would apply in the operation here.

- Ping

2009/3/19 zongning 63316 <[email-masked]>

>  This email and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or em
> [Ning Zong] IMO, peer selection is not in the focus of PPSP at this moment.
> At stated in current PPSP documents, the core of PPSP would help peers to
> discover which chunks are in which peers with an efficient way. Peer
> selection mechanism will leave to the application. They are two questions,
> one is where is the content, another is how to choose better-than-random
> content fetch.
>
> > >

---

From: "Hui Zhang" <[email-masked]>
Date: Thu, 19 Mar 2009 17:17:19 -0400

Following the discussions from Ping and Reinaldo, following are my two cents:

surrounding the choice of tracker-assisted and self-based peer selection schemes, 

two parts in PPSP definition will be affected: 

1.       the message format between tracker and clients, in terms of what information will be exchanged

2.       an (optional) peer probing protocol if a self-based peer selection scheme is a choice.

Part 1 contains the interface that Ping mentioned, and it is a critical component for standardization if we want to address the motivations stated in the PPSP problem statement.

Part 2 might turn out to be have no need for standardization in the context of PPSP if the peer probing protocol would leverage some standardized scheme (e.g., ping, tarceroute, P4P, and etc) for the Peer preference ranking.

On the internal scheme for peer ranking (either by a tracker or a client itself), it might be better let P2P streaming app. providers to define their proprietary schemes. 

Surrounding the NAT traversal functionality, I think the coming BoF bar meeting is a perfect place to get more information on what’re the current practice (e.g. James from PPlive)

and what is the right priority to be assigned.  

Lastly, I have to say I totally agreed on Ping’s comment on the PPSP initiative:  “I would not consider this as a new protocol, as millions have been using it for years. What's new here is that it finally has gathered enough incentive to be open.”

Regards,

Hui

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping Pan
Sent: Thursday, March 19, 2009 8:02 AM
To: zongning 63316
Cc: [email-masked]
Subject: Re: [ppsp] PPSP problem statemnet draft

Agree.

Further, it is not clear to me if we should standard the interface between the tracker managers and the peers initially. At least, that work should be a separated work item from the inter-peer communication.

- Ping

Please see inline.