Continuous One-Way Detection of Available Bandwidth Changes for Video Streaming over Best Effort Networks

Transcription

1 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < Continuous One-Way Detection of Available Bandwidth Changes for Video Streaming over Best Effort Networks Abbas Javadtalab, Mehdi Semsarzadeh, Aziz Khanchi, Shervin Shirmohammadi, Abdulsalam Yassine Distributed and Collaborative Virtual Environment Research Lab (DISCOVER Lab) School of Electrical Engineering and Computer Science (EECS), University of Ottawa, Canada {javadtalab, msemsarzadeh, akhanchi, shervin, Abstract Video streaming over best-effort networks such as the Internet is now a significant application used by most Internet users. However, best-effort networks are characterized by dynamic and unpredictable changes in the available bandwidth, which adversely affect the quality of video. As such, it is important to have real-time detection mechanisms of bandwidth changes to ensure that video is adapted to the available bandwidth and transmitted at the highest quality. In this paper, we propose a Bayesian instantaneous end-to-end bandwidth change prediction model and method to detect and predict one-way bandwidth changes at the receiver. Unlike existing congestion detection mechanisms, which use network parameters such as packet loss probability, round trip time, or jitter, our approach uses weighted inter-arrival time of video packets at the receiver side. Furthermore, our approach is continuous, since it measures available bandwidth changes with each incoming video packet, and therefore detects congestion occurrence in less than 2 ms, on average, which is significantly faster than existing approaches. In addition, it is a one-way scheme, since it only takes into account the characteristics of the incoming path and not the outgoing path, as opposed to other approaches, which use round trip time and are hence less accurate. In this paper, we provide extensive experimental simulations and real-world network implementation. Our results indicate that the proposed detection method is superior to existing solutions. Index Terms Congestion Control, VBR Video, Bayesian Statistics, High Definition Video Conferencing, Inter-arrival Time, Bandwidth Prediction, Bandwidth Change T I. INTRODUCTION ODAY, video is streamed not only at its traditional resolutions of 34p or 48p, but also increasingly at higher resolutions, including High Definition (HD), which is now available in most video-on-demand services such as YouTube and Netflix. In addition to video-in-demand services, video conferencing systems are now featuring highdefinition video. In a High Definition Video Conference (HDVC), individuals from various geographical locations simultaneously attend and contribute in a video conference session at HD quality. HDVCs are increasingly utilized by business personnel to accelerate decision-making processes and reduce traveling costs. In HDVC, the face to face connection is very important, and HDVC solutions must provide a degree of realism where a user is able to read other users from their facial expression. For example, a high ranking sales representative of a company may want to recognize any changes in the facial expression of the remote party upon receiving a price offer, in order to guess if the price was too high or too low. Eye contact, facial expression, and even slight twitches and other reactions must be visible in such scenarios. Therefore, an HDVC system with intolerable inter-frame latency or poor intra-frame quality is not acceptable for users attending those types of meetings as described above. To provide users with an acceptable level of satisfaction and to meet the aforementioned qualities, current HDVC systems [] use dedicated networks with guaranteed quality of service (QoS). However, a dedicated network increases the total cost of the solution and is also a recurring cost. Hence, a solution that takes advantage of Internet s besteffort services is preferred. This paper presents a novel solution mechanism, based on the Internet s best-effort services, that performs timely detection of bandwidth changes to adapt video quality. We propose a Bayesian instantaneous end-to-end bandwidth change prediction model to detect and predict one-way bandwidth changes at the receiver. One of the main challenges of utilizing best effort networks, such as the Internet, for video streaming is to detect the network bandwidth modification and adjust the video bitrate variations [2]. For further illustration, let us consider an HDVC system between two locations over best-effort network as shown in the block diagram of Figure. The video content

2 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 2 is captured at the encoder side and sent through the network after packetizing the video data. Video Encoder Video Decoder Congestion Detector Figure Block diagram of a HDVC system over best-effort networks between two locations In Figure, the video decoder is responsible for reassembling the received video packets and displaying it. The congestion detector, which acts along with the video decoder, collects the packet statistics such as inter arrival delay, jitter, packet loss etc. Based on such information the congestion detection mechanism discovers if there is congestion in the network or not. If the network is congested then the packets are either dropped or delayed. This will lead to degradation of the video quality at the receiver, which is in total contrast with the objective of HD video: to provide a high visual quality. In this case, we need to tell the sender immediately so it decreases the video bitrate to match the available bandwidth. In addition, if the bitrate of the video is lower than the available bandwidth, then we are not providing the highest quality possible given the network capacity. For example, if the available bandwidth changes from 3.5Mbps to 4Mbps while the sender is still sending the video at the lower quality of 3.5 Mbps, then we are wasting valuable resources. We therefore need to move up the video bitrate to 4 Mbps to maximize the quality. The challenge of transmitting HD video over best-effort networks is mainly attributable to the fact that the available bandwidth in such networks is unstable over time and highly dynamic due to competing cross traffic. Indeed, in best effort networks, the bandwidth is not guaranteed and that imposes additional requirements to adjust the video bitrate according to the available bandwidth at a given moment to maintain the QoS of an HDVC system. Recall that in live conversational applications such as video conferencing, the tens of seconds long buffering that allows for handling many of the major challenges of video over IP is not possible. Real-time applications such as video conferencing need a system that gives accurate and fast detection of bandwidth changes in order to adapt to those changes. The only way to provide sufficient time to make the necessary changes to the bitrate is to have a system that gives the indication of bandwidth changes in the network as soon as they happen. The application then decides how to use those indications. This is the way it currently works for live conversational applications. In this category of methods; i.e., methods that quickly detect there is an up or down change in the bandwidth, our system is superior compared to existing methods since it can detect bandwidth variations faster than any other method available. In this paper, we provide the detail analysis as well as the design and implementation of the proposed solution. The main contributions of this paper are: ) We propose a continuous one-way detection method that uses inter-arrival delay of received video packets to predict the available bandwidth changes for video streaming over best effort networks. We show that our method can provide accurate prediction of bandwidth changes; this is rather significant because, as it is wellknown in best-effort networks, packets travel via multiple paths and it is very challenging to provide accurate prediction of packet latency using conventional two-way methods such as Real-time Control Protocol (RTCP) or propping schemes; 2) We propose per packet updating scheme at the client side for fast bandwidth fluctuation prediction and measurement; this is essential in real-time applications such as video conferencing. It is important to detect bandwidth changes as fast as possible to lessen quality degradation at the receiver due to packet loss resulted from bandwidth fluctuations. Video packet loss not only affects the lost frames themselves, but also all ensuing frames that use the lost frames as reference; 3) We propose a realistic model using video data, which is known to have a heavy-tailed distribution [3], to predict congestion. We model the traffic parameters with Pareto distribution that captures the central part and also the outliers of the empirical distribution at once. This allows us to use Bayesian statistical analysis to calibrate the data and to rigorously monitor network conditions. The proposed Bayesian mechanism not only improves upon currently available control methods, but also can be implemented in other real time applications if required; 4) Our proposed method uses the arrival packets as a measurement tool and only considers the inter-arrival delay of the packets; this means that our approach does not introduce network overhead to an already bulky video traffic that operates at the border of the available bandwidth. Also, our method does not require synchronous clocks at the receiver or the sender side, and independent of the underlying network. Unlike existing approaches that uses Explicit Congestion Notification (ECN), our method considers the network as a black-box and avoids the need for data collection within the Internet, and is entirely end-to-end; 5) We provide extensive experimental simulations and realworld network implementation [4]. We tested our method using one of the most demanding video streaming applications: HD Video Conferencing (HDVC ) although Our method was provisionally patented in May 22 ( Network Congestion Prediction US Patent Pending 6/639,53, 22), and after a one-year period of implementation and successful trials (as reported in this paper) with our industry partner Magor Corporation, a permanent patent

