Related Works

There are two kinds of approaches for end-to-end TCP-friendly congestion control: window-based [26] and rate-based [41] approaches. The window-based approach is derived from the AIMD (additive increase multiplicative decrease) rule by adjusting the window size in response to the acknowledgments or to packet loss detection. The rate-based approach attempts to handle the transmission rate directly under the AIMD rule, or sometimes based on analytical equations [41]. The basic method used in AIMD schemes is based on increasing the transmission rate of a sender by an additive value during underload situations. During overload situations the rate is reduced multiplicatively. The adaptation decision is taken from the observations, based on the network state, made during a specific time interval [124]. There are many mechanisms to implement the increase and decrease phases of both kinds of adaptation approaches. The authors of [124,125,126] investigate various mechanisms for realizing an additive increase and multiplicative decrease adaptation scheme based on RTP. They also identified the optimal approaches for increasing and decreasing the transmission rate. Other work in this area can be found in [22,26,41,42,44,77,107,108]. In [77], an end-to-end congestion control mechanism for Internet video is presented. The end system adjusts the sending rate depending on the perceived network status, to satisfy the bandwidth and packet loss requirements while exhibiting a TCP-friendly behavior. Based on that mechanism, a TCP-friendly Internet video streaming employing variable frame-rate encoding is presented in [127,78,76]. It consists of TFRC and on available bandwidth estimator. The video is compressed according to the available bit rate and the end-to-end estimated delay. The goal is to enhance the network adaptability to mitigate the packet loss and bandwidth fluctuation. Another congestion control mechanism that uses the frame rate as a control parameter is presented in [42]. The congestion is detected by measuring the buffer occupancy and loss rate. The available channel bandwidth is estimated by measuring the incoming data rate at the receiver. The frame rate is adjusted accordingly when congestion is detected. In [132], a real-time Internet video congestion control mechanism using error resilient scalable compression and TFRC is presented. Compressed video is packetized into individually decodable packets of equal expected visual importance. The packets can be truncated to instantaneously meet the time varying bandwidth imposed by a TFRC. The idea of changing the frame rate, such as the work given in [77,127,78,76], is much better than this one. This is because dropping packets will degrade the quality too much, but reducing the sending rate by dropping complete frames will reduce considerably the sending rate, do not lose packets and the degradation on the quality will not be as harm as dropping packets randomly from several frames (see Section 7.4 for more details). A TFRC protocol for real-time video applications is presented in [144]. In addition to the classical rate estimation (based on delay and loss), the authors use the perceived video quality (based on the very simple SNR measure) as a way to adjust the transmission rate, and to provide fairness with a competing TCP flow. However, as we have shown in Section 6.6, PSNR gives very poor correlation with subjective quality measurements. Knowing that PSNR is better than SNR for video quality evaluation (in other words, SNR is not a reliable metric to measure the perceived video quality), it is expected that the performance will be consequently poor. In addition, the SNR is measured at the sender side, thus it takes only into account the encoding impairments and not the network impairments. Another comment about this work is that the protocol used to evaluate the network state is RTCP (see next for explanations about its limitation in rate control). A proposal of TFRC called Time-lined TCP which is targeted at streaming media (applications that tolerate both loss and delay) is presented in [97]. The protocol consists of associating a deadline with the data, trying to re-send non-acknowledged packets the same way as TCP, but the process is given up when the deadline is expired. The packet is considered lost only if their deadline has expired before acknowledgment. The idea seems interesting, but it will not work well for real-time applications that cannot tolerate too much delay or loss such as audio or video conferencing. An adaptation scheme called rate adaptation protocol (RAP) is presented in [108]. Just as with TCP, sent packets are acknowledged by the receivers with losses indicated either by gaps in the sequence numbers of the acknowledged packets or timeouts. Using the acknowledged packets, the sender can estimate the round trip delay. If no losses were detected, the sender can periodically increase its transmission rate additively as a function of the estimated round trip delay. After detecting a loss the rate is reduced by half in a similar manner to TCP. However, this approach does not consider the cases of severe losses that might lead to long recovery periods for TCP connections. Hence, the fairness of such an approach is not always guaranteed. In addition, similar to other many TFRC protocols, reducing the sending rate by half in response to a single packet drop may produce a severe degradation of the perceived multimedia quality [126]. Based on that protocol, the authors present in [106,107,109,110] a mechanism for using layered video in the context of unicast congestion control. This quality adaptation mechanism adds and drops layers of the video stream to perform long-term coarse-gained adaptation, while using a TFRC to react to congestion in short timescales. The mismatches between the two timescales are absorbed using buffers at the receiver. Another TFRC proposal is given in [124,125]. It is based on loss-delay adaptation for regulating the transmission behavior of multimedia senders. The goal is to improve the network utilization, avoid congestion, and provide fairness toward competing TCP connections. It uses RTCP to estimate loss and delay. The disadvantage of this proposal is due to the use of RTCP to estimate the loss and delay. This will not react to the rapid changes in the network (see next for the limitation of RTCP).