Subject: Re: [ppsp] PPSP Protocols

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 1 Dec 2008 13:45:36 +0100

Hi Yunfei,
 
Are the mentioned requirements for PPSP traffic (e.g. the rigid real-time requirements) listed somewhere?
Can you provide some input?
 
Christian

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext yunfei zhang
Sent: Monday, December 01, 2008 10:27 AM
To: Victor Pascual Ávila
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

We have discussed these issues in the mailing list.Unfortunately there were something wrong with the mailing list last month and the discussion didn't appear in the mailing list.
I'd like to answer this question once again.
1)As mentioned in the presentation and the problem statement document in the bar bof, PPSP signaling protocol has a similar stack position as P2PSIP.But P2PSIP doesn't meet the rigid real-time requirements in live and vod streaming due to the searching inefficency.Moreover the heavyweight signaling overhead in P2PSIP isn't suitable for streaming applications.
2)RTP seems unsuitable for PPSP transmission for the following reasons:
   a)The timing and syn information in RTP is of no use in one-to-many envirnment which achieves the similar effect using a different means;but we will still explore the feasibilty of using RTP in p2p streaming envrinment.This is one of the main tasks in PPSP transmission part.
   b)In current practice UDP is mostly used for P2P transmission and it proves to be efficent;
 
                                       Yunfei

2008/11/26, Victor Pascual Ávila <[email-masked]>: 

	Hi,
	(trying to catch up with the discussion)
	
	PPSP Signaling Protocol:
	
	On Thu, 23 Oct 2008 11:02:44 +0800, Song Haibin posted a message[1]
	that does not seem to have generated much echo (browsing the
	discussion archive I failed to find any response).
	
	[1] http://www.ietf.org/mail-archive/web/ppsp/current/msg00005.html
	
	Is there any significant difference between "PPSP Signaling Procotol"
	and "P2PSIP Peer Protocol + SIP + OTSp2p-like algorithm"?
	
	PPSP Transmission Protocol:
	
	Why isn't RTP sufficient for this?
	
	Cheers and excuse me if it has been already discussed,
	--
	Victor Pascual Ávila
	_______________________________________________
	ppsp mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/ppsp

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

---

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 1 Dec 2008 10:52:35 -0800

Hi Yunfei,

>>  As for exchanging bitmap,it's a task of using direct connection between two NOT-KNOWN-BEFORE nodes,so there are no nodeid->nodeid connections that >> can be built in PPSP envrinment.

Why do we assume NOT-KNOWN-BEFORE nodes. And also who are these nodes not known to. If the distributed tracker is pointed to by a URI; all nodes interested in a particular stream would effectively join a RELOAD overlay for that particular stream and then could reference each other using nodeids.
As long as the tracker refers to nodes with nodeids any node in the overlay can use it to communicate. The overlay could be a more general overlay of nodes interested in pspp as well similar to some torrent implementations in which a DHT is built overall and not per content item.

Thanks
Saumitra

From: yunfei zhang [mailto:[email-masked]] 
Sent: Monday, December 01, 2008 1:36 AM
To: Das, Saumitra
Cc: Victor Pascual Ávila; [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Hi,Das,Thanks for your comments.
1)It's unsuitable viewing PPSP a overlaid usage on top of RELOAD.But as mentioned in the bar bof, the work of distributing trackers can use P2PSIP as the supporting protocol.
As for exchanging bitmap,it's a task of using direct connection between two NOT-KNOWN-BEFORE nodes,so there are no nodeid->nodeid connections that can be built in PPSP envrinment.
2)I agree with you in this point.In fact we should discuss the possibilty of reusing current IETF protocols in both signaling and transmission protocols since we need to limit the scope of PPSP.
I agree with you that the main question the BOF brought up is what exactly is being standardized here (which components of the overall problem) and why.I'd like to launch a discussion in PPSP mailing list shortly.
 
                           Yunfei

2008/12/1, Das, Saumitra <[email-masked]>: 
I think these are some of the things that need to be discussed based on the Minn BOF.

