[ppsp] review: draft-ietf-ppsp-reqs-01

[Lars Eggert <[e-mail]>]

Hi,

I had some time to give draft-ietf-ppsp-reqs-01 a closer read. I did find quite a number of open issues, see below.

  High-level comment: We need to make sure that all requirements are
  captured in the "PPSP.REQ" list of numbered requirements, and that the
  explanation following each numbered item is purely explanatory.
  Currently, some of the explanatory text does include additional
  requirements.


  High-level comment: This document requires a careful editing pass for
  such things as consistent terminology use, English language issues.
  Also, there's formatting issues wrt non-ASCII characters.


  High-level comment: Some of the editors have been silent on the WG
  list for one or even two years. The WG may need to discuss if there's
  a lack-of-energy problem here.


INTRODUCTION, paragraph 1:
> Intended status: Standards Track

  The charter milestone for this document is "Informational".


INTRODUCTION, paragraph 11:
> Copyright Notice

  The document has a disclaimer for pre-RFC5378 work, but was first
  submitted on or after 10 November 2008.  Does it really need the
  disclaimer?


Section 4., paragraph 0:
>        4.1.3.  Other General Requriements . . . . . . . . . . . . . .  8

  Nit: s/Requriements/Requirements/


Section 1., paragraph 1:
>    demonstrated by PPlive [WWW.PPLive], PPStream [WWW.PPStream], UUSee

  Nit: s/PPlive/PPLive/ (pick one way to capitalize it)


Section 1., paragraph 2:
>    Also some web2.0 streaming applications such as Youtube

  Nit: s/Youtube/YouTube/


Section 1., paragraph 3:
>    [WWW.YouTube], Tudou [WWW.Tudou] are reported to use or are preparing
>    to use P2P engine to accelerate its downloading rate and cut down the
>    transmission cost.

  Is there a reference to back this claim up?


Section 2., paragraph 5:
>    Peer list: A list of peer ID which are in a same swarm maintained by
>    the PPSP tracker.  A peer must fetch the peer list of a swarm from
>    the tracker to know which peers have the required content.

  "Must it", really? I agree that this is one way of getting a peer
  list, but in some deployments it is also possible to get a peer list
  from other peers or through some non-tracker third party.


Section 2., paragraph 7:
>    Usage type: Information used to identify the type of shared content.
>    Currently there are two usage types in PPSP: live streaming and VoD.
>    PPSP may also be extended to support more usage types, e.g. data
>    file.

  "Type of shared content" is not the same as "usage type". Which do you
  mean?


Section 4.1.1., paragraph 0:
> 4.1.1.  Basic Requirements to PPSP Node

  I think we're missing a high-level requirement that the tracker and
  peer protocols should be as similar as possible, in terms of design,
  message formats and flows, etc. Ideally, the peer protocol would be an
  extension to the tracker protocol that adds a few message types. We do
  NOT want two completely different protocols here.


Section 4.1.1., paragraph 1:
>    PPSP.REQ-1: Each peer in PPSP MUST has a unique identifier, i.e. peer
>    ID.

  Unique in what scope? Globally? Swarm? Also, English: s/has/have/


Section 4.1.1., paragraph 2:
>    It's a basic requirement for a peer to be uniquely identified in the
>    PPSP overlay that other peers or tracker can refer the ID for the
>    peer.

  The term "overlay" is ndefined. Do you mean "swarm"?


Section 4.1.1., paragraph 3:
>      The peer ID may be generated from IP address or SIP URI which
>    can distinguish this peer with the others.  But if IP address is used
>    as peer ID, the ID may be unstable as IP address may change while
>    peer moving.

  Not sure if we need to discuss here what the options are for choosing
  peer IDs. If we want to do this, we need to really discuss all the
  options, some obvious ones are missing (e.g., large random value,
  etc.)


Section 4.1.1., paragraph 4:
>    PPSP.REQ-2: The tracker in PPSP MUST have a public identity that can
>    be discovered and accessed by PPSP peers.

  "Public identity" is an undefined term. Do you simple mean "unique
  ID"? If so, again, unique in what scope?


Section 4.1.1., paragraph 5:
>    It requires trackers are reachable with identifiers from Internet or
>    other IP network.  But how to discover the tracker is not in the
>    scope of PPSP.

  I think you're mixing up ID and address here. Also, I don't think we
  need to require anything about tracker reachability here. Either a
  peer can reach an identified tracker with whatever connectivity it
  has, or it can't. Plus, there may be access control or policy in place
  that may cause a tracker to not respond to a peer even when it is
  reachable at the IP layer.


