Re: [ppsp] 回复 :RE: PPPSP Bar BOF minutes

"zhangyunfei" <zhangyunfei@chinamobile.com> Thu, 02 April 2009 07:56 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: ppsp@core3.amsl.com
Delivered-To: ppsp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CA23A6BDF for <ppsp@core3.amsl.com>; Thu, 2 Apr 2009 00:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -87.88
X-Spam-Level:
X-Spam-Status: No, score=-87.88 tagged_above=-999 required=5 tests=[AWL=-4.631, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=0.6, MANGLED_EMAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb3soEL-hr3Q for <ppsp@core3.amsl.com>; Thu, 2 Apr 2009 00:56:11 -0700 (PDT)
Received: from cmccmta (unknown [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id B0CEC3A68C3 for <ppsp@ietf.org>; Thu, 2 Apr 2009 00:56:10 -0700 (PDT)
Received: from LENOVO-917FFE55 ([10.1.4.140]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009040215570623-10993 ; Thu, 2 Apr 2009 15:57:06 +0800
Date: Thu, 02 Apr 2009 15:57:03 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: zongning 63316 <zongning@huawei.com>, "Michael.G.Williams@nokia.com" <Michael.G.Williams@nokia.com>
References: <00b601c9ac95$168bb910$43a32b30$@org><49d1ed5f.07a0660a.5a7c.150 1@mx.google.com><E10EF1DF7E0888498EB1A82965214D3427F1101298@NOK-EUMSG-01.mgdnok.nokia.com> <fbba8a6b82263.82263fbba8a6b@huawei.com>
Message-ID: <200904021556477815015@chinamobile.com>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-04-02 15:57:06, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-04-02 15:57:12
Content-Type: multipart/alternative; boundary="=====003_Dragon871677686112_====="
Cc: "ppsp@ietf.org" <ppsp@ietf.org>
Subject: Re: [ppsp] 回复 :RE: PPPSP Bar BOF minutes
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2009 07:56:14 -0000

Hi,Micheal,
We are just narrow the scope and doing drafting work.As a first attempt,we may narrow the problem statement as somewhat like "supporting p2p streaming cache in mobile and wireless envrinment to solve the low access point scalablity,high transmission cost by the limited access and backbone bandwidth".(This is not the final statement,just a way to express this problem).So it may relate to mobility issue.
However as stated by Ning,we haven't got the point to discuss the solution yet. 




zhangyunfei
2009-04-02



发件人: zongning 63316
发送时间: 2009-04-01 08:58:25
收件人: Michael.G.Williams@nokia.com
抄送: ppsp@ietf.org
主题: [ppsp] 回复 :RE: PPPSP Bar BOF minutes

Hi,  Michael,

The  consensus  from  bar  BoF  was  that  the  Problem  Statement  needs  to  be  refined.  And  we  are  still  far  from  discussing  solutions.
Thank  you.

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!
 *****************************************************************************************

-----  原邮件  -----
发件人:  Michael.G.Williams@nokia.com
日期:  星期二,  三月  31日,  2009  下午10:37
主题:  RE:  [ppsp]  PPPSP  Bar  BOF  minutes
收件人:  ron.even.tlv@gmail.com,  carlw@mcsr-labs.org,  ppsp@ietf.org
抄送:  zongning@huawei.com

>  Hi  Roni,  Carl,
>  
>  Sorry  to  miss  this  bar  BoF.  Was  there  consensus  that  the  problem  
>  statement  for  the  transport  needs  to  include  mobility?  Was  there  a  
>  sense  (hinted  at  by  the  notes  below)  that  the  solution  must  use  
>  MIP,  or  are  other  options  possible?
>  
>  http://www.ietf.org/internet-drafts/draft-zong-ppsp-reqs-00.txt  
>  doesn?t  seem  to  discuss  if  mobility  is  needed.
>  
>  Kind  Regards,
>  Michael
>  
>  ________________________________
>  From:  ppsp-bounces@ietf.org  [mailto:ppsp-bounces@ietf.org]  On  
>  Behalf  Of  ext  Roni  Even
>  Sent:  31  March,  2009  03:15
>  To:  carlw@mcsr-labs.org;  ppsp@ietf.org
>  Subject:  Re:  [ppsp]  PPPSP  Bar  BOF  minutes
>  
>  Hi,
>  Small  comment  "  Mic:    Someone  from  IAB"    the  someone  was  Gonzalo  
>  Camarillo.Roni  Even
>  
>  From:  ppsp-bounces@ietf.org  [mailto:ppsp-bounces@ietf.org]  On  
>  Behalf  Of  Carl  Williams
>  Sent:  Tuesday,  March  24,  2009  5:28  PM
>  To:  ppsp@ietf.org
>  Subject:  [ppsp]  PPPSP  Bar  BOF  minutes
>  
>  
>  Yunfei  asked  me  to  take  minutes  of  the  PPSP  bar  bof  last  night.    
>  Here  are  those  minutes:
>  
>  
>  
>  A  2nd  PPSP  bar  bof  was  held  on  Monday  March  23,  2009  at  IETF  74  
>  San  Francisco  meeting.    This  is  a  follow-up  to  a  meeting  at  IETF  
>  73  Minneapolis.    The  primary  PPSP  (p2p  streaming  protocol)  bar  bof  
>  agenda  is  as  follows.    Any  suggestions  and  contributions  are  
>  welcome.    I  did  an  approx  count  of  110  attendees.
>  
>  Notes  by  Carl  Williams
>  
>  PPSP  Bar  BoF--  IETF  74,  San  Francisco
>  2000-2200  Monday,March  23,Continental  3.
>  Mailing  list:ppsp@ietf.org <mailto:ppsp@ietf.org >  
>  http://www.ietf.org/mailman/listinfo/ppsp
>  Agenda
>  -  Introduction  (Yunfei  Zhang,  5  min)
>  -  Problem  Statement    (Yunfei  Zhang,  50  min)  draft-zhang-ppsp-
>  problem  statement-01
>   <http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-
>  statement-01.txt >
>  -  Protocol  Requirements(Ning  Zong,  15  min)  draft-zong-ppsp-reqs-00
>   <http://www.ietf.org/internet-drafts/draft-zong-ppsp-reqs-00.txt >
>  -  Protocol  Analysis  of  PPlive  and  PPStream  by  Interent  Measurement  
>  (Yunfei  Zhang,15  min)
>  draft-zhang-ppsp-protocol-comparison-measurement-
>  00 <http://www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-
>  comparison-measurement-00.txt >
>  
>  -  Introduction  of  Distributed  Services  Network,  a  vision  of  making  
>  PPSP  and  P2PSIP  into  reality      (Ning  Zong,  15')
>  
>    draft-zhang-ppsp-dsn-introduction-
>  00 <http://www.ietf.org/internet-drafts/draft-zhang-ppsp-dsn-
>  introduction-00.txt >
>  
>  
>  
>  Problem  Statement  ?  Yunfei  Zhang
>  
>  Yunfei  presented  slides  on  problem  statement.    He  noted  that  a  
>  revised  draft  since  Minneapolis  IETF73  bar  bof.      Some  facts  he  
>  noted  were  that  10%  of  backbone  traffic  at  major  Chinese  ISP  is  
>  PPLive.    PPLive  has  110  million  users,  2  million  concurrent  online  
>  peers.20-30%  is  outside  of  china  with  10-15%  in  us.    Yunfei  noted  
>  that  other  streaming  services  from  PPStream  had  70  million  users  
>  and  UUSee  had  1  million  concurrent  online  peers  during  Olympic  
>  games.    Finally  Yunfei  had  listed  many  other  P2P  streaming  vendors  
>  each  having  a  proprietary  streaming  protocol  to  support.
>  
>  Yunfei  stated  that  signal  and  transport  is  the  focus  of  PPSP  to  
>  solve  real  operational  problems.    He  raised  the  question  should  
>  piracy  or  content  protection  be  part  of  work.
>  
>  There  were  many  benefits  of  standardization  that  can  be  had  by  
>  IETF  examining  this  area  of  work  and  standardize  key  pieces.    A  
>  key  benefit  is  that  a  single  client  can  access  multiple  services.    
>  Yunfei  also  stated  that  operators  are  interested  in  this  as  it  is  
>  easier  to  cache  data  to  optimize  traffic  ?  including  mobile  
>  Internet.    For  Network  provider  the  open  standard  allows  interface  
>  with  CDN  systems.    Content  providers  developers  will  be  more  
>  likely  to  implement  an  open  standard,  applications  work  and  more  
>  services.
>  Mic:    Someone  from  IAB  says  that  the  Transport  Ads  weren’t  able  to  
>  make  the  Monday  evening  meeting  and  that  he  would  be  covering  the  
>  meeting  for  IAB.
>  
>  There  were  some  comments  made  about  who  would  implement  PPSP  if  
>  IETF  were  to  go  ahead  with  standardization.
>  
>  Christer  Holmberg:    stated  that  standardize  and  then  
>  interoperable.    In  response  to  other  comments  if  there  is  a  
>  standard,  others  will  switch.    It  has  happened  with  other  
>  technologies.    He  asked  the  question  if  Yunfei  was  in  contact  with  
>  others.    Only  PPLive  and  UUSee  for  now  was  the  response.
>  
>  James  Seng:      Personal  opinion  is  that  technology  is  not  a  key  
>  differentiator.promotion  and  marketing  is  a  key  differentiator.    
>  It  may  have  been  somewhat  important  early  but  not  so  important  now.
>  
>  David  Bryan:    Can  say  that  about  any  working  group.    Sometimes  
>  things  fail.    But  if  standardize,  people  may  do  it.
>  
>  Roni  Even:  Not  just  PPlive  issue.    Service  providers  can  work  in  
>  integrated  environment.    Will  help  people  implement.
>  
>  Comment  was  also  made  by  someone  that  he  had  know  of  other  
>  technologies  that  had  their  own  proprietary  solutions.    Then  you  
>  find  much  smaller  carriers  and  enterprises  ?  can’t  roll  out  their  
>  own  systems  for  legal  reasons  and  other  reasons.    So  standard  is  
>  useful  and  eventually  others  implement  it.
>  
>  Yunfei  continued  with  his  presentation.    He  presented  the  need  to  
>  cache  P2P  streaming  content  between  domains.    This  will  lower  the  
>  cross-network  traffic  and  provide  better  user  performance.    Very  
>  difficult  with  multiple,  proprietary  protocols  which  change  quite  
>  often.
>  Yunfei  went  over  the  standardization  interactions.
>  
>  Question  was  asked  if  the  talk  was  about  live  streaming  or  static  
>  conetn.    What  is  the  concept  of  a  chunks.      The  answer  was  that  it  
>  is  live  streaming.
>  
>  James  Seng:    rest  of  PPlive  streaming  is  mesh  architecture.    Not  
>  able  to  support  1  live  session;  PPlive  session  requires  multiple  
>  chunks.    From  10-20  peers  and  it  does  it  in  form  of  chunks.
>  
>  Simion:    if  it  takes  20  peers  to  support  1  peer,  how  will  network  
>  work?
>  James  Seng:    About  20%  of  peers  will  support  rest  of  80%
>  
>  When  using  PPlive;  5-6  minutes  no  acadmic  paper.    Max  latency  is  
>  90  seconds.  Helsinki  is  big  delay.    From  injection  to  peers  no  
>  matter  where  in  world  is  90  seconds.
>  
>  James  Seng:      metadata;  signaling  should  contain  metadata.
>  
>  Comment:      standardize  transport.    Done  in  2nd  stage.    No  strawman  
>  proposal  at  this  moment.
>  
>  Response  by  chair  is  that  this  is  TODO.    Evaluate  existing  
>  transport  protocols;  use  UDP  for  transport.
>  
>  Why  use  UDP  and  why  not  rtp?    What  is  relation  to  other  working  
>  groups.    P2PSIP,  ALTO,  and  P2PRG  is  exploring  research  problems.    
>  ALTO  is  about  providing  data  to  find  optimal  paths.    P2PSIP  
>  specifies  how  to  organize  DHT.
>  
>  PPSP  is  a  narrow  engineering  task  for  an  existing  problem.    PP2P  
>  is  for  standardizing  the  exchanging  information  in  a  streaming  
>  scenario.    May  resue  work  from  other  groups.    This  work  may  be  
>  useful  to  other  groups.
>  
>  
>  Question:    why  is  IETF  right  place?
>  
>  Response  by  chair:      IETF  is  right  place  for  standardizing  
>  interoperable  Internet-wide  protocols.    We  have  a  group  of  
>  interested  people  who  have  deployed  this  and  with  expertise  in  
>  P2P.      For  example,  streaming  service  operators  (PPlive,  etc).    
>  Top  P2P  streaming  researchers  in  IETF.    Existing  P2P  standards  
>  contributors.    Operators  with  P2P  streaming  implementations  and  
>  developers  of  P2P  streaming  cache  implementations.
>  
>  Question:    try  to  transport  media.    Audio/video  transport  working  
>  group  may  come  in  handy  here.      Comment  was  made  that  the  co-chair  
>  of  AVT  was  in  the  audience  ?  namely  Roni  Even.
>  
>  Chair:      early  to  discuss  what  will  be  done.    Standardization  on  
>  signaling  and  application  then  this  would  be  the  area.
>  
>  Comment:    I  like  module  design.    Here  things  are  compacted  into  a  
>  big  module  ball;  things  should  be  in  sub-problems  that  you  are  
>  trying  to  solve;  little  confusing.
>  
>  James  Seng:  Your  question  is  good  for  open  discussion  section.
>  
>  Yunfei  concluded  his  presentation  on  problem  statement  by  stating  
>  that  the  goal  was  to  eventually  form  a  working  group  within  IETF  
>  to  standardize  an  open  P2P  streaming  protocol.    Need  to  solve  
>  existing  operational  problem.    There  is  work  already  started  on  
>  PPSP  signaling  protocol  and  transport  protocol  is  under  
>  discussion.    Yunfei  stated  that  high-level  areas  of  deliverables  
>  are:  (1)  PPSP  architectural;  (2)  PPSP  signal  protocol;  (3)  PPSP  
>  Transport  Protocol.
>  
>  Comment:    There  is  confusion  to  me  on  what  problem  to  be  solved  
>  and  what  solutions  may  be.
>  
>  Richard  Bennett:    Break  into  component  parts;  Should  deal  with  P2P  
>  transport  problem  which  is  being  dealt  with  in  LEDBAT  WG.)    
>  Richard  stated  that  another  problem  is  to  deal  with  bw  constrained  
>  devices.  Separate  problem.
>  
>  
>  Henning  Schulzrinne  (Columbia  University):  It  is  obvious  you  have  
>  a  solution  in  mind;  let's  talk  about  problem  rather  than  a  solution.
>  
>  James  Seng  (Chair):    we  have  no  solution  in  mind.    There  is  an  
>  understanding  of  streaming  protocols  in  use  today.    James  asked  if  
>  we  need  to  standardize  P2P  streaming  at  all?
>  
>  Henning  Schulzrinne  (Columbia  University):    It  is  not  know  yet  and  
>  we  need  to  define  who  is  taling  to  who  and  what  info  they  are  
>  exchanging.
>  Comment:      should  divide  things  into  smaller  solutions  and  then  
>  compare  with  existing  solutions  (what  we  can  reuse).
>  
>  
>  Jame  Seng:    Repeated  that  we  are  not  pushing  a  solution  from  
>  PPLive.    PPlive  has  yet  to  decide  to  summit  work  to  IETF  on  
>  solution.    PPSP  may  reuse  some  work  like  RTSP,  some  from  AVT  
>  working  group,  etc….      He  mentioned  that  different  streams  are  
>  assembled  into  single  stream.
>  
>  
>  Presentation  was  made  on  PPSP  requirements  by  Ning  Zong.
>  
>  Ning  Zong  provided  a  diagram  on  the  scope  of  PPSP  and  what  it  
>  does.    He  stated  that  the  basic  role  of  PPSP  is  to  define  a  
>  protocol  of  locating  and  transmitting  real-time  data  efficiently  
>  from  multiple  sources  with  different  pieces  in  P2P  environment.
>  
>  Comment  made  by  attendee  that  we  should  have  started  with  this  
>  slide  in  problem  statement.    That  this  diagram  is  clear  and  can  
>  see  things  much  better  on  scope  of  PPSP.
>  
>  Comment:    I  still  don’t  see  major  difference  between  ppsp  and  file  
>  sharing.  There  is  no  information  exchanged  for  specific  streams  
>  regarding  video  signals.  It  looks  to  me    like  a  file  sharing  protocol.
>  
>  Comment:    China  Mobile  wants  to  solve  the  problem  of  controlling  
>  p2p  traffic  as  it  was  stated  early  that  10%  of  traffic  comes  from  
>  PPLive.    So,  what's  the  motivation  of  having  p2p  here?
>  
>  Chair:    China  Mobile  has  launched  mobile  TV,  which  may  have  
>  scalability  problems  and  we  look  to  P2P  to  solve  this.
>  
>  Yunfei  Zhang  presented  Protocol  analysis  of  PPlive  and  PPStream  by  
>  Internet  Measurement.    Yunfei  stated  there  were  questions  (1)  how  
>  to  evaluate  system  performance;  (2)  what  the  performance  
>  limitations  are  under  current  systems  models;  (3)  how  to  decrease  
>  the  pressure  on  the  network.    Yunfei  went  over  his  methodology  of  
>  his  measurements.    He  used  certain  reverse-engineering  methods  to  
>  analyze  its  working  principle.    But  they  they  focused  mainly  on  
>  PPlive  and  PPStream.
>  
>  Here  they  traced  a  standard  client,  captured  interactive  packets  
>  between  the  local  peer  and  others  with  packet  filtering  tools.      
>  They  traced  data  and  fed  it  into  the  dumping  tool.    Then  they  
>  analyzed  the  time  sequences  of  the  protocol  messages.
>  
>  Yunfei  stated  that  the  analysis  items  were:    (1)  official  client  
>  trace;  (2)  system  topology  crawler;  (3)  long  term  multi-online  
>  peers  probe;  (4)  P2P  streaming  client  measurement  in  mobile  IP;  
>  (5)  special  client  accessing  to  official  network  in  order  to  
>  evaluate  the  system  robustness  and  optimize  the  protocol.
>  
>  Messages  were  described  for  PPlive  Live  streaming  as  well  as  for  
>  PPlive  VOD.
>  
>  Yunfei  presented  a  summary  of  his  analysis  conclusion  of  what  was  
>  common  ground  and  what  were  differences  in  key  areas  such  as  chunk  
>  fetch  policy  as  well  as  buffer  aspect.    Such  an  analysis  allows  us  
>  to  have  good  understanding  for  moving  forward  on  PPSP  scoping  work.
>  
>  
>  Comments  continued  on  Open  discussion:
>  
>  Comment:      We  need  to  narrow  down  the  scope  and  provide  an  
>  architectural  framework  and  diagram  to  see  the  request  (who  is  
>  making  it  and  to  whom).    What  is  the  result  of  this  request  and  
>  what  are  all  the  interactions  coming  forth.
>  
>  Comment:    we  need  to  have  consensus  on  the  architecture  and  it  
>  must  be  clarified  more.      It  must  be  made  into  different  
>  components.    Also  what  are  the  working  groups  working  on  the  
>  various  components  today.
>  
>  James  Seng:    Asked  question  if  we  had  consensus  to  create  a  formal  
>  BOF  at  the  next  IETF  meeting  to  present  the  problem  statement  and  
>  a  system  architecture  framework.
>  
>  More  than  half  of  the  room  raised  their  hands.    No  official  count  
>  was  done  but  there  was  consensus  that  a  formal  IETF  BOF  should  be  
>  held.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
_______________________________________________
ppsp  mailing  list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp