Re: [ppsp] AD review of draft-ietf-ppsp-problem-statement-05

["zhangyunfei" <[e-mail]>]

Thanks Wes for your careful review. I'll update the document soon according to your suggestions. Thanks again.

BR
Yunfei




zhangyunfei
2011-10-18



发件人： Wesley Eddy
发送时间： 2011-10-18 12:29:43
收件人： [e-mail]
抄送： [e-mail]
主题： [ppsp] AD review of draft-ietf-ppsp-problem-statement-05

I've  completed  AD  review  of  this  document,  and  while  the  content  is  
complete,  I  don't  think  it's  editorially  quite  ready  for  IETF  Last  Call  
and  IESG  review.    My  comments  below  are  intended  to  help  get  it  there.  
In  some  cases,  I  indicated  suggested  changes  with  an  arrow  "from  - >  to"  
between  the  original  "from"  text  and  the  suggested  "to"  text.

While  it  seems  like  a  lot,  most  of  these  are  actually  pretty  minor  changes.

(1)  In  the  abstract  (and  possibly  the  title  too),  P2P  should  be  spelled  
out  as  peer-to-peer.    In  the  abstract,  "PPSP"  should  be  defined  before  
use  since  this  paragraph  will  appear  in  announcements  (e.g.  for  IETF  LC)  
and  other  places.    Note  that  PPSP  is  singular  ("Protocol",  not  
"Protocols",  but  the  last  sentence  of  the  abstract  and  the  title  of  
Section  4  use  plural).    I  think  it  would  be  good  to  be  more  clear  here  
and  say  something  more  like  "proposes  a  Peer  to  Peer  Streaming  Protocol  
(PPSP)  including  tracker  and  peer  signaling  components,  and  discusses  
the  scope  and  uses  cases  of  PPSP."


(2)  section  1,  2nd  paragraph  -  "This  is  less  challenging  for  highly  
increasing  capability  on  hardware."      I  think  this  sentence  is  vague  at  
best  and  likely  misleading.    The  sentence  prior  to  it  talks  about  
network  efficiency  without  defining  in  what  sense  this  is  meant  (is  it  
efficient  use  of  bandwidth,  low-latency,  low  load  on  servers,  low  power  
usage,  etc.).    The  type  of  efficiency  meant  here  should  be  clarified,  
and  consider  either  removing  or  further  clarifying  the  sentence  
following  it  about  hardware  capabilities.


(3)  section  1,  3rd  paragraph  -  Does  "source"  here  refer  to  the  original  
source  of  the  media  being  streamed,  the  root  node  actually  transmitting  
stream,  or  something  else?    I  think  "heterogeneous  kinds  of  terminals"  
would  be  more  clear  as  "heterogeneous  types  of  peer  or  client  device  
platforms."?

(4)  section  1,  4th  paragraph  -  "lacking  of  an"  - >  "lack  of  an"

(5)  section  1,  2nd  to  last  paragraph  -  when  "PPSP"  is  first  used,  define  it.

(6)  section  2  -  The  definition  of  Chunk  is  pretty  non-specific;  for  
instance,  as-used  in  PPSP,  is  a  chunk  intended  to  fit  in  a  single  
transmitted  packet  or  is  it  generally  a  larger  unit  of  several  kB?    It's  
also  unclear  what's  meant  by  "partitioned  streaming"  here,  as  that  term  
is  not  used  or  defined  elsewhere  in  the  document  as  to  how  it  differs  
from  just  "streaming".

(7)  section  2  -  In  the  swarm  definition,  I  think  it  would  be  reasonable  
to  say  that  they  "distribute  chunks  of  the  same  content",  in  order  to  
tie  the  swarm  definition  into  that  other  defined  term.

(8)  why  is  ALTO's  problem  statement  (RFC  5693)  listed  as  normative?    I  
don't  believe  it  really  is  normative  to  this  PPSP  document,  though  it's  
certainly  informative.

(9)  Section  3.1,  last  paragraph.    We  talk  about  PPSP  here  as  if  it  
already  exists  in  a  usable  form.    Instead  of  "can"  we  probably  need  to  
say  "should  be  able  to",  for  instance,  and  there  are  other  similar  
changes  in  this  paragraph  that  should  not  mislead  someone  into  thinking  
a  PPSP  product  is  already  in  existence  and  does  these  things.