Section 4.1.2., paragraph 1:
>    PPSP.REQ-3: The data resources shared in PPSP services MUST be
>    classified and identified by different usage types.

  If you really mean "usage type" and not "type of content" (see comment
  on terminology above), I don't know if this makes total sense.
  Consider for example the case where some peers are watching a live
  streaming session for a content item. While the live session is still
  ongoing, other peers may already start watching the same content item
  as VoD. We surely would like the cached data on peers that got it via
  live streaming to be available to the peers that started watching a
  VoD session. That gets really hard if we label content with usage
  types. Can we not simply leave it up to the peer algorithms that
  decide which chunks to retrieve to determine how to do this for their
  usage type for a content item?

>    PPSP is designed for P2P live streaming and VoD.  It also has the
>    potential to be used for P2P data file sharing.  These usage types
>    have different requirements for truck queries and transmission
>    behaviors, e.g. data downloading order and time constraint.
>    Therefore, usage types are necessary to guide different content
>    sharing behaviors.

  See above, do we really need to segregate this at the information
  level?


Section 4.1.2., paragraph 3:
>    A swarm refers to a group of peers sharing the same content.  It
>    could be a TV Channel, film name or file name.  Swarm ID can be
>    looked as a resource ID to denote a specific content.  The swarm ID
>    can be used in two cases: 1) a peer requests the tracker for the peer
>    list indexed by a swarm ID; 2) a peer tells the tracker about the
>    swarms it belongs to.

  To me at least, "swarm ID" means "an ID for a swarm, i.e., a group of
  peers sharing a content item." Is this requirement saying that we're
  also going to use the swarm ID to identify the content item? So
  there'd always be exactly one swarm in the network per content item
  (and not maybe two disjoint sets of peers)?


Section 4.1.2., paragraph 5:
>    A key characteristic of P2P streaming system is allowing the data
>    fetching from different peers concurrently.  Therefore, the whole
>    content must be partitioned into small peaces, called chunks in PPSP,
>    for transmission.  The chunks must be formed and sorted by a standard
>    way, so when a peer says it requires some chunks, e.g. 011, 012 and
>    013, other peers could understand which peaces wanted by the peer
>    exactly.  Also, a normative buffer map can be used to show the chunk
>    availability of a peer.

  This doesn't quite capture it. I think what you mean is that the data
  needs to be chunkable, and that each chunk must have a unique ID
  (within which context?) I don't think we need to require anything
  about ordering here other than that peers must be able to determine
  which chunks IDs to request in order to obtain which part of the
  content object. (I.e. there's some sort of mapping, but we don't need
  to care about the details.) Nit: s/peaces/pieces/


Section 4.1.2., paragraph 7:
>    So, the availability of each data unit in a peer can be denoted in a
>    normative bitmap structure.  By exchanging the bitmap, peers in a
>    swarm can schedule the transmission in the grain of the smallest data
>    units.

  The text in PPSP.REQ-6 and the explanation don't go together.
  PPSP.REQ-6 says that the content item must have a standards format,
  which e.g. means that "this data item is an MPEG2 movie". But that is
  totally unrelated to denoting stuff in the availability bitmap. In
  fact, you don't even need to know what type the content has, you can
  chunk and bitmap it as a bytestream.


Section 4.1.3., paragraph 0:
> 4.1.3.  Other General Requriements

  Nit: s/Requriements/Requirements/


Section 4.1.3., paragraph 1:
>    PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable
>    peers to receive streaming data within the time constraints required
>    by specific content items.

  Why is this not a MUST? Also, this isn't always possible, simply
  because of the characteristics of the underlying connectivity.
  Finally, I think you wand to replace "streaming data" by "content".
  (Streaming data is just one type of content.)


Section 4.1.3., paragraph 2:
>    PPSP.REQ-8: The Tracker Protocol and Peer Protocol are Recommended to
>    be carried over TCP (or UDP, when delivery requirements cannot be met
>    by TCP).

  I really think we should be simply requiring TCP here and not even
  talk about UDP.


Section 4.2., paragraph 0:
>   PPSP.REQ-9: The Tracker Protocol is Recommended to support the IP
>   address change report sent from the peer.  The Peer Protocol may
>   support the IP address change report sent from the peer.

  I have no idea what this means. If this is about supporting mobile
  peers, why do we need anything specific to that in the protocol? A
  peer whose IP address changes simply looks like a leave-and-join to
  the swarm.