3 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 3 it can be used in any other application as well. This is by all means a challenging prospect since HDVC is a difficult application to support [5], because of its bulkiness in terms of bandwidth consumption, very high visual quality expectations by the end user, and its realtime nature. Unlike HD video on demand applications such as YouTube and Netflix (at its HD resolution), HDVC cannot be paused or buffered due to its live conversational nature. Also, unlike Standard Definition Video Conferencing such as Skype, HDVC has much higher bandwidth demands. Our experimental results from a real-world network [4] indicate that the proposed detection method is superior to existing solutions. The rest of this paper is organized as follows. In the next section, we provide a detailed overview of the related work. In Section II, we present the mathematical model. In Section IV, the proposed Bayesian congestion detection and control scheme is discussed. The experimental and implementation results for various network conditions are explained in Section V. Finally, in Section VI we conclude the paper and provide directions for future work II. RELATED WORK In this section, we first explain the most common approaches for bandwidth change detection and measurement, then we look at some statistical and mathematical approaches, and finally we look at techniques for available bandwidth estimation. A. TCP-friendliness and Current RTCP Based Approaches The scientific community s consensus is that video bitrate should be adjusted in a manner that makes its transmission TCP-friendly [6]. The concern is to protect TCP flows from aggressive flows [7]. At the same time, because the most popular transport protocol is TCP, changes in the video bitrate should be in a way that the video flow itself is not suppressed by TCP flows either. In [8], a model is proposed in order to adapt the bitrate to network fluctuations for a unicast application, by relying on packet loss probability and RTT measurements. This model replaces Additive-Increase/Multiplicative-Decrease (AIMD) approach in regular TCP and is shown to be TCP compatible. The throughput equation as provided in [9], is given as ( ( ) ) where is the sending rate in packets per second, is round trip time in seconds, and is the loss event rate, between and, of the number of loss events as a fraction of application was submitted in May 23, and at the same time the first license of the technology was given to Magor Corp. () the number of packets transmitted. The sending rate in this scheme depends on RTT and packet loss event rate, and any increase in these two parameters would decrease the sending rate. Eq. () not only performs congestion detection through monitoring RTT and, but also provides a sending rate in response to detected bandwidth fluctuations. Other studies have extended the above TCP-friendly scheme for various applications and network topologies. A comprehensive survey of such studies can be found in[7]. For example, the study in [] extends the TCP-friendly scheme to multicast applications. In [], an RTT based prediction method is developed based on packet loss probability and is shown to be TCP-friendly. The network performance evaluation in [] is based on comparing the true current state and the forecasted state at the end of the preceding control period All the aforementioned schemes utilize RTCP packets to collect network information and in most cases they introduce overhead. Furthermore, the nominal interval of RTCP packets is between and 5 seconds [], [2], which is far too late for real-time applications such as HDVC. B. Traffic stochastic measurements Another area of related research is how to measure the statistical characteristics of Internet traffic. In this subsection, we will review some of the works done in modeling and statistical analysis of Internet traffic. It is well-known that data generated by Internet traffic is multifractal, heavy-tailed, bursty and shows long-range dependence. Empirical traffic data not only happen to be heavy-tailed, but also the central part and tail of the data may illustrate different characteristics. In this regard, the work in [3] models the traffic by considering the superposition of multiple flows with different characteristics. In this method, fractional gamma distribution is used to model the central part of traffic flows which falls short of including heavy-tailed events (the tail part). To remedy this problem, a contaminated process is implemented that models the outliers which cause the heavy-tailed phenomena, then the superposition of these two processes (one for the central part and one for the outliers) models the traffic flow. We will avoid this approach and will model traffic parameters with Pareto distribution that captures the central part and also the outliers of the empirical distribution at once. This will provide us with enough mathematical tools to rigorously monitor network conditions through Bayesian analysis of the data. The work in [4] assesses network failures by engaging confidence intervals for network surveillance. In this approach, Binomial distribution is used to measure the percentage of measurements that falls in a reasonable confidence interval. Our approach is complementary to this method and could be combined with it to make congestion detections more accurate. In addition to the above models, packet loss measurements

