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

From: Ning Zong <[email-masked]>
Date: Thu, 10 Feb 2011 17:11:43 +0800

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!

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Lars
Eggert
发送时间: 2011年1月24日 17:46
收件人: [email-masked]
主题: [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.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Feb 2011 15:51:42 +0200

Hi,

thanks for responding. I have a few more comments below; I'm cutting all the text that I think we have a way forward on.

> tracker function, rather than tracker server.

What I meant is that the current definition is too narrow. Yes, the tracker has a peer list. But so do the peers themselves (although it is likely much less complete than that of the tracker.) But in a system where peers exchange peer information directly, or there are multiple trackers, or there is some other way to get peer information, *nobody* may actually have the definitive list of peers in a swarm - and no one needs to, since the system still works OK.

> protocols are similar. But do we need to make this as a formal requirement?

Why not? 

> RELOAD are preferred in peer/swarm management level, while IP address is for

I'd simply cut the text above then.

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

Because building something on top of UDP is difficult; see RFC5405.

In which case do you think TCP will not be appropriate?

> peer may not re-send join message to the tracker even after IP change. Other

What I'm saying is that a mobility events to the tracker and to other peers looks exactly like a leave followed by a join. In other words, we don't need any extra support in the protocol for it.

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

ALTO is a mechanism for *peers* to perform better then random *initial* peer selection. It's completely unclear if the tracker can even do something useful with the ALTO information, at least without a lot more context about the peer.

> put those peers in limited number of swarms.

The tracker has *no* influence over what swarms peers join or not join, and it can't prevent anything. And peers can obviously simply lie about their battery information.

> possible..." or just "...link status including DSL/wifi/etc..."? Other

Remove it?

Lars

---

From: Ning Zong <[email-masked]>
Date: Fri, 11 Feb 2011 11:40:15 +0800

Hi, Lars,

Thank you for comments. See inline.

-----邮件原件-----
发件人: Lars Eggert [mailto:[email-masked]] 
发送时间: 2011年2月10日 21:52
收件人: Ning Zong
抄送: [email-masked]
主题: Re: 答复: [ppsp] review: draft-ietf-ppsp-reqs-01

Hi,

thanks for responding. I have a few more comments below; I'm cutting all the
text that I think we have a way forward on.

> tracker function, rather than tracker server.

What I meant is that the current definition is too narrow. Yes, the tracker
has a peer list. But so do the peers themselves (although it is likely much
less complete than that of the tracker.) But in a system where peers
exchange peer information directly, or there are multiple trackers, or there
is some other way to get peer information, *nobody* may actually have the
definitive list of peers in a swarm - and no one needs to, since the system
still works OK.

[ZN] I agree that the tracker is not the only part to provide peer list. In
PPSP.PP.REQ-4, it says that peer can also get an extra list of peers other
than those in the list from tracker.
And you are right that the statement here is not precise. I propose to
change "fetch the peer list of a swarm from the tracker" to "fetch an
initial peer list from the tracker or other entity in bootstrapping stage".

Why not?

[ZN] I am OK to make this a formal requirement. How about other
contributors?

[ZN]: I agree.

[ZN] Consider the cases:
1) a large number of connections between peers are only for temporary
information exchange (e.g. chunk availability exchange) and won’t persist
for data transfer (if the requested peers don’t have the requested chunks).
2) a peer may communicate with a small subset of peers only for a short term
and then frequently change to another small subset of peers (like PPLive).
TCP may introduce more (and possibly unnecessary) overhead.

> peer may not re-send join message to the tracker even after IP change.
Other

What I'm saying is that a mobility events to the tracker and to other peers
looks exactly like a leave followed by a join. In other words, we don't need
any extra support in the protocol for it.

[ZN] I agree that we don’t need extra message for this. But it seems that
we then need new requirement about when the peer should send join message -
bootstrap, IP address change, etc...?

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

ALTO is a mechanism for *peers* to perform better then random *initial* peer
selection. It's completely unclear if the tracker can even do something
useful with the ALTO information, at least without a lot more context about
the peer.

[ZN] I think in tracker based P2P system, the tracker can act as the ALTO
client, which receives ALTO information and performs peer selection (Section
3.1 in draft-ietf-alto-reqs-07.txt).
But anyway, I agree that this MAY-level statement should move to
non-requirement text. I propose to revise the requirement as "PPSP system
SHOULD support traffic optimization service, e.g. ALTO [cite]". Other
thoughts?

> put those peers in limited number of swarms.

The tracker has *no* influence over what swarms peers join or not join, and
it can't prevent anything. And peers can obviously simply lie about their
battery information.

[ZN] If tracker doesn't reply with an initial peer list, it would be
difficult (not impossible) for the requesting peer to start - just like
being lack of bootstrap information, right?
I am also thinking that lower battery status of a peer *may* lead tracker to
NOT to put this peer in the peer list for other peers, since lower battery
peer may unstable (e.g. offline soon).

