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

[Ballot comment]
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.

the changes out of the IESG review went through another short WGLC and the WG isn't completely happy with the changes. Waiting for an update of the draft to reflect the changes of the WG.

[Ballot discuss]
Only one issue left.
There are no management and operation requirements in the document: a clear show stopper.
How do you plan on managing your beast? From the charter, I see "operational requirements"

You inserted in the version 12:

  6.2. Operation & Management Requirements

  PPSP.OAM.REQ-1: PPSP protocols MUST provide adequate mechanisms for
  operation & management, as outlined in RFC5706 [RFC5706].

I believe that you completely missed the point.
The point is NOT to have this blanket statement to make the OPS ADs happy.
The point is that you think what the operation & management requirements are for the protocol you are about to specify.
Note: I had a conf. call with Stefano, your doc. shepherd to discuss this topic.

[Ballot comment]
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"

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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 that 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.

[Ballot discuss]
- There are no management and operation requirements in the document: a clear show stopper.
How do you plan on managing your beast?
From the charter, I see "operational requirements"

(2) A "requirements" document that details the specific functional,
operational and performance requirements of the two PPSP
protocols.

- What is the meaning of a SHOULD in a requirement document?
For example:
  PPSP.TP.REQ-4: The tracker protocol SHOULD support the report of the
  peer's chunk availability information to the tracker when tracker
  needs such information to steer peer selection.

  or

  PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP
  SHOULD be supported.

All requirements must be written with MUST, and it's up to framework to specify which of the options are MAY, SHOULD, MUST

[Ballot comment]
- I'm surprised not to see references to the CDNI work, RFC 6707 and 6770
CDNI is the use case in section 5.1, right?

-
  Client: A client in general refers to the service requester in
  client/server computing paradigm. In this draft a client also refers
  to a participant in a P2P streaming system that only receives
  streaming content. In some cases, a node not having enough computing
  and storage capabilities will act as a client. Such node can be
  viewed as a specific type of peer.

So what is a client?
In this draft a client is also ... So we have 2 definitions? A client in general, and a client in this draft?
I'm confused by the (3rd and) 4th sentence.

- My personal preference (up to your AD to enforce it or not) is to have the definitions capitalized.
Let me give an example:
  Peer list: A list of peers which are in a same swarm maintained by
  the tracker.  A peer can fetch the peer list of a swarm from the
  tracker or from other peers in order to know which peers have the
  required streaming content.

I took my dictionary and looked up "swarm".
However, it's only later that I learned that swarm is actually a definition

- I don't understand
  3) How to enable the tracker protocol light-weight, since a tracker
  may need to server large amount of peers?

- missing "is"
OLD
  1) How does the certain content be globally identified and verified?
  Since the content can be retrieved from everywhere, how to ensure the
  exchanged content between the peers authentic?
NEW
  1) How does the certain content be globally identified and verified?
  Since the content can be retrieved from everywhere, how to ensure the
  exchanged content between the peers is authentic?

-
OLD
  3) How to ensure the peer protocol efficient?

NEW
  3) How to ensure the peer protocol efficiency?

[Ballot comment]
[Setting back to No Record to remind me to do a new review]

I agree with the DISCUSS comments of Adrian and the second DISCUSS comment of David. I think there's a lot of unnecessary (and some inappropriate marketing) text in this document and I therefore think it will take some substantial editing to make this of value to be published.

IANA has reviewed draft-ietf-ppsp-problem-statement-11, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions which must be completed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)) to Informational RFC


The IESG has received a request from the Peer to Peer Streaming Protocol
WG (ppsp) to consider the following document:
- 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol
  (PPSP)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Peer-to-Peer (P2P for short) streaming systems show more and more
  popularity in current Internet with proprietary protocols. This
  document identifies problems of the proprietary protocols, proposes
  the development of Peer to Peer Streaming Protocol (PPSP) including
  the tracker and peer protocol, and discusses the scope, requirements
  and use cases of PPSP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational. As a problem statement, it’s more proper to be an informational RFC and this is already indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
From the Abstract section of the draft:
Peer-to-Peer (P2P for short) streaming systems show more and more    popularity in current Internet with proprietary protocols. This    document identifies problems of the proprietary protocols, proposes    the development of Peer to Peer Streaming Protocol (PPSP) including    the tracker and peer protocol, and discusses the scope, requirements    and use cases of PPSP.

Working Group Summary:
There is strong consensus on the WG process in this document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The proposed protocols are being developed and there are already at least three implementations of the PPSP tracker and peer protocol. And there are some operators planning to implement the spec after they are finished.

