Subject: [ppsp] Pull or Pushed-based P2P Streaming?

From: Martin Stiemerling <[email-masked]>
Date: Wed, 27 Oct 2010 14:05:56 +0000

Hi all,

There are basically two ways on how peers "work out" the exchange of their data elements (i.e., the chunks):
- either a peer requests the download of chunks from a remote peer (AKA pull-based) or
- the remote peer pushes chunks to the a particular peer (AKA push-based). This may be either a blind-push or an informed-push.

The problem statement seems to assume a pull-based system (Section 3, bullet 1.3) but from the mailing list and past discussions it does not seem clear to me that there was a decision made. 

However, I see the chance to let the PPSP protocol run in both "modes", but this would require some special considerations during the protocol design. 

So, is push out of the game or didn't we consider this until yet?

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 27 Oct 2010 13:17:56 -0400

My take is that both are still in the running, despite lots of people
(myself, for one) leaning toward a pull-based in our proposed design.
I certainly don't think this is a settled issue yet and would love to
see some more mailing list discussion.

David

On Wed, Oct 27, 2010 at 10:05 AM, Martin Stiemerling
<[email-masked]> wrote:
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>

---

From: "Ye (Yale) Wang" <[email-masked]>
Date: Wed, 27 Oct 2010 14:45:16 -0400

Hi,

Both Pull and Push-based design have their own pros and cons.  And they
both are used in running systems: e.g., Zattoo is Push-based, PPTV is
Pull-based, etc.

Pull-based data exchange is simpler and more robust to peer churn: each
peer just requests the data it needs and responds to requests from
neighbors.  Neighbor substitution does not impact the data exchange.

However, such a design requires that each peer knows what data can be
downloaded from each neighbor.  This is usually done by frequent buffer
map exchanges between peers.  
Buffer map update is non-negligible control overhead: e.g., if a peer
sends buffer map update to 20 neighbors every 2 seconds, then i) the
peer need to send out 10 extra packets per second (for a 300-kbps
channel, a peer sends out ~30 packets per second on average, so the
overhead is roughly 25%), ii) download request can be delayed 1 second
per hop on average (this is not good for large-scale channel).

In push-based data exchange, uploader directly forward data to
downloaders.  This substantially reduces buffer map update overhead, but
push-based design requires uploaders and downloader/subscribers to
manage their relationship (e.g., uploader decides to send which
substreams to which downloader).  This can be very complicated
considering peer churn.

Given the tradeoff, a combination of both pull and push in system design
should not be a surprise.

Thanks,
Ye

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 27 Oct 2010 15:37:52 -0400

> should not be a surprise.
Either a hybrid design, or a design chosen for a given context:

- push: low churn/ample CDN backups, requiring low lags, a software team 
that can handle higher complexity

- pull: relatively higher churns, lower demand on lags, and simpler 
software design

I feel that it is a reasonable approach to first focus on pull based 
systems, as I see that a real push
system will typically still need a pull based system as a backup when 
the parent//child relationship
is not established or disrupted. Thus, it is a "component" of a push 
based system. I can see that
someone might argue that network coding may allow pure pushed based 
systems, or the CDN is so
powerful that clients pull only from CDN, which can be simpler. It will 
be interesting to hear more
from designers of push based systems.

Richard

---

From: [email-masked]
Date: Thu, 28 Oct 2010 14:03:00 +0800

Hi, Richard

What's the meaning of "ample CDN backups"?
I raised some requirements related to CDN in the WG before. I think 
first/hot/all chunks can be pushed to CDN nodes and CDN nodes can push 
chunks to user nodes.
Pushing first chunk can reduce the startup time.

BTW: As I know, UUSee and RayV adopt Push-based design with network 
coding.
BR
Lichun

"Y. R. Yang" <[email-masked]> 
发件人:  [email-masked]
2010-10-28 03:37

收件人
"Ye (Yale) Wang" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [ppsp] Pull or Pushed-based P2P Streaming?

Richard

