Multicast video-on-demand service in an enterprise network with client-assisted patching

Abstract

Multicast Video-on-Demand (VoD) systems are scalable and  cheap-to-operate. In such systems, a single stream is shared by a batch of common user requests. In this research, we propose multicast communication technique in an Enterprise Network where multimedia data are stored in distributed servers. We consider a novel patching scheme called Client-Assisted Patching where clients’ buffer of a multicast group can be used to patch the missing portion of the clients who will request the same movie shortly. This scheme significantly reduces the server load without requiring larger client cache space than conventional patching schemes. Clients can join an existing multicast session without waiting for the next available server stream which reduces service latency. Moreover, the system is more scalable and cost effective than similar existing systems. Our simulation experiment confirms all these claims.

Appendix: Admission control algorithm

The admission controller runs two parallel threads: online request processing thread and batch request processing thread. The online thread processes movie request, VCR, end session and select another patching parent request. The request that cannot be patched by the thread is batched and the other thread deals with these request after batch interval which is in progress. The batch processing thread schedules the batches of the requests by forming multicast groups whenever possible. If a group cannot be formed then a multicast group is formed with only one client with a possibility that other clients may join the multicast session if patching is possible later on.

Before describing the admission control algorithm,we first present the requests and replies to and from the different components of enterprise network and some data structures that are necessary to get an overall idea of the algorithm.

1.1 A.1 Requests and replies

Each switch, server, session, client, movie are distinguished to the Admission Controller. The admission controller maintains a database of the resources and its usage in the system. The decision about a client-request will be made by consulting these statistics. Session id, server id, session start-time and information about regular clients, patched clients and patching parents are the several attributes of a session. Client requests and responses of the Admission Controller can be carried out by using widely used Real-time Streaming Protocol [34]. The protocol commands that we use are as follows:

• SETUP: Each client will place request for a movie to the Admission Controller through this message. The message contains the requested node id and movie id. In return the admission controller will provide a session identifier through RTSP command.

• PLAY: When the client gets a session id from the controller it can now send this command to play out the movie. The command takes the parameters like the movie id, session id and also the play point of the movie or a range of play point. As the command takes a play point, the VCR request can also be initiated through the same command.

• TEARDOWN: Each client will leave a session by sending this command to the Admission Controller. The command contains the information about the session id.

• OPTIONS: The child client, facing patch stream loss, uses this command to request the Admission Controller to select an alternate patching parent. The Admission Controller will find out an alternative patching parent and send the parent address to the respective patched child client.

• RTSP: All the responses the Admission Controller will be this command. In response to the SETUP request of a client, the controller returns session id, the multicast address of the accepted session and also the patching parent address if patching is necessary. If there is limitation of resources it returns error. For the PLAY command, the controller returns the accepted play point range of the movie. If the requested play point cannot be serviced then the current play point is returned which will be regarded as VCR action blocking. In response to the OPTIONS command the controller will returns the new patch parent address.

1.2 A.2 Data structure

Necessary data structures and procedures required for admission control algorithm are as follows:

network: This data structure represents the enterprise network for the multicast VoD system. It is a graph with multiple nodes and connecting links. It must contain information about the servers and clients connected with the network.

multicastTrees[ ]::

This is an array of shortest path trees rooted at the servers. There is one shortest path tree for each server.

serverSource[ ]::

This is an array of nodes to which servers are connected. No more than one server is connected to a node.

batchList[movie-id]::

This is an array of the waiting queues of movies. The client requests that are not satisfied readily by client-assisted patching scheme are queued to corresponding movie queue. The Admission Controller will handle these requests after each batch interval expires.

1.3 A.3 Procedures

The main procedure has already described in Section 2.4. Now the sub-procedures and relevant other pseudo code are presented in the followings:

1.4 A.4 Complexity analysis

Consider the following parameters for an Enterprise Network serving multicast VoD service as shown in the Table 2. We consider MPEG-2 as the movie file format which uses Variable Bit Rate (VBR). We assume server data rate as Constant Bit Rate (CBR) or an average data rate to do the following calculations. However, Statistical Multiplexing can be used in case of VBR data traffic [6].

Table 2 Parameters of enterprise network

As the movie length and the batch interval are almost constant for the system so S has become pseudo constant term in this scenario.

The procedure Admission-Control consists of mainly two threads: one is Online-Requests-Processing Thread and the other is Batched-Requests-Processing Thread. So, its runtime or complexity depends on the complexity of these threads and we present the complexity of those threads first.

