Subject: Re: [ppsp] We have submitted a Tracker Protocol

From: "Wenjun (Kevin) Zeng" <[email-masked]>
Date: Wed, 02 Jun 2010 16:08:08 -0500

Hi Yingjie,

I agree the flexibility this function provides would be beneficial in some
scenarios, especially when streaming deadline is approaching and shorter
delay is desired.

Cheers!

-Kevin

From: Y.J. Gu [mailto:[email-masked]] 
Sent: Sunday, May 30, 2010 8:31 PM
To: [email-masked]; 'zhangyunfei'; 'Omer Luzzatti'; [email-masked]
Subject: 答复: Re: [ppsp] We have submitted a Tracker Protocol

Hi Kevin，

In live streaming, Tracker is able to provide precise peerlist upon a Swarm
ID. While in VoD, there can be multiple options. A requesting peer can get
some peers in a particular Swarm and ask some of them to check whether they
have the desired chunk. But considering the delay constraint in streaming,
this is not an efficient way. 

Another way is what we designed in our draft. Though this is not an always
guaranteed method, the general delay is much lower than the above method.
Besides, we can develop some enhanced mechanism to reduce the delay caused
by un-reported normal buffer aging.   

  _____  

发件人: Wenjun (Kevin) Zeng [mailto:[email-masked]] 
发送时间: 2010年5月30日 乐乐8:54
收件人: 'Y.J. Gu'; 'zhangyunfei'; 'Omer Luzzatti'; [email-masked]
主题: RE: Re: [ppsp] We have submitted a Tracker Protocol

Hi Yunfei and Yingjie,

Thanks a lot for your clarification. 

Please see my responses inline below, starting with [Kevin].

Best.

-Kevin

From: Y.J. Gu [mailto:[email-masked]] 
Sent: Friday, May 28, 2010 8:30 PM
To: 'zhangyunfei'; [email-masked]; 'Omer Luzzatti'; [email-masked]
Subject: 答复: Re: [ppsp] We have submitted a Tracker Protocol

Hi Yunfei and Kevin,

Now we have updated the Tracker protocol and will submit soon. In the latest
version, we define 2 messages. STAT-Query is used by Tracker to query Peer
information.  STAT-Report is initiated by peer to report peer information.
But, as Yunfei said, the system statistics can also be notified by Tracker
to peers, which is an existing schedule policy in P2P application, to
improve the global performance and efficiency of PPSP. We can extend the
STAT-Report to enable Tracker notifies the system statistics information.
Or, to make the syntax more legible, design a new message.

[Kevin] Sounds good to me.

As for your 2nd question, Peer doesn’t use GET to get chunks information of
a candidate peer, instead the chunk id in the GET message indicate which
chunks the requesting peer is interested in and Tracker should find some
candidate peers who possess the desired chunks.  And, in the following
steps, the requesting peer will get detail chunks information by querying
the candidate peers.

[Kevin] Sorry my fault in not clearly stating my question. I was wondering
about the benefit of a peer requesting a list of peers that has a specific
chunk from the tracker. If I understand correctly, in BitTorrent, for
example, tracker returns a list of peers in the swarm upon a request from a
joining peer. Typically requesting peer specifies only the Swarm ID (or file
ID). Specifying chunk ID in the peer list request does provide more
flexibility (and potentially a better customized peer list), but I was a bit
concerned about the synchronization of chuck availability information
between tracker and individual peers (e.g. in the case peers delete some
chunks but have not updated the tracker).  But maybe a first order
approximation of the chunk availability information is sufficient in
practice. 

As for your 3rd question, we have made removed it from the new version.

Thank you very much for your comments. 

  _____  

发件人: zhangyunfei [mailto:[email-masked]] 
发送时间: 2010年5月28日 乐乐10:50
收件人: [email-masked]; 'Omer Luzzatti'; 'Y.J. Gu'; [email-masked]
主题: Re: Re: [ppsp] We have submitted a Tracker Protocol

Hi Kevin.

   For the 1st question,one reason for the tracker (of course, peer can also
send statistics) to send statistics message is that the tracker actively
pushes some system statistics(e.g., accumulated total upload/download ratio,
content scarcity degree,etc)to the peers and the peers can adjust its own
parameters(like caching size or upload/download ratio)accordingly for a
better display.