1. Can PPSP signaling be overlaid as a usage on top of RELOAD. I think this can be a separate usage for reload on the same level as SIP. One obvious use is to implement a distributed tracker. Now whether reload should be used for exchanging bitmaps etc (if that is what we determine the main thing the signaling does) by making direct nodeid->nodeid connections; should be discussed.

2. I agree we need to define what are the goals of the PPSP transmission protocol. Since this is on demand/live streaming ledbat does not apply. Can we reuse some existing transport?

But before these questions, I think the main question the BOF brought up is what exactly is being standardized here (which components of the overall problem) and why.

Thanks,
Saumitra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Ávila
Sent: Wednesday, November 26, 2008 3:08 AM
To: [email-masked]
Subject: [ppsp] PPSP Protocols

Hi,

PPSP Signaling Protocol:

---

From: Song Haibin <[email-masked]>
Date: Tue, 02 Dec 2008 08:51:55 +0800

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Das,

>Hi Yunfei,
>
>As long as the tracker refers to nodes with nodeids any node in the overlay
can
>use it to communicate. The overlay could be a more general overlay of nodes
>interested in pspp as well similar to some torrent implementations in which
a
>DHT is built overall and not per content item.

A DHT built for all is good. But I am not sure if DHT can satisfy every
application, e.g. VOD applications, since there are many click-and-drag
operations, if the DHT discovery efficient for searching streaming segments
is unknown. But if you have distributed trackers architecture in mind, I
think it will make sense to implement DHT among trackers.

Best Regards!
Song Haibin

>1)It's unsuitable viewing PPSP a overlaid usage on top of RELOAD.But as
mentioned
>in the bar bof, the work of distributing trackers can use P2PSIP as the
supporting
>protocol.
>As for exchanging bitmap,it's a task of using direct connection between two
>NOT-KNOWN-BEFORE nodes,so there are no nodeid->nodeid connections that can
be
>built in PPSP envrinment.
>2)I agree with you in this point.In fact we should discuss the possibilty
of
>reusing current IETF protocols in both signaling and transmission protocols
>since we need to limit the scope of PPSP.
>I agree with you that the main question the BOF brought up is what exactly
is
>being standardized here (which components of the overall problem) and
why.I'd
>like to launch a discussion in PPSP mailing list shortly.
>
>                           Yunfei
>
>
>
>I think these are some of the things that need to be discussed based on the
Minn
>BOF.
>
>1. Can PPSP signaling be overlaid as a usage on top of RELOAD. I think this
can
>be a separate usage for reload on the same level as SIP. One obvious use is
to
>implement a distributed tracker. Now whether reload should be used for
>exchanging bitmaps etc (if that is what we determine the main thing the
signaling
>does) by making direct nodeid->nodeid connections; should be discussed.
>
>2. I agree we need to define what are the goals of the PPSP transmission
protocol.
>Since this is on demand/live streaming ledbat does not apply. Can we reuse
some
>existing transport?
>
>But before these questions, I think the main question the BOF brought up is
what
>exactly is being standardized here (which components of the overall
problem)
>and why.
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor
>Pascual Ávila

---

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 1 Dec 2008 17:04:42 -0800

I meant the DHT can be used to search for a tracker for a content item. Beyond that drag and drop operations for searching for streaming segments can be made directly with the tracker node or with a random set of nodes that the tracker provides interested in the stream. These communications need not always use the DHT routing but still can benefit by initially communicating via nodeids reusing the overlay and nat/firewall tranversal modules. Once a direct connection is established with peers bitmap exchange can take place.

Best,
Saumitra

-----Original Message-----
From: Song Haibin [mailto:[email-masked]] 
Sent: Monday, December 01, 2008 4:52 PM
To: Das, Saumitra; 'yunfei zhang'
Cc: [email-masked]
Subject: RE: [ppsp] PPSP Protocols

Das,

can
a

Best Regards!
Song Haibin

mentioned
supporting
be
of
is
why.I'd
Minn
can
to
signaling
protocol.
some
what
problem)
Victor

---

