Subject: [ppsp] Brief review of draft-ietf-ppsp-problem-statement-01

From: Martin Stiemerling <[email-masked]>
Date: Fri, 11 Feb 2011 13:57:30 +0000

Dear all,

Here is my review of draft-ietf-ppsp-problem-statement-01.txt 
(http://tools.ietf.org/id/draft-ietf-ppsp-problem-statement-01.txt)

I have sometimes back commented on the -00 version of this draft and I wasn't too happy about the old version. However, the -01 has made good progress towards a problem statement draft. It is way more readable! 

The good thing is the separation in problem statement and also uses cases. 

Here are some few details:
- There are some places where company or particular project names are mentioned without having the benefit of mentioning them being clear to me. For example, the content centric projects are mentioned, but I don't see the near term relationship of those to the PPSP problem statement draft. I would suggest to remove these loosely related references. The same holds true for Pandoo/PPLive. 

- Section 3: This sections follows the right direction, but I would drill down the technical issues current caused (and foreseeable in the future) in more technical details. For instance, it is problematic to have p2p tv on mobile handsets, as they are limited in battery power, but the bigger issue seems to me the overloading of the wireless part, the backhaul, and probably even the GGSN (or however the packet gateway) is called. PPSP may not be able to fix the downlink part, but I could imagine that the mobile peers are at least not uploading anything or delegate this to the a PPSP super peer in the operator network. 

- Section 3.1: good start, but probably not enough text. this should also be set in relationship with DECADE

- Section 3.4: this is a chance of PPSP, but it may be also worth documenting the fact that a standardized PPSP may not ensure that you can use a single PPSP client for all TV programs or systems. It may happen that different systems use PPSP for signalling and media transport, but implement something system specific on top of that. For instance, they could use some home-grown codec (e.g. WebM) or use encryption.

This is a very brief review, but I would be happy to discuss how to progress with the draft.

  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: Tue, 15 Feb 2011 10:21:59 +0800

Hi Martin,
   Thanks so much for your review. Please see inline and looking forward to more comments on the details of the draft as well as how to proceed the draft.

BR
Yunfei

zhangyunfei
2011-02-15

发件人： Martin Stiemerling
发送时间： 2011-02-11 21:57:45
收件人： [email-masked]
抄送： 
主题： [ppsp] Brief review of draft-ietf-ppsp-problem-statement-01

Dear  all,

Here  are  some  few  details:
-  There  are  some  places  where  company  or  particular  project  names  are  mentioned  without  having  the  benefit  of  mentioning  them  being  clear  to  me.  For  example,  the  content  centric  projects  are  mentioned,  but  I  don't  see  the  near  term  relationship  of  those  to  the  PPSP  problem  statement  draft.  I  would  suggest  to  remove  these  loosely  related  references.  The  same  holds  true  for  Pandoo/PPLive.  
Okay.I'll delete such expressions.

-  Section  3:  This  sections  follows  the  right  direction,  but  I  would  drill  down  the  technical  issues  current  caused  (and  foreseeable  in  the  future)  in  more  technical  details.  For  instance,  it  is  problematic  to  have  p2p  tv  on  mobile  handsets,  as  they  are  limited  in  battery  power,  but  the  bigger  issue  seems  to  me  the  overloading  of  the  wireless  part,  the  backhaul,  and  probably  even  the  GGSN  (or  however  the  packet  gateway)  is  called.  PPSP  may  not  be  able  to  fix  the  downlink  part,  but  I  could  imagine  that  the  mobile  peers  are  at  least  not  uploading  anything  or  delegate  this  to  the  a  PPSP  super  peer  in  the  operator  network.  
I agree with you on the problems you mentioned in mobile P2P TV. Do you mean we need to state more clear what PPSP can do and what it cannot do and what the difference mobile peers have compared with wired peers?

-  Section  3.1:  good  start,  but  probably  not  enough  text.  this  should  also  be  set  in  relationship  with  DECADE
Do you mean a separate section to explain the relationship with related WGs?

-  Section  3.4:  this  is  a  chance  of  PPSP,  but  it  may  be  also  worth  documenting  the  fact  that  a  standardized  PPSP  may  not  ensure  that  you  can  use  a  single  PPSP  client  for  all  TV  programs  or  systems.  It  may  happen  that  different  systems  use  PPSP  for  signalling  and  media  transport,  but  implement  something  system  specific  on  top  of  that.  For  instance,  they  could  use  some  home-grown  codec  (e.g.  WebM)  or  use  encryption.
I agree. Thanks for your advice.

   Martin

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