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

From: "Wenjun (Kevin) Zeng" <[email-masked]>
Date: Thu, 27 May 2010 11:23:18 -0500

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

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 28 May 2010 10:50:18 +0800

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. 

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

 

Regards
Yingjie Gu

---

From: "Wenjun (Kevin) Zeng" <[email-masked]>
Date: Sat, 29 May 2010 19:53:44 -0500

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

抄送： 

Hi Yingjie and all,

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:  

 

Thanks and best.

-Kevin

Yingjie,

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. 

Omer

Hi everyone,

Abstract:

 

Regards

Yingjie Gu