Subject: Re: [ppsp] 转发 :New Version Notification for draft-zong-ppsp-chunk-discovery-00

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Jul 2009 14:02:20 +0200

Hi,

Good start for this topic. 
Some thoughts on the chunk discovery draft

Usability of Reload for this purpose:
Search efficiency
- What would be the required time between FetchReq and FetchAns? 1, 2, 5 or 10 seconds?
- What would be the time, needed from a solution based on reload?
- Is this really the time critical point of this flow? What about ICE checks, we need in any case?

Working Load:
- Do you have a traffic model in mind you can compare with real-time communication?
- For example in case of a football match, there is not much working load during the game. Meaning you have long periods with low message load.
- Real-time communication changes much faster. Calls are much shorter in average.

Message flow in section 3:
- A central point of information in the draft. It would be helpful, if you would extend the description in front of the flow.Especially related to informations, included in the related messages. For example does the FetchAns contain information, which chunk can be taken from which peer? 
- An extended description of the connection phase (attach, ice check, media signalling and media) would be helpful as well.

Best Regards
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zongning 63316
Sent: Monday, June 29, 2009 8:52 AM
To: [email-masked]
Subject: [ppsp] 转发 :New Version Notification for draft-zong-ppsp-chunk-discovery-00

Hi,

There is an initial version of Chunk Discovery for P2P Streaming that describes some mechanisms for distributed chunk discovery in the case of P2P streaming, including re-using RELOAD, and combind Tracker/Peer Gossip method.

Let me know any comments you have. Thanks.

BR,
Ning Zong

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

---

From: zongning 63316 <[email-masked]>
Date: Fri, 03 Jul 2009 09:13:07 +0800

Hi,

Thank you for your comments. Please see in-line.

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

----- Original Message -----
From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thursday, July 2, 2009 8:27 pm
Subject: RE: [ppsp] ?? :New Version Notification for draft-zong-ppsp-chunk-discovery-00
To: ext zongning 63316 <[email-masked]>, [email-masked]

> ICE checks, we need in any case?

[ZONG] That's what we need to evaluate. RELOAD is being deleoped as a generic approach for different applications. However, there is no idea so far, to the best of my knowledge, about to what extend RELOAD support time critical applications. 

> - For example in case of a football match, there is not much 
> working load during the game. Meaning you have long periods with 
> low message load.

[ZONG] In P2P streaming, peers would need to freqently search for serving peers. We have a document called "Survey and Problem Statement of P2P Streaming" in PPSP community. You may want to refer to it.

> - A central point of information in the draft. It would be 
> helpful, if you would extend the description in front of the 
> flow.Especially related to informations, included in the related 
> messages. For example does the FetchAns contain information, which 
> chunk can be taken from which peer? 
> - An extended description of the connection phase (attach, ice 
> check, media signalling and media) would be helpful as well.
> 
> Best Regards
> Christian Schmidt
> 
> 
> 
> 
> Subject: [ppsp] ?? :New Version Notification for draft-zong-ppsp-
> chunk-discovery-00
> 
> Hi,
> 
> There is an initial version of Chunk Discovery for P2P Streaming 
> that describes some mechanisms for distributed chunk discovery in 
> the case of P2P streaming, including re-using RELOAD, and combind 
> Tracker/Peer Gossip method.
> 
> This email and its attachments contain confidential information 
> from HUAWEI, which is intended only for the person or entity whose 
> address is listed above. Any use of the information contained 
> herein in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than 
> the intended recipient(s) is prohibited. If you receive this e-
> mail in error, please notify the sender by phone or em

---

From: zongning 63316 <[email-masked]>
Date: Fri, 03 Jul 2009 09:16:43 +0800

Hi, Christian,

I would also think that for the questions about usability of RELOAD for P2P streaming, we may redirect questions to the P2PSIP community to call for discussion there.

BR,
Ning Zong

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 8 Jul 2009 18:21:51 +0800

Hi,Ning,
   I think this draft is really instructive for PPSP.Here are some primary comments.More comments will be given with deeper considerations on the draft.
