Subject: [ppsp] We have submitted a Tracker Protocol

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 01 Mar 2010 20:21:12 +0800

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.

 <http://www.ietf.org/id/draft-gu-ppsp-tracker-protocol-00.txt>  

Regards

Yingjie Gu

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Mon, 8 Mar 2010 17:06:30 +0800

Hi Yingjie,
 
What a great job that a structure of PPSP tracker protocol has been built.
 
At a quick glance, I think I agree most of your description, but with the following comments:
 
1. Should PPSP tracker take the responsibility to Peer ID allocation and overlay management? IMHO, we should separate the overlay enrollment and management with the PPSP application. The overlay enrollment has been described in RELOAD Base protocol, where an enrollment server issues certificate with Peer ID to each peer who want to join the overlay. The whole procedure of overlay enrollment is independent to the applications that deployed in the overlay. For example, In P2PSIP, the Sip Registration is an message of SIP Usage, that only the peer already in the overlay with Peer ID can do it. Similar, we should look PPSP as one of various applications based on the P2P overlay. Therefore, any overlay maintenance and management method is out of the scope of PPSP. So, I suggest to delete the content about Peer ID allocation and change the name of section 5.1 to "PPSP application management methods". The "JOIN" message can be simply looked as peer registration to the PPSP application, but not overlay.
 
2. I think the KEEPALIVE message should combine with PUT to update the current status of peers periodically as the dynamic resource buffered in each peer during the content distribution.
 
3. Should we use the standard HTTP to format the PPSP tracker protocol? It is also recommended in the problem statement draft.

Br
Lin Xiao 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Y.J. Gu
Sent: 2010年3月1日 20:21
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. 

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> 

 

Regards

Yingjie Gu

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 8 Mar 2010 09:17:11 -0500

Hi Lin,

Thanks for reading.Obviously this is a very early draft, and one of
the main reasons is to generate some discussion like this! I'm sure
there are many, many things we will want to change, but I think one of
the best ways to figure things out it to start with something that we
can then discuss. Thanks!

Some comments inline:

2010/3/8 Xiao, Lin (NSN - CN/Beijing) <[email-masked]>:
> 1. Should PPSP tracker take the responsibility to Peer ID allocation and
> overlay management? IMHO, we should separate the overlay enrollment and
> management with the PPSP application. The overlay enrollment has been
> described in RELOAD Base protocol, where an enrollment server issues
> certificate with Peer ID to each peer who want to join the overlay. The
> whole procedure of overlay enrollment is independent to the applications
> that deployed in the overlay. For example, In P2PSIP, the Sip Registration
> is an message of SIP Usage, that only the peer already in the overlay with
> Peer ID can do it. Similar, we should look PPSP as one of various
> applications based on the P2P overlay. Therefore, any overlay maintenance
> and management method is out of the scope of PPSP. So, I suggest to delete
> the content about Peer ID allocation and change the name of section 5.1 to
> "PPSP application management methods". The "JOIN" message can be simply
> looked as peer registration to the PPSP application, but not overlay.
>

A few comments here. As the original author of the original
(pre-merge) RELOAD, and the P2PSIP chair, I've definitely thought
about RELOAD here! We certainly think a RELOAD usage very well might
be a good candidate for the peer protocol, but remember that P2PSIP
was chartered to make a DHT protocol optimized for P2PSIP, not a
generic DHT that works for everything, so it may turn out not to have
everything we need once we get going. I think the best plan is to try
to reuse, and see if it suits our needs once we start work on a peer
protocol.

I don't see any reason that the tracker can't issue the PeerIDs, even
if RELOAD is used. The credential server is an offline function, but
certainly can be included with the tracker functionality.

> 2. I think the KEEPALIVE message should combine with PUT to update the
> current status of peers periodically as the dynamic resource buffered in
> each peer during the content distribution.
>
> 3. Should we use the standard HTTP to format the PPSP tracker protocol? It
> is also recommended in the problem statement draft.

Personally, I'm strongly behind using an existing mechanism for
*transport* of data.

For the encoding of the actual protocol, I think a text form carried
via something like HTTP or binary both have advantages. Let's discuss
this further. Why would you rather go text-based than binary?

David

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 9 Mar 2010 00:13:11 +0800

Hi David,

Thanks for your reply. 

Of course, you can put enrollment functionality in tracker server. But it is also possible that the enrollment is done by a third party. So, why not leave it outside of the PPSP scope, which make PPSP flexible to be implemented on exist P2P overlay network that has got Peer-ID already for multiple P2P applications.

For the protocol format, I just think it's good if HTTP can be reused here. But I have no strong opinion on it. So, let's keep it as an open issue and further discussed.

Best Regards,
Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David A. Bryan
Sent: Monday, March 08, 2010 10:17 PM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Y.J. Gu; [email-masked]
Subject: Re: [ppsp] We have submitted a Tracker Protocol

Hi Lin,

Thanks for reading.Obviously this is a very early draft, and one of the main reasons is to generate some discussion like this! I'm sure there are many, many things we will want to change, but I think one of the best ways to figure things out it to start with something that we can then discuss. Thanks!

