CHAPTER 3 PRINCIPLE
3.4 H ELPER
3.4.6 Difference between Helper and Waypoint
There is already a similar concept to helper called waypoint [9]. Both helper and waypoint are the peers with unnecessary resource, such as upstream bandwidth, and they provide it to help others. The most different point between waypoint and helper is that waypoint joins the service base on its own decision and helper joins the service when members in the service call for help.
The concept of waypoint is to treat waypoint as common peers. It means that the method of joining service and the data it receive is the same as common peers. Even though waypoint will join the service that need help base on its determination, its join method is the same as other peers. It may not be put in the urgent place that needs help. For example, there is one sub-tree in the service needs help. Waypoint may join this service, but may not be put in that sub-tree by the join mechanism.
Contrary, helper is requested by the members in the service who need help. And the helper joins the service using different joining mechanism. Helper will be put in the place that really needs help. Therefore, participation of helper will solve the issue immediately.
Chapter 4 Mechanism
In this chapter, we will introduce the mechanism of ALM service and the integration of our three approaches in the mechanism. We separate the mechanism into two parts. The first part is the start of an ALM service and the second part is the behavior of peers.
4.1 Service Startup
There are three things need to be done to start an ALM service in the ALM system. First, every peer should establish a neighbor table before join or start a service. Second, if a peer wants to establish an ALM service to share its streaming data, it must decide who the source peer of the service is. Third, the source peer must configure IDA before accepting subscribers.
We describe the details in the following content.
4.1.1 Establish Neighbor Table
Before ALM service start, every peer who wants to join the ALM system, including source peers, subscribers, and even helpers, should establish their own neighbor table. The establishment of neighbor table is prerequisite for our helper approach.
The negotiation between peers and their neighbors is presented in Figure 8. We define a neighbor finding signal. In that signal, we set within how many hop count the peer can be called neighbor and the signal is sent by broadcast method. The signal should be drop when it travels farther than neighbor distance. When peers receive a neighbor finding signal, they should reply an ack signal to original sender.
Figure 8: Negotiation between peers and neighbors
If a peer receives an ack signal from other peer, it means it find a neighbor. The peer should do the reaction presented in Table 1. If the neighbor table is not full, it just adds the sender of the ack signal into the table. If the neighbor table is full, when the sender is closer to it, it just adds it into table and removes the neighbor that is farthest to it. After repeatedly receive the ack signals and do the reaction described above, peer will obtain a neighbor table with closest neighbors inside. Be notice that the neighbor table should resize if there is no any available neighbor when peers need neighbor in Trickle.
Table 1: Reaction after receiving a neighbor ack message
4.1.2 Source of Service
Source peer is the tree roots of the service. It splits streaming data into IDA stripes and sends stripes to its children of each tree. But which peer is the source peer? Is the streaming data owner should be the source peer of the service? It is possible, but not necessary. There are two possible cases.
Source peer is the data owner When the data owner is a peer with sufficient upstream bandwidth and processing capability, such as multimedia service provider, it could be the source peer of the service.
Source peer is not the data owner When the data owner is an individual user, it
probably only can unicast the data to one child. All it can do is to send the streaming data to a proxy server (we call source proxy) with capability of being source peer and the IDA is done by source proxy. It is presented in Figure 9. The source proxy can be the e-home server. Users send data from their mobile devices to their e-home server and then the server multicasts data to numerous peers. Or the source proxy can be provided by ISP with commercial cost. There still has a lot of possibility about the source proxy. It can solve the issue that data owner is not powerful.
Figure 9: An illustration that source peer is a source proxy
4.1.3 IDA Configuration
4.1.3.1 (n, o, m) IDA
After deciding which peer is the source peer, source peer must decide the parameters of IDA. In the previous chapter, we mention we will combine multiple stripes and IDA.
However, we don’t adopt (n, m) IDA but (n, o, m) IDA. All we want to do is to decrease bandwidth consumption from the overhead of IDA.
First, n means in the ALM service, there will be n different trees. The message generated from source peer will be divided into n different stripes and each stripe will be transmitted in different tree. Second, m means every peer that join the service must receive at least m stripes of a message to restore to the original message. Third, o means that when every subscriber wants to join the ALM service, they should join o trees initially, . We have to explain about the range of o, . The IDA operation is decided when the ALM service starting, so n and m can’t be changed. Hence, there will be totally n trees, so o must less or equal n. And o must bigger than m is because we don’t want when any peer leave the service will cause any other peers that is still in the service can not receive m stripes of the message.
n≥ >o m n≥ >o m
Due to we restrict every peer can be interior node in only one tree, so the lower bound of o is m+1. And if we want to decrease the consumption of the bandwidth, we must set o closer to m.
Because o>m, it still can provide a little fault tolerance in normal situation.
4.1.3.2 Apply to Streaming Data
Now, the source peer can apply IDA to streaming data when subscribers join the service.
The (n, o, m) parameters will influence on two things: the size overhead and the fault tolerance of the service. If the size of unit message needs to be encoded by IDA is B and we apply (n, o, m) IDA to it, the size of one stripe will be B/m and the total size of stripes is
. Each subscriber need receive o stripes with size /
n×B m o×B m/ in the beginning. The
ratio of lost stripes subscribers can tolerate is between (o−m) /o to (n−m) /n. 4.1.3.3 Discussion
The reason we add the parameter o is because when a message is processed by IDA, the size of the message will be (n/m) times bigger. If every subscriber joins n trees in the beginning, it will consume too much downstream bandwidth of itself. ((n-m)/m of data is redundant.) In other words, it will consume too much upstream bandwidth of other peers. In order to prevent it happens, we must make every peer to receive redundant stripes as less as possible.
First, we must consider why peers need to receive redundant stripes. The peer receive more than m stripes of a message is because we promise when some stripes delay or lost, they still can restore to the original message without any delay (there are the upper bound of tolerance). Therefore, we need to receive more stripes (join more trees) of one message only when some stripes’ transmission process occur problems. But we still need to receive a little part of redundant stripes (o-m stripes) in normal situation. Otherwise, we will lose one or more message when we are doing remedial action. Oppositely, if the transmission process of stripes has no problem, we should receive stripes as less as possible (join less trees) to prevent the consumption of bandwidth. Hence, after the peer joins o trees in the beginning, every peer
should adjust the number of trees they join dynamically. The method about how to decide the adjustment will be described in later section.
4.2 Behavior of Peers
First, we describe the architecture of peer behaviors. And then we describe the detail of each behavior. The order of behaviors is organized along peer life cycle.
4.2.1 Architecture of Peer Behavior
The architecture of behaviors for peers that will be subscribers or helpers is presented in Figure 10. Arrow symbols mean the direction of data flow or control signals. It shows the interaction of each function and the detail of important behaviors will be described in following sections.
Figure 10: Architecture of peer behavior
4.2.2 Join
4.2.2.1 Randomly Join o Trees
When the peer decides to join an ALM service, it will know the n, o, and m parameters of the service. Hence, the peer knows it must join o trees of the service initially. In Trickle, the
method that peers decide they should join which trees is random selection by themselves. The reason is the same as randomly select a tree to be interior node. We don’t want to add a load balance manager or request any peer, such as source peer, to be responsible for it.
Management of network load will increase the load of peer and also waste bandwidth.
Let us consider the tradeoff of load balance. First, it will make every peer fairly consumes upstream bandwidth. It is not an advantage for our hypothesis. For our helper approach, because the lack of upstream bandwidth, if some peers don’t spend all their upstream bandwidth in the service, they will possibly spend remained upstream bandwidth in other services. Therefore, there is no benefit in this point. Second, load balance will lead the peers distributed averagely. In other words, the height of each tree in the service will be average. It is really an advantage because the end to end delay of all peers will be average.
However, in Trickle, we have done several steps to reach similar effect. One, we make every peer join o trees. In worst case that all subscribers join the same o trees, the load is still averagely distributed into o trees. Two, because of IDA, peers can ignore some worse stripes with high end to end delay in certain trees. Three, the trees and the number of trees each peer joins will change to have better performance. It will be mentioned in following section. Of course, load balance is the best choice, but by these three steps, the end to end delay of the peers will be lease and more average. Furthermore, we don’t need to waste bandwidth to maintain load balance. Therefore, we decide that every peer randomly chooses o trees to join.
And then they randomly choose one of o trees to be interior node.
4.2.2.2 Choose Parents
After each peer chooses which o trees they want to join, they must decide which peer should be their parent in each tree. The selection method of parent is based on tree building algorithm. Our purpose is to devise an approach that is able to suit any tree building algorithm for performance improvement. So any kind of tree building method, like distributed hash tables (DHT) [14], [16] or hierarchical clustering [4], [5], will be fine. The method only needs
to build one tree and other tree can also be built by the same method. Therefore, each new peer will find o parents in different o trees through tree building algorithm.
No matter what tree building algorithm the ALM system choose, we have to add two restrictions for the algorithm. The first restriction is it can’t choose peer that plays the role of leaf node to be any peer’s parent. The second restriction is every peer should have an upper bound of supporting children base on their upstream bandwidth for performance consideration.
4.2.2.3 Cases of Join Accept
There are two cases when peers receive a join request. The first case is presented in Figure 11. If the peer plays the role of interior node in the tree and still has quota to accept new child, then it accept the request and put the id of request sender into its children table.
Figure 11: Negotiation between child and parent
The second case is presented in Figure 12. If the peer that receives a join request already reaches its upper bound of child number, it will request a helper for help. And it also needs to transfer one of its children to be the helper’s child. The detail of using helper is already described in previous chapter. Sometimes, request helper’s help will fail when helper receives the request and it already reaches its upper bound of child number or it already joins other tree.
Figure 13 presents the failure of requesting helper.
Figure 12: Negotiation between child, parent, and helper
Figure 13: Negotiation after the failure of requesting helper
We combine the two cases into one flowchart and it is presented in Figure 14. And the detail reaction when parent receive the join request from a peer is presented in Table 2.
Figure 14: Flowchart of subscriber join
Table 2: Reaction after receiving join request
4.2.3 Receive and Retransmit
For source peer, transmission process is simple. Its responsibility is to generate n stripes using IDA from original data and transmit each different stripe to its corresponding children set in different trees. It is presented in Figure 15. And for peers that are leaf nodes in the tree, all they have to do is wait and receive stripes transmitted from parents. But for other peers that are interior nodes in the tree, there are two different ways to do the retransmission.
Figure 15: An illustration of stripe transmission for source peer
4.2.3.1 General Retransmission
When the peers play the role of interior node in the tree, they have responsibility to retransmit the corresponding stripe to their children. For example, if the peer is interior node in tree k, it must transmit stripe k of the message to its children in tree k. In general case of retransmission, when peers receive a stripe from parent in the tree that they serve as interior node, they just retransmit the stripe to their children. It is presented in Figure 16. So they have
done their responsibility. This is the basic concept of any ALM mechanism.
Figure 16: Peers retransmission
4.2.3.2 Stripe Regeneration
Because we use multiple stripes and IDA approaches, peers can regenerate any stripe they need to retransmit (even if they never receive it) and transmit to their child. The algorithm of stripe regeneration is presented in Table 3. When the peer already receives m stripes of the message from other trees but not including the stripe it need to retransmit, it can use these m stripes and matrix A of IDA to restore them to the original message. And then base on the original message and matrix A, it can generate any one of n stripes it needs.
Table 3: Reaction after receiving one stripe
For example, in Figure 17, peer A join 5 trees to receive stripe S1, S2, S3, S4, S5 from different transmission paths and the IDA parameter m is 4. Peer A serve as interior node in tree 3. Therefore, peer A need to transmit S3 to its children. When A only receive S1, S2, S4, and S5 but S3, it still can generate S3 from other stripes and transmit S3 to its children.
Figure 17: An example of stripe regeneration
Stripe regeneration has several advantages. First, if the stripe needed to retransmit is late or lost, parent still can generate it and transmit to its children. Therefore, parent will prevent the increase of children’s end to end delay or prevent they can’t receive the stripe. Second, when the peer want to change parent (because transmission path broken or performance consideration) in the tree that it serves as interior node, it still can serve its children during changing parent. It also prevents when a peer leave, all its descendants need to find a new parent to repair the transmission path. Only the children of leaving peer need to do the remedial action.
4.2.4 Adjust Number of Joining Trees
We have mentioned before that sometimes peers must decrease the number of joining trees (it means peers decrease the number of receiving stripes) to reduce the consumption of bandwidth. And sometimes peers must increase the number of joining trees when transmission quality is not stable to prevent end to end delay rising or even message loss.
Therefore, we take the dynamic adjustment method to change the number of joining trees to adapt to various situations.
4.2.4.1 Foundation
We must define the rules about when peers need adjustment and how to adjust. Every peer will check every period of time that the success number of message restoration (as long as receive any m stripes of one message, it means a success) in the interval and the interval is predefined by the ALM system. And then we set the upper bound and the lower bound of success number. When the success number of restoring message is not between upper bound and lower bound, the peer will adjust the number of joining trees. Every adjustment will increase or decrease only one tree because transmission issues might be impermanent. We can not predict the transmission issues will continue or not, so we adjust the number of joining trees gradually.
Besides, the decision of upper bound and lower bound of success number will influence
on the message lost rate we can accept. If we don’t want any message loss, we should set the upper bound and lower bound higher. It means peers will join trees easier and leave trees harder.
4.2.4.2 Increase and Decrease
Increase When success number is lower than lower bound, the peer will randomly (we will explain about “random” later) join one more tree. If in next check, the situation is still the same, then the peer will join one more tree until the situation is better or the number of joining trees reaches the upper bound n.
Decrease When success number is equal or higher that upper bound, the peer will leave one tree that behaves worst. If in next check, the situation is still the same then the peer will leave one more tree until the situation is worse or the number of joining trees reaches the lower bound o. The tree that behaves worst means in the interval the peer received stripes that transmitted in the tree is fewest.
Figure 18 present the increase and decrease number of joining trees. We can know the quality of receiving streaming data of each peer by observing their number of joining trees. If the peer’s number of joining trees keeps in the lower bound, it means the peer can receive the streaming data smoothly. On the contrary, if the peer’s number of joining trees keeps in the upper bound, it means the peer receive the streaming data intermittently.
Figure 18 present the increase and decrease number of joining trees. We can know the quality of receiving streaming data of each peer by observing their number of joining trees. If the peer’s number of joining trees keeps in the lower bound, it means the peer can receive the streaming data smoothly. On the contrary, if the peer’s number of joining trees keeps in the upper bound, it means the peer receive the streaming data intermittently.