4 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 4 are studied in [5], [6], and [7] for VPN-based services. In [5], a large-deviation technique is used to estimate packet loss of a Gaussian traffic. In [6], Kalman filter is used to measure packet loss. Also in [7], considering a Gaussian distribution for network traffic, some control techniques are implemented to assess packet loss. One major difference between these approaches and our proposed technique is that we will use heavy-tailed Pareto distribution that more realistically captures statistical properties of Internet data as opposed to light-tailed Gaussian, Gamma or Binomial distributions. C. Available-bandwidth measurement In this subsection, we present some of the existing methods that are capable of measuring the actual amount of the available bandwidth (as opposed to detecting bandwidth changes). The objective here is to show that no existing method can measure the amount of the available bandwidth in a real-time manner and without significant overhead, as needed for our HDVC scenario. In [8], Delphi algorithm is introduced which uses trains of exponentially spaced probing packets for estimating available bandwidth. Unique to this algorithm is a multifractal parametric model for cross-traffic that captures its multiscale statistical properties. This method only considers measuring stationary bandwidth and it is more suitable for single hop; also, it consumes considerable overhead. The proposed method in [9], named TOPP, sends out several packet pairs well-separated in time. It implements linear regression and determines the available bandwidth when delay comes into view. This method introduces overhead and congestion for low bandwidth. SLoPS [2] manipulates streaming rate of trains of packets until determining the available bandwidth, and relies on the analysis of one-way delays of probing packets. If a train of packets are sent, then the difference between one-way delays of consecutive packets is monitored in order to measure the available bandwidth. If the differences are positive, the sending rate is above the available bandwidth, and if the differences are equal to zero, the available bandwidth is understood to be the same as the sending rate. This method is capable of measuring stationary and fluctuating bandwidth, but similar to [9], introduces overhead and traffic congestion for low bandwidth. pathchirp uses exponentially time spaced packets to probe the available bandwidth and monitors the packet in the train at which the queuing delay begins increasing [2]. As a result, a point estimation of the available stationary bandwidth is provided, but at the cost of considerable overhead. Pathload uses the idea that one way delays of a periodic packet stream would show increasing trend if the stream rate is larger than the available bandwidth [22], which is basically the same idea as in the aforementioned methods. While this method does not consume overhead, it suffers from large time convergence. Spruce uses the difference in time spacing between subsequent packets before and after the bottleneck to weight the capacity and estimate the available bandwidth [23]. This method is highly dependent on precise scheduling of probe traffic and only considers only stationary bandwidth. Finally, in [24], the queuing delay at the bottleneck and minimum one way transit time is used to define a parameter,, that captures the proportion of total resources that were consumed by the bottleneck. Values of close to one mean that the entire bottleneck bandwidth was available and values close to zero indicate that the entire bottleneck was used by competing cross traffic. To summarize, there are some methods that can measure the amount of available bandwidth, but they are not real-time and cannot be used in dynamic settings. Most of the above mentioned approaches assume the available bandwidth to be stationary (e.g. [9], [8], [2] and [23]) and consequently measure the available bandwidth over (possibly) few RTTs. However, our approach continuously monitors bandwidth fluctuations in real-time, which makes suitable for our HDVC scenario. For those approaches that measure fluctuating bandwidth such as [22] and [2], they introduce overhead and traffic congestion for low bandwidth. On the contrary, our method does not consume any overhead, it is fast, and does not cause any congestion. Other issues with the above presented methods are related to clock resolution and synchrony between sender and receiver, changes in bottleneck, multiple bottlenecks, and existence of multichannel bottlenecks. Such issues could lead to underestimation or overestimation of the available bandwidth. Therefore, statistical inference is used extensively to minimize the effect of possible outliers. Furthermore, our method avoids using probing packets. Although probing packets could deliver accurate information about the stationary available bandwidth, there is no guarantee that, in very short time periods, these packets travel through the same route as the video packets. Therefore, the video packets themselves at the receiver are used in our method to infer bandwidth fluctuations. Because HDVC packets are usually sent by RTP/UDP protocol, we will not have accurate information about the time spacing of packets at the sender s side, but we use Bayesian tools to calibrate the data. In the next section, we provide more details about the proposed mathematical model. III. PROPOSED MATHEMATICAL MODEL In this section, we introduce our proposed weighted interarrival method and present our statistical model and Bayesian approach. The aim of this section is to build up the technical tools necessary for bandwidth and congestion detection mechanism.

