Subject: [ppsp] Fw: Meaning of Chunk for PPSP

From: "zhangyunfei" <[email-masked]>
Date: Tue, 18 Aug 2009 16:51:19 +0800

I am not sure if Christian's message is received in the mailing list.So redirect it.Some replies are inline.

               Yunfei

zhangyunfei
2009-08-18

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2009-08-18 16:10:55
收件人： ext zhangyunfei
抄送： [email-masked]
主题： Meaning of Chunk for PPSP

The meaning of a chunk needs further clarification. 
Chunk: A chunk is a basic unit of partitioned streaming, which is used for the purpose of storage and advertising to neighbors what parts of a movie a peer holds [Sigcomm:P2P streaming].
Am I right, that one media stream is subdivided into several chunks? 
Yes,you are right.As is stated in the paper,streaming is partitioned into chunks which are distributed and stored by the widespread peers.
Can you describe, how the distribution of a compressed media stream into several chunks can be achieved? 
I am not quite clear about "compressed media".When does it happen?How to play a compressed media stream in the player?Anyway the partition process should be independent of the compression process as I understand.
What happens, if one of the required chunk sources drop during a PPSP session? Partial or complete new chunk discovery? What happens to the stream in between?
In general there is no need of new chunk discovery in case of chunk source drop because streaming is tolerent to the packet drop.And this is the reason why most P2P streaming applications use UDP directly.
What do you mean of the last question,Christian?You mean what happens to the playing stream in case of chunk drop or what?
Regards 
Christian Schmidt

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 18 Aug 2009 11:17:10 +0200

Hi Yunfei,
 
thanks for forwarding to the list.
 
With compressed media, I thought about MPEG2 and MPEG4 (for HDTV).
As far as I know, digial broadcasting uses these kind of compression for broadcasting to reduce needed bandwith.
What kind of codec do you want to use for this purpose?
 
If you devide one media stream into 4 chunks and 1 of the chunks fails, then this would cause a severere loss of quality,
because you would lose a lot of information (every 4th packet), not only a few packets.
 
Regards
Christian Schmidt

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Tuesday, August 18, 2009 10:51 AM
To: [email-masked]
Subject: [ppsp] Fw: Meaning of Chunk for PPSP

               Yunfei
 
________________________________

zhangyunfei
2009-08-18
________________________________

Regards 
Christian Schmidt

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 18 Aug 2009 05:55:57 -0400

On Aug 18, 2009, at 5:17 AM, Schmidt, Christian 1. (NSN - DE/Munich)  
wrote:

> As far as I know, digial broadcasting uses these kind of compression  
> for broadcasting to reduce needed bandwith.
> If you devide one media stream into 4 chunks and 1 of the chunks  
> fails, then this would cause a severere loss of quality,

It sounds that it would appropriate in this case to use something like  
the Scalable Video Coding (SVC) extension (also known as Annex G) of  
the H.264 video codec now in common use for IPTV. SVC allows for  
degradation rather than complete loss of quality if "chunks" of a  
stream are lost or dropped.

Regards
Marshall

> I am not sure if Christian's message is received in the mailing  
> list.So redirect it.Some replies are inline.
>
>                Yunfei
>
> zhangyunfei
> 2009-08-18
> Chunk: A chunk is a basic unit of partitioned streaming, which is  
> used for the purpose of storage and advertising to neighbors what  
> parts of a movie a peer holds [Sigcomm:P2P streaming].
>
> Yes,you are right.As is stated in the paper,streaming is partitioned  
> into chunks which are distributed and stored by the widespread peers.
>
> I am not quite clear about "compressed media".When does it happen? 
> How to play a compressed media stream in the player?Anyway the  
> partition process should be independent of the compression process  
> as I understand.
>
> What happens, if one of the required chunk sources drop during a  
> PPSP session? Partial or complete new chunk discovery? What happens  
> to the stream in between?
>
> In general there is no need of new chunk discovery in case of chunk  
> source drop because streaming is tolerent to the packet drop.And  
> this is the reason why most P2P streaming applications use UDP  
> directly.
>
> What do you mean of the last question,Christian?You mean what  
> happens to the playing stream in case of chunk drop or what?
>
> Regards
> Christian Schmidt
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 18 Aug 2009 13:10:45 +0200

Sounds good, see also http://en.wikipedia.org/wiki/Scalable_Video_Coding

Regards
Christian

