Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03

Johan Pouwelse <peer2peer@gmail.com> Mon, 22 August 2011 19:06 UTC

Return-Path: <peer2peer@gmail.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3244721F8B28 for <ppsp@ietfa.amsl.com>; Mon, 22 Aug 2011 12:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.829
X-Spam-Level:
X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-2.580, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MANGLED_LIST=2.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjjjSuzpvnWc for <ppsp@ietfa.amsl.com>; Mon, 22 Aug 2011 12:05:59 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C221F8A97 for <ppsp@ietf.org>; Mon, 22 Aug 2011 12:05:59 -0700 (PDT)
Received: by pzk33 with SMTP id 33so17356874pzk.18 for <ppsp@ietf.org>; Mon, 22 Aug 2011 12:07:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=rC+MXF8tVoSUqIHVQj06d+X2Dfsq14e8M4o5tlqF/gI=; b=cg+7vkIBXfIzAL4G5UCixfLgXBDVVyPqCUWL66L97UYpNmt+gB0HKR8wzUoSo71X6R 12SYE2qhYD+VWYNBmh52N+NJzGfB8x7b3v/RAGdJNLWf1Dx0ITDJnpZh8Ub5FZKpS2Df AFZKWQDsz1lW4D25PHYZMnqh3r2qGd3A5whFs=
MIME-Version: 1.0
Received: by 10.68.43.67 with SMTP id u3mr288176pbl.312.1314040023797; Mon, 22 Aug 2011 12:07:03 -0700 (PDT)
Received: by 10.143.6.19 with HTTP; Mon, 22 Aug 2011 12:07:03 -0700 (PDT)
In-Reply-To: <E84E7B8FF3F2314DA16E48EC89AB49F01CF69BD0@Polydeuces.office.hd>
References: <E84E7B8FF3F2314DA16E48EC89AB49F01CF51D19@DAPHNIS.office.hd> <201108161556008185916@chinamobile.com> <E84E7B8FF3F2314DA16E48EC89AB49F01CF69BD0@Polydeuces.office.hd>
Date: Mon, 22 Aug 2011 21:07:03 +0200
Message-ID: <CAJYQ-fTvMSfmLoUhibzSDSSj9jPrxabgXeAr8_fY4CdAH9SSMA@mail.gmail.com>
From: Johan Pouwelse <peer2peer@gmail.com>
To: "ppsp@ietf.org" <ppsp@ietf.org>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 22 Aug 2011 19:06:00 -0000

The "draft-ietf-ppsp-problem-statement-03" looks very polished.
After a careful review I think this is all fine and ready for the next level.

Greetings, Johan Pouwelse.

