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 200 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
I. INTRODUCTION
ODAY, video is streamed not only at its traditional resolutions of 340p or 480p, 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 high-definition 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 [1] 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 best-effort 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 1. The video content
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, ayassine}@discover.uottawa.ca
is captured at the encoder side and sent through the network after packetizing the video data.
Video Encoder Video Decoder Congestion Detector
Figure 1 Block diagram of a HDVC system over best-effort networks between two locations
In Figure 1, 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:
1) 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 well-known 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 overheadto an already bulkyvideo 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 real-world network implementation [4] . We tested our method using one of the most demanding video streaming applications: HD Video Conferencing (HDVC1) although
1 Our method was provisionally patented in May 2012 (“Network
Congestion Prediction” US Patent Pending 61/639,531, 2012), 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
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 real-time 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
(√ √ ( ) ) (1) where is the sending rate in packets per second, is round trip time in seconds, and is the loss event rate, between 0 and 1, of the number of loss events as a fraction of application was submitted in May 2013, 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. (1) 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 [10] extends the TCP-friendly scheme to multicast applications. In [10], an RTT based prediction method is developed based on packet loss probability and is shown to be TCP-friendly. The network performance evaluation in [10] 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 1 and 5 seconds [11], [12], 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 [13] 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 [14] 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.
are studied in [15], [16], and [17] for VPN-based services. In [15], a large-deviation technique is used to estimate packet loss of a Gaussian traffic. In [16], Kalman filter is used to measure packet loss. Also in [17], 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 [18], 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 [19], 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 [20] 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 [19], 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 [21]. 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. [19], [18], [21] 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 [20], 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 inter-arrival 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.
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 is the arrival time in timestamp units for packet , then
Note that
(2)
( ) ( )
( ) ( ) (3)
Where and are one-way transmit time and sending time of the ith 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):
(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 [13] 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
subsections, we illustrate the difference between considering fixed and variable shape parameter in light of the applicability of measuring bandwidth variation.
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 i
R
itime 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 ρ=0.5, and ρ=1.5.
Figure 4: Probability density functions of Pareto distributions for =0.001, and =0.002
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 =0.001… to =0.002… 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
( =0.000004 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 [30]. 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.
1) 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 (10), respectively.
( [ ]
( ) ( ) (10) 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:
(∏ ) (11)
( ) ( ) (12)
As equations (11) and (12) 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 0.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 [31], 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 ith packet arrives ( ), the difference is determined as shown in formula (13).
( ) ( ) (13)
where
( ) ∑ (14)
After determining the value of , it will be straightforward to detect network congestion. The steps of List 1 demonstrate the overall scheme.
Step 1-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 (12) to update the expected value of
( ) ( )
Step 3- Evaluate Diff: Evaluate using (13):
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 1 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 1, 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
) ( ) (n1 MA n2 MA Diffi i i
increase) in the bandwidth. Considering steps 1, 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 0.02, 0.05, and 1.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 [31]. 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] [12]. 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, S1 sends the video stream over RTP and it goes through routers R1 and R2. The whole throughput of the system is determined by link capacity L1. S4 acts as receiver, while S2 and S3 are used to generate additional traffic other than the video stream, thus, representing typical traffic activity. S1 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 50 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 1 S1 L1 S2 R1 R2 S3 S4 Figure 6 The simulation setup
For all of the cases inTable 1, the video encoder bitrate is fixed and is equal to the Initial bandwidth of each case. The network then changes its bandwidth at frame 60 (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 1. Network condition cases some changes
Case Number
Network Bandwidth (Mbps)
HD Videos SD Videos
Initial Secondary Initial Secondary
1 2.0 3.0 2.0 1.0 2 2.0 2.5 2.0 1.5 3 2.0 2.25 4 2.0 1.75 5 2.0 1.5 6 2.0 1.0 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 [12] [11]. However, because one of our goals is to illustrate the speed of our approach, we have decreased the RTCP transmission interval to 1 second (in Table 2) and 0.1 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 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 511.5 milliseconds sooner, with a standard deviation of 322.95 milliseconds. In addition, the competing approach behaves poorly when the bandwidth increases. In case 6 of (bandwidth decreasing from 2 to 1 Mbps for HD videos), our approach is, on average, 320.6 milliseconds faster and the standard deviation of differences is 125 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 0.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.
Table 2. Response time comparison for the proposed and TCP friendly schemes, with 1 sec RTCP interval– HD videos Case# Sequence
name
Response time (Sec)
Difference Proposed method [12][9] 1 Tractor 0.0990 No detection Sun flower 0.1224 No detection Station 2 0.1201 No detection Rush hour 0.1382 No detection
2
Tractor 0.1216 No detection Sun flower 0.1616 No detection Station 2 0.1438 No detection Rush hour 0.1647 No detection
3
Tractor 0.088198 No detection ∞ Sun flower 0.182185 No detection ∞ Station 2 0.150716 No detection ∞ Rush hour 0.155048 No detection ∞
4
Tractor 0.116134 No detection ∞ Sun flower 0.185065 No detection ∞ Station 2 0.150716 No detection ∞ Rush hour No detection No detection 0
5 Tractor 0.1995 1.1970 0.9975 Sun flower 0.1649 1.1970 1.0321 Station 2 0.2262 0.5966 0.3703 Rush hour 0.1867 0.5966 0.4099 6 Tractor 0.1836 0.5966 0.4130 Sunflower 0.1541 0.5966 0.4425 Station 2 0.1994 0.3973 0.1979 Rush hour 0.1683 0.3973 0.2290
Average time ahead when both methods have
detection 0.5115
Table 3. Response time comparison for the proposed and TCP friendly schemes, with 0.1 sec RTCP interval – SD videos
Case# Sequence name
Response time (Sec)
Difference Proposed method [12][9] 1 City 0.1708 0.4035 0.2327 Crew 0.2734 0.2042 -0.0692 Harbour 0.3283 0.4035 0.0752 Ice 0.1982 0.4035 0.2053 2 City 0.1755 0.5027 0.3272 Crew 0.2745 0.2042 -0.0703 Harbour No detection 0.6022 Ice 0.2043 0.4035 0.1992
Average time ahead when both methods have detection
0.128586
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 1. 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 0.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.
(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 1.75 Mbps), c) Case 5 (2 Mbps to 1.5 Mbps) and d) Case 6 (2 Mbps to 1 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 1500 kbps and proxy was configured to provide this bitrate at first and then
drop it to 1000 kbps after 7 seconds. In the second scenario, the video bitrate was initially set to the 1500 kbps and proxy was configured to increase it to 2000 Kbps after 7 seconds. Figure 10 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. (13). 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 1. We can see from the figure that our solution detects the fluctuation about 160ms after bandwidth modification.
Table 4. Response time comparison for the proposed and TCP friendly schemes, with 0.2 sec RTCP interval– HD videos Case# Sequence
name
Response time (Sec)
Difference Proposed method [12][9] 1 Tractor 0.0943 No detection Sunflower 0.1302 No detection Station 2 0.0936 No detection Rush hour 0.1332 No detection
2
Tractor 0.1056 No detection Sunflower 0.1872 No detection Station 2 0.0936 No detection Rush hour 0.1653 No detection
3
Tractor 0.122249 No detection ∞
Sunflower 0.164523 No detection ∞ Station 2 0.137348 No detection ∞ Rush hour 0.108936 No detection ∞
4
Tractor 0.401153 0.283389 -0.1178
Sunflower No detection 0.243406 ∞ Station 2 0.279008 0.203455 -0.0755 Rush hour No detection 0.103394 ∞
5 Tractor 0.2110 3.0552 2.8442 Sunflower 0.1496 3.0552 2.9056 Station 2 0.4107 1.9919 1.5811 Rush hour 0.2005 1.9919 1.7914 6 Tractor 0.1975 0.9321 0.7345 Sunflower 0.1520 0.9321 0.7801 Station 2 0.2537 0.9321 0.6784 Rush hour 0.2082 0.9321 0.7238
Average time ahead when both methods have
detection 1.18459
Server Network Proxy
Client
Figure 8 Experiment Setup
Figure 9 A snapshots of an HDVC session
Figure 10 The proposed method’s performance when bandwidth changes from 1500 kbps to 1000 kbps with 50 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 11, 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 900ms 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
-0.01 -0.008 -0.006 -0.004 -0.002 -8E-17 0.002 0.004 0.006 0.008 0.01 -1506 -1282 -1066 -762 -448 -223 70 277 572 869 1268 1636 Receiving time(milisecond) Diff Down Up
fluctuation prediction and measurement as proposed in this paper. Clearly, our results demonstrate that conventional TCP-friendly 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.
Figure 11 The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 1500 kbps to 1000 kbps with 50kbits 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 12 shows the results of the second scenario, where our method detects the bandwidth increase within 900ms. This is mainly due to the above explanation regarding the slow effect on the inter-arrival delay. However, our proposed method performed much better than the TCP friendly approach. As shown in Figure 13, the TCP friendly approach detects the bandwidth increase after 1200ms. That is, 300ms 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.
Figure 12 The proposed method’s performance when bandwidth changes from 1500 kbps to 2000 kbps
Figure 13 The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 1500kbps to 2000 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 14 and Figure 16 represent the TCP friendly method with 200kbits and 100kbits buffer size in the router. Figure 15 and Figure 17 represent our method with 200kbits and 100kbits buffer size in the router. For buffer size 200kbits, the TCP friendly method detected the bitrate modification at 3611ms while our method was able to detect the bandwidth modification at 80ms. For the case of buffer size 100kbits, the TCP friendly method detected the bandwidth modification at 2032ms while our method was able to detect the modification at 191ms.
Clearly, the performance of our method is superior compared to the TCP friendly method. Our method is faster than the TCP friendly method by 3531ms and 1841ms for buffer sizes 200kbits and 100kbits 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. . 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 -1506 -1384 -1178 -976 -768 -559 -346 -223 -24 169 369 566 766 976 1268 Bi tr at e ( M b p s) Receiving time(milisecond) -0.005 0 0.005 0.01 0.015 0.02 0.025 0.03 0.035 0.04 -11305 -9853 -8473 -7842 -6031 -4856 -3609 -2298 -1583 -193 1185 1305 1657 V al u e Receiving time(milisecond) Diff Upper Bound Lower Bound 0 0.5 1 1.5 2 2.5 3 3.5 4 Bi tr at e ( M b p s)
Receiving time (milisecond) Bitrate
In the next subsection, we provide our real-world implementation of the proposed method.
Figure 14 The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 1500 kbps to 1000 kbps with 200kbits routers buffer.
Figure 15 the proposed method’s performance when bandwidth changes from 1500 kbps to 1000 kbps with 200 kbits router’s buffer
Figure 16 The amount of available bandwidth calculated by the TCP friendly method when bandwidth changes from 1500 kbps to 1000 kbps with 100kbits routers buffer.
Figure 17 the proposed method’s performance when bandwidth changes from 1500 kbps to 1000 kbps with 100 kbits router’s buffer
D. Real-world Implementation
In this subsection, we test our method in real network and stream video between two locations that are far from each other. In this test, each streaming packet goes through some intermediate routers and different ISP zones. We evaluated our method over an actual HDVC session performed over the Internet. We established an HDVC session between our DISCOVER Lab at the University of Ottawa and Magor’s location in Kanata, Ottawa’s suburb. The bandwidth was around 1.5mbps and both TCP-friendly and our method were implemented on Magor Solution. Upon receiving a packet, the required information is then calculated and passed to each method.. Figure 18 and Figure 19 are the output of our method and the RTCP method respectively. Since we did not know the exact amount of bandwidth and we cannot determine it, we only compared the results of detecting bandwidth changes. From figures 17 and 18, we can notice that the RTCP based method shows a bandwidth reduction at 10703 ms from the beginning while our method has detected at the change after 9973ms. The RTCP based method was slower by 730ms compared to our method. As expected, our method measures bandwidth reduction faster than the other methods, leading to the possibility of adjusting the video bitrate sooner, which in terms leads to a higher quality of experience by the end user.
Figure 18 A real trace of the proposed method over the Internet 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 -7 6 6 3 -6 9 5 5 -6 0 7 2 -5 3 5 1 -4 6 5 4 -3 8 5 8 -3 1 0 8 -2 3 0 7 -1 5 1 5 -7 2 8 -1 8 7 8 4 1 6 0 1 2 3 9 9 3 1 0 7 4 0 0 3 5 0 1 2 6 0 8 9 7 7 1 1 8 7 2 9 9 3 4 1 Bi tr at e ( M b p s)
Receiving time (milisecond)
-0.04 -0.03 -0.02 -0.01 0 0.01 0.02 0.03 -3 8 5 8 -3 4 1 5 -2 9 0 7 -2 4 1 5 -2 0 0 5 -1 5 1 5 -1 0 2 9 -6 2 0 -1 2 2 2 9 2 7 8 4 1 2 8 9 1 7 0 7 2 2 0 5 2 6 9 7 3 1 0 7 3 6 0 6 4 3 8 6 4 9 0 6 5 4 2 6 6 0 8 9 V al ue
Receiving time (milisecond)
Diff 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 B it rat e (M bps ) Receiving time(milisecond) -0.02 -0.015 -0.01 -0.005 0 0.005 0.01 0.015 0.02 -1510 -1101 -623 -209 297 723 1230 1724 2318 2899 3530 V al ue
Receiving time (milisecond)
-0.01 0 0.01 0.02 0.03 0.04 0.05 0.06 9.973 10.188 10.426 10.638 10.739 10.892 11.07 11.207 11.324 11.42 11.637 V al u e Receiving time(second) Diff Lower Bound Upper Bound
Figure 19 A real trace of the TCP friendly methods over the Internet
VI. CONCLUSION AND FUTURE WORK
In this paper, we described a continuous one-way detection of available bandwidth changes for video streaming over best effort networks. We have provided detail analysis of the proposed method and performed extensive simulation and real-world implementation and evaluation. One of the main advantages of the proposed approach is that the mechanism is receiver-based and depends only on the path connecting the sender to the receiver and hence does not rely on RTT. The proposed Bayesian mechanism improves upon currently available control methods, and can also be implemented in other real time applications if required. The results of our experiments show that the proposed method predicts the congestion occurrence well ahead of the popular TCP friendly methods, in all of the simulation cases. The proposed solution can be used as a standalone mechanism or in conjunction with other methods, even TCP friendly methods, in order to provide more information for the rate adaptation decision engine. Furthermore, our approach does not introduce network overhead to an already bulky video traffic that operates at the border of the available bandwidth. Also, it does not require synchronous clocks at the receiver or the sender side, and independent of the underlying network. For our future work, the mathematical model can be improved by considering a stochastic minimum value for the Pareto distribution. We plan on refining the parameters of the measurement schemes in order to develop a systematic approach of choosing the threshold values. Extending the implementation of the proposed method to include http-based video streaming is our next step. While client-based adaptation approaches react late to channel variations and fail to stream at the optimal rate, we plan to study the effect of predicting bandwidth changes in the ability to direct HTTP client requests to the optimal streaming rate, which can be still decoded by a standard DASH client. Another direction for future work would be the investigation of integrating network
bandwidth utilization models with the proposed prediction approach. The output of such integration will be used to proactively enhance any degradation of user’s QoE by allocating the bandwidth resources according to the user’s QoE requirements.
REFERENCES
[1] Vidyo Personal Telepresence, “VidyoRoom TM Administrator and User
Guide,”
http://www.vidyo.com/wp-content/uploads/2013/11/VidyoRoom_Admin_and_User_Guide_2.2.2-A.pdf, 2013. .
[2] M. Lee, “Video Traffic Prediction Based on Source Information and Preventive Channel Rate Decision for RCBR,” IEEE Trans. Broadcast., vol. 52, no. 2, pp. 173–183, Jun. 2006.
[3] E. Casilari, a. Reyes, a. D az-Estrella, and F. Sandoval, “Heavy-tailed distribution of scene duration in VBR video,” Electron. Lett., vol. 35, no. 2, p. 134, 1999.
[4] A. Javadtalab, S. Shirmohammadi, and M. Hosseini, “DEMO PAPER : A FAST-ADJUSTING HIGH-QUALITY RATE CONTROL ALGORITHM FOR HD VIDEO STREAMING,” in IEEE International Conference on Multimedia and Expo, 2013, pp. 3–4.
[5] A. Javadtalab, M. Omidyeganeh, S. Shirmohammadi, and M. Hosseini, “On the Suitability of Current x264 Rate Controller Algorithms for High Definition Video Conferencing,” in International Symposium on Artificial Intelligence and Signal Processing (AISP), 2011, pp. 107–112.
[6] S. Floyd and K. Fall, “Promoting the Use of End-to-End Congestion Control in the Internet,” IEEE/ACM Trans. Netw., vol. 7, no. 4, pp. 458–472, 1999.
[7] N. Singhal and R. M. Sharma, “Survey on TCP Friendly Congestion Control for Unicast and Multicast Traffic,” Int. J. Comput. Appl., vol. 26, no. 1, pp. 23–30, 2011.
[8] S. Floyd, M. Handley, J. Padhye, and J. Widmer, “Equation-based congestion control for unicast applications,” in Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication - SIGCOMM ’00, 2000, pp. 43–56.
[9] M. Handley, J. Padhye, and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification,” Network Working Group, 2008. .
[10] J. Widmer and M. Handley, “Extending equation-based congestion control to multicast applications,” in Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM ’01, 2001, pp. 275–285.
[11] H. Gharavi, K. Ban, and J. Cambiotis, “RTCP-based frame-synchronized feedback control for IP-video communications over multipath fading channels,” in IEEE International Conference on Communications (IEEE Cat. No.04CH37577), 2004, pp. 1512–1516.
[12] H. Schulzrinne, S. Casner, H. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications, RFC3550 standard, 2003.,”
Network Working Group, 2003. .
[13] G. Giorgi and C. Narduzzi, “A Study of Measurement-Based Traffic Models for Network Diagnostics,” IEEE Trans. Instrum. Meas., vol. 57, no. 8, pp. 1642–1650, Aug. 2008.
[14] M. Bertocco, R. Tittoto, E. Rizzi, and L. Benetazzo, “Statistical Analysis of Measurements for Telecommunication-Network Troubleshooting,” in IEEE Conference on Instrumentation and Measurement Technology, 2002, no. May, pp. 21–23.
[15] D. Zhang, S. Member, and D. Ionescu, “Measurement and Control of Packet Loss Probability for MPLS VPN Services,” IEEE Trans. Instrum. Meas., vol. 55, no. 5, pp. 1587–1598, 2006.
[16] D. Zhang and D. Ionescu, “A New Method for Measuring Packet Loss Probability Using a Kalman Filter,” IEEE Trans. Instrum. Meas., vol. 58, no. 2, pp. 488–498, 2009.
[17] D. Zhang and D. Ionescu, “Online Packet Loss Measurement and Estimation for VPN-Based Services,” IEEE Trans. Instrum. Meas., vol. 59, no. 8, pp. 2154–2166, 2010.
[18] V. Ribeiro, M. Coates, R. Riedi, S. Sarvotham, B. Hendricks, and R. Baraniuk, “Multifractal cross-traffic estimation,” in ITC Specialist Seminar on IP Traffic Measurement, 2000, pp. 1–15. 0 0.5 1 1.5 2 2.5 9973 10188 10426 10638 10739 B it rat e (M bps )
Receiving time (milliseconds)
[19] B. Melander, M. Bjorkman, and P. Gunningberg, “A new end-to-end probing and analysis method for estimating bandwidth bottlenecks,” in EEE. Global Telecommunications Conference, 2000, vol. 1, no. 1, pp. 415–420. [20] M. Jain and C. Dovrolis, “End-to-End Available Bandwidth : Measurement Methodology , Dynamics , and Relation With TCP Throughput,” IEEE/ACM Trans. Netw., vol. 11, no. 4, pp. 537–549, 2003. [21] V. J. Ribeiro, R. H. Riedi, R. G. Baraniuk, J. Navratil, and L. Cottrell, “pathChirp : Efficient Available Bandwidth Estimation for Network Paths,” in
Workshop on Passive and Active Monitoring, 2003, pp. 1–11.
[22] M. Jain and C. Dovrolis, “Pathload : a measurement tool for end-to-end available bandwidth,” in In Proceedings of Passive and Active Measurements (PAM) Workshop, 2002, pp. 14–25.
[23] J. Strauss, D. Katabi, and F. Kaashoek, “A measurement study of available bandwidth estimation tools,” in Proceedings of the conference on Internet measurement conference - IMC ’03, 2003, p. 39.
[24] V. Paxson, “End-to-end Internet packet dynamics,” IEEE/ACM Trans. Netw., vol. 7, no. 3, pp. 277–292, Jun. 1999.
[25] L. De Vito, S. Rapuano, and L. Tomaciello, “One-Way Delay Measurement: State of the Art,” IEEE Trans. Instrum. Meas., vol. 57, no. 12, pp. 2742–2750, Dec. 2008.
[26] I. Phillips, D. Parish, M. Sandford, O. Bashir, and A. Pagonis, “Architecture for the management and presentation of communication network performance data,” IEEE Trans. Instrum. Meas., vol. 55, no. 3, pp. 931–938, 2006.
[27] M. . Crovella and A. Bestavros, “Self-similarity in World Wide Web traffic: evidence and possible causes,” IEEE/ACM Trans. Netw., vol. 5, no. 6, pp. 835–846, 1997.
[28] K. Krishnamoorthy, Handbook of statistical distributions with applications. Chapman & Hall, 2006, p. 376.
[29] V. Paxson and S. Floyd, “Wide area traffic: the failure of Poisson modeling,” IEEE/ACM Trans. Netw., vol. 3, no. 3, pp. 226–244, Jun. 1995. [30] A. K. Bansal, Bayesian Parametric Inference. Alpha Science Intl Ltd, 2007, p. 400.
[31] A. Khanchi, M. Semsarzadeh, A. Javadtalab, and S. Shirmohammadi, “Continuous one-way available bandwidth change detection in high definition video conferencing,” in ACM Workshop on Network and Operating Systems Support for Digital Audio and Video, 2013, pp. 25–30.
[32] M. A. Ferreira and P. Santa-Clara, “Forecasting stock market returns: The sum of the parts is more than the whole,” J. financ. econ., vol. 100, no. 3, pp. 514–537, Jun. 2011.
[33] X264, “x264,” http://www.videolan.org/developers/x264.html, 2014. [Online]. Available: http://developers.videolan.org/x264.htm.
[34] “NS-2,” Network Simulator version 2 (NS-2), 2011. [Online]. Available: http://www.isi.edu/nsnam/ns/.
[35] Linux Foundation, “Netem,” 2009. [Online]. Available: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem. [36] K. Chen and K. Nahrstedt, “Limitations of equation-based congestion control in mobile ad hoc networks,” in 24th International Conference on Distributed Computing Systems Workshops, 2004, pp. 756–761.