Section 4.2., paragraph 8:
>    PPSP.TP.REQ-7: The PPSP tracker MAY generate the peer list with the
>    help of traffic optimization services, e.g.  Alto.

  Not sure if we need this, since a "MAY"-level statement isn't really a
  requirement. This would make more sense as a non-requirement in
  explanatory text. Also, cite ALTO.


Section 4.2., paragraph 9:
>    PPSP.TP.REQ-8: The peer status report (update) message MAY have the
>    option to carry streaming status of the peer, including online time,
>    link status including available uplink and downlink bandwidth, peer
>    capability and other streaming parameters of the peer.  Therefore,
>    the tracker is able to select better candidate peers for streaming
>    without the help of other traffic optimization services.

  s/streaming//g (not all swarms are for streaming)


Section 4.3., paragraph 0:
>    PPSP.TP.REQ-9: Battery status of the peer SHOULD be reported to the
>    tracker in the case where the peers are constrained by their limited
>    battery (e.g. cellphone),

 Why? What is the tracker supposed to do with this information? Also,
 what metric do you envision to be applied here, mW?  4.3.  PPSP Peer
 Protocol Requirements


Section 4.3., paragraph 2:
>    PPSP.PP.REQ-1: The PPSP peers MUST implement the PPSP peer protocol
>    to exchange information and negotiate the data chunk requests and
>    responses before any content is transmitted.

  Not quite sure what the "before any content is transmitted" bit is
  about?


Section 4.3., paragraph 3:
>    PPSP.PP.REQ-2: The content availability request message MUST allow
>    the peer to solicit the chunk ID and bitmap information from other
>    peers with the respect of the peer list received from tracker.

  Not quite sure what you mean with "with respect to"?


Section 4.3., paragraph 8:
>    Due to the dynamic change of the buffered content in each peer and
>    the frequent join/leave of peers to the swarm, the content
>    availability among neighbourhoods are always changing,which requires
>    being updated on time.  This update should be done at least on
>    demand, which means when a peer requires finding more peers with
>    certain chunks, it send a message to all peer in the swarm for
>    content availability update.

  This is going too far in describing algorithmic behavior. I'm
  especially concerned about the "sending to all peers" bit; surely we
  want to allow peers freedom in determining how far to spread any such
  requests?


Section 4.3., paragraph 10:
>    PPSP.PP.REQ-6: The peer streaming status update information MAY be
>    advertised among peers.

  s/streaming//g (not all swarms are for streaming)

>    Streaming status information should be related to the content
>    delivery, including online time, link status including available
>    uplink and downlink bandwidth, peer capability and other streaming
>    parameters of the peer.  With this information, a peer can select
>    more appropriate peers for content sharing based on some content
>    sharing strategies and/or application requirements.

  <Insert my standard rant about how difficult it is to provide and use
  bandwidth information here.> Also, s/streaming//g (not all swarms are
  for streaming)


Section 4.3., paragraph 11:
>    PPSP.PP.REQ-7: Battery status of the peer SHOULD be reported to other
>    peers in the case where the peers are constrained by their limited
>    battery (e.g. cellphone),

  See my battery comment for the tracker protocol.


Section 4.4., paragraph 1:
>    PPSP.ERR.REQ-1: A peer MUST be able to respond with error information
>    to the peers sending PPSP messages, when some information (e.g. peer
>    list, chunk expression) cannot be understood in the message.

  Why? Dropping such requests silently is much preferred from a DDoS
  angle.


Section 4.4., paragraph 4:
>    PPSP.ERR.REQ-2: A PPSP tracker, which is operating close to its
>    capacity limit, MUST be able to inform peers about its impending
>    overload situation, and redirect them to another PPSP tracker.

  Why? I really don't want to redo the SIP-overload work for PPSP. Let
  the peers choose to go to another tracker when the one they have
  chosen is unresponsive.


Section 4.4., paragraph 5:
>    PPSP.ERR.REQ-3: A PPSP tracker, which is operating close to its
>    capacity limit, MUST be able to inform peers about its impending
>    overload situation, and terminate the conversation with the current
>    PPSP tracker.

  See above.


Section 4.4., paragraph 6:
>    PPSP.ERR.REQ-4: A PPSP tracker, which is operating close to its
>    capacity limit, MUST be able to inform peers about its impending
>    overload situation, and reject new conversation attempts.

  See above.


