Subject: [ppsp] Review of draft-ietf-ppsp-problem-statement-00

From: Martin Stiemerling <[email-masked]>
Date: Tue, 26 Oct 2010 15:15:56 +0000

Dear all,

This is my review of draft-ietf-ppsp-problem-statement-00.

* General
1) Intended Status is not "Standards Track" but "Informational". Check the WG charter.
2) document structure: 
The whole structure looks to me like glued together from various components without considering how such draft is structured at best. For instance, there are definitions of components in Section 1.3, 3, and 5. Furthermore, Section 6 is somewhat out of scope the document? Looks like a leftover from pre-WG times?!

* Detailed review
- Section 1.1: too much talk about background. This can be condensed with a few examples.
- Section 1.2: I do not see how the content of this section address what the heading promises "Research or Engineering". Does this section anyhow still belong in this draft, as the question seems to be answered as consequence of having an IETF working group (not being touched down in IRTF)?
- Section 1.3: Does read more than early definitions, justification why PPSP, but no objectives.
- Section 3: should be combined and better structured, with parts of Section 1.3 and Section 5. Way too much details about how such a system works for an introduction section.
- Section 3, bullet 1.3: this precludes that PPSP will work on pull-based P2P streaming systems, as it states "request for content".
- Section 4: Please remove the citation of the P2PNEXT guy, as this is a biased statement of a single person promoting its project. Should be in a IETF WG item, anyhow.
- Section 4: The general idea of the section (i.e., issues with non-standard systems) is nice but way too long. IMHO a shorter, more precise section would suite the interested reader much more. I would also remove the "incentives for dev standard PPSP", as this sounds like marketing but not to be part of a problem statement. 
- Section 5: see first comment to Section 3.
- Section 6: does not belong here (anymore)
- Section 7: Always good to have use cases, but it is probably good to have them earlier in the draft. 
- Section 7.1, Figure 3: I could not figure out what the abbreviations in the figures are standing for. Ok, I can guess, but other reads not familiar with the area might not be able to ;)
- - Section 7.1, Figure 3: Why does this call for standard PPSP? What are the point of interaction between the players?
- Section 7.2: Why is this 3 screen system? What is the deal of this section??
- Section 7.3: I do not get the point? Are you referring to use PPSP as "range extender" for CDNs? I.e., using P2P towards the customer and between the custoumer to take off load from the CDN infrastructure (edge server/caches)?
- Section 8: not the type of sec. cons. I would expect here. Looks rather specific, e.g., attacks on tracker. Are we going for tracker systems and if, why is this nailed down in the problem statement which is by the way informational?

That's a first high-level review. I'm happy to discuss the comments.

With kind regards,

  Martin

[email-masked]

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

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 27 Oct 2010 10:43:04 +0800

Thanks Martin for the careful review.It's very helpful.More comments are welcome. I'm revising it according to the mailing list discussion.

BR
Yunfei

zhangyunfei
2010-10-27

发件人： Martin Stiemerling
发送时间： 2010-10-26 23:16:13
收件人： [email-masked]
抄送： 
主题： [ppsp] Review of draft-ietf-ppsp-problem-statement-00

Dear  all,

*  General

*  Detailed  review

With  kind  regards,

   Martin

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

---

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

Hi Yunfei,  all,

There were some questions in the review.

I would appreciate some replies to those, e.g., to Section 7.3.

  Martin