1)Is there any prototype ready to use the proposed RELoAD based solution in p2p streaming?
2)How often a peer registers what it has?I understand that the proposed RELOAD based solution requires peer to publish its content per chunk.In general, they may be some hundred of chunks in a peer's cache,and it must publish it very soon.If every chunk is published once,then the communication between the peer and overlay is really huge.
3)It is suggested to add some data struct in PeerRegistrationData,say,time-to-live of the chunk to avoid those out of date chunk is still available in the search.
4)How does a peer search in order to play the live streaming?Does a peer continously request (movie1,chunk1).(movie1,chunk2),...(movie1,chunkn) or other means?
5)I agree with the draft that RELoAD based solution need more evaluations and expriments.

zhangyunfei
2009-07-08

发件人： zongning 63316
发送时间： 2009-06-29 14:52:03
收件人： [email-masked]
抄送： 
主题： [ppsp] 转发 :New Version Notification for draft-zong-ppsp-chunk-discovery-00

Hi,

BR,
Ning  Zong

------------------------------------------------------------
From:    IETF  I-D  Submission  Tool   <[email-masked] >
To:    [email-masked]
Subject:    New  Version  Notification  for  draft-zong-ppsp-chunk-discovery-00
Date:    Sun28  Jun  2009  23:44:17  -0700  (PDT)

A  new  version  of  I-D,  draft-zong-ppsp-chunk-discovery-00.txt  has  been  successfuly  submitted  by  Ning  Zong  and  posted  to  the  IETF  repository.

Filename:  draft-zong-ppsp-chunk-discovery
Revision:  00
Title:  Chunk  Discovery  for  P2P  Streaming
Creation_date:  2009-06-28
WG  ID:  Independent  Submission
Number_of_pages:  15

Abstract:
This  document  describes  several  mechanisms  of  Chunk  Discovery  in  P2P
Streaming  use  case.    The  Chunk  Discovery  for  P2P  streaming  provides
the  functionality  of  streaming  sources  registrar  and  discovery  in  a
fully-distributed  system.    It  provides  register,  update  and  lookup
service  for  video  chunks  in  the  P2P  Streaming  applications.    The
mechanisms  include  a  P2P  streaming  usage  for  REsource  LOcation  And
Discovery  (RELOAD),  and  a  combined  Trakcer  and  Peer  Gossip  method.

The  IETF  Secretariat.

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

---

From: "Jan Seedorf" <[email-masked]>
Date: Wed, 8 Jul 2009 18:39:52 +0200

Dear Yunfei,

Have you decided yet when the bar BoF for PPSP is going to be in Stockholm? People are starting to make dinner and offline discussion meeting plans for the week in Stockholm ...

Best regards,
Jan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> zhangyunfei
> Sent: Mittwoch, 8. Juli 2009 12:22
> To: zongning 63316; [email-masked]
> Subject: Re: [ppsp] 转发 :New Version Notification for draft-zong-ppsp-
> chunk-discovery-00
> 
> Hi,Ning,
>    I think this draft is really instructive for PPSP.Here are some
> primary comments.More comments will be given with deeper considerations
> on the draft.
> 2)How often a peer registers what it has?I understand that the proposed
> RELOAD based solution requires peer to publish its content per chunk.In
> general, they may be some hundred of chunks in a peer's cache,and it
> must publish it very soon.If every chunk is published once,then the
> communication between the peer and overlay is really huge.
> 3)It is suggested to add some data struct in
> PeerRegistrationData,say,time-to-live of the chunk to avoid those out
> of date chunk is still available in the search.
> 4)How does a peer search in order to play the live streaming?Does a
> peer continously request
> (movie1,chunk1).(movie1,chunk2),...(movie1,chunkn) or other means?
> ________________________________
> 
> zhangyunfei
> 2009-07-08
> ________________________________
> 
> 发件人： zongning 63316
> There  is  an  initial  version  of  Chunk  Discovery  for  P2P
> Streaming  that  describes  some  mechanisms  for  distributed  chunk
> discovery  in  the  case  of  P2P  streaming,  including  re-using
> RELOAD,  and  combind  Tracker/Peer  Gossip  method.
> 
> from  HUAWEI,  which  is  intended  only  for  the  person  or  entity
> whose  address  is  listed  above.  Any  use  of  the  information
> contained  herein  in  any  way  (including,  but  not  limited  to,
> total  or  partial  disclosure,  reproduction,  or  dissemination)  by
> persons  other  than  the  intended  recipient(s)  is  prohibited.  If
> you  receive  this  e-mail  in  error,  please  notify  the  sender  by
> phone  or  em ail  immediately  and  delete  it!
> 
> A  new  version  of  I-D,  draft-zong-ppsp-chunk-discovery-00.txt  has
> been  successfuly  submitted  by  Ning  Zong  and  posted  to  the
> IETF  repository.
> 
> mechanisms  include  a  P2P  streaming  usage  for  REsource  LOcation
> And Discovery  (RELOAD),  and  a  combined  Trakcer  and  Peer  Gossip
> method.
> 
> 
> 
> The  IETF  Secretariat.
> 
> 
>

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 9 Jul 2009 13:54:04 +0800