The draft describes the requirements and problem statements for the standardization of Peer and Tracker streaming protocols that are being specified in separate documents. The Problem Statement draft is not a protocol specification so the question about implementation does not apply. However, there are already both Peer and Trackers streaming protocol implementations.

Personnel:
Who is the Document Shepherd?

Stefano Previdi
Who is the Responsible Area Director?

Martin Stiemerling

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

An in depth review has been done by the Document Shepherd and by the Responsible Area Director.
Review has pointed out mostly editorial aspect of the draft content.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
According to the WG and IESG review comments, I think this version is well reflected the concerns about the breadth and the depth.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
The document would certainly benefit from review focused on Security aspects.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
Both Document Shepherd and Area Director already did a review of the document and both feel the document is ready for IESG review.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes. All authors confirmed IPR disclosure status.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
In the WG,  there are relatively notable number of people understand and agree with the document. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
idnits 2.12.13  tmp/draft-ietf-ppsp-problem-statement-11.txt:    Checking boilerplate required by RFC 5378 and the IETF Trust (see  http://trustee.ietf.org/license-info):  ----------------------------------------------------------------------------      No issues found here.    Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:  ----------------------------------------------------------------------------      No issues found here.    Checking nits according to http://www.ietf.org/id-info/checklist :  ----------------------------------------------------------------------------    ** There are 11 instances of too long lines in the document, the longest      one being 1 character in excess of 72.    == There are 22 instances of lines with non-RFC2606-compliant FQDNs in the      document.    Miscellaneous warnings:  ----------------------------------------------------------------------------    == Line 412 has weird spacing: '...is only  provi...'    Checking references for intended status: Informational  ----------------------------------------------------------------------------    == Unused Reference: 'PPTV' is defined on line 931, but no explicit      reference was found in the text    == Unused Reference: 'PPStream' is defined on line 933, but no explicit      reference was found in the text        Summary: 1 error (**), 4 warnings (==), 0 comments (--).      Run idnits with the --verbose option for more detailed information about      the items above.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
No IANA considerations on this draft.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
No such languages are used in this draft.

after the merger with the requirements document (done in order to satisfy IESG reviews), this needs to be re-last-called in the working group, as the requirements were never put through a WGLC

[Ballot discuss]
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.

[Ballot comment]
(This was a discuss. A WG chair re-assured me that the "usage"
document in the PPSP charter would address the issue.)
- I don't see what PPSP WG document will include "considerations on
threats and mitigations when combining both protocols in an
application." That's the kind of thing that gets forgotten and where
protocol specification authors will say "that's not my problem."
What's the plan for addressing that in the WG?

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

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

[Ballot discuss]
(And one for the authors/chairs...)
- I don't see what PPSP WG document will include "considerations on
threats and mitigations when combining both protocols in an
application." That's the kind of thing that gets forgotten and where
protocol specification authors will say "that's not my problem."
What's the plan for addressing that in the WG?

[Ballot comment]
I agree with the DISCUSS comments of Adrian and the second DISCUSS comment of David. I think there's a lot of unnecessary (and some inappropriate marketing) text in this document and I therefore think it will take some substantial editing to make this of value to be published.

[Ballot comment]
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

[Ballot discuss]
I do, of course, support the development of a P2P streaming protocol, and I think it will be good for the industry. It is good to write a document that provides some justification and background for this.

However, I do agree with others who have commented that the document overdoes this a little bit. A shorter and more matter-of-fact style would have worked better on me.

But that is not my Discuss comment, I also have a more specific technical concern. Section 3.1 makes it sound like to deploy P2P caches an ISP needs to implement DPI-based detection of P2P content. I think that is first of all wrong, as adding the ISP as a participant in the particular trackers and P2P networks offers a much cleaner way to do this. Secondly, I do not think the IETF should condone or recommend DPI-based hidden caching.

This does not change the fact that I agree with the general point of Section 3.1 that a standardized method will be easier to implement, even when you do the implementation in the correct way.

I suggest deleting some of the text from Section 3.1. that deals with the specifics of how the ISP deals with participation in a P2P network; those details are unnecessary for the general point to be made.

[Ballot discuss]
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.

[Ballot comment]
- 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
else?

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

[Ballot comment]
- 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-case 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
else?

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

[Ballot discuss]
(Discuss discuss, for the IESG really I guess)
How does this all fit with decade and cdni?  Are we heading towards a good
or bad outcome with all those?  An example of a bad outcome would
be 3 ways to do one thing that are incompatible but the same except for
gratuitous differences. Maybe I'm just missing some context but something
seems wrong somewhere...

(And one for the authors/chairs...)
- I don't see what PPSP WG document will include "considerations on
threats and mitigations when combining both protocols in an
application." That's the kind of thing that gets forgotten and where
protocol specification authors will say "that's not my problem."
What's the plan for addressing that in the WG?

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

---

The definition of CDN in section 2 actually only provides a definition
of "CDN node".

---

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

[Ballot discuss]
As it stands, I'm affraid I don't see much value in this document.
Although it is probably harmless and the usecases may provide
valuable background, a lot of the document is a discussion around
the topic and does not give the WG any guidance or instructions.

I think most of the "justification" in the Introduction is not really
needed. Since the WG has been chartered, it is not necessary to go into
great detail on your motivation. You could lift a few lines from the
WG charter, and then use the paragraphs that say what this document
does.

Similarly, section 3 provides motivation for a standard PPSP, but the
existence of the WG is plenty good enough orivation for the work. What
seems to be missng, however, is the problem statement that says what
the PPSP actually has to do. In other words, I find the document
strangely without guidance to the developers of a standard PPSP.

Fixing this might be particularly hard because there is no bug fix
and no easy textual addition. Maybe I should phrase the question as
"why does the WG see this document as a valuable addition to the canon?"

[Ballot comment]
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.

[Ballot discuss]
There is a fine line between providing evidence for a case to design something and delivering a commercial message. Unfortunately, even though the author does not appear to work for the companies mentioned the introduction sounds like a commercial. Additionally later in the document there is reference to at least one other company.

Please will the author look at each mention of a company name and re-write the text to provide the evidence in a more objective, vendor neutral, style.

[Ballot comment]
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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)) to Informational RFC