5 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 5 In the illustration below and for the sake of simplicity, we will first consider only one queue of video packets that travel from a single sender to a single receiver through a best-effort network. At the receiver, the arrived packets are time-stamped. We define the random process of inter-arrival times,, as the difference in packet spacing at the receiver for a pair of subsequent packets. If units for packet i, then R i is the arrival time in timestamp (2) subsections, we illustrate the difference between considering fixed and variable shape parameter in light of the applicability of measuring bandwidth variation. Note that ( ) ( ) ( ) ( ) (3) Where and are one-way transmit time and sending time of the i th packet, respectively. Because the video packets are sent by RTP, the receiver has no information about the sending times. Obviously, out of order delivery is a problem here, but we will use statistical inference to minimize the impact of this issue. The basic idea in our method is that the OTT shows an increasing trend when the available bandwidth drops as the queue size of the intermediate devices such as routers increases. Studies regarding OTT measurements can be found in [25] and [26]. Due to variable packet sizes transmitted over the network, we use the weighted inter-arrival time,, as defined in formula (4): Similar to existing studies on Internet data analysis (e.g. [27], [24] ), and as confirmed by our measurements of HDVC packets, the random variable is heavy-tailed and approximately fits to a Pareto distribution, as shown in Figure 2. Reference [3] models network traffic by a count of the number of data units (i.e., packets) that flow through the observation point during a given time slot of length T; therefore, the authors of that paper use a gamma distribution. Our research focuses on the weighted interval arrival time of packets and as our significant amount of simulation indicates a Pareto distribution is adequate for modeling purpose. This is consistent with the fact that most internet data is self-similar. The probability density function (PDF) of a Pareto random variable with parameters and is: ( ) (5) where is the minimum value of the random variable and is the shape parameter. In line with the above, for the random variable which corresponds to video packets, we assume a Pareto distribution with fixed or random variable shape parameter,. In the next (4) Figure 2 Logarithmic histogram of weighted inter-arrival time for video packets of a sample video trace. A. Shape parameter as a fixed value In this case, we assume that throughout an HDVC session, for all s, the random variable has a Pareto distribution with a fixed shape parameter. Based on this assumption, we build our congestion control method using a fixed parameter. The characteristics of Pareto distribution with respect to a fixed parameter varies as follows [28]: : finite average : finite variance : finite skewness : finite kurtosis It is a well-known that due to the nature of Internet traffic, most Internet data with Pareto distribution have shape parameter, and consequently there is slight chance for the existence of mean and variance [27] [29]. Because there is no guarantee for the existence of statistical central tendency (mean) and dispersion (variance, standard deviation) parameters, developing any method based on these parameters will lead to unreliable solutions. In addition, Internet data is known to exhibit self-similarity, burstiness, and long-range dependence, whereas having a fixed shape parameter does not address these characteristics. Hence, we conclude that considering a fixed value for shape parameter will not help us understand the behavior of bandwidth variations. B. Shape parameter as a random variable In this case, we assume that the shape parameter is random variable that varies over time. This a reasonable assumption given the complex nature of Internet communications and data traffic as explained in [27] and [24]. This time-varying perspective will harness the unpredictable behavior of bandwidth variations. In other words, while follows a Pareto distribution, there is no reason to accept a universal value for the shape parameter because this parameter may change over

