S ERVICE S TARTUP

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.