The IESG has received a request from the Peer to Peer Streaming Protocol
WG (ppsp) to consider the following document:
- 'Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Peer-to-Peer(P2P for short) streaming systems show more and more
  popularity in current Internet with proprietary protocols. This
  document identifies problems of the proprietary protocols, proposes a
  Peer to Peer Streaming Protocol(PPSP) including tracker and peer
  signaling components, and discusses the scope and uses cases of PPSP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/


No IPR declarations have been submitted directly on this I-D.

Hi; this is a big improvement and you pretty much addressed all my comments, but there are
still a few very minor clean-ups that I think should be made before going to IETF Last Call
and IESG Review.  I know these seem petty and annoying since they're now just editorial
comments and not at all technical, but as this is going to be the first PPSP document to go
forward for publication, I think we should strive to make it as high-quality as possible.  The
directorate reviews and IESG reviews will be much easier to handle if we leave them less of
these kinds of things to find.  I hope you'll agree.

The few items I noted in this version are:

- I probably wasn't clear when I commented about this before, but section 9 (References)
  should be specifically named "Informative References".

- There are two "Authors' Addresses" sections.  The second one should be deleted; it looks
  like it's just a template.

- In references, URLs should begin with "http://"

- If you check idnits:
  http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ppsp-problem-statement-06.txt
  It would be good to fix the 2 "weird spacing" warnings.