>>> - the remote peer pushes chunks to the a particular peer (AKA 
push-based). This may be either a blind-push or an informed-push.
>>>
>>> The problem statement seems to assume a pull-based system (Section 3, 
bullet 1.3) but from the mailing list and past discussions it does not 
seem clear to me that there was a decision made.
>>>
>>> However, I see the chance to let the PPSP protocol run in both 
"modes", but this would require some special considerations during the 
protocol design.
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
London W3 6BL | Registered in England 2832014

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: chen tian <[email-masked]>
Date: Thu, 28 Oct 2010 16:36:32 +0800

Hi Lichun,

In p2p streaming systems, if some pieces are not yet retrieved when their
playback deadlines are approaching, a peer can fetch them directly from CDN
as a backup. I think this is the meaning of “CDN backups”.

You are proposing that: CDN nodes can be used as the first tier reflectors
of the whole p2p overlay. I do not think this issue has direct relationship
with the design choice of push/pull mode.

Chen Tian

2010/10/28 <[email-masked]>

> BTW: As I know, UUSee and RayV adopt Push-based design with network coding.
> BR
> Lichun
>
>
>
>   *"Y. R. Yang" <[email-masked]>*
> bullet 1.3) but from the mailing list and past discussions it does not seem
> clear to me that there was a decision made.
> >>>
> >>> However, I see the chance to let the PPSP protocol run in both "modes",
> but this would require some special considerations during the protocol
> design.
> >>>

---

From: [email-masked]
Date: Thu, 28 Oct 2010 17:17:41 +0800

Hi， Chen Tian

Fetching from CDN as a backup is pull not push.
Push mode can be chosen for the context of using CDN nodes as the first 
tier reflectors.

BR
Lichun

chen tian <[email-masked]> 
2010-10-28 16:36

收件人
[email-masked]
抄送
"Y. R. Yang" <[email-masked]>, "[email-masked]" <[email-masked]>, 
[email-masked]
主题
Re: [ppsp] Pull or Pushed-based P2P Streaming?

Hi Lichun,
 
In p2p streaming systems, if some pieces are not yet retrieved when their 
playback deadlines are approaching, a peer can fetch them directly from 
CDN as a backup. I think this is the meaning of “CDN backups”.
 
You are proposing that: CDN nodes can be used as the first tier reflectors 
of the whole p2p overlay. I do not think this issue has direct 
relationship with the design choice of push/pull mode.
 
Chen Tian

Hi, Richard 

收件人

Richard

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 11:34:56 +0800

Hi folks,
   I have the same idea with Richard, Tian and David on this issue. And we are always seeking the compatibility in the protocol design for both modes. But this is not trivial and need more discussions.
   In recent two years, works on pull-push p2p streaming are a hot topic in reseach.One typical idea in such pull-push combination is that they are based on unstructured(mesh) overlay unlike previous push mode who construct and maintain a strict parent-child relationship. The current push mode in these proposals, to the best of my understanding, is at the stable condition of the peer-peer connection and once there are some packet loss or othe low QoS condition detected, it turns to pull-mode.
    Welcome to add more words on the pull-push mode.
   
   What's more, 

zhangyunfei
2010-10-29

发件人： Y. R. Yang
发送时间： 2010-10-28 03:38:06
收件人： Ye (Yale) Wang
抄送： [email-masked]
主题： Re: [ppsp] Pull or Pushed-based P2P Streaming?

Richard

> >   <[email-masked] >    wrote:
> > >  Hi  all,
> > >

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 11:46:07 +0800

One more quick supplement:
  In the following pull-push mode for unstructured overlay, there is no much change in the signaling part:Tracker protocol and peer protocol(Maybe some more interactions and fields). Basically the difference compared with pure pull mode is in the data transfer phase.

BR
Yunfei

zhangyunfei
2010-10-29

发件人： zhangyunfei
发送时间： 2010-10-29 11:36:16
收件人： Y. R. Yang; Ye (Yale) Wang; Martin Stiemerling; [email-masked]; alexandretian
抄送： [email-masked]
主题： Re: [ppsp] Pull or Pushed-based P2P Streaming?