6 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 6 time even during a single HDVC session. In order to show how a random variable helps to detect bandwidth variations, we have extracted the Pareto pdf for two different values as shown in Figure 3. Figure 3 Probability density functions of Pareto distributions for ρ=.5, and ρ=.5. Figure 4: Probability density functions of Pareto distributions for =., and =.2 As the figure shows, in the case of, the distribution has a lighter tail and the chance for encountering larger weighted inter-arrival times decreases. Whereas for, the distribution has a fatter tail, and we may experience larger weighted inter-arrival times. In addition, in order to show the effect of x_m on the density. Figure 4 shows how a change in the minimum value from =. to =.2 would alter the pdf when. Therefore, a stochastic shape parameter can be used to detect and administer bandwidth variations. In this paper, we propose the use of Bayesian statistics to model bandwidth variations and detect congestion. The details of the Bayesian method are presented in the next section. IV. PROPOSED BAYESIAN METHOD In this section, we provide the details of the proposed Bayesian method. Specifically, this section presents how the weighted inter-arrival times can be used to update the distribution of, and later in subsection B we present the steps of our measurement scheme. Assume that we have a reasonable estimate of the minimum parameter. This information can be obtained from previous experiences or it can simply be a sensible number ( =.4 for instance), although it should not be much smaller than the actual minimum. From this point, the only unknown factor in the Pareto distribution is the shape parameter,, which in turn is considered the new random variable. As a random variable, the shape parameter needs a distribution by itself. In Bayesian statistics, it is known that the conjugate distribution for the shape parameter of a Pareto distribution with known minimum,, is the gamma distribution [3]. The choice of the gamma distribution guarantees that as we dynamically update the information according to weighted inter-arrival times, the distribution of does not alter from the gamma distribution. We will assume that ( ) where ( ) is the gamma distribution with mean and variance and, respectively [28]. Next, we will first show how the weighted inter-arrival times can be used to update the distribution of. Then, we will introduce the measurement scheme. ) Updating the distribution of At the beginning of the session, we assume that the shape parameter denoted by follows the gamma distribution, ( ), where and are predetermined and fixed. These fixed numbers can be chosen based on prior knowledge or we can choose some logical fixed positive numbers with the hope that the system will correct itself in a short period of time. Note that initially the mathematical expectation of is. After the arrival of two packets, is calculated where packet numbering has started from zero. The likelihood function of ( ), proportional to, is shown in (6). ( ) { (6) Therefore, the posterior distribution of the shape parameter based on the observed data,, is: ( [ ] ) (7) As a result, based on the numerical value of, follows a gamma distribution with the average presented in (8). ( ) ( ) (8) Once the next packet arrives and is calculated, it will be used to obtain a new estimation of the Pareto shape parameter, and its corresponding average, shown in equations (9) and (), respectively. ( [ ] ) (9)

7 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 7 ( ) ( ) () This scheme will be continued and after each packet arrival the expectation of the shape parameter is calculated, which will provide us with a sequence of mathematical expectations of the shape parameters. Note that for simplicity, we can write: ( ) () ( ) ( ) (2) As equations () and (2) illustrate the effect of is minimal algebraically because is involved in the calculations through ( ), which is a slowly varying function. In addition, our detection of bandwidth variations is based on sharp changes in the expected values of. A small change or in determining would not have a significant impact on our detection since all s would be adjusted to the fixed. Moreover, note that if the bandwidth stays more or less constant, we expect the values of ( ) not to change drastically, and the only change in occur through which varies linearly. Therefore, if bandwidth is fixed we should encounter a linear. Our data shows that the sequence is highly associated with the reliability of the network. In the next section we will show that the bandwidth variations can be measured by utilizing the moving average of ( ). Figure 5: The reaction of E( ) to bitrate change In order to express the relation of and network status, we have extracted ( ) based on the arrival time of video packets, when the video bitrate is varying between.75 and 2Mbps. The resulting ( ) is shown in Figure 5. Although at the large scale the network condition follows ( ) with an apparent linear trend, but in the small scale the non-linearity of ( ) makes it impossible to apply any linear analysis. As the bandwidth variation has to be detected with an accuracy of milliseconds, we are proposing to use the moving average of ( ) instead of its instant values or the average rate. 2) Measurement Scheme In our previous work [3], the analysis of actual HDVC traces shows that variations of ( ) highly depend on bandwidth fluctuations. Therefore, we propose a measurement scheme based on comparing moving averages of ( ). Comparing moving averages is a well-known technique used for the prediction of stock markets and financial applications [32]. We propose to generate a numerical sequence of differences of the last moving averages of orders and ( ) following each packet arrival. When the i th packet arrives ( ), the difference is determined as shown in formula (3). where ( ) ( ) ( ) (3) (4) After determining the value of, it will be straightforward to detect network congestion. The steps of List demonstrate the overall scheme. Step -Measure Raw network information: Determine arrival time, and size of packets upon arrival at the receiver s side and extract using (4). Step 2- Update ( ): Use (2) to update the expected value of ( ) ( ) Step 3- Evaluate Diff: Evaluate using (3): Diff MA n ) MA ( i i ( i n2 Step 4- Generate lower and upper bound: Generate lower and upper bounds every fraction of a second. Step 5- Monitor bound crossings: Monitor lower and upper bound crossings, and detect bandwidth changes when a crossing happens. List Proposed method for measuring bandwidth changes An acute decline in the value of indicates a decrease in the available bandwidth and, analogously, a rise in shows an increase. As shown in List, after extracting the value, we can detect bandwidth changes by comparing fluctuations with lower and upper bounds, represented by and, respectively. Here, is the time interval that the bounds are kept fixed. Once crosses the lower (upper) bound it indicates a decrease (an )

8 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 8 increase) in the bandwidth. Considering steps, 2, and 3, once is sampled, the lower and upper bounds will be generated according to the following rules: If the first nonzero decimal of is of order, the bounds are proposed to be and. We have used a closer lower bound to increase sensitivity with HDVC in mind. Otherwise, if the first nonzero decimal of is of order where, then bounds should be ( ) In order, to avoid computation complications, we may choose a lower bound for ( ( ) ) To avoid computation complexity, all calculations should be restarted periodically, using the initial values. It should be noted that the numbers.2,.5, and.5 in the above rules have been determined experimentally using dozens of actual HDVC traces, where it was found that these numbers do not depend on the specific video but on network behavior [3]. These numbers are quite important and their choice affects the sensitivity of our congestion detection and measurement method. It is also important to consider that this method is a one shut scheme and it resumes its regular operation after the encoder responses to the notification. V. EVALUATION AND EXPERIMENTAL RESULTS In this section, we provide comprehensive experimental simulations and real-world implementation and evaluation. We show that the speed and accuracy of our method is superior to most common used methods such as rate adjustment algorithm of RTT-based schemes [9] [2]. In order to examine the performance of the proposed method, we have used the x264 reference software in [33] as the H.264/AVC video encoder and the NS2 software in [34] as the network simulator platform. In addition to the simulations, the method has also been implemented in the commercial HDVC solution provided by our industry partner Magor Corp, and real-world test scenarios have been performed over the Internet to prove the robustness of the proposed method. A. NS2 Simulations The simulation setup is depicted in Figure 6. Here, S sends the video stream over RTP and it goes through routers R and R2. The whole throughput of the system is determined by link capacity L. S4 acts as receiver, while S2 and S3 are used to generate additional traffic other than the video stream, thus, representing typical traffic activity. S sends video packets and S4 collects the video packets and stores them for analysis. All network parameters are stored in log files. In our simulation scenario, various videos are coded and sent through the NS2 software. For this experiment, and. We use a dynamic and update the bounds every 5 packet arrivals, based on the update rules discussed in the previous section. In order to examine the performance of our method for different network conditions, we have considered six cases for HD videos and 2 cases for SD videos as shown in Table S2 S R L R2 Figure 6 The simulation setup For all of the cases in Table, the video encoder bitrate is fixed and is equal to the Initial bandwidth of each case. The network then changes its bandwidth at frame 6 (second 2 of the video) to the Secondary bandwidth indicated in the table. Note that at second 2, the bandwidth reduction process is initiated and therefore it takes a while for the network to reach the target secondary bandwidth. The video encoder bitrate is not adjusted after bandwidth manipulation. Table. Network condition cases some changes Network Bandwidth (Mbps) Case Number HD Videos SD Videos Initial Secondary Initial Secondary Table 2 and Table 3 show the response times of the tested methods for various HD and SD video sequences and network conditions, respectively. We should mention that the recommended time spacing between RTCP packets is 5 seconds [2] []. However, because one of our goals is to illustrate the speed of our approach, we have decreased the RTCP transmission interval to second (in Table 2) and. second (in Table 3) to give our competitor an edge and help it perform faster. It should be noted that, in this section, when we refer to TCP friendly methods, we mean conventional schemes that are based on the TCP friendly approaches as described in Section II. Recall that such approaches use RTCP for exchanging network statistics between sender and receiver. RTCP-based methods make up the great majority of current approaches. The term No detection represents the cases where no bandwidth change is detected during the simulation period, which is 5.5 seconds. As the results of Table 2 and S3 S4

9 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 9 Table 3 show, our proposed method outperforms RTCP-based methods in 95.8% of the simulation cases. When both approaches have successful detection, our approach detects bandwidth changes on average 5.5 milliseconds sooner, with a standard deviation of milliseconds. In addition, the competing approach behaves poorly when the bandwidth increases. In case 6 of (bandwidth decreasing from 2 to Mbps for HD videos), our approach is, on average, 32.6 milliseconds faster and the standard deviation of differences is 25 milliseconds. Moreover, in the first four cases the competing approach has no detection during the simulation period. To conclude, in order to show the efficiency of our method, we have considered an unrealistic case of RTCP transmission interval of.2 second for HD size videos. The simulation results for this case are shown in Table 4. As Table 4 shows, even in the unrealistic cases, our proposed method outperforms the RTCP-based scheme, in most simulation cases. Case# Table 2. Response time comparison for the proposed and TCP friendly schemes, with sec RTCP interval HD videos Sequence Response time (Sec) name Proposed [2] [9] Tractor method.99 No detection Sun flower.224 No detection Station 2.2 No detection Rush hour.382 No detection Tractor.26 No detection Sun flower.66 No detection Station No detection Rush hour.647 No detection Difference Tractor.8898 No detection Sun flower.8285 No detection Station No detection Rush hour.5548 No detection Tractor.634 No detection Sun flower.8565 No detection Station No detection Rush hour No detection No detection Tractor Sun flower Station Rush hour Tractor Sunflower Station Rush hour Average time ahead when both methods have detection.55 Table 3. Response time comparison for the proposed and TCP friendly schemes, with. sec RTCP interval SD videos Case# 2 Sequence name Response time (Sec) Proposed method [2][9] Difference City Crew Harbour Ice City Crew Harbour No detection.622 Ice Average time ahead when both methods have detection In addition, Figure 7 shows the graphs of with the generated upper and lower bounds for the Rush hour video sequence, while network condition is set based on cases 3 to 6 of Table. We can see that, for the majority of cases, our method detects changes efficiently, except for the following case: In, Figure 7-b, our method does not detect the slight decrease in bandwidth, which means that the amount of decrease has a very light effect on the delays and the inter arrival delay is not significantly affected. Although in that case the curve of turns flat and then decreases, the behavior of our detection method is expected since as we see from the figure the curve did not cross the boundaries. The main portion of the idea comes from calculating inter-arrival time of the consequent packets and updating Bayesian model accordingly. The main indicator of bandwidth change in, Figure 7 is the blue curve (Diff). The blue curve shows bandwidth changes almost immediately. The values of the bounds as mentioned before are not an integrated part of our detection system. These bounds can be chosen in a way that detection occurs in 7(b). However, we chose a more relaxed sensitivity. That is the reason that no detection happens in 7(b). Meanwhile, please note that the sending rate of the Rush hour video for all cases in, Figure 7 is capped at 2 Mbps. Therefore, a decrease of.25 Mbps in bandwidth does not drastically affect the inter-arrival time of subsequent packets and quality of video. However, an increase of the same size in the bandwidth would trigger a rush of packets and cause shorter inter-arrival times. Hence, the blue curve starts increasing dramatically in 7(a) after this increase. Our analysis, shows that the Bayesian model developed in our paper is more sensitive to bandwidth increases compared to sudden same size decreases.

10 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < (a) (b) (c) (d) Figure 7 Graphs for our proposed approach for the Rush hour video for various decreasing cases a) Case 3 (2 Mbps to 2.25 Mbps), b) Case 4 (2 Mbps to.75 Mbps), c) Case 5 (2 Mbps to.5 Mbps) and d) Case 6 (2 Mbps to Mbps) B. Commercial testbed experiments In addition to simulations, similar scenarios have been tested with a commercial HDVC system testbed provided by our partner Magor Corporation. Figure 8 presents the experiment setup. In the figure, both the client and the server send video to each other and represent two parties in an HDVC session. The proxy server is responsible to emulate various network conditions and policies. We have used netem in the proxy to emulate real network traffic patterns [35]. To have a fixed reference to compare the results, a prerecorded video of a real session is used in the experiment. A snapshot of an HDVC session is shown in Figure 9. We performed experiments with multiple scenarios. In the first scenario, the video bitrate was initially set to 5 kbps and proxy was configured to provide this bitrate at first and then drop it to kbps after 7 seconds. In the second scenario, the video bitrate was initially set to the 5 kbps and proxy was configured to increase it to 2 Kbps after 7 seconds. Figure presents the results of the first scenario. Two variables have been shown in the figure. The x-axis represents the time of bandwidth change, with the negative and positive values indicating the time before and after bandwidth change, respectively; i.e., bandwidth change occurs at time zero. The y-axis represents the Diff variable according to Eq. (3). As mentioned before, the Diff variable determines the behavior of the network in our proposed method, and crossing the lower bound and upper bound indicates the method detecting the bandwidth modification which is mentioned in List. We can see from the figure that our solution detects the fluctuation about 6ms after bandwidth modification.

