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

From: Wesley Eddy <[email-masked]>
Date: Tue, 18 Oct 2011 00:29:30 -0400

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

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 18 Oct 2011 14:08:15 +0800

Thanks Wes for your careful review. I'll update the document soon according to your suggestions. Thanks again.

BR
Yunfei

zhangyunfei
2011-10-18

发件人： Wesley Eddy
发送时间： 2011-10-18 12:29:43
收件人： [email-masked]
抄送： [email-masked]
主题： [ppsp] AD review of draft-ietf-ppsp-problem-statement-05

In  some  cases,  I  indicated  suggested  changes  with  an  arrow  "from  - >  to"  

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

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

(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)"

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

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

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

--  
Wes  Eddy
MTI  Systems
_______________________________________________
ppsp  mailing  list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 25 Oct 2011 11:18:31 +0800

Hi All,

I've updated the distributed tracker draft for a while. Could you please
give your comment on it ? Thanks!

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.t
xt

Abstract

This document defines PPSP tracker usages for REsource LOcation And

Discovery (RELOAD).  Although PPSP assumes a centralized tracker from

peer's point of view, the logical centralized tracker could be realized

by a cluster of geographically distributed trackers. In this draft, we

design distributed trackers system, which are organized by RELOAD. It

provides lookup service for file/channel indexes and Peer Status among

the distributed trackers.

BR

Xiao Lin

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Tue, 25 Oct 2011 11:34:52 +0800

Thanks lin for updating the draft.

Maybe it’s better to give a brief introduction of the updating from -01
version to -02 version.

  _____  

Best Regards
Gu Yingjie

发件人: [email-masked] [mailto:[email-masked]] 代表 Xiao, Lin
(NSN - CN/Beijing)
发送时间: 2011年10月25日 乐乐11:19
收件人: [email-masked]
主题: [ppsp] PPSP distributed tracker

Hi All,

I’ve updated the distributed tracker draft for a while. Could you please
give your comment on it ? Thanks!

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.txt

Abstract

 

BR

Xiao Lin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 25 Oct 2011 14:41:13 +0800

The updating content in v02 includes :

l  The local tracker can keep the content record of  local peers, at the same time when it forwards the  content update/registration information to tracker overlay. So, most content requests can be solved locally. 

l  Delete  the open issues in chapter 5, and decide to use local connection tracker to manage the status of the ppsp peers locally, as most peer requests are from local peers according to the algorithm mentioned above. If the peer status can not be found in local connection tracker, the request is forwarded to the tracker overlay, as each local tracker always registries its own address to a node on tracker overly, whose ID has a DHT mapping  with the PPSP peer. As the position of the peer status , which is also the peer’s connection node address, is always registered to the tracker overlay according to RELOAD.

l  A data kind for peerStatusIndex is defined.

As still some editorial errors, I’ll give a new version soon.

BR

Xiao Lin 

From: ext Yingjie Gu(yingjie) [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 11:35 AM
To: Xiao, Lin (NSN - CN/Beijing); [email-masked]
Subject: 答复: [ppsp] PPSP distributed tracker

Maybe it’s better to give a brief introduction of the updating from -01 version to -02 version.

________________________________

Best Regards
Gu Yingjie

发件人: [email-masked] [mailto:[email-masked]] 代表 Xiao, Lin (NSN - CN/Beijing)
发送时间: 2011年10月25日 乐乐11:19
收件人: [email-masked]
主题: [ppsp] PPSP distributed tracker

Hi All,

I’ve updated the distributed tracker draft for a while. Could you please give your comment on it ? Thanks!

 

Abstract

 

BR

Xiao Lin

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Tue, 25 Oct 2011 15:40:39 +0800

Thanks to Lin  again for doing all the work.

I would apologize, as co-author, I failed to contribute to this version of
updating. 

Here is my comments and hope it can help.

  _____  

Best Regards
Gu Yingjie

发件人: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]] 
发送时间: 2011年10月25日 乐乐14:41
收件人: ext Yingjie Gu(yingjie); [email-masked]
主题: RE: [ppsp] PPSP distributed tracker

l  The local tracker can keep the content record of  local peers, at the
same time when it forwards the  content update/registration information to
tracker overlay. So, most content requests can be solved locally. 