Hi folks,
   
   What's more, 

zhangyunfei
2010-10-29

发件人： Y. R. Yang

Richard

---

From: Ye Wang <[email-masked]>
Date: Fri, 29 Oct 2010 00:09:41 -0400

On Fri, 2010-10-29 at 11:46 +0800, zhangyunfei wrote:
>   In the following pull-push mode for unstructured overlay, there is
> no much change in the signaling part:Tracker protocol and peer
> protocol(Maybe some more interactions and fields). 
You are right.  Push operations may require the peer protocol to enable
the management of parent-child relationship, e.g., "subscribe" and
"unsubscribe" messages.

> Basically the difference compared with pure pull mode is in the data
> transfer phase.
Right, in Push, the sender will initiate the data transfer.

>  
> BR
> Yunfei
>  
> 
> ______________________________________________________________________
> zhangyunfei
> 2010-10-29
> 
> ______________________________________________________________________
> 发件人： zhangyunfei
>    I have the same idea with Richard, Tian and David on this issue.
> And we are always seeking the compatibility in the protocol design for
> both modes. But this is not trivial and need more discussions.
>    In recent two years, works on pull-push p2p streaming are a hot
> topic in reseach.One typical idea in such pull-push combination is
> that they are based on unstructured(mesh) overlay unlike previous push
> mode who construct and maintain a strict parent-child relationship.
> The current push mode in these proposals, to the best of my
> understanding, is at the stable condition of the peer-peer connection
> and once there are some packet loss or othe low QoS condition
> detected, it turns to pull-mode.
> ______________________________________________________________________
> zhangyunfei
> 2010-10-29
> 
> ______________________________________________________________________
> 发件人： Y. R. Yang
> > > >  There  are  basically  two  ways  on  how  peers  "work  out"
>  the  exchange  of  their  data  elements  (i.e.,  the  chunks):
> > > >  -  the  remote  peer  pushes  chunks  to  the  a  particular
>  peer  (AKA  push-based).  This  may  be  either  a  blind-push  or
>  an  informed-push.
> > > >
> > > >  The  problem  statement  seems  to  assume  a  pull-based
>  system  (Section  3,  bullet  1.3)  but  from  the  mailing  list
>  and  past  discussions  it  does  not  seem  clear  to  me  that
>  there  was  a  decision  made.
> > > >
> > > >  However,  I  see  the  chance  to  let  the  PPSP  protocol
>  run  in  both  "modes",  but  this  would  require  some  special
>  considerations  during  the  protocol  design.
> > > >
> > > >  NEC  Europe  Limited  |  Registered  Office:  NEC  House,  1
>  Victoria  Road,  London  W3  6BL  |  Registered  in  England  2832014
> > > >
> > > >

---

From: chen tian <[email-masked]>
Date: Fri, 29 Oct 2010 13:34:07 +0800

Hi Yunfei,

You are exactly right at this point. I happened to develop an
experimental pull-push mode system for unstructured overlay recently,
based on Yale's existing pull-based system. There is no extra
signaling in Tracker protocol. For peer protocol, there are several
extra signals:
(1) Substream Subscribe Request: a downloader can
subscribe/unsubscribe a substream from an uploader;
(2)Substream Subscribe Response: an uploader's decision of the
sumstream subscribe/unsubscribe request;
(3)Substream Subscribe Inform: an uploader can decide to disconnect a
substream subscription, and inform this to the downloader;
(4) Substream State Feedback: a downloader can report healthy states
of each substream to the corresponding uploader.

Hope to hear more from designers of real production systems.

Chen Tian

