[ppsp] AD review of draft-ietf-ppsp-problem-statement-05

[Wesley Eddy <[e-mail]>]

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.

While it seems like a lot, most of these are actually pretty minor changes.

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


Thanks for bearing with these in order to progress this document.

-- 
Wes Eddy
MTI Systems