Y.J. Gu :  How frequently the content record is shared among trackers?  I
guess not real-time sharing, because the content record is updated quite
often.  It could be an implementation choice, but we can give some advise in
the draft. 

l  Delete  the open issues in chapter 5, and decide to use local connection
tracker to manage the status of the ppsp peers locally, as most peer
requests are from local peers according to the algorithm mentioned above. If
the peer status can not be found in local connection tracker, the request is
forwarded to the tracker overlay, as each local tracker always registries
its own address to a node on tracker overly, whose ID has a DHT mapping
with the PPSP peer. As the position of the peer status , which is also the
peer’s connection node address, is always registered to the tracker overlay
according to RELOAD.

Y.J. Gu : Why not share peer status when you share content record? The
reason that we share content record among trackers is to decrease the
response time to a request for some content that is not locally stored. If
the content can be found locally, but the tracker still have to find the
status through the overlay, it doesn’t decrease the response time. The
status shared on tracker overlay might not be accurate, but neither do the
content record. It’s only a way to improve the performance. The peer, who
get an inaccurate information from the tracker, can correct it by
communicating with the peers in peerlist. Even the local connection tracker
can not promise an accurate content record and peer status.

 

BR

Xiao Lin 

 

  _____  

Best Regards
Gu Yingjie

Hi All,

 

Abstract

 

BR

Xiao Lin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 25 Oct 2011 16:11:33 +0800

Hi Yingjie,

I’ve answered your questions as followed.

By the way, I’m submitting a updated version 03, which may describe the change more clearly. 

BR

Xiao Lin