2010/10/29 zhangyunfei <[email-masked]>:
>   In the following pull-push mode for unstructured overlay, there is no much
> change in the signaling part:Tracker protocol and peer protocol(Maybe some
> more interactions and fields). Basically the difference compared with pure
> pull mode is in the data transfer phase.
>
> BR
> Yunfei
>
> ________________________________
> zhangyunfei
> 2010-10-29
> ________________________________
> 发件人： zhangyunfei
>    I have the same idea with Richard, Tian and David on this issue. And we
> are always seeking the compatibility in the protocol design for both modes.
> But this is not trivial and need more discussions.
>    In recent two years, works on pull-push p2p streaming are a hot topic in
> reseach.One typical idea in such pull-push combination is that they are
> based on unstructured(mesh) overlay unlike previous push mode who construct
> and maintain a strict parent-child relationship. The current push mode in
> these proposals, to the best of my understanding, is at the stable condition
> of the peer-peer connection and once there are some packet loss or othe low
> QoS condition detected, it turns to pull-mode.
> ________________________________
> zhangyunfei
> 2010-10-29
> ________________________________
> 发件人： Y. R. Yang
>> > >  There  are  basically  two  ways  on  how  peers  "work  out"  the
>> > >  exchange  of  their  data  elements  (i.e.,  the  chunks):
>> > >  -  the  remote  peer  pushes  chunks  to  the  a  particular  peer
>> > >  (AKA  push-based).  This  may  be  either  a  blind-push  or  an
>> > >  informed-push.
>> > >
>> > >  The  problem  statement  seems  to  assume  a  pull-based  system
>> > >  (Section  3,  bullet  1.3)  but  from  the  mailing  list  and  past
>> > >  discussions  it  does  not  seem  clear  to  me  that  there  was  a
>> > >  decision  made.
>> > >
>> > >  However,  I  see  the  chance  to  let  the  PPSP  protocol  run  in
>> > >  both  "modes",  but  this  would  require  some  special  considerations
>> > >  during  the  protocol  design.
>> > >

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 14:00:44 +0800

Hi Tian,
   Great and very useful information. I think these information is very solid for improving the current protocol drafts in accomodating both modes.
  It would be great if we can read drafts on detailing these messages regarding PPSP protocols.

Yunfei

zhangyunfei
2010-10-29

发件人： chen tian
发送时间： 2010-10-29 13:34:14
收件人： zhangyunfei
抄送： Y. R. Yang; Ye (Yale) Wang; Martin Stiemerling; [email-masked]; [email-masked]
主题： Re: Re: [ppsp] Pull or Pushed-based P2P Streaming?

Hi  Yunfei,

Chen  Tian

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 13:53:15 +0800

Yes.I agree with your point.
It would be great if we have more discussion and contributions on these messages and fields to clarify what we really need in the protocols to support both modes. Thanks.

BR
Yunfei

zhangyunfei
2010-10-29

发件人： Ye Wang
发送时间： 2010-10-29 12:09:30
收件人： zhangyunfei
抄送： Y. R. Yang; Martin Stiemerling; [email-masked]; alexandretian; [email-masked]
主题： Re: Re: [ppsp] Pull or Pushed-based P2P Streaming?

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 14:39:08 +0800

Hi Lichun,
   Regarding UUSee, according to the paper "UUSee: Large-Scale Operational On-Demand Streaming with Random Network Coding" on Infocom 2010, it should be a pull-push mode with two steps:
   Step1:PPSP-like tracker and peer protocol for exchaging the segement availablity iformation;
   Step2:Push protocol is for " perfect coordination", i.e., after a peer asks the tracker and exchangs segment infoarmtion, the following task is "From which peer do I need to download segment". This is where push protocol used.
   Of course the deployment of network coding brings one additional benefit with lower overhead of exchanging segement availability (a politive feedback from step2 to step1) which Richard mentioned as a drawback of pure pull mode.

BR
Yunfei

zhangyunfei
2010-10-29

发件人： [email-masked]
发送时间： 2010-10-28 14:07:37
收件人： Y. R. Yang
抄送： [email-masked]; [email-masked]
主题： Re: [ppsp] Pull or Pushed-based P2P Streaming?

Hi, Richard 

What's the meaning of "ample CDN backups"? 
I raised some requirements related to CDN in the WG before. I think first/hot/all chunks can be pushed to CDN nodes and CDN nodes can push chunks to user nodes. 
Pushing first chunk can reduce the startup time. 