Some comments inline:

2010/3/8 Xiao, Lin (NSN - CN/Beijing) <[email-masked]>:
> 1. Should PPSP tracker take the responsibility to Peer ID allocation 
> and overlay management? IMHO, we should separate the overlay 
> enrollment and management with the PPSP application. The overlay 
> enrollment has been described in RELOAD Base protocol, where an 
> enrollment server issues certificate with Peer ID to each peer who 
> want to join the overlay. The whole procedure of overlay enrollment is 
> independent to the applications that deployed in the overlay. For 
> example, In P2PSIP, the Sip Registration is an message of SIP Usage, 
> that only the peer already in the overlay with Peer ID can do it. 
> Similar, we should look PPSP as one of various applications based on 
> the P2P overlay. Therefore, any overlay maintenance and management 
> method is out of the scope of PPSP. So, I suggest to delete the 
> content about Peer ID allocation and change the name of section 5.1 to 
> "PPSP application management methods". The "JOIN" message can be simply looked as peer registration to the PPSP application, but not overlay.
>

A few comments here. As the original author of the original
(pre-merge) RELOAD, and the P2PSIP chair, I've definitely thought about RELOAD here! We certainly think a RELOAD usage very well might be a good candidate for the peer protocol, but remember that P2PSIP was chartered to make a DHT protocol optimized for P2PSIP, not a generic DHT that works for everything, so it may turn out not to have everything we need once we get going. I think the best plan is to try to reuse, and see if it suits our needs once we start work on a peer protocol.

I don't see any reason that the tracker can't issue the PeerIDs, even if RELOAD is used. The credential server is an offline function, but certainly can be included with the tracker functionality.

> current status of peers periodically as the dynamic resource buffered 
> in each peer during the content distribution.
>
> 3. Should we use the standard HTTP to format the PPSP tracker 
> protocol? It is also recommended in the problem statement draft.

For the encoding of the actual protocol, I think a text form carried via something like HTTP or binary both have advantages. Let's discuss this further. Why would you rather go text-based than binary?

David

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

---

From: Omer Luzzatti <[email-masked]>
Date: Fri, 12 Mar 2010 10:46:03 +0200

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,

Abstract:

Regards

Yingjie Gu

---

From: Omer Luzzatti <[email-masked]>
Date: Fri, 12 Mar 2010 17:31:54 +0200

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 generate and the peers to be able to accept; in practice some
additional information and complexity might 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:
to the Join response or even to the Get-response.

On Mon, Mar 1, 2010 at 2:21 PM, Y.J. Gu <[email-masked]> wrote:

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

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 17 Mar 2010 12:02:18 +0800

Hi Omer,
Thanks a lot for reading and your comments.  Thank all the authors and
contributors for composing the draft. 
See inline please for my consideration of your comments.

Regards

Yingjie Gu

  _____  

From: Omer Luzzatti [mailto:[email-masked]] 
Sent: Friday, March 12, 2010 4:46 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [ppsp] We have submitted a Tracker Protocol

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.

I think this is a great idea. This is an early draft, wherein we try to make
out a simple but clear architecture and protocol overview.  I believe there
are other methods/aspects that we have omitted. Seems that we have already
prepared part of premises for "Invitation". For example, Trakers record peer
status by "Join" and update the status by "PUT" and maybe also "Keepalive".
(Btw, we leave "Keepalive" carrying peer status as an open issue. ), by peer
status Tracker can learn who could help. And in some existing application,
peers store the content even when they have left the swarm, which could be a
potential content source in VoD.   However, I agree with you that this will
make the system complicate. One thing is "does the swarm welcome an
irrelative nodes?", if the streaming is a private content only target to
some particular peers. Another question, if it is an open swarm, comes to my
mind is "how could Tracker know when helper nodes are necessary" or "does
Tracker always try to invite helpers", i.e. Trackers have to know the
overall performance of the swarm. Maybe "STATISTICS" can do the job, I'm not
sure now. We need more voice on this issue.

 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

In early draft, a peer does not report which chunk it deletes. If a peer
deliberately deletes a swarm, I think it can just LEAVE, otherwise it will
be still in candidate list on Tracker and other peers may keep requesting
from it.  If a peer deletes a chunk, other peers will know that through
Buffer Map.  And there is an Expiration Time in PUT message, which will
notify Tracker when to remove a peer from a swarm/chunk list. 

In  6.2.4.1.  PUT Resource Info, we introduce a mechanism by which you need
not PUT entire list of chunks, maybe a start and an end chunk is enough.

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

Well, up to now, this is what I expect. This is not a problem in live
streaming, where content may not be stored. In VoD, peers usually store a
large number of continuous chunks. by PUT in 6.2.4.1, this will not impact
Tracker a lot. What do you think?

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.  

The first way is okay, and I think this can be resovled when a peer first
learn a swarm ID by some means, e.g. by EPG or by an introduction file, in
which different ppv has been assigned different swarm ID , and this I would
say is not in the scope of Tracker protocol. 

Thank you again for your comments. :)

 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,

Abstract:

 

Regards

Yingjie Gu