BR

Yunfei 

  _____  

zhangyunfei

2010-05-28

  _____  

发件人： Wenjun (Kevin) Zeng

发送时间： 2010-05-28 00:23:24

收件人： 'Omer Luzzatti'; 'Y.J. Gu'; [email-masked]

抄送： 

主题： Re: [ppsp] We have submitted a Tracker Protocol

Hi Yingjie and all,

While reading the tracker protocol draft, I came across the following
questions.

1.

The draft proposes that “Tracker may send STATISTICS messages to peers and
peers report with the requested information.”  

Any reason this should be initiated by the tracker, but not the peers? Some
of the statistics parameters defined later such as Caching size and
bandwidth seem to be more static information which could be reported when
joining the swarm (using “put”). By the way, what is the definition of the
“content report” parameter?

2. In the “put” and “get” methods between tracker and peers, chunk ID is
involved. 

I was wondering what use cases do we have here for a peer to get the chunk
information of the candidate peers from tracker (as opposed to directly from
the peers)? There could be a synchronization issue between tracker and peers
at the chunk level. This is probably related to Omer’s first question
below.

I can understand having chunk info in the “put” method as this could be
used for calculating statistics by the tracker.

3.

5.3 Statistics:  

Peer-Communication : 0x1 (Reserved) 

why do we have “peer communication” parameter in the tracker protocol?

Thanks and best.

-Kevin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Omer
Luzzatti
Sent: Friday, March 12, 2010 2:46 AM
To: Y.J. Gu; [email-masked]
Subject: Re: [ppsp] We have submitted a Tracker Protocol

Yingjie,

Congrats on the first draft of the tracker protocol, really amazing work
done in short time. 

Design point to consider: 

Especially for live streaming the tracker may need to ‘recruit’ resources
to the swarm. These ‘helper nodes’ are joined nodes (and rightly you
separated the ‘join’ from the swarmID) that could be helpful either for
their bandwidth or storage. In general a tracker-originated ‘Get’ is what
the server should send and the peers to be able to accept; in practice some
additional information may be needed since the peers may not be real
participates in the swarm but acting in different roles (super nodes,
helpers, etc…). Note that in VOD you may want to ‘distribute’ the content
which again will require the above. I know this complicates things
significantly but please give it a thought.

Questions:

1.      It is not clear to me how a peer indicates that it ‘deleted’ a
chunk from its storage. Does a peer send the entire list of chunks in every
‘put’? this may be good if not too segmented but still if I delete my
entire ‘VOD title/swarm’ data the server should be notified. 

2.      Do you expect peers to ‘put’ all of their existing storage just
after ‘joining’? 

3.      For security reasons we may want to consider having a ‘session ID’
to the Join response.

4.      As you stated, for live streaming chunks won’t be used so basically
a peer will request a peer-list to watch that ‘channel/swarm’. However,
the swarmID may not be sufficient to indicate the entity wished to be
watched. A peer may be authorized to watch the current program within the
channel (the swarm) but not the next one (say a PPV event). This problem
could be solved in one the following ways: a) letting the tracker reply with
a different ‘swarm-ID’ to a get request (which btw will help when having
different qualities swarms, or when there is more than one swarm
representing the same content); b) having also a program ID as part of the
reply. 

Regards and praises again for the work

Omer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Y.J.
Gu
Sent: Monday, March 01, 2010 2:21 PM
To: [email-masked]
Subject: [ppsp] We have submitted a Tracker Protocol

Hi everyone,
We submitted a Tracker Protocol draft for ppsp.

Abstract:

   This document defines P2P streaming Tracker Protocol, including
functional entities and architecture, components, syntax and semantics. 

   Tracker protocol is an application-level protocol for peers to register,
publish/request content and inform peers status to Trackers. It is also for
trackers to provide peer lists to peers, send control/manage messages and
communicate with other trackers. Tracker protocol can serve both live media
and Video on Demand (VoD), as well as file sharing. 

The URL for this draft is:
 <http://www.ietf.org/id/draft-gu-ppsp-tracker-protocol-00.txt>
http://www.ietf.org/id/draft-gu-ppsp-tracker-protocol-00.txt

We appreciate your comments.
Thanks.

 

Regards

Yingjie Gu