Remove it?

[ZN] I am OK, how about other contributors?

Lars

---

From: "Y.J. GU" <[email-masked]>
Date: Fri, 11 Feb 2011 15:09:56 +0800

Sorry for chiming in. Here is some of my opinions on the comments and proposals.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ning
> Zong
> Sent: Friday, February 11, 2011 11:40 AM
> To: 'Lars Eggert'
> Cc: [email-masked]
> Subject: [ppsp] 答复: 答复: review: draft-ietf-ppsp-reqs-01
> 
> Hi, Lars,
> 

[Gyj] I agree that peer can get peerlist from Tracker and other peers. But I am not very sure whether 'getting peerlist from other entity in bootstrapping stage' or 'non-tracker third party'is in the scope of PPSP. According to Section 4 in draft-ietf-ppsp-problem-statement, there are only two entities in PPSP architecture : Tracker and Peer. I agree that a peerlist can be gotten from non-tracker and non-peer entity, but that is not PPSP consideration. So, getting peerlist from either Tracker or peer is okay, other than those, I think, are out of the scope of PPSP. 
I propose to revise the requirement as ' A peer can fetch the peer list of a swarm from
either tracker or other peers to know which peers have the required content '

> [ZN] I am OK to make this a formal requirement. How about other

[Gyj] What Lars suggest is an ideal situation. And we should follow the requirement. But for now, I am not sure whether there are some messages in Peer Protocol that can not be extend by Tracker Protocol. I suggest we define this requirement as a 'SHOULD' item. Lars also suggest 'SHOULD'.

> I'd simply cut the text above then.

[Gyj] What the Requirement draft needs to decide is whether the Peer ID need to be unique in global or just in a swarm. I didn't go through the requirement draft words by words, but my memory is that we don't decide yet. 

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Mon, 14 Feb 2011 17:54:56 +0800

Thanks Lars for such a close review on the draft. It's really helpful for us to re-consider some issues and to refine the draft for the next version.  
As the comments are very long, I just list my opinions simply as followed:

1. for the peerlist fetching, I think we have got the agreement that Peer can fetch the peer list of a swarm from either tracker or other peers, and the initial peerlist should be fetched from tracker.

2. Agree to add a new requirement to declare that the protocol design should keep same style for both Peer protocol and tracker protocol, in terms of message formats and flows,

3. It is agreed that the Peer ID is unique within a swarm. But considering the special situation that a peer may take part in multiple swarms, is it better to simply keep one ID for the peer among different swarms?

4.  For some issues from mobility consideration, I agree with Lars as I suggested in IETF 79 that, it's not necessary to make such a specific requirement to handle IP address changing. Any peer status change can be reflected in the periodically status report, including the battery status. The detailed items which status should be involved in the report should not be fully listed in the requirement draft.

5. for ALTO support, I agree with Ning that tracker can work as an ALTO client to refine the peer selection responding.

BR
Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Y.J. GU
Sent: Friday, February 11, 2011 3:10 PM
To: 'Ning Zong'; 'Lars Eggert'
Cc: [email-masked]
Subject: [ppsp] RE: 答复: 答复: review: draft-ietf-ppsp-reqs-01

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ning Zong
> thanks for responding. I have a few more comments below; I'm cutting 
> all the text that I think we have a way forward on.
> 
> > [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.
> 
> What I meant is that the current definition is too narrow. Yes, the 
> tracker has a peer list. But so do the peers themselves (although it 
> is likely much less complete than that of the tracker.) But in a 
> system where peers exchange peer information directly, or there are 
> multiple trackers, or there is some other way to get peer information, 
> *nobody* may actually have the definitive list of peers in a swarm - 
> and no one needs to, since the system still works OK.
> 
> [ZN] I agree that the tracker is not the only part to provide peer 
> list. In PPSP.PP.REQ-4, it says that peer can also get an extra list 
> of peers other than those in the list from tracker.

[Gyj] I agree that peer can get peerlist from Tracker and other peers. But I am not very sure whether 'getting peerlist from other entity in bootstrapping stage' or 'non-tracker third party'is in the scope of PPSP. According to Section 4 in draft-ietf-ppsp-problem-statement, there are only two entities in PPSP architecture : Tracker and Peer. I agree that a peerlist can be gotten from non-tracker and non-peer entity, but that is not PPSP consideration. So, getting peerlist from either Tracker or peer is okay, other than those, I think, are out of the scope of PPSP. 
I propose to revise the requirement as ' A peer can fetch the peer list of a swarm from either tracker or other peers to know which peers have the required content '

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

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

> information exchange (e.g. chunk availability exchange) and won’t 
> persist for data transfer (if the requested peers don’t have the requested chunks).
> 2) a peer may communicate with a small subset of peers only for a 
> short term and then frequently change to another small subset of peers (like PPLive).

