Subject: [ppsp] charter discussion, peer<->tracker protocol

From: "Omer Luzzatti" <[email-masked]>
Date: Thu, 10 Dec 2009 15:50:10 +0200

Dear all,

A few comments/questions regarding the peer<->tracker protocol:

1.    I believe that the protocol should reflect the fact that sometimes
the tracker may 'recruit' additional resources to the swarm. This
ability to 'recruit' nodes helps facilitating the streaming in most p2p
existing live streaming platforms. These recruited nodes may be
'super-nodes' (hosted by the provider or identified as such by the
platform), or regular nodes called to hold some segments of data.

2.    Related to the above and yet somewhat more delicate question is
whether different nodes have different 'roles'. The most obvious
example, related to super-nodes, is the need of a consumer node to be
aware of the fact that in the retrieved peer-list some of the nodes are
indeed super-nodes (thus are reliable, have all data, etc...). In a
different example the recruited nodes may be called to behave
differently and e.g. not to fetch the entire media stream/file but only
parts of it (VOD p2p streaming is an obvious case for this). 

3.  The tracker peer list might also include additional information
about the peers in the peer list. Common additional information is the
'zone' the peers are from (be a 'zone' the country, or the actual ISP),
LAN information, NAT types, 'role' (see my previous point), and so on.
This has to be somehow combined with ALTO which most probably will
contribute an In-ISP information. Another related point is whether the
peers in the peer-list are 'ordered'.

4. I'm less sure how this should be tackled (and if at all under this
scope) but to my experience, sometimes, the tracker should be able to
'redirect' the peer to another channel/swarm. Example: the same
channel/event is being broadcasted from multiple encoders (for
redundancy and scalability) and the tracker acts also as a 'balancer' to
spread the viewers among the swarms. In some other cases, such as in
multiple stream qualities for 'adaptive bandwidth' (not SVC but multiple
channels in different qualities thus the way it is done in Silverlight)
the tracker 'picks' the channel according to pre-defined rules or
strategies (e.g. customers that paid for the service will be redirected
to a high-quality channel while the non-paying customers to a
lower-quality channel). 

5. To some extent the tracker should also, directly or indirectly,
receive feedback, such as status and statistics, from the peers. Basic
example is the peer's viewing quality. This information, usually, is not
being used to help the specific peer but the aggregation of such
information helps the platform/tracker to identify 'starvation' cases
and as a result to allocate additional resources to the swarm.

Regards,

Omer

 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

---

From: "Y.J. Gu" <[email-masked]>
Date: Fri, 11 Dec 2009 09:52:59 +0800

Hi Omer,
Thank you for putting forward these issues to arouse discussions on Tracker
protocol. 
See in line please. 

Regards

Yingjie Gu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Omer
Luzzatti
Sent: Thursday, December 10, 2009 9:50 PM
To: [email-masked]
Subject: [ppsp] charter discussion, peer<->tracker protocol

Dear all,

1.    I believe that the protocol should reflect the fact that sometimes the
tracker may 'recruit' additional resources to the swarm. This ability to
'recruit' nodes helps facilitating the streaming in most p2p existing live
streaming platforms. These recruited nodes may be 'super-nodes' (hosted by
the provider or identified as such by the platform), or regular nodes called
to hold some segments of data.

Gu yj: Agree. I would say that recruited nodes could also be caches, CDN
servers, or even content servers. These recruited nodes are usually
configured in the Tracker or notified by out-of-band protocol. But it also
could be reflected by Tracker protocol if the recruited peers understand
Tracker protocol. The Tracker protocol (i.e. peer<->tracker protocol) will
respond requesting peers with peerlists including these recruited nodes. 

2.    Related to the above and yet somewhat more delicate question is
whether different nodes have different 'roles'. The most obvious example,
related to super-nodes, is the need of a consumer node to be aware of the
fact that in the retrieved peer-list some of the nodes are indeed
super-nodes (thus are reliable, have all data, etc.). In a different example
the recruited nodes may be called to behave differently and e.g. not to
fetch the entire media stream/file but only parts of it (VOD p2p streaming
is an obvious case for this). 