> -----Original Message-----
> From: zhangyunfei [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2010 4:43 AM
> To: Martin Stiemerling; [email-masked]
> Subject: Re: [ppsp] Review of draft-ietf-ppsp-problem-statement-00
> 
> Thanks Martin for the careful review.It's very helpful.More comments
> are welcome. I'm revising it according to the mailing list discussion.
> 
> BR
> Yunfei
> 
> ________________________________
> 
> zhangyunfei
> 2010-10-27
> ________________________________
> 
> 发件人： Martin Stiemerling
> The  whole  structure  looks  to  me  like  glued  together  from
> various  components  without  considering  how  such  draft  is
> structured  at  best.  For  instance,  there  are  definitions  of
> components  in  Section  1.3,  3,  and  5.  Furthermore,  Section  6
> is  somewhat  out  of  scope  the  document?  Looks  like  a  leftover
> from  pre-WG  times?!
> 
> *  Detailed  review
> -  Section  1.2:  I  do  not  see  how  the  content  of  this  section
> address  what  the  heading  promises  "Research  or  Engineering".
> Does  this  section  anyhow  still  belong  in  this  draft,  as  the
> question  seems  to  be  answered  as  consequence  of  having  an
> IETF  working  group  (not  being  touched  down  in  IRTF)?
> -  Section  1.3:  Does  read  more  than  early  definitions,
> justification  why  PPSP,  but  no  objectives.
> -  Section  3:  should  be  combined  and  better  structured,  with
> parts  of  Section  1.3  and  Section  5.  Way  too  much  details
> about  how  such  a  system  works  for  an  introduction  section.
> -  Section  3,  bullet  1.3:  this  precludes  that  PPSP  will  work
> on  pull-based  P2P  streaming  systems,  as  it  states  "request  for
> content".
> -  Section  4:  Please  remove  the  citation  of  the  P2PNEXT  guy,
> as  this  is  a  biased  statement  of  a  single  person  promoting
> its  project.  Should  be  in  a  IETF  WG  item,  anyhow.
> -  Section  4:  The  general  idea  of  the  section  (i.e.,  issues
> with  non-standard  systems)  is  nice  but  way  too  long.  IMHO  a
> shorter,  more  precise  section  would  suite  the  interested  reader
> much  more.  I  would  also  remove  the  "incentives  for  dev
> standard  PPSP",  as  this  sounds  like  marketing  but  not  to  be
> part  of  a  problem  statement.
> -  Section  7:  Always  good  to  have  use  cases,  but  it  is
> probably  good  to  have  them  earlier  in  the  draft.
> -  Section  7.1,  Figure  3:  I  could  not  figure  out  what  the
> abbreviations  in  the  figures  are  standing  for.  Ok,  I  can
> guess,  but  other  reads  not  familiar  with  the  area  might  not
> be  able  to  ;)
> -  -  Section  7.1,  Figure  3:  Why  does  this  call  for  standard
> PPSP?  What  are  the  point  of  interaction  between  the  players?
> -  Section  7.3:  I  do  not  get  the  point?  Are  you  referring  to
> use  PPSP  as  "range  extender"  for  CDNs?  I.e.,  using  P2P
> towards  the  customer  and  between  the  custoumer  to  take  off
> load  from  the  CDN  infrastructure  (edge  server/caches)?
> -  Section  8:  not  the  type  of  sec.  cons.  I  would  expect
> here.  Looks  rather  specific,  e.g.,  attacks  on  tracker.  Are  we
> going  for  tracker  systems  and  if,  why  is  this  nailed  down  in
> the  problem  statement  which  is  by  the  way  informational?
> 
> NEC  Europe  Limited  |  Registered  Office:  NEC  House,  1  Victoria
> Road,  London  W3  6BL  |  Registered  in  England  2832014
> 
>

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 28 Oct 2010 23:11:16 +0800

Hi Martin，
   Thanks for the comments.Some quick replies on the questions are as follows:
Section7.2: Three screen refers to sharing video streaming contents among hetergeneous terminals, say, PC screen, TV screen and mobile terminal screen. The intention of this section is showing the compatibility of PPSP for hetergeneous environments.

Section7.3 wants to express two points. The first is for CDN vendors to provide service. The small p2p vendors want to increase the streaming delivery performance by the help of stable CDNs as the super-peers in their systems. PPSP helps CDN nodes seamlessly join the P2P streaming delivery without too much work. The second is for CDN internal construction. PPSP helps scheduling the contents among these nodes.

More comments are welcome.

BR
Yunfei

zhangyunfei
2010-10-28

发件人： Martin Stiemerling
发送时间： 2010-10-27 21:56:33
收件人： zhangyunfei; [email-masked]
抄送： 
主题： RE: [ppsp] Review of draft-ietf-ppsp-problem-statement-00

Hi  Yunfei,    all,

   Martin