"Y. R. Yang" <[email-masked]> 
发件人:  [email-masked] 
2010-10-28 03:37 收件人"Ye (Yale) Wang" <[email-masked]> 
抄送"[email-masked]" <[email-masked]> 
主题Re: [ppsp] Pull or Pushed-based P2P Streaming?

Richard

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Oct 2010 09:35:31 +0200

Hi Yunfei

One additional general question concerning a combined solution:

Could a combined pull and push based solution for P2P streaming partly solve the NAT problem?

-          Push based solution for serving peer behind NAT

-          Pull based solution for receiving peer behind NAT

BR

Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Friday, October 29, 2010 8:39 AM
To: [email-masked]; Y. R. Yang
Cc: [email-masked]
Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming?

Hi Lichun,

BR

Yunfei

zhangyunfei

2010-10-29

收件人： Y. R. Yang

Hi, Richard 

2010-10-28 03:37 

收件人

抄送

主题

		

Richard

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 29 Oct 2010 16:03:14 +0800

Hi Chrisitian,
  Thanks for the proposal. I didn't think too much on this before. At a first thought, your proposal should be workable. Great!
  Actually in some pull based practice, tracker is acting as the TURN/STUN server. I see no directly big problem to use push mode helping the serving peer behind NAT to proactively traversing the NAT.
   David and Lichun may have more comments on this.

BR
Yunfei

zhangyunfei
2010-10-29

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2010-10-29 15:35:44
收件人： ext zhangyunfei; [email-masked]; Y. R. Yang
抄送： [email-masked]
主题： RE: [ppsp] Pull or Pushed-based P2P Streaming?

Hi Yunfei

BR
Christian

 
Hi Lichun,
 
BR
Yunfei

zhangyunfei
2010-10-29

Hi, Richard 

Richard

---

From: Fabio Hecht <[email-masked]>
Date: Fri, 29 Oct 2010 10:24:27 +0200

Push only works if you can make reasonable QoS assumptions and there is
an obvious way for peers to coordinate what they subscribe to. Normally,
multiple trees are used. This makes the distribution not very flexible,
as the source needs to define how many trees there will be beforehand.

Pull works better in environments which may change constantly (churn,
user started a download etc.), since peers may request different chunks
to different peers freely. Churn or a sudden change in available
bandwidth are not special cases. Yes, there are extra messages that need
to be exchanged, but they are very small compared with the bitrate of
the video stream.

So, in my opinion, PPSP should implement a pull protocol. Perhaps the
ability of switching to push could be added as an additional (optional)
feature.

Regards

Fabio

On Fri, 2010-10-29 at 16:03 +0800, zhangyunfei wrote:
> Hi Chrisitian,
>   Thanks for the proposal. I didn't think too much on this before. At
> a first thought, your proposal should be workable. Great!
>   Actually in some pull based practice, tracker is acting as the
> TURN/STUN server. I see no directly big problem to use push mode
> helping the serving peer behind NAT to proactively traversing the NAT.
>    Regarding UUSee, according to the paper "UUSee: Large-Scale
> Operational On-Demand Streaming with Random Network Coding" on Infocom
> 2010, it should be a pull-push mode with two steps:
> 
> 
>    Step2:Push protocol is for " perfect coordination", i.e., after a
> peer asks the tracker and exchangs segment infoarmtion,
> the following task is "From which peer do I need to download segment".
> This is where push protocol used.
> 
> 
>    Of course the deployment of network coding brings one additional
> benefit with lower overhead of exchanging segement availability (a
> politive feedback from step2 to step1) which Richard mentioned as a
> drawback of pure pull mode.
> 
> 
>  
> 
> 
> BR
> 
> 
> Yunfei
> 
> 
>  
> 
> 
>                                    
> Re: [ppsp] Pull
> or Pushed-based
> P2P Streaming?
> >>> There are basically two ways on how peers "work out" the exchange
> of their data elements (i.e., the chunks):
> >>> The problem statement seems to assume a pull-based system (Section
> 3, bullet 1.3) but from the mailing list and past discussions it does
> not seem clear to me that there was a decision made.
> >>>
> >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
> >>>
> >>>

