Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)
draft-ietf-ppsp-problem-statement-15

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"

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

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

   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.

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.