Gu yj: This is an interesting point! As for the first example, my concerns
is that if consumer nodes know who are super-nodes and most requests are
send to the super-nodes (because every node want  guaranteed downloading ),
the super-nodes will become hot points and we know what happen next. So I
suspect whether consumer nodes should be able to identify super-nodes. It
could be Tracker's duty to make sure that super-nodes(as well as other
good-quality nodes) are well utilized. As for the second example, I think
it's not what Tracker Protocol should do.

3.  The tracker peer list might also include additional information about
the peers in the peer list. Common additional information is the 'zone' the
peers are from (be a 'zone' the country, or the actual ISP), LAN
information, NAT types, 'role' (see my previous point), and so on. This has
to be somehow combined with ALTO which most probably will contribute an
In-ISP information. Another related point is whether the peers in the
peer-list are 'ordered'.

Gu yj: I agree with your 'ordered peers' idea. The order can show the
priority that Tracker want peers to understand. As to my best knowledge,
some P2P applications don't follow the order in the peerlist, in which case
'ordered information' may not work well. An optional solution is for Tracker
to respond with separated peerlists. For example, the first part of peerlist
is sent to requesting peers including the most preferred peers, then the
requesting peers will first try the preferred peers. The second part of the
peerlist is then sent to requesting peers after a while, and so on.

4. I'm less sure how this should be tackled (and if at all under this scope)
but to my experience, sometimes, the tracker should be able to 'redirect'
the peer to another channel/swarm. Example: the same channel/event is being
broadcasted from multiple encoders (for redundancy and scalability) and the
tracker acts also as a 'balancer' to spread the viewers among the swarms. In
some other cases, such as in multiple stream qualities for 'adaptive
bandwidth' (not SVC but multiple channels in different qualities thus the
way it is done in Silverlight) the tracker 'picks' the channel according to
pre-defined rules or strategies (e.g. customers that paid for the service
will be redirected to a high-quality channel while the non-paying customers
to a lower-quality channel). 

Gu yj: Could this redirection be done before requests are sent to Tracker? I
mean the consumer interface of the application can instruct which channel a
peer could watch.

5. To some extent the tracker should also, directly or indirectly, receive
feedback, such as status and statistics, from the peers. Basic example is
the peer's viewing quality. This information, usually, is not being used to
help the specific peer but the aggregation of such information helps the
platform/tracker to identify 'starvation' cases and as a result to allocate
additional resources to the swarm.

Gu yj: Totally agree!

Regards,

Omer

****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********

****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 11 Dec 2009 10:04:02 +0800

Dear Omer,
   Thanks for your comments.It's very informative and instructive.Please see inline for the reply.Thanks again!

BR
Yunfei

zhangyunfei
2009-12-11

发件人： Omer Luzzatti
发送时间： 2009-12-10 22:08:12
收件人： [email-masked]
抄送： 
主题： [ppsp] charter discussion, peer<->tracker protocol

Dear all,
 
1.    I believe that the protocol should reflect the fact that sometimes the tracker may ‘recruit’ additional resources to the swarm. This ability to ‘recruit’ nodes helps facilitating the streaming in most p2p existing live streaming platforms. These recruited nodes may be ‘super-nodes’ (hosted by the provider or identified as such by the platform), or regular nodes called to hold some segments of data.
 Sound interesting.If we have such mechanism, the streaming quality in the starting time may be better.The key is how to balance this "proactive" message and the "feedback" periodic message from the peer to the tracker. Do they have the same effect?Or better if combined? 
2.    Related to the above and yet somewhat more delicate question is whether different nodes have different ‘roles’. The most obvious example, related to super-nodes, is the need of a consumer node to be aware of the fact that in the retrieved peer-list some of the nodes are indeed super-nodes (thus are reliable, have all data, etc…). In a different example the recruited nodes may be called to behave differently and e.g. not to fetch the entire media stream/file but only parts of it (VOD p2p streaming is an obvious case for this).
I think the peer tracker protocol shall covers this message. 
 