Section 5., paragraph 2:
>    PPSP.SEC.REQ-1: PPSP MUST ensure that only authorized users can
>    access the original media in the P2P streaming system.  This can be
>    achieved by defining or adopting such mechanisms as user
>    authentication and/or key management scheme.

  I think this goes in the right direction, but is phrased in a way that
  may be too strong. How about "PPSP MUST support closed swarms, where
  are peers are authenticated." I think this is as much as we can
  guarantee, because even with closed swarms, the content can leak
  (think about a hacked peer).


Section 5., paragraph 3:
>    PPSP.SEC.REQ-2: Confidentiality of the streaming data SHOULD be
>    supported and the corresponding key management scheme MUST scale well
>    without degrading the system performance.

  s/SHOULD/MUST optionally/ (i.e., it must be implemented but may not be
  used by all swarms)


Section 5., paragraph 5:
>    PPSP.SEC.REQ-4: PPSP MUST prevent stream pollution attacks.  In the
>    stream pollution attack, the attacker mixes into the stream bogus
>    chunks, or declare the chunks it doesn't have.

  Do we need to prevent this attack outright, or is it sufficient to
  identify it and exclude the offending peer from the swarm (which may
  be easier)? In other words, do we really need to treat this attack
  differently than PPSP.SEC.REQ-5?


Section 5., paragraph 8:
>    PPSP.SEC.REQ-6: PPSP MUST prevent peers from exhausting the P2P
>    streaming system's available resource, e.g. processing capacity,
>    bandwidth, etc.

  How? The Internet as a whole doesn't have this capability, and since
  we're running on top of it, this seems difficult to achieve.


Section 5., paragraph 9:
>    Given the prevalence of DoS attacks in the Internet, it is important
>    to realize that a similar threat could exist in a large-scale
>    streaming system where attackers are capable of consuming a lot of
>    resources with just a small amount of effort.

  That makes sense, but PPSP.SEC.REQ-6 is phrased much more broadly.


Section 5., paragraph 10:
>    PPSP.SEC.REQ-7: PPSP SHOULD minimize the dependency on reachability
>    of centralized servers.

  Unless we're willing to make a statement like "all peers MUST be
  accessible as if they were trackers", this requirement is basically
  useless.


Section 5., paragraph 12:
>    PPSP.SEC.REQ-9: Security mechanisms of PPSP SHOULD not limit the
>    scalability, performance and reliability of the P2P streaming system.

  Security always introduces an overhead. So it will always limit the
  scalability and performance compared to using no security. So this
  isn't really a useful requirement. Also: s/SHOULD not/SHOULD NOT/


Section 8.2., paragraph 7:
>    [Survey]   Zong, N. and X. Jiang, "Survey of P2P Streaming",
>               IETF PPSP BoF, November 2008.

  Unused Reference: 'Survey' is defined on line 564, but no explicit
  reference was found in the text


Section 8.2., paragraph 8:
>    [ProbSta]  Zhang, Y., "Problem Statement of P2P Streaming Protocol
>               (PPSP)", IETF PPSP BoF, November 2008.

  Unused Reference: 'ProbSta' is defined on line 567, but no explicit
  reference was found in the text


Section 8.2., paragraph 9:
>    [P2PLive]  Guo, Y., Liang, C., and Y. Liu, "Adaptive Queue-based
>               Chunk Scheduling for P2P Live Streaming", IFIP
>               Networking Proceedings, May 2008.

  Unused Reference: 'P2PLive' is defined on line 570, but no explicit
  reference was found in the text


Section 8.2., paragraph 10:
>    [LiveStream]
>               Pascual, V., "Live Streaming over P2PSIP", International
>               SIP Conference 10th Edition, January 2009.

  Unused Reference: 'LiveStream' is defined on line 574, but no explicit
  reference was found in the text


Section 8.2., paragraph 11:
>    [I-D.ietf-p2psip-base]
>               Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
>               H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
>               Base Protocol", draft-ietf-p2psip-base-01 (work in
>               progress), December 2008.

  Unused Reference: 'I-D.ietf-p2psip-base' is defined on line 578, but
  no explicit reference was found in the text


Section 8.2., paragraph 12:
>    [PPSPPS]   Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
>               "PPSP Problem Statement",
>               draft-zhang-ppsp-problem-statement-05 (work in progress).

  This document has been replaced by draft-ietf-ppsp-problem-statement.