Hi,Jan,
   Thanks for your kind reminding.We have request to IETF secretary for reserving the room with the time slot of July 30(Thursday) 2000-2200.But now the reply has yet to come although I think there is no much problems for the meeting place because it's after the IETF technical Plenary.I will publish the final time as soon as I get the reply.

zhangyunfei
2009-07-09

发件人： Jan Seedorf
发送时间： 2009-07-09 00:40:13
收件人： zhangyunfei; zongning 63316; [email-masked]
抄送： 
主题： Date for PPSP bar BoF

Dear  Yunfei,

Best  regards,
Jan

---

From: "Jan Seedorf" <[email-masked]>
Date: Thu, 9 Jul 2009 09:31:02 +0200

Dear Yunfei,

Thanks a lot for the info, that helps in planning the week.

See you in Stockholm,

 - Jan

> From: zhangyunfei [mailto:[email-masked]]
> Sent: Donnerstag, 9. Juli 2009 07:54
> To: Jan Seedorf; zongning 63316; [email-masked]
> Subject: Re: Date for PPSP bar BoF
> 
> Hi,Jan,
>    Thanks for your kind reminding.We have request to IETF secretary for
> reserving the room with the time slot of July 30(Thursday) 2000-
> 2200.But now the reply has yet to come although I think there is no
> much problems for the meeting place because it's after the IETF
> technical Plenary.I will publish the final time as soon as I get the
> reply.
> 
> Have  you  decided  yet  when  the  bar  BoF  for  PPSP  is  going  to
> be  in  Stockholm?  People  are  starting  to  make  dinner  and
> offline  discussion  meeting  plans  for  the  week  in  Stockholm  ...
> 
> Best  regards,
> Jan
> 
> >  1)Is  there  any  prototype  ready  to  use  the  proposed  RELoAD
> based
> >  solution  in  p2p  streaming?
> >  5)I  agree  with  the  draft  that  RELoAD  based  solution  need
> more
> >  evaluations  and  expriments.
> >
> >  主题：  [ppsp]  转发  :New  Version  Notification  for  draft-zong-
> ppsp-chunk-
> >  discovery-00
> >
> >  Hi,
> >
> >  Subject:        New    Version    Notification    for    draft-zong-
> ppsp-chunk-
> >  discovery-00
> >  This    document    describes    several    mechanisms    of
> Chunk    Discovery
> >  in    P2P
> >  Streaming    use    case.        The    Chunk    Discovery    for
> P2P    streaming
> >  provides
> >  the    functionality    of    streaming    sources    registrar
> and    discovery
> >  in    a
> >  fully-distributed    system.        It    provides    register,
> update    and
> >  lookup
> >  service    for    video    chunks    in    the    P2P    Streaming
> applications.
> >  The