> > 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?
> 
> What I'm saying is that a mobility events to the tracker and to other 
> peers looks exactly like a leave followed by a join. In other words, 
> we don't need any extra support in the protocol for it.
> 
> [ZN] I agree that we don’t need extra message for this. But it seems 
> that we then need new requirement about when the peer should send join 
> message - bootstrap, IP address change, etc...?
>
>
> >  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"?
> 
> ALTO is a mechanism for *peers* to perform better then random 
> *initial* peer selection. It's completely unclear if the tracker can 
> even do something useful with the ALTO information, at least without a 
> lot more context about the peer.
> 
> [ZN] I think in tracker based P2P system, the tracker can act as the 
> ALTO client, which receives ALTO information and performs peer 
> selection (Section
> non-requirement text. I propose to revise the requirement as "PPSP 
> system SHOULD support traffic optimization service, e.g. ALTO [cite]". 
> Other thoughts?
> 
> > 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
> The tracker has *no* influence over what swarms peers join or not 
> join, and it can't prevent anything. And peers can obviously simply 
> lie about their battery information.
> 
> difficult (not impossible) for the requesting peer to start - just 
> like being lack of bootstrap information, right?
> I am also thinking that lower battery status of a peer *may* lead 
> tracker to NOT to put this peer in the peer list for other peers, 
> since lower battery peer may unstable (e.g. offline soon).
> 
> >  <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?
> 
> Remove it?
>

---

From: Ning Zong <[email-masked]>
Date: Tue, 15 Feb 2011 09:32:06 +0800

Thanks Lin,

Please see inline.

-----邮件原件-----
发件人: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]] 
发送时间: 2011年2月14日 17:55
收件人: ext Y.J. GU; Ning Zong; Lars Eggert
抄送: [email-masked]
主题: RE: [ppsp] RE: 答复: 答复: review: draft-ietf-ppsp-reqs-01

Thanks Lars for such a close review on the draft. It's really helpful for us
to re-consider some issues and to refine the draft for the next version.  
As the comments are very long, I just list my opinions simply as followed:

1. for the peerlist fetching, I think we have got the agreement that Peer
can fetch the peer list of a swarm from either tracker or other peers, and
the initial peerlist should be fetched from tracker.
[ZN] +1

2. Agree to add a new requirement to declare that the protocol design should
keep same style for both Peer protocol and tracker protocol, in terms of
message formats and flows,
[ZN] +1

3. It is agreed that the Peer ID is unique within a swarm. But considering
the special situation that a peer may take part in multiple swarms, is it
better to simply keep one ID for the peer among different swarms?
[ZN] I would leave this cross-swarm peer ID management issue to the
application level - e.g. application may use its own mechanism to correlate
various peer IDs for a single node/device.

4.  For some issues from mobility consideration, I agree with Lars as I
suggested in IETF 79 that, it's not necessary to make such a specific
requirement to handle IP address changing. Any peer status change can be
reflected in the periodically status report, including the battery status.
The detailed items which status should be involved in the report should not
be fully listed in the requirement draft.
[ZN] I agree we can merge this into one requirement item.

5. for ALTO support, I agree with Ning that tracker can work as an ALTO
client to refine the peer selection responding.
[ZN] +1

BR
Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Y.J. GU
Sent: Friday, February 11, 2011 3:10 PM
To: 'Ning Zong'; 'Lars Eggert'
Cc: [email-masked]
Subject: [ppsp] RE: 答复: 答复: review: draft-ietf-ppsp-reqs-01

Sorry for chiming in. Here is some of my opinions on the comments and
proposals.

> initial peer list from the tracker or other entity in bootstrapping
stage".

[Gyj] I agree that peer can get peerlist from Tracker and other peers. But I
am not very sure whether 'getting peerlist from other entity in
bootstrapping stage' or 'non-tracker third party'is in the scope of PPSP.
According to Section 4 in draft-ietf-ppsp-problem-statement, there are only
two entities in PPSP architecture : Tracker and Peer. I agree that a
peerlist can be gotten from non-tracker and non-peer entity, but that is not
PPSP consideration. So, getting peerlist from either Tracker or peer is
okay, other than those, I think, are out of the scope of PPSP. 
I propose to revise the requirement as ' A peer can fetch the peer list of a
swarm from either tracker or other peers to know which peers have the
required content '

> [ZN] I am OK to make this a formal requirement. How about other 

[Gyj] What Lars suggest is an ideal situation. And we should follow the
requirement. But for now, I am not sure whether there are some messages in
Peer Protocol that can not be extend by Tracker Protocol. I suggest we
define this requirement as a 'SHOULD' item. Lars also suggest 'SHOULD'.

> I'd simply cut the text above then.

[Gyj] What the Requirement draft needs to decide is whether the Peer ID need
to be unique in global or just in a swarm. I didn't go through the
requirement draft words by words, but my memory is that we don't decide yet.