-- 
Fabio Hecht

University of Zurich - Department of Informatics (IfI)
Binzmühlestrasse 14 CH-8050 Zürich, Switzerland
Ph.: +41 44 6357129 / 6350892  Fax: +41 44 6356809
VoIP sip:[email-masked]

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Oct 2010 11:04:12 +0200

Hi Yunfei,

especially if the tracker is needed as TURN server, additional performance requirements would be needed at the tracker.

This could be avoided with my proposal.

PS: Then you would need the tracker as TURN/STUN server only if both serving and receiving peer are behind NATs.

Br

Christian

From: ext zhangyunfei [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 10:03 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]; dbryan
Cc: [email-masked]
Subject: Re: RE: [ppsp] Pull or Pushed-based P2P Streaming?

Hi Chrisitian,

BR

Yunfei

 

zhangyunfei

2010-10-29

抄送： [email-masked]

Hi Yunfei

BR

Christian

Hi Lichun,

BR

Yunfei

zhangyunfei

2010-10-29

收件人： Y. R. Yang

Hi, Richard 

2010-10-28 03:37 

收件人

抄送

主题

		

Richard

---

From: [email-masked]
Date: Fri, 29 Oct 2010 17:18:40 +0800

Hi, Yunfei and Chrisitian

You two are right. Without STUN/relay, a peer with public address still 
can push content to NATed peer or pull content from NATed peer. 
But the peer with public address has to wait NATed peer to connect to it 
first. A NATed peer can't share content with other NATed peers without NAT 
traversal either.
Verycd emule (a very popular emule client in China) uses connection 
reversal and hole punching to solve these two problems respectively. Both 
connection reversal and hole punching require a third-party node's help. 
The third-party node in verycd emule's network can be a traversal server 
or a peer with public address.
We can use ICE to solve PPSP's NAT traversal problem, because ICE combines 
STUN, relay, connection reversal and hole punching. 
BTW: Does anyone know the NAT traversal solution adopted by pplive or 
other commercial P2P streaming systems?

BR
Lichun

"zhangyunfei" <[email-masked]> 
2010-10-29 16:03

收件人
"Schmidt, Christian 1. (NSN - DE/" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "dbryan" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: RE: [ppsp] Pull or Pushed-based P2P Streaming?

Hi Chrisitian,
  Thanks for the proposal. I didn't think too much on this before. At a 
first thought, your proposal should be workable. Great!
  Actually in some pull based practice, tracker is acting as the TURN/STUN 
server. I see no directly big problem to use push mode helping the serving 
peer behind NAT to proactively traversing the NAT.
   David and Lichun may have more comments on this.
 
BR
Yunfei

zhangyunfei
2010-10-29

Hi Yunfei
 
One additional general question concerning a combined solution:
Could a combined pull and push based solution for P2P streaming partly 
solve the NAT problem?
-          Push based solution for serving peer behind NAT
-          Pull based solution for receiving peer behind NAT
 
BR
Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
ext zhangyunfei
Sent: Friday, October 29, 2010 8:39 AM
To: [email-masked]; Y. R. Yang
Cc: [email-masked]
Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming?
 
Hi Lichun,
   Regarding UUSee, according to the paper "UUSee: Large-Scale Operational 
On-Demand Streaming with Random Network Coding" on Infocom 2010, it should 
be a pull-push mode with two steps:
   Step1:PPSP-like tracker and peer protocol for exchaging the segement 
availablity iformation;
   Step2:Push protocol is for " perfect coordination", i.e., after a peer 
asks the tracker and exchangs segment infoarmtion, the following task is 
"From which peer do I need to download segment". This is where push 
protocol used.
   Of course the deployment of network coding brings one additional 
benefit with lower overhead of exchanging segement availability (a 
politive feedback from step2 to step1) which Richard mentioned as a 
drawback of pure pull mode.
 
BR
Yunfei

zhangyunfei
2010-10-29

Hi, Richard 

收件人

Richard

