Re: [ppsp] PPSP distributed tracker

["Xiao, Lin (NSN - CN/Beijing)" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, October 27, 2011 5:39 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Yingjie Gu(yingjie); [e-mail]
Subject: Re: [ppsp] PPSP distributed tracker

 

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?

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

 

 

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?

[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

 

 

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?

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

On 25/10/2011, Xiao, Lin (NSN - CN/Beijing) <[e-mail]> wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of

> Xiao, Lin (NSN - CN/Beijing)

> Sent: Tuesday, October 25, 2011 4:12 PM

> To: ext Yingjie Gu(yingjie); [e-mail]

> Subject: Re: [ppsp] PPSP distributed tracker

> 

> 

> 

> 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:[e-mail]]

> Sent: Tuesday, October 25, 2011 3:41 PM

> To: Xiao, Lin (NSN - CN/Beijing); [e-mail]

> Subject: 答复: [ppsp] PPSP distributed tracker

> 

> 

> 

> 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:[e-mail]]

> 发送时间: 2011年10月25日 乐乐14:41

> 收件人: ext Yingjie Gu(yingjie); [e-mail]

> 主题: RE: [ppsp] PPSP distributed tracker

> 

> 

> 

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

> 

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

> 

> 

> 

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

> 

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

> 

> 

> 

> 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:[e-mail]]

> Sent: Tuesday, October 25, 2011 11:35 AM

> To: Xiao, Lin (NSN - CN/Beijing); [e-mail]

> Subject: 答复: [ppsp] PPSP distributed tracker

> 

> 

> 

> 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

> 

> 

> 

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

> - CN/Beijing)

> 发送时间: 2011年10月25日 乐乐11:19

> 收件人: [e-mail]

> 主题: [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

> 

> 

> 

> 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

> 

>