In [15], it shows that the delivery ratio decreases when the transient condition becomes serious in P2P networks. We propose a multi-streaming scheme on the streaming layer, called ConStream, to resist this condition. The basic architecture of our proposed approach is like SplitStream, striping the content across a forest of interior-node-disjoint multicast trees that distributes the forwarding load among all participating peers. In SplitStream, a content source forwards the content via different stripes in a proper sequence, and the content length to forward a stripe each time is fixed. However, in our ConStream, we merge three stripes as a unit named multi-stripe and the total stripes in SplitStream can be viewed as several multi-stripes.
The content in a multi-stripe will be divided into small pieces, and they will be forwarded by three multicast trees concurrently. Also we insert parity packets [18]
into streams for error recovery.
There are some problems when several streams work concurrently. Firstly, if streams deliver contents via the same tree architecture, the forwarding capacity that senders (interior nodes) can offer will be shared by those streams. In addition, several streams a client received will be interrupted at the same time if any one of this client’s
ancestors lefts. Secondly, if streams are delivered via different tree architectures, how we can do to prevent generating more load to the source or bigger delay jitter to clients.
Figure 2. Concept of stripe and multi-stripe.
In Figure 2, it shows the difference between the traditional stripe and multi-stripe.
We view the total contents as many fixed time segments, and stripes are used to deliver these segments in turn. Traditionally, the source delivers contents via one single tree during each stripe delivering, as illustrated in Figure 3. In multi-stripe, three stripes are grouped into a unit and contents are delivered by three stripes concurrently, as illustrated in Figure 4. During packets delivering in sequence via different streams, we insert parity packets into them. A parity packet is generated from the two latest transmitted packets. Once any interior node fails in one stream, the descendants of this streaming tree can recover the lost data by parity packets from the other two living streams during the time of repairing the failed tree. In Figure 4, the parity packet (5 6) is generated and inserted into streaming 1 after packet (5) and
12
packet (6) are delivered via streaming 2 and streaming 3, respectively. For a certain client, if data packet (5) is lost, this packet can be recovered by packet (6) and parity packet (5 6). Additionally, due to the characteristic of the forest of interior-node-disjoint [13], one faulty interior client just causes bad effect on one tree.
Thus, our approach can work robustly unless one client loses more than one stream simultaneously, which is a situation that seldom happens.
Figure 3. Deliver the content via stripes.
Figure 4. Deliver the content via multi-stripe.
13
Based on the characteristic of the forest of interior-node-disjoint, these concurrent streams will work on different tree structures and the forwarding capacity of each client won’t be shared by more than one stream. In the view point of any node itself, among the trees, a node is an interior node in only one tree, and it is a leaf node in each of the other trees. In this way, one client receives the content via three different streams, but it plays as an interior node which is responsible to forward contents to no more than one stream. Figure 5 shows that nodes A, B, and C are interior nodes in stripe 1; nodes D and E are interior nodes in stripe 2; nodes F and G are interior nodes in stripe 3; node H just plays leaves in the multi-stripe. Here we can observe that the forwarding capacity of each node is just used for a single stream even if this node also receives from other distinct streams.
Figure 5. Concurrent streams during the time interval of multi-stripe.
14
15
The server load and bandwidth needed in our approach will increase due to adding parity packets, but the required delivery rate in each stream will be moderated.
The forwarding load of each interior node in a multi-stripe will be 1.5 times the forwarding load in a traditional stripe, because each parity packet generated is accompanying with two data packets. However, considering the time interval of multi-stripe that increases 3 times, the delivery rate of each stream in multi-stripe is only half of the delivery rate of the stripe. The results are that packets in Figure 4 are sparser than packets in Figure 3. The delivery rate is defined as the amount of packets delivered over a time unit. In this way, the burden on peers will be efficiently reduced during delivery time although the total forwarding load increases. Therefore, it’s a feasible solution to ease up the burden on those peers with not enough outgoing bandwidth.
According to [13], a node in the overlay network will contribute its bandwidth for data forwarding. As shown in Figure 6, the forwarding capacity of a node is defined as the number of its receivers, and indegree is defined as the number of distinct stripes that a node requests. For the feasibility of forest construction in SplitStream, it needs to satisfy the following two conditions. (1) Feasible condition: if forest construction is feasible, the sum of the desired indegrees of all nodes cannot exceed the sum of the forwarding capacities of all nodes. (2) Sufficient condition: for
the above feasible condition to hold, each node’s forwarding capacity must exceed its desired indegree [13].
Figure 6. Conception of indegree and forwarding capacity.
Following the above conditions, the more forwarding capacity a client contributes the more indegree a client can receive. These two conditions emphasize fairness and are used to improve performance. And since our proposed architecture is based on SplitStream, we can also make our model ideal by satisfying the feasible condition and sufficient condition. According to our improved architecture, clients can contribute more capacity to promote efficiency in a system and to easily satisfy the need of indegree, because their original load is lowered by decreasing the delivery rate.
In our ConStream, we merge three stripes as a multi-stripe and take it as a unit to forward the content. But why not merge four, five, or six as a multi-stripe? When
16
17
streams are delivered concurrently, a client will receive contents from different paths, and the delay time of these data will be more variant than that of just from one path.
For example, in Figure 5, node F receives contents form streaming 1, streaming 2, and streaming 3 concurrently, but the hops of stream paths from the source to node F are 4, 3, and 2, respectively. This situation will result in unsteady quality of media contents played in real time. To reduce such a jitter problem, we merge only three stripes and we also base on the slowest stream to start the real time multimedia playing during multi-stripe delivering. However, in this way, it will cause the client buffer being occupied by the data from the other two streams during waiting for the slowest stream.
So, we increase clients’ buffers to avoid the packet loss problem.
18