Tradeoff between system profit and user delay/loss in providing near video-on-demand service

Abstract

In a near video-on-demand (near-VOD) system, requests for a movie arriving in a period of time are grouped (or "batched") together and served with a single multicast stream. In this paper, we consider providing near-VOD services when there is a cost associated with using a network multicast channel. We address the tradeoff between system profit, given by the total pay-per-view collected minus the total channel cost, and user delay or user loss (due to reneging). We first analyze and compare the tradeoff of two traditional "basic" schemes, namely, the window-based schemes in which a maximum user delay can be guaranteed, and the batch-size based scheme in which system profit can be guaranteed. By combining these basic schemes, we present a scheme which can adaptively balance system profit and user delay when the underlying request rate fluctuates. We then consider the case in which delayed users may renege and determine how system profit can be maximized by sizing the batching period given user's reneging behavior. We show that maximizing profit can lead to excessively high user loss rate, especially when the channel cost is high and users are not very patient. Therefore, a shorter suboptimal batching period should be used for this case in reality. We finally introduce schemes which are able to offer high profit or low user loss when the underlying arrival rate fluctuates.Index Terms-Multicasting, near video-on-demand, request batching, system profit, user delay, user loss.

Broadcasting video with the knowledge of user delay preference

“…As an example, we consider that the reservation period is exponential with mean minutes [i.e., ], yielding (6) from which and can be obtained. We consider a baseline system where minutes, req/min and min .…”

Medusa: A Novel Stream-Scheduling Scheme for Parallel Video Servers

“…Two kinds of batching schemes were proposed: first come first serve (FCFS) and maximum queue length (MQL) [4,6,9,10,11,12]. In FCFS, whenever a server schedules a multicast stream, the client with the earliest request arrival is served.…”

“…We just explain the scheduling for the request R i+4 , others can be deduced by rule (3). When request R i+4 arrives, the parallel video server firstly notifies the corresponding clients of R i+4 to receive the video segments S(4, 4), S(5, 5), S (6,6), and S(7, 7) from the complete multicast stream CS i . It searches the stream information list, and finds out that segment S(2, 2) will be transmitted on patching multicast stream PS i+3 and the transmission start time of S(2, 2) is later than t i+4 .…”

“…The conventional scheduling scheme sequentially schedules RTP server nodes to transfer segments of a video object via unicast propagation method. Previous works [4,5,6,7,8] have shown that most clients often request several hot videos in a short time interval. This makes the conventional scheduling scheme send lots of same Giga Figure 1: A larger-scale VOD system supported by parallel video servers.…”

Time-Shifted Streaming in a Tree-Based Peer-to-Peer System

“…For instance, Chaining [3] and Patching [4] employ media servers and IP multicast, where IP multicast is used to reduce server workload. The authors of [5] study trade-off between the system profit and user experiences in a near-VoD system. In [6], patching and batching of server-based VoD service are augmented by taking into consideration heterogeneity in receivers.…”