From: Song Haibin <[email-masked]>
Date: Tue, 02 Dec 2008 10:36:29 +0800

>From: Das, Saumitra [mailto:[email-masked]]
>Sent: Tuesday, December 02, 2008 9:05 AM

>I meant the DHT can be used to search for a tracker for a content item.
Beyond
>that drag and drop operations for searching for streaming segments can be
made
>directly with the tracker node or with a random set of nodes that the
tracker
>provides interested in the stream. These communications need not always use
the
>DHT routing but still can benefit by initially communicating via nodeids
reusing
>the overlay and nat/firewall tranversal modules. Once a direct connection
is
>established with peers bitmap exchange can take place.

I think it is somewhat similar to OpenDHT. It has no obvious differences
with the normal tracker based p2p system, except that the first step is a
DHT search for a tracker for a particular content.

I also agree with you on the nat/fw traversal problem. I think designing
PPSP protocol should consider this problem.

IMHO bitmap exchange can be a standardized point here.

My two cents,
Song Haibin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 2 Dec 2008 13:30:35 +0800

Interesting discussion.

In order to make things clear, I'd like to draw a picture of the relationship between P2PSIP and PPSP and analyze their similar and difference. 

Logically, there are two main steps in both P2PSIP and P2PP: (1) searching for the other side node(s) of the communication and (2) setting up traffic connection(s) and transmission(s). The step (2) basically depends on the transport protocol (TCP/UDP, RTP...) and IP. The step (1) is solved by the DHT overly in P2PSIP because of the distribution of the registration info; while it is solved by tracker(s) in PPSP. 

During the whole process of a traffic session, send(s) and receiver(s) could be logically looked as nodes outside the P2P overlay (or called the clients of the overlay/trackers), although they can coexist with the overlay peers/trackers in the same entities. Therefore, the whole logical topology could be described logically by only sender(s)/receiver and a overlay (or tracker (s)) :

For P2PSIP:                         
Sender/receiver <--  (1) -->  (P2P overlay organized by DHT ) <-- (1) --> receiver/sender  
       |                                                                                                             |
       |______________|-->                               (2)                       <--|__________|

For PPSP:
receiver <--  (1) -->    ( Tracker(s) which could be organized by DHT)          <--  (1) --> sender 
    |                                                                                                               |  --> sender
    |                                                                                                               :
    |                                                                                                               |  --> senders
    |                                                                                                                            |
    |______________|-->                             (2)                                    -->|____________|

And the corresponding relationship between logical entities of P2PSIP and PPSP could be list as following:

   P2PSIP                                                             PPSP
DHT overlay                                =                     Tracker(s)
Sender/receiver                           =                    senders/receiver
Registration Info of certain peer     =              peer lists related to certain resources
Encoded voice packets                =                   streaming chunks

To my understanding the P2PSIP mainly try to solve the searching problems in step (1) and PPSP focuses on the point to multi-points transmission issues in step (2). And the DHT is used to organize the peers and resources, and to give a routing method for quick searching within highly distributed registration info or trackers. 

It seems that, we can also look track(s) as a peer (or peers), and then the tracker(s) searching can be based on DHT, which is in the same scope of P2PSIP. If only one track is used, URI maybe a more direct way. This, I thank, need further discussion. However, the behavior of step (2) is something need to be considered more which is out of the scope of P2PSIP. However, the possibility that to extend the current RTP/RTSP to support step (2) worth further consideration.

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, December 02, 2008 10:36 AM
To: 'Das, Saumitra'; 'yunfei zhang'
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Beyond
made
tracker
the
reusing
is
>established with peers bitmap exchange can take place.

I think it is somewhat similar to OpenDHT. It has no obvious differences with the normal tracker based p2p system, except that the first step is a DHT search for a tracker for a particular content.

I also agree with you on the nat/fw traversal problem. I think designing PPSP protocol should consider this problem.

My two cents,
Song Haibin