Before starting the threads the procedure does some initialization tasks by calling procedure Init-Admission-Controller. This procedure computes the shortest path trees rooted at each server and there are s servers in the system. Dijkstra’s algorithm [13] is used to compute the shortest path trees and it takes O(ElogV) computation. Thus, the Procedure Init-Admission-Controller requires total O(sElogV) computation.

Now we discuss the complexity of Batched-Requests-Processing-Thread. The batched requests are those requests that cannot be satisfied by patching scheme immediately after requesting. The thread first sorts an array using Quick Sort [33] to get the scheduling order (MFQLF) of movies and there are m number of movies [13, 27]. Thus sorting takes $O(m \lg m)$ computation. After sorting, the thread admits the movie requests one by one according to the scheduled order (MFQLF). The acceptance or rejection depends on the available resources. There can be at most $n_\text r$ requests for a movie as there are total $n_\text r$ number of clients who are seeking admission. For each movie request, the procedure admitClient finds out a multicast session that has the minimum shortest path distance from the client to the multicast tree of that session and there can be at most S sessions of a movie. Finding the availability of resources for admitting a request requires the cost of traversing a multicast tree which is O(E) computation for each session. Thus, the procedure admitClient takes O(SE) computation and the main loop of the thread has total $O(n_{\text r}SE)$ computation. Therefore, the total complexity of Batched-Requests-Processing Thread is $O(m \lg m + n_{\text r}SE)$ i.e. $O(m \lg m + n_{\text c}E)$.

The complexity of Online-Requests-Processing Thread has the following components:

• The first procedure Process-Movie-Request of the thread again consists of two sub-procedures: selectPatchSession and selectPatchingParent. So, its complexity depends on the complexity of those procedures. They are discussed below:

  • Procedure selectPatchSession finds out a patchable session from S sessions of that movie. It also ensures if resources are available along the path from the client to the multicast tree of that session which requires O(E) computation. Thus, the complexity of the procedure is O(SE) i.e. O(E). This is the resource required for regular stream.

  • Procedure selectPatchingParent finds out a patching parent of a client from the current members of a session. It first finds out the shortest path tree of the enterprise network rooted at the client node that initiates the request. So, it takes O(ElogV) computation to compute the shortest path tree as discussed earlier. After computing the shortest path tree, it finds out the shortest path client as a patching parent from the participants of that session. Finding shortest path client in a multicast tree requires O(E) computation and the average number of clients per multicast session is k. Thus it takes another O(kE), $O(n_{\text c}E$) computation. Therefore, the run time of the procedure selectPatchingParent is $O(E\log V + n_{\text c}E)$.

  Therefore, the procedure Process-Movie-Request requires $O(n_{\text c}E + E\log V + n_{\text c}E)$ i.e. $O(E\log V + n_{\text c}E)$ computation.

• Procedure Process-VCR-Request consists of two sub-procedures: admitVCRRequest and selectPatchingParent. The procedure admitVCRRequest performs in a similar way as the procedure admitclient does. As we have discussed earlier in this section, the complexity of those sub-procedures are O(SE) and $O(E\log V + n_{\text c}E)$ respectively. Thus, the procedure needs total $O(SE + E\log V + n_{\text c}E)$ i.e. $O(E\log V + n_{\text c}E)$ computation.

• The complexity of procedure Process-SessionEnd-Request has the same complexity as procedure selectPatchingParent. So, the complexity of this procedure is $O(E\log V + n_{\text c}E)$.

Thus, the complexity of Online-Requests-Processing Thread will be the sum total of the complexity of its four procedures. So far we consider the computational complexity of processing one request for these procedures. There can be at most $n_\text r$ online requests of each type. So, the complexity of the thread is $O(n_{\text r}E\log V + n_\text r n_{\text c}E)$ i.e. $O(n_{\text c}E\log V + n_\text c^2E)$.

The complexity of procedure Admission-Control is the sum total of the complexity of its two threads and the initial procedure. So, the complexity of the procedure is $O(sE\log V + m \lg m + n_{\text c}E + n_{\text c}E\log V + n_\text c^2E)$ i.e. $O(sE\log V + n_{\text c}E\log V + n_\text c^2E)$. Therefore, the runtime of the procedure increases with the increase of the network size, the number of clients and the number of movies in the system.