11 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < Case# Table 4. Response time comparison for the proposed and TCP friendly schemes, with.2 sec RTCP interval HD videos Sequence Response time (Sec) name Proposed [2][9] Tractor method.943 No detection Sunflower.32 No detection Station No detection Rush hour.332 No detection Tractor.56 No detection Sunflower.872 No detection Station No detection Rush hour.653 No detection Difference Tractor No detection Sunflower No detection Station No detection Rush hour.8936 No detection Tractor Sunflower No detection Station Rush hour No detection.3394 Tractor Sunflower Station Rush hour Tractor Sunflower Station Rush hour Average time ahead when both methods have detection Client Network Proxy Figure 8 Experiment Setup Server Figure 9 A snapshots of an HDVC session -8E Diff Down Up Receiving time(milisecond) Figure The proposed method s performance when bandwidth changes from 5 kbps to kbps with 5 kbits router buffer As we have explained previously in Section IV (see Figure 5), the value of Diff should be none-descending in case of no congestion occurring in the bandwidth. Before any modifications happen in the network, the diff is ascending meaning that there is no bandwidth congestion. But, when impairments are applied at the proxy, the slope of the diff becomes negative and follows the network s behavior. In technical terms, the inter-arrival delay describes the whole inter-media queue status of the internal routers. On the other hand, the available bandwidth report of the TCP friendly methods for the aforementioned scenario is depicted in Figure, where bandwidth change also happens at time zero. But, the first indication of bandwidth congestion appears after quite some time of receiving enough loss events. The earliest possible time for the TCP friendly method to detect the bandwidth congestion in the network was around 9ms after applying network impairments. The detection happens after the internal queue in the proxy becomes full and starts to drop the packets. This could be too late for real-time applications such as HDVC. In such applications, packets loss not only affects the lost frames themselves, but also all ensuing frames that use the lost frames as reference. This leads to a loss of video quality at the receiver side. In fact it emphasizes our explanation in Section I regarding the need for fast bandwidth