>operations, if the DHT discovery efficient for searching streaming 
>segments is unknown. But if you have distributed trackers architecture 
>in mind, I think it will make sense to implement DHT among trackers.
>
>Best Regards!
>Song Haibin
>
>
>>Thanks
>>Saumitra
>>
>>
>>
>>As for exchanging bitmap,it's a task of using direct connection 
>>between
two
>>I think these are some of the things that need to be discussed based 
>>on
the
>>be a separate usage for reload on the same level as SIP. One obvious 
>>use
is
>>But before these questions, I think the main question the BOF brought 
>>up
is

---

From: "Hui Zhang" <[email-masked]>
Date: Tue, 2 Dec 2008 01:57:56 -0500

Hi Saumitra,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Das, Saumitra
Sent: Monday, December 01, 2008 1:53 PM
To: yunfei zhang
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Hi Yunfei,

 

I guess what Yunfei said is NOT-COMMUNICATED-BEFORE. A peer will directly get the peer list from the tracker which includes their network addresses. Therefore no need to utilize a DHT for node-ID-to-IP-address translation.

As for exchanging bitmap, as the bitmap content in each node is live and keeps changing, a node has to keep probing some nodes it may or may not have communicated before for deciding where to get the next play-back segment. Using a DHT to broadcast a node's bitmap information or a node's find-its-next-video-segment request seems to have a performance concern.

Regards,

Hui

Thanks

Saumitra

To: Das, Saumitra

                           Yunfei

Thanks,

Saumitra

-----Original Message-----

To: [email-masked]

Hi,

PPSP Signaling Protocol:

--

Victor Pascual Ávila

ppsp mailing list

[email-masked]

ppsp mailing list

[email-masked]

ppsp mailing list

[email-masked]

---

From: "Hui Zhang" <[email-masked]>
Date: Tue, 2 Dec 2008 02:11:55 -0500

Hi Xiao Lin,

Interesting comparison & analysis. One point I would like to add is that
in (1), for P2PSIP it's 1:1 static relationship for sender/receiver, while for PPSP it's N:M dynamic relationship, which is the core part PPSP signaling protocol tries to tackle.

Regards,

Hui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Tuesday, December 02, 2008 12:31 AM
To: ext Song Haibin; Das, Saumitra; yunfei zhang
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Interesting discussion.

For P2PSIP:                         

For PPSP:

   P2PSIP                                                             PPSP
DHT overlay                                =                     Tracker(s)

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, December 02, 2008 10:36 AM
To: 'Das, Saumitra'; 'yunfei zhang'
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Beyond
made
tracker
the
reusing
is

My two cents,
Song Haibin

two
the
is
is

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 2 Dec 2008 15:51:50 +0800

Hi Hui,

Yes, you are right, "1 to 1" and "1 to m" is the major difference. 

However, we can put the info of all the corresponding peers in a peer list, right?  So, the process to find the multiple peers could be replaced by discovering this peer list. And peer lists related to certain content can be looked as resources stored in the overlay which are equivalent to the peer registration infor in P2PSIP. Then, it is actually the problem to locate the right tracker with the right peer list in the overlay.  So that, there is no much difference between P2PSIP and PPSP in step (1) if we look trackers as peers in the overlay. 

But, obviously, the Peer Gossiping communication is not within the description of step (1), which seems also a part of PPSP signalling protocol.

Best Regards,
Xiao Lin

