Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)

Note: This ballot was opened for revision 07 and is now closed.

(David Harrington) Discuss

Discuss (2012-02-28 for -08)
updated for -08-

This update does not address the discusses I raised for -07-. 
I see that the intention is to combine the problem statement and requirements into one document. I think the title (not the filename) should be changed to reflect this. Please address the discuss points below:

1) in section 4, there is a discussion of pull-based versus push-based. The discussion talks about the benefits of pull-based (but not the drawbacks) and the fact that most systems use this approach. Then the push-based approach, which few deployed systems use, is discussed including the drawbacks but not much about the benefits. Then the conclusion is that a hybrid system woudl be best, with little justification for why hybrid i smore practical, and no discussion of whether anybody actually does this now.

2) This document is supposed to be a problem statement, but throughout it the design of the proposed PPSP protocol is thron in. This document should focus on identifying what the problems are that need to be solved. Basically, this should discuss what problems the tracker and peer protocols each must address. This document seems to lump the tracker and peer protocols together as the PPSP protocol, and doesn't differentiate or clearly describe the problems that need to be solved by each protocol.

I recommend dropping the notion of a PPSP protocol suite, which seems to encourage marketing of PPSP, and blurring of the distinction between the two protocols. This document should focus on describing the problems to be addressed by each of the two protocols: 
"The tracker protocol handles the initial and periodic exchange of meta
information between trackers and peers, such as peer lists and content
information." - what are the problems that a tracker protocol addresses, and what problems must be overcome in its design? 
"The peer protocol controls the advertising and exchange of media data availability between the peers." - what are the problems that the peer protocol addresses, and what problems must be overcome in tis design?

in 5.3, there is an incomplete sentence.
in 5.3, "a mobile peer within a high-load base station is unlikely to be selected, which may lead to higher load on the base station." is unclear. Does this mean "a mobile peer within a high-load base station is unlikely to be selected, because selecting the mobile peer might lead to higher load on the base station."?

Discussion of the PPSP working group should be removed form the document. The goals and deliverables of the WG are documented in the charter, which will have a similar lifetime as the WG. This document published as an RFC will exist long after the WG has been closed.

(Martin Stiemerling) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2013-04-15 for -13)
No email
send info
I was surprised that my old Discuss had popped up when I re-entered the IESG. I have checked the new version, and that removes my original concern. Thank you for working so hard on this document, the document really is much improved since last time.

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-12-13 for -11)
No email
send info
Thank you for addressing my concern.

(Benoît Claise) (was Discuss) No Objection

Comment (2013-02-24 for -13)
No email
send info
Thanks for addressing my DISCUSS

(Ralph Droms) No Objection

(Wesley Eddy) (was No Record, Yes) No Objection