-----Original Message-----
From: ext Marshall Eubanks [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 11:56 AM
To: Schmidt, Christian 1. (NSN - DE/Munich)
Cc: ext zhangyunfei; [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

Regards
Marshall

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 18 Aug 2009 10:33:05 -0400

I think the discussion still leads back to the open question from the
Stockholm meeting of whether we are talking about live streaming or
getting chunks of a pre-recorded video file (a movie, for example). At
the end of the meeting, the chairs noted that this was still an open
question.

If we are getting a pre-recorded file, then one grabs chunks,
reassembles locally, and plays -- the group then is concerned about
the location of peers with chunks, finding the appropriate chunks, and
possibly the protocol to obtain them, but the real time issues
wouldn't be covered in this group.

If it is about true live streaming, then in addition to the above, you
would need to discuss the real-time issues that folks are bringing up
in this thread.

It would be interesting to see what people think. Which problem is
this group looking to solve?

David

On Tue, Aug 18, 2009 at 5:55 AM, Marshall Eubanks<[email-masked]> wrote:
>
> On Aug 18, 2009, at 5:17 AM, Schmidt, Christian 1. (NSN - DE/Munich) wrote:
>
>> Hi Yunfei,
>>
>> If you devide one media stream into 4 chunks and 1 of the chunks fails,
>> then this would cause a severere loss of quality,
> It sounds that it would appropriate in this case to use something like the
> Scalable Video Coding (SVC) extension (also known as Annex G) of the H.264
> video codec now in common use for IPTV. SVC allows for degradation rather
> than complete loss of quality if "chunks" of a stream are lost or dropped.
>
> Regards
> Marshall
>
>> Regards
>> Christian Schmidt
>>
>>
>>
>>
>>
>>
>> Chunk: A chunk is a basic unit of partitioned streaming, which is used for
>> the purpose of storage and advertising to neighbors what parts of a movie a
>> peer holds [Sigcomm:P2P streaming].
>>
>> Yes,you are right.As is stated in the paper,streaming is partitioned into
>> chunks which are distributed and stored by the widespread peers.
>>
>> I am not quite clear about "compressed media".When does it happen?How to
>> play a compressed media stream in the player?Anyway the partition process
>> should be independent of the compression process as I understand.
>>
>> What happens, if one of the required chunk sources drop during a PPSP
>> session? Partial or complete new chunk discovery? What happens to the stream
>> in between?
>>
>> In general there is no need of new chunk discovery in case of chunk source
>> drop because streaming is tolerent to the packet drop.And this is the reason
>> why most P2P streaming applications use UDP directly.
>>
>> What do you mean of the last question,Christian?You mean what happens to
>> the playing stream in case of chunk drop or what?
>>
>> Regards
>> Christian Schmidt
>>

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 18 Aug 2009 16:42:23 +0200

> this group looking to solve?

Last December I sent my personal (and general) thoughts on the P2P
streaming problem statement, comments are welcome.

http://www.ietf.org/mail-archive/web/ppsp/current/msg00081.html

Cheers,
-- 
Victor Pascual Ávila

---

From: Yong Lucy <[email-masked]>
Date: Tue, 18 Aug 2009 16:38:14 -0500

Hi All,

This is my view. The incentive for downloading a streaming from multiple
sources is that each source may not be able to transmit a streaming fast
enough as needed by the receiver. Therefore, that multiple sources send
chunks at the same time provides the opportunity to meet the receiver need.
Another motivation is that live editing a streaming for the end viewer,
which requests to get churns from difference sources. As folks point out,
the applications introduce some issues that a receiver has to deal with in
order to make it work well. 

If this is a practical need in today's network, then we certainly can
develop some smart receiver functions/protocol to make it work. That is the
working group jobs. Now, we need a clear problem statement and motivation
that most of people can agree on and like to work on. 

Regards,
Lucy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Victor Pascual Avila
Sent: Tuesday, August 18, 2009 9:42 AM
To: David A. Bryan
Cc: [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

Cheers,

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 19 Aug 2009 12:13:02 +0800

Hi Christian，
   Please see inline for the detail.

zhangyunfei
2009-08-19

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2009-08-18 17:17:28
收件人： ext zhangyunfei; [email-masked]
抄送： 
主题： RE: [ppsp] Fw: Meaning of Chunk for PPSP

Hi Yunfei,

If you devide one media stream into 4 chunks and 1 of the chunks fails, then this would cause a severere loss of quality,
because you would lose a lot of information (every 4th packet), not only a few packets.
To the best of my knowledge, in current practice, non-compressed media( e.g., codec in AVI) or RM codec are used mostly. I guess such codec has some characteristic of relatively independent of each other block. There are also attempt of using H.264, which is SVC codec in p2p streaming applications.
Regards
Christian Schmidt

               Yunfei

zhangyunfei
2009-08-18

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 19 Aug 2009 12:15:01 +0800

zhangyunfei
2009-08-19

发件人： Marshall Eubanks
发送时间： 2009-08-18 17:56:01
收件人： Schmidt, Christian 1. (NSN - DE/Munich)
抄送： ext zhangyunfei; [email-masked]
主题： Re: [ppsp] Fw: Meaning of Chunk for PPSP

Exactly!There are such efforts to do this.We are also considering such codec. However it seems lack of video source with this codec, which is a problem that is not widely used.
Regards
Marshall

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 19 Aug 2009 12:21:16 +0800

Yes, I agree with David's opinion.This is an open question.More discussions are needed in the mailing list. Personally I think in the signaling level, the requirement for the protocol of live streaming should NATUALLY back-compatible meet the requirements of pre-recorded streaming.Of course there are many different requirements to realize the whole systems for live streaming and pre-recorded streaming.

               Yunfei

zhangyunfei
2009-08-19

发件人： David A. Bryan
发送时间： 2009-08-18 22:33:28
收件人： Marshall Eubanks
抄送： [email-masked]
主题： Re: [ppsp] Fw: Meaning of Chunk for PPSP

David

On  Tue,  Aug  18,  2009  at  5:55  AM,  Marshall  Eubanks <[email-masked] >  wrote:
> >  ext  zhangyunfei

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 19 Aug 2009 14:26:21 +0800

As PPSP is focusing on locating required chunks from different peers, there is no much difference between P2P live streaming and P2P on-demand streaming in this level. 
 
Both of the two systems need find and download chunks to fulfill a certain time range and then another in order.The player reassembles the chunks and starts to play once the first time range is fully downloaded. 
 
The main differences, I think, are where the start point of the downloading is and how long a time range is for play. For real time video the start point of the downloading is related to current time, while for on-demand system it always from the beginning of the movie or where the user want it to start. Moreover, the real time system may be more sensitive to the length of a time range. However, these could be configured by different applications themselves.
 
So, I think, it is possible to design a common PPSP protocol for both systems. The specific requirements for real time streaming could be proposed as an extension of PPSP if necessary.
 
BR
Lin Xiao

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Wednesday, August 19, 2009 12:21 PM
To: David A. Bryan; Marshall Eubanks
Cc: [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

               Yunfei

zhangyunfei
2009-08-19

发件人： David A. Bryan

 

David

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Aug 2009 09:57:16 +0200

Additional requirements for on-demand streaming would complicate the system a lot.
 
- In on-demand streaming system, you have functions like stop/start, slow motion, fast motion, going forward, going back, repeat....
- How to mange the following situation: 
    . User A download an on-demand stream for a movie.
    . User B download this move via User A.
    . What to do with User B, if User A interrupt presentation or skip parts of the movie?
 
So you see, it brings a lot of complexity to content server and peers. Therefore I would propose, to exclude on-demand streaming from initial goals. If needed, this could be added later.
 
Regards
Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Xiao, Lin (NSN - CN/Beijing)
Sent: Wednesday, August 19, 2009 8:26 AM
To: ext zhangyunfei; David A. Bryan; Marshall Eubanks
Cc: [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

 

BR
Lin Xiao

 
               Yunfei

zhangyunfei
2009-08-19

发件人： David A. Bryan

 

David

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 19 Aug 2009 16:16:50 +0800

Genearlly speaking,user B will download the moive from multiple sources,user A,user C,,,User N.Once userA drops the network or forwards the movie, user B will change to update the peerlist if there is no enough peers accommodating userB.This is same as live streaming.So for each user at a certain time,there is little diffrerence in signaling interaction in case of live streaming and VoD streaming.
We may explore more in the different points of signaling interaction in case of live streaming and VoD streaming to see if we should exclude or include VoD streaming from begining.

                           BR
                            Yunfei

zhangyunfei
2009-08-19

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2009-08-19 15:57:27
收件人： Xiao, Lin (NSN - CN/Beijing); ext zhangyunfei; David A. Bryan; Marshall Eubanks
抄送： [email-masked]
主题： RE: [ppsp] Fw: Meaning of Chunk for PPSP

Regards
Christian

BR
Lin Xiao

               Yunfei

zhangyunfei
2009-08-19

发件人： David A. Bryan

David

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 19 Aug 2009 16:50:50 +0800

Agree with Yunfei.
 
IMHO, the procedure of P2P streaming, no matter live or VoD, is simply composed of DOWNLOADING and PLAYING. The issues here are what to download (to make sure the exact chunks required to be downloaded); where to download (to find the exact peers with required chunks) and how to reassemble the chunks and play locally (out of scope of PPSP). PPSP tries to solve the first two issues above, i.e.locating the resource and scheduling the downloading process. Others (e.g.stop/start, slow motion, fast motion, going forward, going back, repeat the video) can be solved by applications locally if applicable. So, I still don't think there is too much difference between them in the signaling level of PPSP. 

BR
Xiao Lin

From: ext zhangyunfei [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2009 4:17 PM
To: Schmidt, Christian 1. (NSN - DE/Munich); Xiao, Lin (NSN - CN/Beijing); David A. Bryan; Marshall Eubanks
Cc: [email-masked]
Subject: Re: RE: [ppsp] Fw: Meaning of Chunk for PPSP

                           BR
                            Yunfei

zhangyunfei
2009-08-19

 

Regards
Christian

 

 
BR
Lin Xiao

 
               Yunfei

zhangyunfei
2009-08-19

发件人： David A. Bryan

 

David

---

From: Gyorgy Dan <[email-masked]>
Date: Wed, 19 Aug 2009 10:54:16 +0200

On demand streaming has additional functionality, but eventually you
might want to integrate on-demand and live streaming (e.g., stop the
live stream, watch a previous part, and then jump ahead). What to do
then, will we need three protocols, one for live, one for on-demand and
for the integration of the two?

In my understanding the goal of PPSP is not to develop a p2p live
streaming "system", but to develop a "protocol" for the signaling part
of p2p media delivery. Given the standardized signaling protocol, people
can develop diverse algorithms that implement the logic required for
live streaming, on-demand, or a mixture of the two.

As far as the signaling part is concerned, I do not see much difference
between live and on-demand streaming: locating peers and content seem to
be very similar problems in both cases. Sure, the protocol has to be
designed to be flexible enough to incorporate both, but this would
probably not make things overly complicated.

Best regards,
György

Schmidt, Christian 1. (NSN - DE/Munich) wrote:
> - In on-demand streaming system, you have functions like stop/start, 
> slow motion, fast motion, going forward, going back, repeat....
> So you see, it brings a lot of complexity to content server and peers. 
> Therefore I would propose, to exclude on-demand streaming from initial 
> goals. If needed, this could be added later.
> Regards
> Christian
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Xiao, Lin (NSN - CN/Beijing)
> *Sent:* Wednesday, August 19, 2009 8:26 AM
> *To:* ext zhangyunfei; David A. Bryan; Marshall Eubanks
> *Cc:* [email-masked]
> *Subject:* Re: [ppsp] Fw: Meaning of Chunk for PPSP
>
> As PPSP is focusing on locating required chunks from different peers, 
> there is no much difference between P2P live streaming and P2P 
> on-demand streaming in this level.
> Both of the two systems need find and download chunks to fulfill a 
> certain time range and then another in order.The player reassembles 
> the chunks and starts to play once the first time range is fully 
> downloaded.
> The main differences, I think, are where the start point of the 
> downloading is and how long a time range is for play. For real time 
> video the start point of the downloading is related to current time, 
> while for on-demand system it always from the beginning of the movie 
> or where the user want it to start. Moreover, the real time system may 
> be more sensitive to the length of a time range. However, these could 
> be configured by different applications themselves.
> So, I think, it is possible to design a common PPSP protocol for both 
> systems. The specific requirements for real time streaming could be 
> proposed as an extension of PPSP if necessary.
> BR
> Lin Xiao
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext zhangyunfei
> *Sent:* Wednesday, August 19, 2009 12:21 PM
> *To:* David A. Bryan; Marshall Eubanks
> *Cc:* [email-masked]
> *Subject:* Re: [ppsp] Fw: Meaning of Chunk for PPSP
>
> Yes, I agree with David's opinion.This is an open question.More 
> discussions are needed in the mailing list. Personally I think in the 
> signaling level, the requirement for the protocol of live streaming 
> should NATUALLY back-compatible meet the requirements of pre-recorded 
> streaming.Of course there are many different requirements to realize 
> the whole systems for live streaming and pre-recorded streaming.
> Yunfei
> ------------------------------------------------------------------------
> zhangyunfei
> 2009-08-19
> ------------------------------------------------------------------------
> *发件人：* David A. Bryan
> *发送时间：* 2009-08-18 22:33:28
> *收件人：* Marshall Eubanks
> *抄送：* [email-masked]
> *主题：* Re: [ppsp] Fw: Meaning of Chunk for PPSP
> On Tue, Aug 18, 2009 at 5:55 AM, Marshall Eubanks <[email-masked] 
> > wrote:
> >
> > > As far as I know, digial broadcasting uses these kind of 
> compression for
> > > broadcasting to reduce needed bandwith.
> fails,
> > > because you would lose a lot of information (every 4th packet), 
> not only a
> > > few packets.
> > >
> >
> used for
> > > Can you describe, how the distribution of a compressed media 
> stream into
> > > several chunks can be achieved?
> > >
> happens to

-- 
György Dán
School of Electrical Engineering
KTH Royal Institute of Technology
Stockholm, Sweden
http://www.ee.kth.se/~gyuri

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 19 Aug 2009 07:27:21 -0400

On Aug 19, 2009, at 4:50 AM, Xiao, Lin (NSN - CN/Beijing) wrote:

> Agree with Yunfei.
>
> IMHO, the procedure of P2P streaming, no matter live or VoD, is  
> simply composed of DOWNLOADING and PLAYING.

In live streaming, there is generally no concept of a file, just the  
stream. If you are watching, e.g., a sports event, there is streaming  
of video, and no file even exists (and, frequently, there is not even  
a clear stop time, as the stream will last as long as the event does).  
I think that this will affect things, even at the signaling level. (If  
I watch a movie, there is a start and stop time, and I may want the  
entire movie downloaded. If I am watching the Olympics, the start time  
may have been days before, the stop time days later, and I am unlikely  
to want to download the entire period.)

Regards
Marshall

> The issues here are what to download (to make sure the exact chunks  
> required to be downloaded); where to download (to find the exact  
> peers with required chunks) and how to reassemble the chunks and  
> play locally (out of scope of PPSP). PPSP tries to solve the first  
> two issues above, i.e.locating the resource and scheduling the  
> downloading process. Others (e.g.stop/start, slow motion, fast  
> motion, going forward, going back, repeat the video) can be solved  
> by applications locally if applicable. So, I still don't think there  
> is too much difference between them in the signaling level of PPSP.
>
>
>
> BR
> Xiao Lin
>
> To: Schmidt, Christian 1. (NSN - DE/Munich); Xiao, Lin (NSN - CN/ 
> Beijing); David A. Bryan; Marshall Eubanks
> Cc: [email-masked]
> Genearlly speaking,user B will download the moive from multiple  
> sources,user A,user C,,,User N.Once userA drops the network or  
> forwards the movie, user B will change to update the peerlist if  
> there is no enough peers accommodating userB.This is same as live  
> streaming.So for each user at a certain time,there is little  
> diffrerence in signaling interaction in case of live streaming and  
> VoD streaming.
> We may explore more in the different points of signaling interaction  
> in case of live streaming and VoD streaming to see if we should  
> exclude or include VoD streaming from begining.
>
>                            BR
>                             Yunfei
> zhangyunfei
> 2009-08-19
> So you see, it brings a lot of complexity to content server and  
> peers. Therefore I would propose, to exclude on-demand streaming  
> from initial goals. If needed, this could be added later.
>
> Regards
> Christian
>
>
>
>
> As PPSP is focusing on locating required chunks from different  
> peers, there is no much difference between P2P live streaming and  
> P2P on-demand streaming in this level.
>
> or where the user want it to start. Moreover, the real time system  
> may be more sensitive to the length of a time range. However, these  
> could be configured by different applications themselves.
>
> So, I think, it is possible to design a common PPSP protocol for  
> both systems. The specific requirements for real time streaming  
> could be proposed as an extension of PPSP if necessary.
>
> BR
> Lin Xiao
>
> discussions are needed in the mailing list. Personally I think in  
> the signaling level, the requirement for the protocol of live  
> streaming should NATUALLY back-compatible meet the requirements of  
> pre-recorded streaming.Of course there are many different  
> requirements to realize the whole systems for live streaming and pre- 
> recorded streaming.
>
>                Yunfei
>
> zhangyunfei
> 2009-08-19
> 发件人： David A. Bryan
> > >  As  far  as  I  know,  digial  broadcasting  uses  these  kind   
> of  compression  for
> > >  because  you  would  lose  a  lot  of  information  (every   
> 4th  packet),  not  only  a
> > >  few  packets.
> > >
> >
> > >  I  am  not  sure  if  Christian's  message  is  received  in   
> the  mailing  list.So
> > >  redirect  it.Some  replies  are  inline.
> > >
> > >                              Yunfei
> > >
> > >  zhangyunfei
> > >  2009-08-18
> > >  Can  you  describe,  how  the  distribution  of  a  compressed   
> media  stream  into

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 19 Aug 2009 07:34:00 -0400

On Aug 19, 2009, at 12:15 AM, zhangyunfei wrote:

> of  compression
> >  because  you  would  lose  a  lot  of  information  (every  4th   
> packet),  not
> >  only  a  few  packets.
> >
>
> Exactly!There are such efforts to do this.We are also considering  
> such codec. However it seems lack of video source with this codec,  
> which is a problem that is not widely used.

This is a new codec, and devices implementing it are just appearing.

In my opinion, PPSP should not require any specific codec, but should  
allow for support of these sorts of advanced features. For example, I  
should be able to receive a lower bit rate with a layered codec, if I  
have less bandwidth to apply to stream. In native multicast, this  
would be done by putting the different layers on different multicast  
groups, and allowing for SDP configuration to select the appropriate  
layers. FEC is supported in the same fashion. In my opinion. PPSP  
should support this sort of functionality, and should use the existing  
Internet infrastructure (such as SDP files to configure stream  
reception) as much as possible.

Regards
Marshall

> Regards
> Marshall
>
> >  Regards
> >  Christian  Schmidt
> >
> >
> >
> >
> >
> >
> >  From:  [email-masked]  [mailto:[email-masked]]  On   
> Behalf
> >  Of  ext  zhangyunfei
> the  mailing
> media  stream
> >  into  several  chunks  can  be  achieved?
> >

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 19 Aug 2009 08:19:01 -0400

IMHO, what Marshall states was my perception of the problem being solved by PPSP from the Bar BoF discussion in Stockholm -- delivery of live content, which could use multicast groups in portions of the network where they were available.

As Xiao Lin stated in a post earlier today, stop/start, slow motion, rewind, fast forward, start from beginning can be solved by other applications (local or remote from the user device), such as the file transfer implemented by P2P today.

There are a number of posts and some comments in the Stockholm meeting that cited streaming movies as an example, and I think there is already P2P file transfer technology to meet this need if the DVR type function is implemented on the user device. There is a potential application for a DVR style service that is not implemented in the end device, and implemented in some remote location, but in my opinion this is not streaming and is a separable problem. Once you have stop/start times and or forward/rewind or different speeds, multicast cannot be used.

Thanks,

Dave 

> Behalf Of Marshall Eubanks
> Sent: Wednesday, August 19, 2009 7:27 AM
> To: Xiao, Lin (NSN - CN/Beijing)
> Cc: [email-masked]
> > IMHO, the procedure of P2P streaming, no matter live or 
> VoD, is simply 
> > composed of DOWNLOADING and PLAYING.
> 
> In live streaming, there is generally no concept of a file, 
> just the stream. If you are watching, e.g., a sports event, 
> there is streaming of video, and no file even exists (and, 
> frequently, there is not even a clear stop time, as the 
> stream will last as long as the event does).  
> I think that this will affect things, even at the signaling 
> level. (If I watch a movie, there is a start and stop time, 
> and I may want the entire movie downloaded. If I am watching 
> the Olympics, the start time may have been days before, the 
> stop time days later, and I am unlikely to want to download 
> the entire period.)
> 
> Regards
> Marshall
> 
> > required to be downloaded); where to download (to find the 
> exact peers 
> > with required chunks) and how to reassemble the chunks and play 
> > locally (out of scope of PPSP). PPSP tries to solve the first two 
> > issues above, i.e.locating the resource and scheduling the 
> downloading 
> > process. Others (e.g.stop/start, slow motion, fast motion, going 
> > forward, going back, repeat the video) can be solved by 
> applications 
> > locally if applicable. So, I still don't think there is too much 
> > difference between them in the signaling level of PPSP.
> >
> >
> >
> > BR
> > Xiao Lin
> >
> > forwards the movie, user B will change to update the 
> peerlist if there 
> > is no enough peers accommodating userB.This is same as live 
> > diffrerence in signaling interaction in case of live 
> streaming and VoD 
> > streaming.
> > Additional requirements for on-demand streaming would 
> complicate the 
> > system a lot.
> >
> >     . What to do with User B, if User A interrupt 
> presentation or skip 
> > parts of the movie?
> >
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of ext Xiao, Lin (NSN - CN/Beijing)
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of ext zhangyunfei
> > the whole systems for live streaming and pre- recorded streaming.
> >
> >                Yunfei
> >
> > zhangyunfei
> > 2009-08-19
> > 发件人： David A. Bryan
> > getting  chunks  of  a  pre-recorded  video  file  (a  
> movie,  for   
> > example).  At
> > the  location  of  peers  with  chunks,  finding  the  
> appropriate   
> > chunks,  and
> > would  need  to  discuss  the  real-time  issues  that  
> folks  are   
> > bringing  up
> > in  this  thread.
> >
> > > >  With  compressed  media,  I  thought  about  MPEG2  
> and  MPEG4   
> > (for  HDTV).
> > >  video  codec  now  in  common  use  for  IPTV.  SVC  
> allows  for   
> > degradation  rather
> > > >  Am  I  right,  that  one  media  stream  is  
> subdivided  into   
> > several  chunks?
> > > >
> > > >  should  be  independent  of  the  compression  process 
>  as  I   
> > understand.
> > > >
> > > >  session?  Partial  or  complete  new  chunk  
> discovery?  What   
> > happens  to  the  stream
> > > >  in  between?
> > > >

---

From: Yong Lucy <[email-masked]>
Date: Wed, 19 Aug 2009 11:08:29 -0500

Hi Marshall,

See inline.

Regards,
Lucy

> Marshall Eubanks
> Sent: Wednesday, August 19, 2009 6:27 AM
> stream. 
[LY] This is the traditional way to deliver live streaming. On Internet, a
live streaming may be delivered as a set of content files with a playlist.
Then the difference between live streaming and VoD is that the content files
may not exist yet for a live streaming even the playlist already exists (or
predicted based on the index rule) while all the content files already and
the playlist exist for VoD.  

In my understanding, the target work here is for a streaming delivered as
churns (files). Thus, the work can apply to both live streaming and VoD. But
it does not apply to a living streaming that is not delivered as churns.
Maybe it is necessary to further clarify this in the charter.

[Snipped]

---

From: Gyorgy Dan <[email-masked]>
Date: Wed, 19 Aug 2009 10:27:05 +0200

Best regards,
György

Schmidt, Christian 1. (NSN - DE/Munich) wrote:
> Behalf Of

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 20 Aug 2009 09:53:20 +0800

I agree with Marshall's opinion on the codec issue.SDP may be a means to negotiating the parameters.

zhangyunfei
2009-08-20

发件人： Marshall Eubanks
发送时间： 2009-08-19 19:34:04
收件人： zhangyunfei
抄送： Schmidt, Christian 1. (NSN - DE/; [email-masked]
主题： Re: [ppsp] Fw: Meaning of Chunk for PPSP

Regards
Marshall

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 20 Aug 2009 10:02:22 +0800

ee.tv> <[email-masked]>
Subject: Re: Re: [ppsp] Fw: Meaning of Chunk for PPSP
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon032770315344_====="

This is a multi-part message in MIME format.

--=====003_Dragon032770315344_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon032770315344_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon032770315344_=====--

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 19 Aug 2009 22:47:13 -0400

I don't know what this is, but please don't send attachments through  
IETF lists.

Regards
Marshall

On Aug 19, 2009, at 10:02 PM, zhangyunfei wrote:

> WWVzLEkgdGhpbmsgTHVjeSdzIGV4cGxhaW5hdGlvbiBtYWtlcyB1cyBtb3JlIGNsZWFyIGFib3V0
> IHRoZSB0YXJnZXQgb2YgUFBTUC5XZSBhcmUganVzdCBtb2RpZnlpbmcgdGhlIGNoYXJ0ZXIgYW5k

---

From: Ning Zong <[email-masked]>
Date: Thu, 20 Aug 2009 10:58:14 +0800

I tend to agree on Dan’s opinion.
As stated in PPSP problem statement, the functionalities of advanced play-out characters belong to “Play-out Layer” in the P2P streaming components architecture. PPSP focus on “Communication Layer” where the command from “Play-out Layer” is converted to which chunks are to be discovered among peers. E.g. if we do jump, the current chunks to be fetched may change from “Chunk ID 10” to “Chunk ID 20”, that’s what the PPSP signaling part needs to understand.
I couldn’t see the strong reason why not include both live streaming and VoD at the time being. There are some differences, but we could have a flexible protocol for discovering distributed sources (note again, we are not defining the whole system).
My two cents.

BR,
Ning Zong

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Gyorgy Dan
发送时间: 2009年8月19日 16:27
收件人: Schmidt, Christian 1. (NSN - DE/Munich)
抄送: [email-masked]
主题: Re: [ppsp] Fw: Meaning of Chunk for PPSP

Best regards,
György

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 20 Aug 2009 11:10:13 +0800

fr <[email-masked]> <[email-masked]>
Subject: Re: Re:
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon076352273554_====="

--=====003_Dragon076352273554_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon076352273554_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon076352273554_=====--

---

From: Ning Zong <[email-masked]>
Date: Thu, 20 Aug 2009 11:17:01 +0800

It seems that your mailbox has some problem. Please check it, Yunfei.

BR,
Ning Zong
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
zhangyunfei
发送时间: 2009年8月20日 11:10
收件人: Marshall Eubanks
抄送: [email-masked]
主题: [ppsp] (no subject)

fr <[email-masked]>
<[email-masked]>
Subject: Re: Re:
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon076352273554_====="

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 Aug 2009 06:41:04 +0200

Hi Dave,

I think thats a good approach for the problem. We should distinguish between:

Live Streaming (e.g. TV Broadcast):
- The user can connect / disconnect to a video stream (no influence to the video stream with start/stop, forward/rewind).
- The user can either just watch the programm or additional store the information in a file (DVR).
- The file would be available for further proceedings. 

File Sharing:
- The user can download files containing video material.
- The user can imidiately start to display the content.
- The file is available for further proceedings.

The File Sharing case is allready covered by p2p technique available today. 
Therefore, PPSP should focus on the Live Streaming case.

Best Regards
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mcdysan, David E
Sent: Wednesday, August 19, 2009 2:19 PM
To: Marshall Eubanks; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

Thanks,

Dave 

> > On  Behalf  Of

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 20 Aug 2009 08:03:55 -0400

On Aug 20, 2009, at 12:41 AM, Schmidt, Christian 1. (NSN - DE/Munich)  
wrote:

> - The user can connect / disconnect to a video stream (no influence  
> to the video stream with start/stop, forward/rewind).

These is also video-conferencing, which is similar to TV Broadcast,  
but is generally duplex, has latency restrictions, no file structure  
at all and (typically) no need to recover old data (in other words,  
past a certain latency delayed packets can be regarded as lost).

I would hope PPSP would support videoconferencing and telepresence as  
well.

Regards
Marshall

> IMHO, what Marshall states was my perception of the problem being  
> solved by PPSP from the Bar BoF discussion in Stockholm -- delivery  
> of live content, which could use multicast groups in portions of the  
> network where they were available.
>
> As Xiao Lin stated in a post earlier today, stop/start, slow motion,  
> rewind, fast forward, start from beginning can be solved by other  
> applications (local or remote from the user device), such as the  
> file transfer implemented by P2P today.
>
> There are a number of posts and some comments in the Stockholm  
> meeting that cited streaming movies as an example, and I think there  
> is already P2P file transfer technology to meet this need if the DVR  
> type function is implemented on the user device. There is a  
> potential application for a DVR style service that is not  
> implemented in the end device, and implemented in some remote  
> location, but in my opinion this is not streaming and is a separable  
> problem. Once you have stop/start times and or forward/rewind or  
> different speeds, multicast cannot be used.
>
> Thanks,
>
> Dave
>

---

From: Yong Lucy <[email-masked]>
Date: Thu, 20 Aug 2009 14:31:06 -0500

I agree Dan and Ning views and would like to point out the assumption in PPSP work. The scope of PPSP is to focus on "communication layer" under the architecture in the problem statement. "play-out layer" is out of scope. Some people bring the case that "play-out layer" itself may also involve some network communication for instance nVCR. This is a very valid case. But PPSP work does not aim on the communication within "play-out layer".

Cheers,
Lucy

> Sent: Wednesday, August 19, 2009 9:58 PM
> To: 'Gyorgy Dan'; 'Schmidt, Christian 1. (NSN - DE/Munich)'
> Cc: [email-masked]
> Subject: [ppsp] ??: Fw: Meaning of Chunk for PPSP
> 
> As stated in PPSP problem statement, the functionalities of advanced play-
> out characters belong to “Play-out Layer” in the P2P streaming components
> architecture. PPSP focus on “Communication Layer” where the command from
> “Play-out Layer” is converted to which chunks are to be discovered among
> peers. E.g. if we do jump, the current chunks to be fetched may change
> from “Chunk ID 10” to “Chunk ID 20”, that’s what the PPSP signaling part
> needs to understand.
> I couldn’t see the strong reason why not include both live streaming and
> VoD at the time being. There are some differences, but we could have a
> flexible protocol for discovering distributed sources (note again, we are
> not defining the whole system).
> My two cents.
> 
> BR,
> Ning Zong
> 
> -----邮件原件-----
> PPSP

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 21 Aug 2009 10:14:52 +0800

I fail to post the reply to the mailing list as the response of Lucy's previous comments.Post it again.I think Lucy's explaination makes us understand PPSP scope more clearly.And Lucy's suggestion on the charter modification is just under discussion and we are doing the modification.

                    BR
                       Yunfei

zhangyunfei
2009-08-21

发件人： Yong Lucy
发送时间： 2009-08-21 03:31:17
收件人： 'Ning Zong'; 'Gyorgy Dan'; 'Schmidt,Christian 1. (NSN - DE/Munich)'
抄送： [email-masked]
主题： Re: [ppsp] ??: Fw: Meaning of Chunk for PPSP

Cheers,
Lucy

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 21 Aug 2009 10:27:48 +0800

om><5D84FDD8D5DC8646 [email-masked]><452C09DD-C9B9-41DE-A2BD-90 [email-masked]><793F49BA1FC821409F99F10862A0E4DB03A63D66@FHDP1LU MXCV14.us.one.verizon.com><[email-masked]> <[email-masked]>
Subject: Re: Re: [ppsp] Fw: Meaning of Chunk for PPSP
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon878481105163_====="

--=====003_Dragon878481105163_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon878481105163_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon878481105163_=====--

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 15:45:56 +0800

Hi Schmidt and Dave,

Regarding the focus of PPSP, I would prefer to use the term “signaling
protocol between PPSP peers” instead of service types such as “live
streaming” or “file sharing/VoD”, because some requirements to the
protocols to be developed by PPSP would support both live streaming and VoD.
For an instance, even in live streaming, we support the cases that the users
store the live content for further distribution (as pointed out by Schmidt),
such as TSTV (time-switch TV) where the stored content can be separated into
chunks and distributed in a VoD-like manner. That is, supporting chunk
availabilities exchange among peers would be required in the protocols to be
developed by PPSP.
Of course, it is definitely helpful to discuss which scenarios we need to
consider and support in order to point out which functionalities/parameters
we need put into the PPSP protocols.

BR,
Ning Zong

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Schmidt,
Christian 1. (NSN - DE/Munich)
发送时间: 2009年8月20日 12:41
收件人: ext Mcdysan, David E; Marshall Eubanks; Xiao, Lin (NSN - CN/Beijing)
抄送: [email-masked]
主题: Re: [ppsp] Fw: Meaning of Chunk for PPSP

Hi Dave,

I think thats a good approach for the problem. We should distinguish
between:

Live Streaming (e.g. TV Broadcast):
- The user can connect / disconnect to a video stream (no influence to the
video stream with start/stop, forward/rewind).
- The user can either just watch the programm or additional store the
information in a file (DVR).
- The file would be available for further proceedings. 

File Sharing:

Best Regards
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Mcdysan, David E
Sent: Wednesday, August 19, 2009 2:19 PM
To: Marshall Eubanks; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: Re: [ppsp] Fw: Meaning of Chunk for PPSP

IMHO, what Marshall states was my perception of the problem being solved by
PPSP from the Bar BoF discussion in Stockholm -- delivery of live content,
which could use multicast groups in portions of the network where they were
available.

As Xiao Lin stated in a post earlier today, stop/start, slow motion, rewind,
fast forward, start from beginning can be solved by other applications
(local or remote from the user device), such as the file transfer
implemented by P2P today.

There are a number of posts and some comments in the Stockholm meeting that
cited streaming movies as an example, and I think there is already P2P file
transfer technology to meet this need if the DVR type function is
implemented on the user device. There is a potential application for a DVR
style service that is not implemented in the end device, and implemented in
some remote location, but in my opinion this is not streaming and is a
separable problem. Once you have stop/start times and or forward/rewind or
different speeds, multicast cannot be used.

Thanks,

Dave

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Aug 2009 09:56:51 +0200

Hi Ning,

That we need a definition of a PPSP peer.
What qualifies a peer to be a PPSP peer?
What is the differentiation between a peer and a PPSP peer?

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:46 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E'; 'Marshall Eubanks'; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: 答复: [ppsp] Fw: Meaning of Chunk for PPSP

Hi Schmidt and Dave,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 15:56:47 +0800

Hi, Schmidt,

I have another comment. Please see in-line.

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

The File Sharing case is allready covered by p2p technique available today. 
Therefore, PPSP should focus on the Live Streaming case.
[ZONG NING]: I agree that VoD is quite similar to file sharing and P2P file
sharing has been well deployed. My point is that we are doing standard
protocol in PPSP which is still new to IETF. We will examine the common
parts of current P2P technique and see how much we can reuse them in PPSP.
Do you mean that IETF will not do something that has been already well
deployed and studied by other body?

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 16:00:21 +0800

Sorry, TSTV should be "time-shift TV". I apologize for my English.

BR,
Ning Zong

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Ning Zong
发送时间: 2009年8月21日 15:46
收件人: 'Schmidt, Christian 1. (NSN - DE/Munich)'; 'ext Mcdysan, David E';
'Marshall Eubanks'; 'Xiao, Lin (NSN - CN/Beijing)'
抄送: [email-masked]
主题: [ppsp] 答复: Fw: Meaning of Chunk for PPSP

Hi Schmidt and Dave,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Aug 2009 10:09:57 +0200

>deployed and studied by other body?

Lets say, if a solution for a problem is reasonable, implemented, deployed and allready available
Under reasonable conditions, they would not do something in this field.
For example, in P2PSIP, they allways excluded the invention of a new DHT algorithm.

My intension was
- to narrow down the scope of the PPSP charter to a reasonable size
- to differentiate from existing solutions, e.g. Bittorent
- to differentiate from P2PSIP work

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:57 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E'; 'Marshall Eubanks'; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: 答复: [ppsp] Fw: Meaning of Chunk for PPSP

Hi, Schmidt,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 16:24:35 +0800

Hi Schmidt,

PPSP peer is nothing new but referred to as the peers in streaming
scenarios.
PPSP peers not only receive the streaming content, but storing and uploading
the streaming content to others.
In a broad sense, PPSP peers include multiple entities such as user devices,
network caches, CDN servers, etc. in streaming scenarios and with the above
mentioned roles.
We will document this definition in Problem Statement. Thank you for asking.

BR,
Ning Zong

-----邮件原件-----
发件人: Schmidt, Christian 1. (NSN - DE/Munich)
[mailto:[email-masked]] 
发送时间: 2009年8月21日 15:57
收件人: ext Ning Zong; ext Mcdysan, David E; Marshall Eubanks; Xiao, Lin
(NSN - CN/Beijing)
抄送: [email-masked]
主题: RE: [ppsp] Fw: Meaning of Chunk for PPSP

Hi Ning,

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:46 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E';
'Marshall Eubanks'; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: 答复: [ppsp] Fw: Meaning of Chunk for PPSP

Hi Schmidt and Dave,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 16:35:43 +0800

Hi, please see in-line.

BR,
Ning Zong

-----邮件原件-----
发送时间: 2009年8月21日 16:10

>deployed and studied by other body?

Lets say, if a solution for a problem is reasonable, implemented, deployed
and allready available
Under reasonable conditions, they would not do something in this field.
For example, in P2PSIP, they allways excluded the invention of a new DHT
algorithm.
[ZONG NING]: Well, we are not going to define new mechanisms for p2p file
sharing in PPSP, we are going to reuse some of current p2p techniques, e.g.
chunk availability exchange. Just like P2PSIP adopt Chord as a basic DHT
algorithm.

My intension was
- to narrow down the scope of the PPSP charter to a reasonable size
[ZONG NING]: Yes, we are trying to narrow down the scope to only the
signaling between peers, or peer and tracker. We will definitely continue to
consider which functions we need to include (e.g. some advanced streaming
characters, Codec, etc.).
- to differentiate from existing solutions, e.g. Bittorent
[ZONG NING]: Yes, we will try to point out the differences between
Bittorrent and VoD. Do you have good ideas on this issue?
- to differentiate from P2PSIP work
[ZONG NING]: Yes, we will definitely do this.

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:57 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E';

Hi, Schmidt,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Aug 2009 11:24:13 +0200

Hi,

For this purpose an actual version of the planned PPSP WG charter would be helpful.
Can somebody please provide an actual version? 

BR
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 10:36 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E'; 'Marshall Eubanks'; Xiao, Lin (NSN - CN/Beijing)
Cc: [email-masked]
Subject: 答复: [ppsp] Fw: Meaning of Chunk for PPSP

Hi, please see in-line.

BR,
Ning Zong

-----邮件原件-----

My intension was

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:57 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E';

Hi, Schmidt,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: Ning Zong <[email-masked]>
Date: Fri, 21 Aug 2009 17:31:28 +0800

Hi, Schmidt

Yunfei and I are drafting the PPSP charter now.
It will be available soon (hopefully within 2 weeks) for list discussions.

BR,
Ning Zong

-----邮件原件-----
发送时间: 2009年8月21日 17:24

Hi,

For this purpose an actual version of the planned PPSP WG charter would be
helpful.
Can somebody please provide an actual version? 

BR
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 10:36 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E';

Hi, please see in-line.

BR,
Ning Zong

-----邮件原件-----

My intension was

Regards
Christian

-----Original Message-----
From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:57 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext Mcdysan, David E';

Hi, Schmidt,

BR,
Ning Zong

-----邮件原件-----

Hi Dave,

File Sharing:

Best Regards
Christian Schmidt

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

Thanks,

Dave

---

From: "Roni Even" <[email-masked]>
Date: Tue, 25 Aug 2009 11:32:20 +0300

Hi Marshall,
P2P Video conferencing and tele-presence are based on P2PSIP. What is the use case for PPSP for these applications since the content is point to point in most cases and not distributed to multiple listeners.

Roni Even

> Sent: Thursday, August 20, 2009 3:04 PM

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 25 Aug 2009 16:49:40 +0800

I agree with Roni for the suggestion of chunk definition and service type involvement.

              Yunfei 

zhangyunfei
2009-08-25

发件人： Roni Even
发送时间： 2009-08-25 16:40:51
收件人： [email-masked]
抄送： 
主题： [ppsp] ***SPAM*** 7.092 (5) RE: 答复: Fw: Meaning of Chunk for PPSP

Hi,
I  think  that  that  a  common  definition  of  a  chunk  should  be  in  the  charter
but  it  should  be  based  on  the  various  use  cases  that  need  to  be  in  scope  of
PPSP.  If  the  solution  is  for  live  streaming  as  well  as  for  stored  content  it
should  be  eventually  reflected  in  the  chunk  description  enabling  both  case.
I  assume  that  this  will  require  as  a  first  step  to  agree  on  the  use  cases.
I  agree  that  the  signaling  protocols  between  PPSP  peers"  is  one  but  it
should  address  the  in-scope  service  types.

Roni  Even

>  Sent:  Friday,  August  21,  2009  10:46  AM
>  To:  'Schmidt,  Christian  1.  (NSN  -  DE/Munich)';  'ext  Mcdysan,  David  E';
>  Subject:  [ppsp]  答复:  Fw:  Meaning  of  Chunk  for  PPSP
>  
>  Hi  Schmidt  and  Dave,
>  
>  Schmidt,
>  ext
>  solved  by
>  rewind,