(10)  Section  3.2  -  "P2P-type  is  accounting  for  a  large  portion"  - >  
"systems  using  P2P  account  for  a  large  portion".

(11)  Section  3.2  -  "vast  of  same"  - >  "vastly  the  same"?

(12)  Section  3.2  -  "contents,  increases"  - >  "contents,  and  increases"

(13)  Section  3.2  -  "CDN  provider"  - >  "CDN  providers"

(14)  Section  3.2  -  "can  be  either  HTTP  or  PPSP"  - >  "could  be  via  
something  like  traditional  HTTP  requests,  or  could  use  streaming  setup  
via  PPSP."?

(15)  Section  3.3  -  "seventeen  millions"  - >  "seventeen  million",  and  
"more  and  more  studies"  - >  "multiple  prior  studies"

(16)  Section  3.3  -  "lower  and  costly"  - >  "lower  rate,  and  costly  in  
terms  of  energy  consumption"?

(17)  Section  3.3  -  "relatively  frequest  to  exchange"  - >  "exchanged  
relatively  frequently"

(18)  Section  3.3  -  I  do  not  understand  the  sentence  "The  new-added  
information  should  help  the  tracker/peer  to  make  the  decision".  
Consider  removing  this  or  finding  a  way  to  clarify  what  it  means,  if  
it's  necessary  to  keep.

(19)  Section  3.3  -  "maybe  requires  a  new  expression  on  "bitmap""  - >  "may  
require  alternative  methods  for  distributing  bitmap  information"?


(20)  Section  3.4  -  "resource-constraint"  - >  "resource-constrained"  in  
the  title  and  text

(21)  Section  3.4  -  "set  top  box"  - >  "set  top  boxes  (STBs)"

(22)  Section  3.4  -  this  should  be  clarified  to  distinguish  between  
whether  the  resource  that's  constrained  is  the  persistent  storage  or  RAM  
on  the  devices

(23)  Section  4  -  "are  belonging"  - >  "belong"

(24)  Section  4  -  In  the  description  of  push-based  and  hybrid  modes,  it's  
unclear  how  peers  find  the  head  node  or  how  they  find  each  other  
compared  to  how  they  find  the  tracker  in  a  pull-based  mode.    This  
probably  requires  a  brief  description.

(25)  Section  4  -  Instead  of  saying:
   "PPSP  is  targeted  to  standardize  the  signaling  protocols  in  this  
tracker-based  architectures  for  supporting  both  live  and  VoD  streaming."
I  think  it  be  more  accurate  to  say:
   "PPSP  includes  standard  signaling  protocols  for  tracker-based  
architectures  that  support  either  live  or  offline  streaming."


(26)  Section  4  -  "In  detail,  PPSP  designs  - >  "The  PPSP  design  includes""

(27)  Section  5.1  -  The  first  paragraph  needs  to  be  rewritten,  since  it  
seems  more  likely  to  refer  to  content  providers  (selling  bits  of  media)  
rather  than  "vendors"  that  we  usually  refer  to  as  people  selling  boxes.  
   I  think  the  picture  is  clear,  but  the  text  is  not.    Note  that  the  
super-node  concept  was  brought  up  in  this  paragraph  without  any  
explanation  or  definition  of  what  we  mean  by  it  in  PPSP.

(28)  Section  5.3  -  "With  PPSP  Peers"  - >  "With  PPSP,  peers"

(29)  Section  5.4  -  CDS  is  not  defined

(30)  Section  5.5  -  I  understand  the  intent,  but  the  first  two  paragraphs  
here  need  to  be  cleaned  up  and  clarified.    The  figure  is  very  clear;  the  
text  isn't.

(31)  The  document  should  consistently  use  either  "P2P"  or  "p2p"

(32)  Many  of  the  Informative  References  are  only  URLs,  and  I  suspect  
this  RFC  will  live  on  much  longer  than  most  of  those  URLs.    I  think  that  
wherever  it's  reasonable,  those  URLs  should  be  replaced  with  more  stable  
references.    I  understand  that  this  won't  be  possible  in  all  cases.


Thanks  for  bearing  with  these  in  order  to  progress  this  document.

--  
Wes  Eddy
MTI  Systems
_______________________________________________
ppsp  mailing  list
[e-mail]
https://www.ietf.org/mailman/listinfo/ppsp