2011/8/22 Martin Stiemerling <Martin.Stiemerling@neclab.eu>:
> Hi Yunfei,
>
>
>
> Here is the text proposal for the security section. It is fairly short but
> should suffice the considerations for the problem statement. I have included
> the "protection of the content distribution" to the scope; this is included
> in the current text. However, it will be necessary to document what the
> threat to the content distribution is, e.g., to not forward chunks or
> exchange chunks with bogus data; and also to document mitigations to this
> (hashes, hash tress, etc).
>
>
>
> Here you go:
>
>
>
> 6. Security Considerations
>
>
>
> This memo discusses the problem statement around a peer-to-peer streaming
> protocols without specifying the protocols. The protocol specification is
> deferred to other memos under development in the PPSP working group.
>
>
>
> The PPSP protocol specifications, e.g., the peer protocol and the tracker
> protocol, will document the expected threats and how they will be mitigated
> for each protocol, but also considerations on threats and mitigations when
> combining both protocols in an application. This will include privacy of the
> users, protection of the content distribution, but not protection of the
> content by Digital Rights Management (DRM).
>
>
>
>   Martin
>
>
>
> From: zhangyunfei [mailto:zhangyunfei@chinamobile.com]
> Sent: Tuesday, August 16, 2011 9:56 AM
> To: Martin Stiemerling; ppsp@ietf.org
> Subject: Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
>
>
>
> Hi Martin,
>
> Thanks for the careful review. Please see inline for the reply.
>
> BR
>
> Yunfei
>
>
>
> ________________________________
>
> zhangyunfei
>
> 2011-08-16
>
> ________________________________
>
> 发件人: Martin Stiemerling
>
> 发送时间: 2011-08-15 21:06:14
>
> 收件人: ppsp@ietf.org
>
> 抄送:
>
> 主题: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
>
>
>
> [Writing  not  as  WG  chair,  but  as  individual  contributor]
>
>
>
> Dear  all,
>
>
>
> I  have  reviewed  the  draft  draft-ietf-ppsp-problem-statement-03  and
>  did  mainly  find  editorial  issues.
>
>
>
> Non-Editorials:
>
> -  Section  3.1,  2nd  paragraph,  "    With  PPSP,  P2P  cache  can  detect
>  P2P  streaming  applications  much    easier  without  needing  to  update
>  its  library.";  It  might  not  be  completely    obvious  to  an  average
>  reader  why  a  standarizded  P2P  protocol  would  make  things  easier
>  here.  How  about  adding  at  the  end  of  this  sentence:  ",  as  there
>  is  only  a  single  protocol  to  be  detected  and  not  a  potentially
>  unknown  set  of  proprietary  P2P  protocols".
>
>
>
> [Yunfei]Good proposal!
>
> -  Section  3.2,  1st  paragraph,  1st  sentence.  I  cannot  see  the
>  relationship  between  the  section's  intended  scope  and  DONA  or  any
>  other  content  centric  networking.
>
> [Yunfei] Acutally it wants to explain the phenomenon that stream
> content(including using P2P)will account a lot in future network is a trend.
> But maybe we can replace the trend by actual figures(e.g, in section1, cisco
> figures)to avoid the misleading sentence.
>
> -  Section  3.2,  3rd  paragraph,  You  lost  me  with  the  everything
>  after  the  first  sentence  of  this  paragraph.  I  don't  understand
>  what  it  is  saying  or  what  it  should  be  saying.
>
> [Yunfei] The sentence is saying that PPSP reduces the complexity of the case
> by case adaptation between CDN and the CP.Maybe I can rewrite this part.
>
> -  Section  3.3,  1st  paragraph,  The  first  sentence  about  "mobility
>  and  wireless  are  becoming  increasingly  dominate  "  is  basically
>  reflecting  the  current  situation,  but  what  is  the  relationship  to
>  the  future  Internet  activities  mentioned  there?  The  mobile  and
>  wireless  part  is  already  sort  of  dominant  by  today.
>
> [Yunfei] Good question. Similar to  section 3.1, replace "trend" by "fact".
>
> -  Section  3.4,  2nd  paragraph:  I  know  what  this  paragraph  is
>  aiming  at,  i.e.,  reusing  the  same  library  and  potentially  other
>  optimizations.  But  it  would  be  better  to  rephrase  the  paragraph.
>  E.g.,  "PPSP  can  help  to  reduce  the  resource  consumption  on
>  resource  constraint  devices,  such  as  STBs  or  mobile  phones,  by
>  reusing  a  PPSP  base  library  and  ..."
>
> [Yunfei] Fine for the change.
>
>
>
> -  Security  section:
>
> I'm  not  sure  that  the  current  security  section  is  exactly  what  we
>  need  for  the  problem  statement.  It  is  on  one  hand  detailed  on
>  the  threat  description  (e.g.,  "peers  may  report  fake  information
>  about  available  content"),  but  on  the  other  side  lacks  the
>  description  of  countermeasures  to  those  threats.
>
> I  would  propose  to  rewrite  the  security  section  to  cover  a
>  broader  focus  on  highlighting  certain  threats,  but  letting  the  fix
>  to  those  to  the  particular  protocol  specifications,  i.e.,  the  peer
>  protocol  and  the  tracker  protocol.
>
>
>
> I  can  provide  some  initial  text,  if  there  is  an  agreement  to
>  replace  the  security  section.
>
> [Yunfei] Thanks and would be glad to see your detailed text on broadening
> the section. And would ask Christian for more comments.
>
>
>
> Editorials  (mainly  suggestions  to  improve  readability):
>
> -  General:  There  are  many  places  where  the  dots  are  misplaced,
>  e.g.,  in
>
>  -  Section  1,  2nd  paragraph,  "  paradigm  [Survey].The".  This  should
>  read  "paradigm  [Survey].  The"  (space  between  dot  and  The)
>
> -  Which  Internet  draft  template  is  being  used  for  this  draft?  The
>  new  templates  have  the  "Abstract"    before  the  part  on  "  Status
>  of  this  Memo"  and  "  Copyright  Notice".
>
> -  Section  1,  2nd  paragraph,  comma  missing,  replace  "like  CNN  [CNN]
>  PPstream"  with  "like  CNN  [CNN],  PPstream"
>
> -  Section  1,  2nd  paragraph,  replace  "Client-Server"  with
>  "client-server".  The  spelling  of  this  is  not  consistent  in  the
>  draft.
>
> -  Section  1,  4th  paragraph,  replace  "Almost  all  these  systems"
>  with  "  Almost  all  of  these  systems".
>
> -  Section  1,  4th  paragraph,  replace  "P2P  streaming,  the  open
>  protocols  will  dynamically  reduce    "  with  "P2P  streaming,  open
>  protocols  may  reduce  "
>
> -  Section  2,  paragraph  starting  with  "PPSP",  replace  "The
>  abbreviation  of  P2P  streaming  protocols"  with  "The  abbreviation  of
>  Peer-to-Peer  Streaming  Protocols"
>
> -  Section  2,  paragraph  starting  with  "Tracker",  replace  "list  of
>  peers  storing  chunks  for  a  specific  channel  or  streaming  file"
>  with  "list  of  peers  which  participate  in  a  specific  video  channel
>  or  in  the  distribution  of  a  streaming  file".
>
> -  Section  2,  paragraph  starting  with  "Tracker",  replace  "from  peers
>  for  peer  lists"  with  "from  peers  with  a  list  of  candidate
>  peers".
>
> -  Section  3,  1st  paragraph,  replace  "The  problems  brought  by
>  proprietary"  with  "The  problems  imposed  by  proprietary"
>
> -  Section  3.1,  title  of  this  section,  replace  "Difficulties  for
>  ISP  in  deploying  P2P  caches"  with  "Difficulties  for  ISPs  in
>  deploying  P2P  caches"
>
> -  Section  3.1,  1st  paragraph,  replace  "P2P    cache  is  used  to
>  reduce  the"  with  "P2P  caches  are  used  to  reduce  the"  or  "P2P
>  caching  is  used  to  reduce  the"
>
> -  Section  3.1,  2nd  paragraph,  replace  "With  PPSP,  P2P  cache  can
>  detect"  with  "With  PPSP,  a  P2P  cache  can  detect"
>
> -  Section  3.1,  2nd  paragraph,  the  last  sentence,  there  are  two
>  commas  between  "tracker/peer  protocol"  and  "which  is  easier..."
>
> -  Section  3.2,  2nd  paragraph,  replace  "Similar  to  the  cache  case,
>  this"  with  "Similar  to  the  caching  case  in  Section  3.1,  this"
>
> -  Section  3.3,  1st  paragraph,  last  sentence,  the  dot  at  the  end
>  is  missing.
>
> -  Section  3.3,  2nd  paragraph,  page  10,  replace  "trackers  and  peers
>  need  more  information"  with  "trackers  and  peers  may  need  more
>  information"
>
> -  Section  3.3,  2nd  paragraph,  page  10,  there  is  terminology
>  collision,  as  serving  gateway  is  translated  to  GGSN.  A  change  of
>  a  SGSN  will  not  be  noticed  by  the  terminal.  Moving  to  a  new
>  GGSN  might  be.  However,  moving  to  a  new  GGSN  might  be  experience
>  like  any  other  event  where  the  IP  address  changes.
>
> -  Section  3.4,  1st  paragraph,  replace  "In  other  word"  with  "In
>  other  words"
>
> -  Section  3.4,  1st  paragraph,  replace  "multiple  programs  in  one
>  resource  constraint"  with  "multiple  programs  in  a  resource
>  constraint"
>
> -  Section  4,  1st  paragraph:  replace  full  1st  paragraph  with
>
> "The  objective  of  the  PPSP  working  group  is  to  design  a  unified
>  peer-  to-peer  streaming  protocol  (PPSP)  to  address  the  problems
>  discussed  in  the  preceding  sections."
>
> -  Section  4,  3rd  paragraph:  replace  "and  then  retrieve  for  wanted
>  streaming"  with  "and  then  retrieve  the  wanted  streaming"
>
> -  Section  4,  4th  paragraph:  replace  "  topology  e.g.,  a  tree."
>  With  "  topology,  e.g.,  a  tree."
>
> -  Section  4,  4th  paragraph:  replace  "(maybe  with  recommended
>  order)"  with  "(potentially  in  a  recommended  order)"
>
> -  Section  4,  4th  paragraph:  replace  "Few  practical  systems"  with
>  "Few  commercially  deployed"
>
> -  Section  4,  5th  paragraph:  what  is  "unfounded  data"?
>
> -  Section  4,  6th  paragraph:  move  this  paragraph  to  page  12  before
>  paragraph  starting  with  "In  detail,"
>
> -  Section  4,  last  paragraph,  page  12:  I'm  not  sure  that  we  still
>  need  this  paragraph.  Can  we  remove  it?
>
> -  Section  5,  1st  paragraph,  there  is  a  leftover:  "   <Text  for
>  this  section >".
>
> -  Section  5.2,  1st  paragraph,  replace  "Also  it  can  also  talk"
>  with  "It  can  also  communicate"
>
> -  Section  5.3,  2nd  paragraph,  replace  "  With  PPSP  Peers  can
>  identify  the  types  of  access  networks,  their  load/congestion
>  information"  with  "  With  PPSP,  peers  may  be  able  to  identify  the
>  type  of  access  networks,  average  load".  Do  not  include  congestion
>  information,  as  this  information  is  anyhow  too  volatile  to  be
>  tracked  by  some  entity  of  the  peer  network,  other  than  the  peers
>  which  are  anyhow  directly  communicating  with  each  other.
>
> -  Section  5.3,  2nd  paragraph,  replace  "be  selected,  which  will
>  lead  to"  with  "be  selected,  which  may  lead  to"
>
> -  Section  5.5,  1st  paragraph,  replace  "section3"  with  "Section  3"
>
> -  Section  5.5,  1st  paragraph,  replace  "nodes  in  the  network"  with
>  "nodes  at  the  network"
>
> -  Reference  section:  This  section  does  not  follow  the  style  of
>  references  as  used  in  the  RFC  series  and  needs  to  be  updated.
>
>
>
> [Yunfei]I'll update these editorial issues in new version draft.
>
>
>
> Kind  regards
>
>
>
>    Martin
>
>
>
> martin.stiemerling@neclab.eu
>
>
>
> NEC  Laboratories  Europe  -  Network  Research  Division  NEC  Europe
>  Limited  |  Registered  Office:  NEC  House,  1  Victoria  Road,  London
>  W3  6BL  |  Registered  in  England  2832014
>
>
>
>
>
> _______________________________________________
>
> ppsp  mailing  list
>
> ppsp@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ppsp
>
> _______________________________________________
> ppsp mailing list
> ppsp@ietf.org
> https://www.ietf.org/mailman/listinfo/ppsp
>
>