From: ext Yingjie Gu(yingjie) [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 3:41 PM
To: Xiao, Lin (NSN - CN/Beijing); [email-masked]
Subject: 答复: [ppsp] PPSP distributed tracker

I would apologize, as co-author, I failed to contribute to this version of updating. 

 

Best Regards
Gu Yingjie

Y.J. Gu :  How frequently the content record is shared among trackers?  I guess not real-time sharing, because the content record is updated quite often.  It could be an implementation choice, but we can give some advise in the draft. 

[Lin]: content record is not shared among trackers, it only stored in both local connection tracker (for traffic localization) and the responsible swarm tracker located by RELOAD mechanism (maintains overall peerlist for a swarm). 

Y.J. Gu : Why not share peer status when you share content record? The reason that we share content record among trackers is to decrease the response time to a request for some content that is not locally stored. If the content can be found locally, but the tracker still have to find the status through the overlay, it doesn’t decrease the response time. The status shared on tracker overlay might not be accurate, but neither do the content record. It’s only a way to improve the performance. The peer, who get an inaccurate information from the tracker, can correct it by communicating with the peers in peerlist. Even the local connection tracker can not promise an accurate content record and peer status.

[Lin]:   No. I mean, node status always maintained by its local connection tracker, but only put the information that how to find the local connection tracker of the peer (the position of the peer status) on the tracker overlay.  So, the frequent status updates can be done locally, but there must be a way (by RELOAD overlay ) to find the position of the status information, and the position information do not need frequent updates, which saves the traffic across overlay.  

 

BR

Xiao Lin 

 

Best Regards
Gu Yingjie

Hi All,

 

Abstract

 

BR

Xiao Lin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 25 Oct 2011 16:25:13 +0800

Hi,

As I said, I made another version to give a clearer description. Also the Figures and the flows are modified accordingly.

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-03.txt

BR

Xiao Lin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Tuesday, October 25, 2011 4:12 PM
To: ext Yingjie Gu(yingjie); [email-masked]
Subject: Re: [ppsp] PPSP distributed tracker

Hi Yingjie,

BR

Xiao Lin

 

Best Regards
Gu Yingjie

 

BR

Xiao Lin 

 

Best Regards
Gu Yingjie

Hi All,

 

Abstract

 

BR

Xiao Lin

---

From: Johan Pouwelse <[email-masked]>
Date: Wed, 26 Oct 2011 23:39:11 +0200

Dear PPSP,
Just completed a review of V3 of your distributed tracker proposal.

Main point:
As indicated my me before within PPSP, light-weight solutions are not often
proposed here. This proposal leans towards overengineering.

This proposal does not make a distinction between tracker replication
and distribution using PEX or DHT. By having multiple central
trackers, reliability should improve. However, how many seconds does a
peer wait when a query gets no reply? If a peer waits for 10 seconds
before trying a secondairy peers the result is significant loss of
user experienced performance and degradation of streaming service.
Should a peer issue multiple request in parallel to ensure fast
performance at the cost of server resources? From my viewpoint a PPSP
standard should recommend policies here. You agree?

Section 2 defines six different entities/roles, where 2 is the
minimum. By expanding the tracker functionality to include network
locality, piece availability registration and a tracker2tracker
protocol we risk defining a standard which cannot be implemented,
scale or compete with the performance of minimalistic solutions.
Missing from this draft is the handling of NATed peers. Does the
tracker do a simple dialback to check if a peer is connectable? Is
connectability part of peer info?

For over 10 years the Bittorrent tracker protocol seems to be doing
well. This proposal is a radical departure from this deployed
technology. An explanation why this is done would significantly
improve this draft in my opinion. Is that possible?

 Greetings, johan.
On 25/10/2011, Xiao, Lin (NSN - CN/Beijing) <[email-masked]> wrote:
> Hi,
>
>
>
> As I said, I made another version to give a clearer description. Also the
> Figures and the flows are modified accordingly.
>
>
>
> [Lin]: content record is not shared among trackers, it only stored in both
> local connection tracker (for traffic localization) and the responsible
> swarm tracker located by RELOAD mechanism (maintains overall peerlist for a
> swarm).
>
>
>
> [Lin]:   No. I mean, node status always maintained by its local connection
> tracker, but only put the information that how to find the local connection
> tracker of the peer (the position of the peer status) on the tracker
> overlay.  So, the frequent status updates can be done locally, but there
> must be a way (by RELOAD overlay ) to find the position of the status
> information, and the position information do not need frequent updates,
> which saves the traffic across overlay.
>
>
>

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Thu, 27 Oct 2011 10:54:02 +0800

Hi Johan,

Thank you very much for your comments. I agree with you that the proposal now is not that mature. Valuable suggestions are appreciated and helpful to refine the solution.  

Try to answer your questions in line as following:

BR

Xiao Lin

-----Original Message-----
From: ext Johan Pouwelse [mailto:[email-masked]] 
Sent: Thursday, October 27, 2011 5:39 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Yingjie Gu(yingjie); [email-masked]
Subject: Re: [ppsp] PPSP distributed tracker

Dear PPSP,

Main point:

[Lin]: Yes. I think parallel requests may necessary, but not from peer directly. To keep the simplification, we need decouple the PPSP tracker protocol with the distributed tracker deployment solution here. A normative tracker request is sent to a local tracker (by tracker protocol). This local tracker takes the responsibility for the distributed searching, which needn’t be aware by the requested peer. As local swarms managed by the tracker, at most time it can reply a list with local peers. Or the swarm tracker, which responsible for the swarm globally, should be queried. The solution can reduce the cross area traffic in both peer overlay and tracker overlay. But considering the waiting time, as you suggested, the local tracker may send query the tracker overlay at the same time when it searches the swarm locally.

[Lin]:Yes. We do need NAT traversal in PPSP, but it should be solved from the level of PPSP tracker protocol. As the distributed tracker use directly the PPSP tracker protocol for peer-tracker communication, it’ll implement the NAT traversal mechanism adopted by tracker protocol. PPSP WG had made a decision to take this part out from tracker protocol as a individual draft for NAT traversal study:

http://tools.ietf.org/html/draft-li-ppsp-nat-traversal-02

[Lin]: Good question. A single service provider may not require such complex deployment. However, considering the purpose of the PPSP, which is to setup a standardized platform for all P2P file/video sharing applications. Multiple and distributed tracker deployment may required in the future. 

Greetings, johan.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of

> Xiao, Lin (NSN - CN/Beijing)

> By the way, I’m submitting a updated version 03, which may describe the

> change more clearly.

> 发件人: [email-masked] [mailto:[email-masked]] 代表 Xiao, Lin (NSN

> - CN/Beijing)