-----Original Message-----
From: ext Hui Zhang [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 3:12 PM
To: Xiao, Lin (NSN - CN/Beijing); ext Song Haibin; Das, Saumitra; yunfei zhang
Cc: [email-masked]
Subject: RE: [ppsp] PPSP Protocols

Hi Xiao Lin,

Interesting comparison & analysis. One point I would like to add is that in (1), for P2PSIP it's 1:1 static relationship for sender/receiver, while for PPSP it's N:M dynamic relationship, which is the core part PPSP signaling protocol tries to tackle.

Regards,

Hui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Tuesday, December 02, 2008 12:31 AM
To: ext Song Haibin; Das, Saumitra; yunfei zhang
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Interesting discussion.

For P2PSIP:                         

For PPSP:

   P2PSIP                                                             PPSP
DHT overlay                                =                     Tracker(s)

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, December 02, 2008 10:36 AM
To: 'Das, Saumitra'; 'yunfei zhang'
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Beyond
made
tracker
the
reusing
is

My two cents,
Song Haibin

two
the
is
is

---

From: songhaibin 64081 <[email-masked]>
Date: Tue, 02 Dec 2008 21:04:47 +0800

Hui,

So, I think ordinary peers are not suitable for the tracker function.

Best Regards,
Song Haibin

> in (1), for P2PSIP it's 1:1 static relationship for 
> sender/receiver, while for PPSP it's N:M dynamic relationship, 
> which is the core part PPSP signaling protocol tries to tackle.
> 
> Regards,
> 
> Hui
> 
> In order to make things clear, I'd like to draw a picture of the 
> relationship between P2PSIP and PPSP and analyze their similar and 
> difference. 
> 
> Logically, there are two main steps in both P2PSIP and P2PP: (1) 
> searching for the other side node(s) of the communication and (2) 
> setting up traffic connection(s) and transmission(s). The step (2) 
> basically depends on the transport protocol (TCP/UDP, RTP...) and 
> IP. The step (1) is solved by the DHT overly in P2PSIP because of 
> the distribution of the registration info; while it is solved by 
> tracker(s) in PPSP. 
> 
> During the whole process of a traffic session, send(s) and 
> receiver(s) could be logically looked as nodes outside the P2P 
> overlay (or called the clients of the overlay/trackers), although 
> they can coexist with the overlay peers/trackers in the same 
> entities. Therefore, the whole logical topology could be described 
> logically by only sender(s)/receiver and a overlay (or tracker 
> (s)) :
> 
> For P2PSIP:                         
>       |                                                           
>                                                  |
>    |                                                              
>                                                 |  --> sender
>    |                                                              
>                                                 :
>    |                                                              
>                                                 |  --> senders
>    |                                                              
>                                                              |
> And the corresponding relationship between logical entities of 
> P2PSIP and PPSP could be list as following:
> 
>   P2PSIP                                                          
>   PPSP
> DHT overlay                                =                     
> Tracker(s)Sender/receiver                           =              
>      senders/receiver
> To my understanding the P2PSIP mainly try to solve the searching 
> problems in step (1) and PPSP focuses on the point to multi-points 
> transmission issues in step (2). And the DHT is used to organize 
> the peers and resources, and to give a routing method for quick 
> searching within highly distributed registration info or trackers. 
> 
> It seems that, we can also look track(s) as a peer (or peers), and 
> then the tracker(s) searching can be based on DHT, which is in the 
> same scope of P2PSIP. If only one track is used, URI maybe a more 
> direct way. This, I thank, need further discussion. However, the 
> behavior of step (2) is something need to be considered more which 
> is out of the scope of P2PSIP. However, the possibility that to 
> extend the current RTP/RTSP to support step (2) worth further 
> consideration.
> 
> Best Regards,
> Xiao Lin
> 
> 
> 
> 
> 
> >I meant the DHT can be used to search for a tracker for a content 
> item.Beyond
> >that drag and drop operations for searching for streaming 
> segments can 
> >be
> made
> >provides interested in the stream. These communications need not 
> always 
> >use
> the
> I think it is somewhat similar to OpenDHT. It has no obvious 
> differences with the normal tracker based p2p system, except that 
> the first step is a DHT search for a tracker for a particular content.
> 
> I also agree with you on the nat/fw traversal problem. I think 
> designing PPSP protocol should consider this problem.
> 
> >>From: [email-masked] [mailto:[email-masked]] On 
> Behalf 
> >>Of
> >Das,
> >>Saumitra
> >
> >>Hi Yunfei,
> >>
> >>use it to communicate. The overlay could be a more general 
> overlay of
> nodes
> >>interested in pspp as well similar to some torrent 
> implementations in
> which
> >a
> >>Cc: Victor Pascual ?vila; [email-masked]
> >>1)It's unsuitable viewing PPSP a overlaid usage on top of 
> RELOAD.But 
> >>as
> >mentioned
> >>in the bar bof, the work of distributing trackers can use P2PSIP 
> as 
> >>the
> >supporting
> >>protocol.
> >>NOT-KNOWN-BEFORE nodes,so there are no nodeid->nodeid 
> connections that 
> >>can
> >be
> >>I agree with you that?the main question the BOF brought up is 
> what 
> >>exactly
> >is
> >>?????????????????????????? Yunfei
> >>
> >>
> >>
> >>1. Can PPSP signaling be overlaid as a usage on top of RELOAD. I 
> thinkthis
> >can
> >>exchanging bitmaps etc (if that is what we determine the main 
> thing 
> >>the
> >signaling
> >>does) by making direct nodeid->nodeid connections; should be 
> discussed.>>
> >>Since this is on demand/live streaming ledbat does not apply. 
> Can we 
> >>reuse
> >some
> >>existing transport?
> >>
> >>From: [email-masked] [mailto:[email-masked]] On 
> Behalf 
> >>Of
> >Victor
> >>Pascual ?vila
> >>Is there any significant difference between "PPSP Signaling 
> Procotol">>and "P2PSIP Peer Protocol + SIP + OTSp2p-like algorithm"?
> >>
> >>Victor Pascual ?vila

