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

[Ning Zong <[e-mail]>]

Hi, Lars

Thank you for the deep review. Please see my response starting with [ZN].
I'd also like to invite more opinions/suggestions from other
authors/contributors as I think some of the issues are still open. Thanks!

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Lars
Eggert
发送时间: 2011年1月24日 17:46
收件人: [e-mail]
主题: [ppsp] review: draft-ietf-ppsp-reqs-01

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.

[ZN] I will check it through the document. If there are any requirements in
the explanatory text, I will separate them as new requirement items in the
next revision.


  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.

[ZN] Will be corrected in next revision.

  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".

[ZN] Will be corrected in next revision.


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/

[ZN] Will be corrected in next revision. 

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

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

[ZN] Will be unified as "PPLive" in next revision.

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

  Nit: s/Youtube/YouTube/

[ZN] Will be corrected in next revision.

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?

[ZN] You are right. I will check it with other authors and then add a
reference, or change the wording.

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.

[ZN] In current charter we don't focus on specific tracker entity, but
general tracker function provided with various forms such as centralized,
distributed, or third-party provided.
We can explicitly state in next revision that here the tracker refer to
tracker function, rather than tracker server.

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?

[ZN] Consider your further comments below, I agree that this requirement of
"usage type" for classifying live streaming, VoD, etc is not necessary for
tracker/peer protocols and can be implemented by application level.
So I propose to delete this requirement. Other thoughts?

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.

[ZN] You are right, and in the current design, the tracker and peer
protocols are similar. But do we need to make this as a formal requirement?

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/

[ZN] IMO, it is enough for peer ID to be unique in a swarm. I will
explicitly state this in next revision. Other thoughts?


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"?

[ZN] Should be 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.)

[ZN] Option for choosing peer ID is still a open issue. IMO, consider the
case that IP address may change, unique peer IDs such as those used in
RELOAD are preferred in peer/swarm management level, while IP address is for
peer connection.
Other thoughts?

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?

[ZN] The current statement is misleading. The main focus here is "publicly
reachable" rather than "unique ID".
In this case, I agree that we don't need requirement for reachability and
then propose to delete this requirement. Other thoughts?

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.

[ZN] see above.

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?

[ZN] see above.

>    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)?

[ZN] IMO, the content ID and swarm ID should be decoupled and let
application level to decide how to generate swarm ID.
I propose to change the text to " A swarm refers to a group of peers sharing
the same content. A swarm ID is an ID uniquely identifies a swarm. The swarm
ID can be used in two cases... ...".
Other thoughts?

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/

[ZN] You are right. The necessary requirement here is that a chunk must have
an unique ID in swarm wise.
I propose to change the text to "Each chunk MUST have an unique ID in the
swarm such as the peer understand which pieces are requested. An example for
generating the chunk IDs is the bitmap approach [cite]".
Other thoughts?

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.

[ZN] The text in PPSP.REQ-6 is misleading. I think the purpose here is to
define bitmap for denoting chunk availability.
Consider that PPSP.REQ-5 is the requirement for chunk ID and bitmap is just
one way for identifying chunks, I propose to delete PPSP.REQ-6.
Other thoughts?

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

  Nit: s/Requriements/Requirements/

[ZN] Will be corrected in next revision.

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.)

[ZN] IMO, tracker/peer protocols should help achieving the streaming feature
as stated in current PPSP charter. As tools in P2P streaming system, MUST is
too strong for protocols to guarantee the streaming feature.
Plus, I think we currently focus on streaming media, rather than all types
of content sharing according to the charter. Other thoughts?

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.

[ZN] I don’t quite understand why must TCP?

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.

[ZN] Yes, this is merged from another draft for mobile P2P case:
http://tools.ietf.org/id/draft-lu-ppsp-mobile-04.txt
IMO, this is helpful to re-connect between peers in a timely manner since
peer may not re-send join message to the tracker even after IP change. Other
thoughts?

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.

[ZN] How about change "MAY" to "SHOULD support" - which means "optionally
implement"?

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

[ZN] I think the main scenario is mobile P2P where peers have very limited
power and are not suitable for long-term streaming and the tracker may only
put those peers in limited number of swarms.

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?

[ZN] As stated in charter, content transmission itself is not in the current
scope. Chunk request and response are signaling for next-step data
transmission.

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"?

[ZN] Sorry for confusion. Should be "... from other peers in the peer list
received from the tracker".

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?

[ZN] I agree this is going too far beyond explanatory text. I will change
the wording and of course leave the freedom to peer algorithms.

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)

[ZN] Understand. How about "...link status including available bandwidth if
possible..." or just "...link status including DSL/wifi/etc..."? Other
suggestions?

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.

[ZN] See above.

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.

[ZN] I am OK with your suggestion. Other thoughts?

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.

[ZN] I am OK with your suggestion. Other thoughts?

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).

[ZN] I am OK with your suggestion.

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?

[ZN] I agree that we can merge this into 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.

[ZN] Concerning the comments below, I propose to restrict REQ-6 by only
explicitly stating prevent DoS attacks. Other thoughts?

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.

[ZN] I think it would make more sense if we state in the view of system
robustness, i.e. when centralized tracker fails the system SHOULD work by
supporting distributed tracker. Other thoughts?

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/

[ZN] I propose to delete this REQ-9.

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

[ZN] Will be corrected in next revision.

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

[ZN] Will be corrected in next revision.

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

[ZN] Will be corrected in next revision.

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

[ZN] Will be corrected in next revision.

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

[ZN] Will be corrected in next revision.

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.

[ZN] Will be corrected in next revision.