---

From: "Kang Heng WU" <[email-masked]>
Date: Fri, 29 Oct 2010 17:22:55 +0800

Hi Fabio and Yunfei,

Should we use “suggestion pull” to replace “pure push”. For example, PeerA requests data from PeerB. PeerB can suggest PeerA to download some pieces. Maybe these pieces are rare in PeerB’s neighbor list. But PeerA can accept PeerB’s suggestion to download these pieces, or reject PeerB’s suggestion and does not download these pieces according to its self decision. This method “suggestion pull” can avoid the redundancy drawbacks in “pure push” or “push with network coding”.

Best regards,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabio Hecht
Sent: Friday, October 29, 2010 4:24 PM
To: zhangyunfei
Cc: [email-masked]
Subject: Re: [ppsp] Pull or Pushed-based P2P Streaming?

Regards

Fabio

-- 
Fabio Hecht

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This message (including any attachments) is for the named
addressee(s)'s use only. It may contain sensitive, confidential,
private proprietary or legally privileged information intended for a
specific individual and purpose, and is protected by law. If you are
not the intended recipient, please immediately delete it and all copies
of it from your system, destroy any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of
this message and/or any attachments is strictly prohibited.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 29 Oct 2010 11:09:17 -0400

Interesting idea. Need to think about this one a bit more. There would still
be the issue of NAT traversal for actually connecting up the peers using the
gossip protocol (i.e., I still need to be able to route and exchange
peer-protocol messages with peers behind NATs), but might make things
easier.

Slightly tangential to this discussion, but one thing I want to be a bit
careful about are solutions that rely too heavily on using the tracker for
STUN/TURN capabilities. While you may want to do that in some scenarios, I
think we should have a design that doesn't force you to have a centralized
server in place in order to make the system function. (This would allow for
the distributed tracker (among peers) scenario in the future). Additionally,
a deployment may be willing to provide a simple tracker, but not want to
deploy a full NAT traversal capability in that server. (we had a similar
debate in P2PSIP around making it mandatory for the credential server to
provide STUN/TURN services, but eventually designed a system where (for most
deployments) the peers can provide the STUN/TURN service among themselves)

This has been one reason I am looking at RELOAD in our present design for a
peer protocol (there are others, including a nice security model, reuse,
ease of implementing distributed model later, etc.). There may of course be
other ways to do this that still don't require the tracker be used to for
NAT traversal, so a good topic to think more about.

David

2010/10/29 zhangyunfei <[email-masked]>

>  ------------------------------
>  zhangyunfei
> 2010-10-29
>  ------------------------------
>  *发件人：* Schmidt, Christian 1. (NSN - DE/Munich)
> *发送时间：* 2010-10-29 15:35:44
> *收件人：* ext zhangyunfei; [email-masked]; Y. R. Yang
> *抄送：* [email-masked]
> *主题：* RE: [ppsp] Pull or Pushed-based P2P Streaming?
>
>
> Hi Yunfei
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *ext zhangyunfei
> *Sent:* Friday, October 29, 2010 8:39 AM
> *To:* [email-masked]; Y. R. Yang
> *Cc:* [email-masked]
> *Subject:* Re: [ppsp] Pull or Pushed-based P2P Streaming?
>
>
>
> Hi Lichun,
>
> "From which peer do I need to download segment". This is where push protocol
> used.
>
>    Of course the deployment of network coding brings one additional benefit
> with lower overhead of exchanging segement availability (a politive feedback
> from step2 to step1) which Richard mentioned as a drawback of pure pull
> mode.
>
>
>
> BR
>
> Yunfei
>
>
>  ------------------------------
>
> zhangyunfei
>
> 2010-10-29
>  ------------------------------
>
> *发件人：* [email-masked]
>
> *发送时间：* 2010-10-28 14:07:37
>
> *收件人：* Y. R. Yang
>
> *抄送：* [email-masked]; [email-masked]
>
> *主题：* Re: [ppsp] Pull or Pushed-based P2P Streaming?
>
>
>
>
> Hi, Richard
>