---

From: "James Seng" <[email-masked]>
Date: Tue, 2 Dec 2008 21:10:59 +0800

The (peer discovery) situation may looks similar but they are actually
quite different.

In P2PSIP, the purpose is to identify the unique other end-point for
the communication.

In P2P Streaming, the discovery is not to find the other unique
end-point but a set of peers.

Apple & Orange. Both are fruits but obviously quite different.

-James Seng

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 2 Dec 2008 14:16:04 +0100

> So, I think ordinary peers are not suitable for the tracker function.

And the requirements for the tracker function are...
-- 
Victor Pascual Ávila
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: jlei <[email-masked]>
Date: Wed, 03 Dec 2008 10:38:06 +0100

Hi, James, all:

I would agree with your opinion, as well as the suggestion from Yunfei 
that PSPSIP is not completely suitable for the PPSP requirements in 
terms of supporting P2P media streaming.

The main difference has been highlighted below. ---- my two cents!

Cheers

Jun
>>>> As long as the tracker refers to nodes with nodeids any node in the
>>>>         
>> overlay
>>     
>>> can
>>>       
>>>> use it to communicate. The overlay could be a more general overlay of
>>>>         
>> nodes
>>     
>>>> interested in pspp as well similar to some torrent implementations in
>>>>         
>> which
>>     
>>> a
>>>       
>>>> reusing current IETF protocols in both signaling and transmission
>>>>         
>> protocols
>>     
>>>> 1. Can PPSP signaling be overlaid as a usage on top of RELOAD. I think
>>>>         
>> this
>>     
>>> can
>>>       

-- 
Dr. Jun Lei
Research Associate

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen 

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

---

From: jlei <[email-masked]>
Date: Wed, 03 Dec 2008 10:50:27 +0100

Hi, Lin ,

thanks for the nice explanation.

However, I would say that it might be still a slightly different from 
"putting all the corresponding peers in a peer list", from peer 
management point view. For P2PSIP, the main idea would be finding a 
corresponding ID --- unique identifier of arbitrary peer. For PPSP 
signaling protocol, the main task would be tracking the available peers 
for certain peer, who can provide media resource.

Therefore, for the former ID management would be the main focus, 
however, the latter focuses on available resources management. If we put 
all corresponding information in the peer list, it would be much 
overloaded or ? I would say the lookup algorithms might be different.

What do you think?

-- 
Dr. Jun Lei
Research Associate

Address:

---

From: "Hui Zhang" <[email-masked]>
Date: Wed, 3 Dec 2008 10:19:45 -0500

Hi Victor,

Please see slide 12 in the attached survey by Ning Zong et al. 
The basic tracker function is for new peer registration, providing stream metadata and initial peer list.

Hui

---