- I think the "missing reference" idnits comments are really just due to the lack of spaces
  between the  reference labels and surrounding text (e.g. "foo[bar]" or "[foo]bar" is found in
  some places instead of "foo [bar] baz".  These should be corrected by adding spaces.

I'm sorry for sending this back a second time, but do think we're very close now!

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
I've completed AD review of this document, and while the content is complete, I don't think it's editorially quite ready for IETF Last Call and IESG review.  My comments below are intended to help get it there.  In some cases, I indicated suggested changes with an arrow "from -> to" between the original "from" text and the suggested "to" text.


(1) In the abstract (and possibly the title too), P2P should be spelled out as peer-to-peer.  In the abstract, "PPSP" should be defined before use since this paragraph will appear in announcements (e.g. for IETF LC) and other places.  Note that PPSP is singular ("Protocol", not "Protocols", but the last sentence of the abstract and the title of Section 4 use plural).  I think it would be good to be more clear here and say something more like "proposes a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP."


(2) section 1, 2nd paragraph - "This is less challenging for highly increasing capability on hardware."  I think this sentence is vague at best and likely misleading.  The sentence prior to it talks about network efficiency without defining in what sense this is meant (is it efficient use of bandwidth, low-latency, low load on servers, low power usage, etc.).  The type of efficiency meant here should be clarified, and consider either removing or further clarifying the sentence following it about hardware capabilities.


(3) section 1, 3rd paragraph - Does "source" here refer to the original source of the media being streamed, the root node actually transmitting stream, or something else?  I think "heterogeneous kinds of terminals" would be more clear as "heterogeneous types of peer or client device platforms."?

(4) section 1, 4th paragraph - "lacking of an" -> "lack of an"

(5) section 1, 2nd to last paragraph - when "PPSP" is first used, define it.

(6) section 2 - The definition of Chunk is pretty non-specific; for instance, as-used in PPSP, is a chunk intended to fit in a single transmitted packet or is it generally a larger unit of several kB?  It's also unclear what's meant by "partitioned streaming" here, as that term is not used or defined elsewhere in the document as to how it differs from just "streaming".

(7) section 2 - In the swarm definition, I think it would be reasonable to say that they "distribute chunks of the same content", in order to tie the swarm definition into that other defined term.

(8) why is ALTO's problem statement (RFC 5693) listed as normative?  I don't believe it really is normative to this PPSP document, though it's certainly informative.

(9) Section 3.1, last paragraph.  We talk about PPSP here as if it already exists in a usable form.  Instead of "can" we probably need to say "should be able to", for instance, and there are other similar changes in this paragraph that should not mislead someone into thinking a PPSP product is already in existence and does these things.

(10) Section 3.2 - "P2P-type is accounting for a large portion" -> "systems using P2P account for a large portion".

(11) Section 3.2 - "vast of same" -> "vastly the same"?

(12) Section 3.2 - "contents, increases" -> "contents, and increases"

(13) Section 3.2 - "CDN provider" -> "CDN providers"

(14) Section 3.2 - "can be either HTTP or PPSP" -> "could be via something like traditional HTTP requests, or could use streaming setup via PPSP."?

(15) Section 3.3 - "seventeen millions" -> "seventeen million", and "more and more studies" -> "multiple prior studies"

(16) Section 3.3 - "lower and costly" -> "lower rate, and costly in terms of energy consumption"?

(17) Section 3.3 - "relatively frequest to exchange" -> "exchanged relatively frequently"

(18) Section 3.3 - I do not understand the sentence "The new-added information should help the tracker/peer to make the decision".  Consider removing this or finding a way to clarify what it means, if it's necessary to keep.

(19) Section 3.3 - "maybe requires a new expression on "bitmap"" -> "may require alternative methods for distributing bitmap information"?


(20) Section 3.4 - "resource-constraint" -> "resource-constrained" in the title and text

(21) Section 3.4 - "set top box" -> "set top boxes (STBs)"

(22) Section 3.4 - this should be clarified to distinguish between whether the resource that's constrained is the persistent storage or RAM on the devices

(23) Section 4 - "are belonging" -> "belong"

(24) Section 4 - In the description of push-based and hybrid modes, it's unclear how peers find the head node or how they find each other compared to how they find the tracker in a pull-based mode.  This probably requires a brief description.

(25) Section 4 - Instead of saying:
"PPSP is targeted to standardize the signaling protocols in this tracker-
  based architectures for supporting both live and VoD streaming."
I think it be more accurate to say:
"PPSP includes standard signaling protocols for tracker-based architectures
  that support either live or offline streaming."


(26) Section 4 - "In detail, PPSP designs -> "The PPSP design includes""

(27) Section 5.1 - The first paragraph needs to be rewritten, since it seems
more likely to refer to content providers (selling bits of media) rather
than "vendors" that we usually refer to as people selling boxes.  I think
the picture is clear, but the text is not.  Note that the super-node concept
was brought up in this paragraph without any explanation or definition of
what we mean by it in PPSP.

(28) Section 5.3 - "With PPSP Peers" -> "With PPSP, peers"

(29) Section 5.4 - CDS is not defined

(30) Section 5.5 - I understand the intent, but the first two paragraphs here
need to be cleaned up and clarified.  The figure is very clear; the text isn't.

(31) The document should consistently use either "P2P" or "p2p"

(32) Many of the Informative References are only URLs, and I suspect this RFC
will live on much longer than most of those URLs.  I think that wherever it's
reasonable, those URLs should be replaced with more stable references.  I
understand that this won't be possible in all cases.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Martin Stiemerling (martin.stiemerling@neclab.eu) is the document
shepherd for this document. The document shepherd has reviewed the
document and is is ready for forwarding it to the IESG.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

It has received adequate review from a broad range of people in the WG.
No concerns.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No, not necessary.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No, the document does not raise any concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus behind this document. No controversial issues.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Passed ID nits. There is one editorial, i.e., some lines are too long.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

There is a split in normative and informative references. There is
no normative reference which is not ready.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document has no request to IANA and also does not define
any identifier/extension/etc, as it is a problem statement only.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such formal languages here.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

P2P streaming systems show more and more popularity in current
Internet with proprietary protocols. This document identifies
problems of the proprietary protocols, proposes standard signaling
protocols called PPSP and discusses the scope and use cases of PPSP.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Nothing to note.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

This document has been reviewed by the PPSP WG.