Comment (2012-12-12 for -11)
No email
send info
I think that given the protocol spec work PPSP is producing, this document is a helpful record for understanding some of the rationale behind protocol design decisions.

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-12-14 for -09)
No email
send info
- Section 4 says that you can have pull, push or a hybrid but does
say if the PPSP wg is going to work on all of those or some of
those. (Its sort of implied that all will be done via different
"modes" but that's not clearly stated.) Since it'd be better to only
have one "mode," I think the document should justify choosing to do
all "modes." (If that's really what the PPSP WG are planning. If not
then the document should say what the WG is actually planning.)

- Section 5 really needs to say what sections 5.x are.  They could
be use-cases the WG is going to tackle, or maybe the WG will decide
later, or whatever is the case. Without that, its hard to know why
sections 5.x are present.

- 5.1: "easily expand the broadcasting scale" just seems wrong.  Is
that sales-pitch (in which case delete it) or do you mean something

- Section 6 should mention that a malicious (or careless)
peer/tracker can leak private information about other peers or

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2011-12-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the comments provided in the Gen-ART Review by
  Francis Dupont on 24-Nov-2011.  The review can be found here:

(Dan Romascanu) No Objection

Comment (2011-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I find the document useful in intent but problematic in the way it is written, and I beleive that some of the sections need serious editing before publication. As the critical issues are covered in DISCUSSes of other ADs I will enter them as COMMENT: 

1. Section 1 needs to be shortened and all 'commercial' content needs to be dropped. The main functions should be described avoiding the mentioning of the vendors names. 

2. The requirements from the tracker and peer protocols need to be sumarized and listed in one place. I found the figures in section 5 quite useful to understand the functions, but it took time and effort to go through them as they are disparated in the descriptions of the use cases

3. Avoid text (like in the Abstract) that may be interpreted as the protocol proposal is included in this document

(Peter Saint-Andre) No Objection

Comment (2011-12-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The first three paragraphs of the Introduction are mostly marketing and deserve to be deleted.

"In this document we propose an open P2P Streaming Protocol..." I think you mean "propose the development of" because this document does not define such a protocol.

Section 3.3, paragraph 1: these numbers will become stale quickly. I suggest removing this paragraph.

(Robert Sparks) No Objection

Comment (2011-12-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It's not obvious how this document is going to help the working group with it's protocol work, or help document the work once it's complete. Is the set of use cases intended to be a set of motivating examples, or does it exhaustively cover every scenario the protocol is expected to handle? Please consider clarifying those points.

(Sean Turner) No Objection

(Adrian Farrel) (was Discuss) Abstain

Comment (2012-12-13 for -11)
No email
send info
I appreciate the effort that the authors have put in to revise this 
document after the previous evaluation by the IESG. This was a huge
task and they have gone a long way to improve the document.

At this point I do not believe it would serve any purpose to stand in
the way of this document. Therefore I will raise my concerns as Comments
and Abstain on the document.

I continue to believe that the use-cases are valuable material that will
help enable readers to understand the purpose of a streaming protocol.


The purpose of the document as stated in the Introduction is to propose
the development of a standardised protocol. I believe that we (the IETF)
understand the benefits of standardised solutions.

I would prefer that this document discussed (and claimed to discuss) the
functional requiremets that the proposed protocol must satisfy.

The introduction of section 6 certainly intends to meet my desires, but
I do not find the substance of the section convincing and I think that 
its introduction at the end of the document, its brevity compared to the 
rest of the document, and the issues raised by other ADs show that it is
not really the requirements section that the document needs.


Some of my comments from before have not been addressed...


I like that "chunk" is a unit of "block" with sub-unit "piece". What
is "block"? :-)


"key signaling protocol" may be unfortunate term because it is used
in other context to indicate a protocol that is used to signal "keys"

Barry Leiba Abstain

Comment (2012-12-12 for -11)
No email
send info
Overall, I'm not happy with this document, but I'm having trouble being specific enough to put my objections in as blocking comments (DISCUSSes).  I find a lot of it harder to understand than I'd like.  I hope the comments below can help, at least somewhat, in that regard, and I'll be happy to discuss these if you like.

-- Section 4 --

In Section 2, you define a "Tracker", and you say, "The tracker is a logical component which can be centralized or distributed."  That makes sense.  But in Section 4, you refer to the distributed version as "tracker-less architecture".  If it's not too late, I'd like to urge you to use "centralized-tracker" and "distributed-tracker" instead of "tracker-based" and "tracker-less" -- the tracker function still exists in what you're calling tracker-less architecture, and I think the term is misleading.

But now I'm not sure that "architecture" is the right word here either:

   PPSP.REQ-7: The tracker SHOULD be robust, i.e., when centralized
   tracker fails, the P2P streaming system should still work by
   supporting distributed trackers.

What you seem to be saying is that a P2P streaming system has to be able to shift back and forth from a centralized tracker function to a distributed one.  So whether it's centralized or distributed is not part of the *architecture*.

-- Section 6 --
A minor point, but I think it would improve the readability if you used either hanging indents or a numbered list for the requirements, so it's visually clearer where each requirement begins and ends.

A more major point is that this seems to me to be a very incomplete list of protocol requirements.  It doesn't feel like it gives much guidance toward developing the protocol, though that might just be because you don't really have many requirements that have to be documented in this way.  But many of the requirements that are here are hard for me to understand as written.  See below for some of that.

   PPSP.REQ-1: Each peer MUST have a unique ID (i.e. peer ID) in a swarm.
   It's a basic requirement for a peer to be uniquely identified in a
   swarm that other peers or tracker can refer to the peer by ID.

The definition of "Peer ID" says this:

   Peer ID: The identifier of a peer such that other peers, or the
   tracker, can refer to the peer by using its ID.

The definition seems to mean that the peer ID is unique in a more broad universe than the swarm.  Does a peer have a peer ID when it's not part of a swarm?  Does its Peer ID change when it changes swarms?  A peer can be in more than one swarm; does it have a different peer ID in each swarm?  This isn't clear.

   PPSP.REQ-3: The streaming content MUST allow to be partitioned into

I can't parse this, and I don't understand it.  It must allow *what* to be partitioned?  How does streaming content "allow" anything?  Is it that the peer or the swarm or the tracker allows something?  As I say, I don't understand.

   PPSP.REQ-4: Each chunk MUST have a unique ID (i.e. chunk ID) in the

   Each chunk must have a unique ID in the swarm so that the peer can
   understand which chunks are stored in which peers and which chunks
   are requested by other peers.

I understand the requirement -- that's fine -- but I don't follow the rationale: all peers in a swarm are serving up the same content, right?  And how does the chunk ID tell anyone where the chunk is stored?

   PPSP.TP.REQ-1: The tracker protocol MUST allow the peer to solicit
   the peer list from the tracker with respect to a specific swarm in a
   query and response manner.

   The tracker request message may also include the requesting peer's
   preference parameter (e.g. preferred number of peers in the peer list)
   or preferred downloading bandwidth. The tracker will then be able to
   select an appropriate set of peers for the requesting peer according
   to the preference.

   PPSP.TP.REQ-2: The tracker SHOULD support generating the peer list
   with the help of traffic optimization services, e.g. ALTO

PPSP.TP.REQ-1 is written as "THE peer list from the tracker", but the explanation of REQ-1 and the wording of REQ-2 makes it seem like there isn't a fixed peer list that a particular tracker will give for a given swarm.  It seems that when a peer requests *A* peer list from the tracker, the tracker is likely to return a list that's tailored to the requesting peer, and that probably doesn't just contain all the peers in the swarm.  Is that right?

If that's what's expected, that should be made clearer.

   PPSP.TP.REQ-5: The chunk availability information between peer and
   tracker MUST be expressed in a compactable method.

   The peers may report chunk availability digest information (i.e.,
   compact expression of chunk availability) to the tracker when
   possible in order to decrease the bandwidth consumption in mobile
   networks. For example, if a peer has a bitmap like 111111...1(one
   hundred continuous 1)xxx..., the one hundred continuous "1" can be
   expressed by one byte with seven bits representing the number of "1",
   i.e., "one hundred" and one bit representing the continuous sequence
   is "1" or "0". In this example, 100-8=92 bits are saved. Considering
   the frequency of exchange of chunk availability and the fact that
   many bitmaps have a quite long length of continuous "1" or "0", such
   compression is quite useful.

It seems to me that the real requirement here (and in PPSP.PP.REQ-7) is that the design of the mechanism for communicating chunk availability information has to take and frequency of requests and efficient use of bandwidth into account.  A requirements document shouldn't be going into detail about compression.

   PPSP.TP.REQ-7: The tracker protocol MUST allow the tracker to
   authenticate the peer.

   This ensures that only the authenticated users can access the
   original content in the P2P streaming system.

Is "allow" correct here?  You're saying that the tracker protocol MUST have a provision for authentication, but it doesn't have to be used?  But then the description seems to say that authentication *does* have to be used.  Again, I'm confused.

   PPSP.PP.REQ-2: The chunk information exchanged between a pair of
   peers MUST NOT be passed to other peers, unless validated (e.g.
   prevent hearsay and DoS).

Unless *what* is validated?  It sounds like it's the chunk information that has to be validated.  Or is it meant to be the request for information?  Validated how?  This is the first use of the word "validated", so I don't know what it means in this context.

(Pete Resnick) (was No Record, No Objection) Abstain

Comment (2012-12-12 for -11)
No email
send info
Barry has done a much better job of identifying the issues in Section 6 than I ever could. In addition, I find the use of 2119 language in requirements lists downright silly. But like Barry, I don't think any of these are DISCUSS worthy.

I also find the information in sections 3, 4, and 5, while of marginal interest, of very little use to someone who will eventually be implementing the protocols that come out of this group. I understand that the WG was chartered to produce a problem statement, but I don't think this turned out to be a useful product for an RFC.

I therefore Abstain.

(Gonzalo Camarillo) Recuse