3.  The tracker peer list might also include additional information about the peers in the peer list. Common additional information is the ‘zone’ the peers are from (be a ‘zone’ the country, or the actual ISP), LAN information, NAT types, ‘role’ (see my previous point), and so on. This has to be somehow combined with ALTO which most probably will contribute an In-ISP information. Another related point is whether the peers in the peer-list are ‘ordered’.
We share the same opinion on this. Some "zone" or "network location"info shall be reflected in PPSP information.
As for the "order"of the peers in the peerlist, this seems a problem out of the scope of PPSP.PPSP just deals with information exchange. The following action done by the tracker seems vendor dependent,e.g, what order of the returned peers . Different p2p streaming vendors can do this differently.
 4  4. I’m less sure how this should be tackled (and if at all under this scope) but to my experience, sometimes, the tracker should be able to ‘redirect’ the peer to another channel/swarm. Example: the same channel/event is being broadcasted from multiple encoders (for redundancy and scalability) and the tracker acts also as a ‘balancer’ to spread the viewers among the swarms. In some other cases, such as in multiple stream qualities for ‘adaptive bandwidth’ (not SVC but multiple channels in different qualities thus the way it is done in Silverlight) the tracker ‘picks’ the channel according to pre-defined rules or strategies (e.g. customers that paid for the service will be redirected to a high-quality channel while the non-paying customers to a lower-quality channel). 
      Very interesting!I think this can be a very good feather if the tracker has such ability when we want to run a real P2P streaming system.I'd like to see more discussion about this in the mailing list.

5. To some extent the tracker should also, directly or indirectly, receive feedback, such as status and statistics, from the peers. Basic example is the peer’s viewing quality. This information, usually, is not being used to help the specific peer but the aggregation of such information helps the platform/tracker to identify ‘starvation’ cases and as a result to allocate additional resources to the swarm.

I agree.We address the same point in the problem statement draft and I think this can be done in the second stage.
 
Regards,
Omer

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 11 Dec 2009 10:16:53 +0800

Hi,yingjie,
   Please see inline for the reply.

BR
Yunfei

zhangyunfei
2009-12-11

发件人： Y.J. Gu
发送时间： 2009-12-11 10:03:47
收件人： 'Omer Luzzatti'; [email-masked]
抄送： 
主题： Re: [ppsp] charter discussion, peer<->tracker protocol

Hi Omer,
Thank you for putting forward these issues to arouse discussions on Tracker protocol. 
See in line please. 

Regards
Yingjie Gu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Omer Luzzatti
Sent: Thursday, December 10, 2009 9:50 PM
To: [email-masked]
Subject: [ppsp] charter discussion, peer<->tracker protocol

Dear all,

Gu yj: Agree. I would say that recruited nodes could also be caches, CDN servers, or even content servers. These recruited nodes are usually configured in the Tracker or notified by out-of-band protocol. But it also could be reflected by Tracker protocol if the recruited peers understand Tracker protocol. The Tracker protocol (i.e. peer<->tracker protocol) will respond requesting peers with peerlists including these recruited nodes. 

Yunfei：Yingjie raised another interesting problem.I would like ask Omer to clarify his intention? Do you mean "recruiting"some nodes who haven't have tracker protocol?Or just "recruting"addtional peers since the tracker may not hold the complete set of peers.
Anyway,Yingjie's comments make me consider another points,can/need we add some additional servers(nodes) who may be not PPSP nodes but can contribute to PPSP swarm?

Gu yj: This is an interesting point! As for the first example, my concerns is that if consumer nodes know who are super-nodes and most requests are send to the super-nodes (because every node want  guaranteed downloading ), the super-nodes will become hot points and we know what happen next. So I suspect whether consumer nodes should be able to identify super-nodes. It could be Tracker’s duty to make sure that super-nodes(as well as other good-quality nodes) are well utilized. As for the second example, I think it’s not what Tracker Protocol should do.
Yunfei：Agree.

Gu yj: I agree with your ‘ordered peers’ idea. The order can show the priority that Tracker want peers to understand. As to my best knowledge, some P2P applications don’t follow the order in the peerlist, in which case ‘ordered information’ may not work well. An optional solution is for Tracker to respond with separated peerlists. For example, the first part of peerlist is sent to requesting peers including the most preferred peers, then the requesting peers will first try the preferred peers. The second part of the peerlist is then sent to requesting peers after a while, and so on.
Yunfei:I am not sure about if this is in scope.We can discuss more about this.
 