From: "yunfei zhang" <[email-masked]>
Date: Tue, 9 Dec 2008 14:23:17 +0800

Hi,Christian,Sorry to delay the email.Attached is the draft and slides of
the problem statement of ppsp.Please check it for reference.Looking forward
to discussing more in PPSP with you.

                         Yunfei

2008/12/1, Schmidt, Christian 1. (NSN - DE/Munich) <
[email-masked]>:
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *ext yunfei zhang
> *Sent:* Monday, December 01, 2008 10:27 AM
> *To:* Victor Pascual Ávila
> *Cc:* [email-masked]
> *Subject:* Re: [ppsp] PPSP Protocols
>
>
>  We have discussed these issues in the mailing list.Unfortunately there
> were something wrong with the mailing list last month and the discussion
> didn't appear in the mailing list.
> 1)As mentioned in the presentation and the problem statement document in
> the bar bof, PPSP signaling protocol has a similar stack position as
> P2PSIP.But P2PSIP doesn't meet the rigid real-time requirements in live and
> vod streaming due to the searching inefficency.Moreover the heavyweight
> signaling overhead in P2PSIP isn't suitable for streaming applications.
>    a)The timing and syn information in RTP is of no use in one-to-many
> envirnment which achieves the similar effect using a different means;but we
> will still explore the feasibilty of using RTP in p2p streaming
> envrinment.This is one of the main tasks in PPSP transmission part.

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Dec 2008 09:01:06 +0100

Hi Yunfei,
 
in the problem statement (PDF), you mention in section 2: 
Problem: "First, the startup delay(20~30s), the latency between the broadcasting time and the audience view time(120s), the re-buffering time after a dragging or forward/backward in VoD(6~8s) and the channel switch time are still long. How to reduce these delays in the Internet is an open question"
 
In the BAR BOF presentation,  you mention mandatory requirements, which are nearly the same, you mentioned to be a problem in your problem description. If the recommended figures are similar to the actual figures, where is the problem?
 
Therefore my question remain:
What numbers do you recommend for this purpose, that this is no longer a problem in this area?
 
Regards
Christian

From: ext yunfei zhang [mailto:[email-masked]] 
Sent: Tuesday, December 09, 2008 7:23 AM
To: Schmidt, Christian 1. (NSN - DE/Munich)
Cc: Victor Pascual Ávila; [email-masked]
Subject: Re: [ppsp] PPSP Protocols

Hi,Christian,Sorry to delay the email.Attached is the draft and slides of the problem statement of ppsp.Please check it for reference.Looking forward to discussing more in PPSP with you.

                         Yunfei

2008/12/1, Schmidt, Christian 1. (NSN - DE/Munich) <[email-masked]>: 

	Hi Yunfei,

	Christian

	
	 
	                                       Yunfei

		Hi,
		
		PPSP Signaling Protocol:

---

From: "yunfei zhang" <[email-masked]>
Date: Tue, 9 Dec 2008 16:06:41 +0800

hi,Christian,Thanks for your question.
The numbers are just practical performance we observe in today's Internet
instead of recommend figures.We think they are still large and so one
mission of ppsp is to set up an efficient protocol to reduce these
latencies.

                          Yunfei

2008/12/9, Schmidt, Christian 1. (NSN - DE/Munich) <
[email-masked]>:
> Problem: "First, the startup delay(20~30s), the latency between the
> broadcasting time and the audience view time(120s), the re-buffering time
> after a dragging or forward/backward in VoD(6~8s) and the channel switch
> time are still long. How to reduce these delays in the Internet is an open
> question"
>
> In the BAR BOF presentation,  you mention mandatory requirements, which are
> nearly the same, you mentioned to be a problem in your problem description.
> If the recommended figures are similar to the actual figures, where is the
> problem?
>
> *From:* ext yunfei zhang [mailto:[email-masked]]
> *Sent:* Tuesday, December 09, 2008 7:23 AM
> *To:* Schmidt, Christian 1. (NSN - DE/Munich)
> *Cc:* Victor Pascual Ávila; [email-masked]
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *ext yunfei zhang