12 Value Bitrate (Mbps) Bitrate (Mbps) > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 2 fluctuation prediction and measurement as proposed in this paper. Clearly, our results demonstrate that conventional TCPfriendly methods do not have the caliber to detect bandwidth changes as fast as possible to lessen quality degradation at the receiver due to packet loss resulted from bandwidth fluctuations. Our method, on the other hand, could detect the modification even if there was no explicit indication about the network loss received at the client side Bitrate Receiving time(milisecond) Figure The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 5 kbps to kbps with 5kbits router buffer. In the second scenario, the effect of bandwidth increase is discussed. The detection of increase bitrate is harder than the decrease case. This is because the decrease of the bitrate immediately affects the queues on the routers and increases the inter-arrival delay. However, the increase of the bitrate has less effect on the internal router s queue and its effect on the inter-arrival delay is rather slow. Figure 2 shows the results of the second scenario, where our method detects the bandwidth increase within 9ms. This is mainly due to the above explanation regarding the slow effect on the interarrival delay. However, our proposed method performed much better than the TCP friendly approach. As shown in Figure 3, the TCP friendly approach detects the bandwidth increase after 2ms. That is, 3ms slower than our method, but the result of the TCP friendly approach appears after 9 seconds. This is expected since it is a conservative method [36]. This again is considered not adequate for real-time applications such as HDVC, which has stringent quality requirements Receiving time(milisecond) Figure 2 The proposed method s performance when bandwidth changes from 5 kbps to 2 kbps Diff Upper Bound Lower Bound.5.5 Receiving time (milisecond) Figure 3 The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 5kbps to 2 kbps. C. Impact of the Router s queue Another practical use of our system is in the case when Internet Service Providers (ISPs) increase the queue size of the intermediate routers, which is a procedure used to decrease the packet loss to avoid retransmission. The router s queue size affects both the increase and decrease bitrate scenarios. The larger queue size imposes a delay in the TCP friendly method as loss packets decrease while the delay of packets increases. Packets that are received with delay could be acceptable for many applications such as file transfer and http web pages. But, for live and conversational applications such as video conferencing, delayed packets that are received out of the deadline are treated as loss packets and hence they cannot be used for decoding. Packet loss not only affects the lost frames themselves, but also all ensuing frames that use the lost frames as reference. This has a direct effect on the video quality at the receiver side. The proposed method has greater advantage over TCP-friendly approaches to mitigate such issue. Figure 4 and Figure 6 represent the TCP friendly method with 2kbits and kbits buffer size in the router. Figure 5 and Figure 7 represent our method with 2kbits and kbits buffer size in the router. For buffer size 2kbits, the TCP friendly method detected the bitrate modification at 36ms while our method was able to detect the bandwidth modification at 8ms. For the case of buffer size kbits, the TCP friendly method detected the bandwidth modification at 232ms while our method was able to detect the modification at 9ms. Clearly, the performance of our method is superior compared to the TCP friendly method. Our method is faster than the TCP friendly method by 353ms and 84ms for buffer sizes 2kbits and kbits respectively. As explained in the previous subsection, the faster the detection and prediction of bandwidth changes, the more time leverage to make the necessary changes to the bitrate and keep the highest quality..