4. I’m less sure how this should be tackled (and if at all under this scope) but to my experience, sometimes, the tracker should be able to ‘redirect’ the peer to another channel/swarm. Example: the same channel/event is being broadcasted from multiple encoders (for redundancy and scalability) and the tracker acts also as a ‘balancer’ to spread the viewers among the swarms. In some other cases, such as in multiple stream qualities for ‘adaptive bandwidth’ (not SVC but multiple channels in different qualities thus the way it is done in Silverlight) the tracker ‘picks’ the channel according to pre-defined rules or strategies (e.g. customers that paid for the service will be redirected to a high-quality channel while the non-paying customers to a lower-quality channel). 
 
Gu yj: Could this redirection be done before requests are sent to Tracker? I mean the consumer interface of the application can instruct which channel a peer could watch.
Yunfei:The senario may be as follows,the source doesn't excpect the burst and the "split" occurs dynamically.

Gu yj: Totally agree!
 
Regards,
Omer

---

From: "Omer Luzzatti" <[email-masked]>
Date: Fri, 11 Dec 2009 15:03:06 +0200

Thank you Yunfei and Yingjie, great comments,

Mine inline.

Regards

Omer

From: zhangyunfei [mailto:[email-masked]] 
Sent: Friday, December 11, 2009 4:17 AM
To: Y.J. Gu; Omer Luzzatti; [email-masked]
Subject: Re: Re: [ppsp] charter discussion, peer<->tracker protocol

Hi,yingjie,

BR

Yunfei

________________________________

zhangyunfei

2009-12-11

________________________________

发件人： Y.J. Gu

抄送： 

Hi Omer,

See in line please. 

Regards

Yingjie Gu

________________________________

	Dear all,

	Omer: Indeed my point was about peers within the network, those that ‘know’ the PPSP protocol. Yunfei’s rightly hints that in the case that the tracker holds the complete set of peers this solution may not be needed, however, in a multi-channel environment the situation gets complex; here’s why: whenever one channel with many viewers needs more ‘super-nodes’, these super-nodes, who may have helped other channels in the past, should be actively called to help in the specific channel in starvation. Thus, in my mind, super-nodes are resources that are actively monitored and called to help when they are needed for BW or storage. 

	As for the protocol itself, both could be used: a permanent connection, in which the tracker pushes a ‘please join channelX’ message to the SN, or a heartbeat – ‘am I needed’ message from the SN to the tracker followed by a response from the Tracker. Note that in both cases the tracker ‘asks’ the SN to join a channel.

	Yunfei：Agree.

	Omer: I actually disagree on two grounds (but agree we don’t have to agree now :-))

	     1) the only way to guarantee service from moment one is to have the peers know which are the super-nodes.

	     2) in my mind the only way to protect the super-nodes and to make sure they will not be attacked is to let the peers know these are indeed the super-nodes and should be approached only in the ‘last moment’ for segments the peer hasn’t received from other peers. How would a peer know otherwise that a neighbor peer e.g. within its LAN (or a strong caching peer provided by the ISP) is one that could be used without limitations while super nodes peers are to be approached only in ‘last moment’. I do assume (and/or securely validate) the PPSP clients are ‘trustable’.

	More generally we’re touching a point here that seems to be crucial - both my arguments above assume PPSP is (indeed ambitiously) trying to build a real TV-IP P2P solution and thus should approach questions such as startup-time, delays, QoS, and targeted SLA.  If so ‘reliable sources’ of this or that kind must be part of the system and (as I tried to convince) ‘known’ to the other peers as such.

	Omer: good suggestions. As Yunfei says maybe not in this scope and probably we’ll have to end up with both, namely ‘suggested order not mandatory’ and ability to send them all in one response or in various lists.

	Omer: Gu yj is right, the meta-requests could be done before to another ‘super tracker’ service and then, only when the peer knows the ‘exact channel’, approaching the tracker for the peer-list. So, probably not in this scope at all.

	Gu yj: Totally agree!

	Regards,

	Omer