<figure><img src="image_1.png" /></figure>

HAL
open science

# Rate Adaptive Congestion Control Using Lookup Table Scheme to Enhance Quality of Experience

Jane Lissah, Mercy Mbise

► To cite this version:

Jane Lissah, Mercy Mbise. Rate Adaptive Congestion Control Using Lookup Table Scheme to Enhance Quality of Experience. 15th International Conference on Social Implications of Computers in Developing Countries (ICT4D), May 2019, Dar es Salaam, Tanzania. pp.701-711, 10.1007/978-3-030-18400-1_57 . hal-02285271

HAL Id: hal-02285271

https://inria.hal.science/hal-02285271

Submitted on 12 Sep 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RATE ADAPTIVE CONGESTION CONTROL USING LOOKUP TABLE
SCHEME TO ENHANCE QUALITY OF EXPERIENCE

Jane Lissah

Student, University of Dar es Salaam

janelissah@gmail.com

Mercy Mbise, PhD

University of Dar es Salaam

mercymbise@gmail.com

**Abstract.** In recent years video communication has occupied a large percentage of Internet traffic and the trend is expected to increase. Many services are offered via the Internet use video content to reach millions of users. Real time video services in the Internet are mostly done by using User Datagram Protocol (UDP). UDP is preferable because it is fast, but has a weakness of not supporting congestion control mechanisms; hence it usually floods the channel it is using causing congestion which then leads to packet loss, excessive delay and jitter. To support good quality of experience (QoE), packet loss, delay and jitter must be kept at accepted values.

This paper presents part of an ongoing MSc. research work whose aim is to develop a rate adaptive congestion control scheme using a lookup table. The scheme use Real Time Transport Protocol (RTP) and RTP Control Protocol (RTCP) to provide end to end network transport service which is not provided by UDP and control service. The proposed congestion control scheme comprises of two components:- a lookup table and congestion control equation. The lookup table is created at the beginning of sender's application and keeps a record of fraction loss and Inter Packet Gap (IPG), which is the interval in time between sending packets. Upon receiving a report the lookup table is searched to see if there is a match for the report's fraction loss value and returns, the appropriate IPG value. If there is no match a congestion control equation is used to compute a new IPG value, which is then added to the lookup table and used for rate adjustment.

Simulation of the proposed work was done using NS3, where by the Quality of Service (Qos) parameter which affect the Quality of Experience (QoE) such as delay and jitter were observed. Elvavid, a video quality evaluation tool is used to measure the quality of video by using Peak Signal Noise Ratio (PSNR) and Mean Opinion Score (MOS) measurements.

**Keywords:** UDP, RTP, RTCP, QoE, QoS, Rate-adaptive congestion control
# 1 Introduction

In recent years video communication has occupied a large percentage on the Internet and the trend is expected to increase[1], [2]. Many services are offered via the Internet use video contents to reach millions of users. Real time video services in the Internet transported is done using the User Datagram Protocol (UDP) [3] because of its unreliable nature which does not require it to retransmit lost packets. UDP is preferable because it is fast [4], but has a weakness of not supporting congestion control mechanism: hence it usually floods the channel it is using causing congestion to occur which then lead to packet loss, excessive delay and jitter.

To support good Quality of Experience (QoE), packet loss, delay and jitter must be kept at accepted values. Real Time Transfer protocol (RTP) is a protocol which works on top of UDP with the aim of providing end to end connection services between systems. The RTP was designed to be used for audio and video transmission over the Internet, it perform packet loss detection and reorder packets at destination. RTP works with Real Time Control Protocol (RTCP) which monitors the Quality of Service (QoS) parameters and provides different feedback reports[5].

Though the RTP/UDP work well with real time video delivery, it is subjected to high packet losses, excessive delay and jitter since it has no congestion control and tend to congest the network by sending data at a rate higher than available bandwidth. A large number of packet losses, excessive delay and jitter affect the quality of video thus affecting the Quality of Experience (QoE) of end user. According to [6], [7] in order to assure a good QoE to end user, a certain level of QoS must be provisioned.

This paper presents a rate adaptive congestion control which uses a lookup table. The congestion control is designed to work with RTP/RTCP protocols and is based on using QoS parameters (delay, jitter and packet loss) as observed in the RTCP report to find interval value being kept in the lookup table to adjust sending rate by adjusting interval between packets being send over the Internet.

The paper is organized as follows;- section 2 gives a review of relevant literature for rate adaptive congestion control for video streaming. Section 3 gives the description of the model, section 4 gives the outline of simulation setup, section 5 give the results observed and finally section 6 concludes the paper.
## 2 Related Works

Congestion in real time multimedia transmission affect the quality of media as perceived by user, in voice transmission voice is not hear properly and may be characterized by noise or alternation while in video quality of picture may suffer as well as voice and picture synchronization [8]. Congestion in the network may be due to buffer length in the intermediate nodes, slow processor speed at router even though line capacity is high and mismatch of bandwidth between different parts of network [9].

Congestion control includes techniques which are used to control or/ and prevent congestion. The aim of congestion control is to allow for efficient use of bandwidth and support fairness among different flows in the link. There are two approaches for congestion control, end to end congestion control and network assisted congestion control [10].

A number of researchers have investigated congestion control for video streaming. The studies are divided into network-centric congestion control and application level/ end user congestion control [11]. A survey by [12] covers a number of network-centric congestion control schemes where routers are also involved in congestion control throughout the communication channel, while the application layer congestion control schemes are implemented on top of the Transport layer to facilitate video streaming by adapting the sending rate depending on network conditions. Works proposed in [13], [14], [15] and [16] are some of the examples of schemes proposed to be implemented at the application layer using different techniques to support video streaming.

## 3 Methodology

A proposed rate adaptive congestion control scheme comprises of two components; a lookup table and congestion equation. The lookup table is made of associative array using hash table data structure. The hash table data structure uses indices to store key-value data pair. Fraction loss is used as key values while the IPG (Inter Packet Gap) value is used as a value. Congestion control equation is used to calculate the IPG value for rate adjustment whenever there is no value for the fraction loss (key value) obtained from the RTCP receiver report.

Fraction loss is one of the parameters included in the RTCP receiver report and it represents the ratio of number of lost packets between the intervals of transmitting RTCP receiver report to total packets sent within that interval. Other parameters in the RTCP receiver report are number of packets lost, delay and jitter [5]. The RTCP receiver report is sent by the receiver every 5 seconds so as not to flood the channel with feedback packets.
The congestion control equation (1) uses QoS parameters (delay, jitter and fraction loss) which are in the RTCP receiver report to compute a new Inter Packet Gap (IPG). IPG is used as a basis for rate adaptation in order to limit the number of packets sent by UDP application depending on the condition of the network. The congestion control equation is defined as:

$$IPG = (d * j * fl) / 10^{13} \dots (1)$$

Where IPG represents interval between packets, d represents estimated delay experienced by the last packet before sending a new RTCP packet, j represents jitter experienced and fl represents fraction loss. The product of delay, jitter and fraction loss is divided by $10^9$ to obtain IPG value in microseconds. The congestion control equation is used whenever the value is not found on the lookup table (Fig. 1.)

A lookup table created using a hash table uses *key* and *value* pair for its functionality. The fraction loss is used as *key* value while the IPG is used as the *value*. When a new RTCP receiver report is received by the sender, the sender uses fraction loss to search if there is a value which is associated with the key value (fraction loss) in the lookup table. If there is no value, the IPG value for that fraction loss is calculated and used for rate adjustment and stored at the lookup table for future use.

At the start of sender application, the lookup table is initiated with default value of IPG which is used throughout the program when fraction loss is zero and before the sender starts receiving the RTCP receiver report. This is one of the components which make the scheme give good results during simulation. The lookup table is implemented using hash table because it takes a constant time O(1) to search the table even when the table is very much populated. Hash table supports fast search and one index can be used to store multiple pair of key values.
<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Proposed rate adaptive congestion control scheme</figcaption></figure>

The sender (sending point) encapsulates video stream data packets with RTP which provides means to track the number of packets sent and a timestamp for tracking delay. The packets are then encapsulated with UDP and are sent to the receiver (Receiving point) via the Internet. At the receiver, packet sequence numbers are captured to determine the number of packets received and lost and the time stamp is used to obtain the delay and jitter values. Then the RTCP receiver report header is created at the receiver and encapsulated with UDP, and then sent over the Internet to the sender after every five seconds.

Upon receiving the RTCP receiver report packet, the sender extracts the values captured by the receiver. The values contained in the report are packet loss, maximum packets received, highest sequence number observed, jitter and fraction packet loss. These values are then used by the proposed congestion control scheme for rate adjustment at the sender by either increasing or decreasing the IPG value. Only three values (delay, jitter and fraction loss) are used in the congestion control equation since fraction loss is derived from packet loss value, maximum packet received value and highest sequence number observed.

# 4 Simulation setup

Experiments are conducted by simulating different scenarios using NS3. A simulated topology was set up which included three network subnets of Local Area Network
(LAN) as shown in Fig. 2. Subnet one is comprised of Node 0, Node 1 and Node 2 with link capacity of 100Mbps. Subnet two is made up of Node 2 and Node 3 with link capacity of 4 Mbps, and subnet three is made up of Node 3, Node 4 and Node 5 with link capacity of 100Mbps. The link in subnet two is set to a small value to reflect the scarcity of resource in links which are shared by many nodes.

<figure><img src="image_4.png" /><figcaption>Fig. 1. Simulated Network topology</figcaption></figure>

Three applications were used to send video stream data obtained from [17], which provide video data prepared for simulations. A high motion video sequence “high-way” is used. Highway video sequence is in YUV format with a duration of 80.1s. The resolution of the video clip is 352×288 pixels which is known as the common intermediate format(CIF). The videos are en-coded at 25 frames/s with the *ffmpeg* [18] video encoder. *ffmpeg* generates three types of frames namely intra-frame (I), predictive frame (P) and bi-directional frame (B). Frames are organized in groups, called group of pictures (GoP). Each GoP consists of one I frame, some P frames and some B frames between I and P frames, the value of GoP at the *ffmpeg* encoder is set to 12. In the original MPEG-4 format the encoded video files cannot be used in the NS3. Using Evalvid framework [19] the encoded video clip is converted to trace file which is used in NS3. The trace file is then stored at a sender node (Node 0) and transferred to the receiver node (Node 4) using topology in Fig. 2.

Video stream data were sent from Node 0 to Node 4 while TCP traffic was sent from Node 1 to Node 5. The first part of experiment involved three application demonstrate
the responsiveness of the proposed scheme in UDP flow (fig. 3). First application did not contain any additional mechanism for congestion control; the second application contained rate adaptive congestion control mechanism which was used to regulate the time interval between packets using UDP. The rate adaptive congestion control uses the data obtained from the RTCP receiver report to find the appropriate interval to be used. The third application used the proposed rate adaptive congestion control scheme; a lookup table is created upon the start of the application.

The second part of the experiment involved integrating evalvid video quality evaluation tool into NS3, integrating the proposed congestion control scheme into the evalvid application and performing the simulation. The evalvid tool records delay, and jitter which are experienced by each video frames (fig 4 and fig 5 respectively) as well as give QoE measurement in terms of Peak Noisy Signal Ratio (PSNR) values and Mean Opinion Score (MOS) (fig.6 and fig 7 respectively).

# 5 RESULTS AND DISCUSSIONS

Experiments were conducted using NS3, whereby applications were modified to accommodate the use of RTP and RTCP protocols. RTP is used to add sequence number and timestamp to datagram packets whereas RTCP is used for control. Applications used RTCP receiver reports which were sent by the receiver after every 5s to perform sending rate adjustment [5]. Simulation result obtained was compared to related work by [16] as this work also used Evalvid video quality evaluation tool and experiment parameter were made to be similar to this work. Here are the observed results:-

## 5.1 UDP Flow

Fig. 3, presents the UDP flow when the same congestion is used with lookup table and without lookup table. It is observed that the number of packets sent within the interval is decreased for the video stream sent by the application using the proposed scheme.
<figure><img src="image_5.png" /><figcaption>Fig. 3. UDP Flow</figcaption></figure>

The application using the proposed scheme was able to be more responsive in the changing rate of the channel. This allowed the application to increase or decrease the sending rate by increasing or decreasing the IPG value between sending packets. This has led to the decrease of amount of bytes (total number of packets) which are sent out at one instance.

## 5.2 Delay

Delay value for video frames which arrive at the receiver was also observed (Fig.9). There is improvement in delay value observed where by the existing work by [16] recorded and average delay of 77.7 microseconds, the proposed congestion control scheme recorded average delay of 50.1 microseconds. The existing work recorded highest delay of 147.55 microseconds and lowest delay at 20.35 microseconds while the proposed work recorded highest delay at 136.10 microseconds and the lowest delay at 10.3 microseconds (Fig4). This improvement can be explained as a result of reducing congestion in the links which connect the devices. When links are congested with a lot of packets, it takes a long time for packets to reach the destination, hence improvement in delay value signify the performance of the proposed scheme.
<figure><img src="image_6.png" /><figcaption>Fig. 4. Delay as observed between existing proposed and proposed congestion control scheme in video streaming</figcaption></figure>

5.3 Jitter

Cumulative jitter values were also observed. The proposed scheme observed the improvement of jitter values, where by low cumulative jitter value were observed when the proposed congestion control scheme is used as compared to existing work by [16]. The proposed congestion control scheme performed well as all observed jitter for video frames was below 150ms (fig.5.)
<figure><img src="image_7.png" /><figcaption>Fig. 5. Jitter as observed between existing proposed and proposed congestion control scheme in video streaming</figcaption></figure>

5.4 PSNR value and MOS value

The video quality was measured by means of Peak Signal Noise Ratio (PSNR) and Mean Opinion Score (MOS). The Evalvid evaluation tool uses full reference quality evaluation method. Where by original video is compared to video constructed after being transmitted over the communication channel frame by frame. There is observed improvement in PNSR value, where by the existing work observed an average of 31.25 db whereas the proposed scheme observed an average PSNR value of 34.49 db. Fig.6. shows psnr values obtained for 2000 frames.
<figure><img src="image_8.png" /><figcaption>**Fig. 6.** PSNR as observed between existing proposed and proposed congestion control scheme in video streaming</figcaption></figure>

MOS measures how human perceive quality of video. It is calculated using a combination of number of lost packets in percent, the average delay, average jitter and R-value which is expresses the subjective quality of connection. MOS value ranges from 1 to 5, 1 being worse and 5 excellent. The observed average MOS by the proposed work is 3.98 as oppose to 3.15 which was observed by [16].

<figure><img src="image_9.png" /><figcaption>**Fig. 7.** Average MOS as observed between existing proposed and proposed congestion control scheme in video streaming</figcaption></figure>
# 6 CONCLUSION

This paper has presented a new rate adaptive congestion control scheme which uses lookup table to regulate packet sending rate at the sender by using QoS values obtained from the RTCP receiver reports. From these results, it is observed that there is improvement of delay and jitter value experienced by the frame during the transmission of video over the Internet. The improvement in delay and jitter also lead to the improvement of the QoE as it was witnessed in the delay PSNR and MOS values. The proposed scheme has indication of good performance but has limitation as it only focused on unicast wired network. Further research will be performed using the scheme for wireless networks as well as implementing it on multicast applications.

# 7 REFERENCES

[1] D. Solomon and G. Motta, *Handbook of Data Compression*, 5th Edition. Springer-Verlag London Limited, 2010.

[2] G. Carlucci, L. De Cicco, S. Holmer, S. Mascolo, and S. Member, "Congestion Control for Web Real-Time Communication," *IEEE/ACM TRANSACTIONS Netw.*, pp. 1–14, 2017.

[3] P. Bari, S. Holmer, and P. Bari, "Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)," 2016.

[4] Z. Li and M. S. Drew, *Fundamentals of Multimedia*, Second Edi. Springer International Publishing Switzerland, 2014.

[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "Real Time Transport Protocol," *Internet Standard*, 2003. [Online]. Available: https://tools.ietf.org/html/rfc3550. [Accessed: 10-Oct-2018].

[6] R. Stankiewicz and A. Jajszczyk, "A survey of QoE assurance in converged networks," *Comput. Networks*, vol. 55, no. 7, pp. 1459–1473, 2011.

[7] K. J. Ma and R. Bartoł, "Journal of Network and Computer Applications A survey of schemes for Internet-based video delivery," vol. 34, pp. 1572–1586, 2011.

[8] E. Chandra and B. Subramani, "A Survey on Congestion Control," *Glob. J. Comput. Sci. Technol.*, vol. 9, no. 5, pp. 82–87, 2010.

[9] A. Afanasyev, N. Tilley, P. Reiher, and L. Kleinrock, "Host-to-Host Congestion Control for TCP," *IEEE Commun. Surv. Tutorials*, vol. 12, no. 3, pp. 304–342, 2010.

[10] B. A. Forouzan, *Data Communications and Networking*, Fifth Edit. McGraw-
Hill Companies, Inc. New York, United States of America, 2013.

[11] N. Yuvaraju B and N. Chiplunkar, "Second International Conference on Computer and Network Technology PICCO: PROTOCOL INDEPENDENT CONGESTION CONTROL METHOD USING MOBILE RELAYS FOR AD-HOC NETWORKS," pp. 93–97, 2010.

[12] R. Adams, "Active Queue Management: A Survey," *IEEE Commun. Surv. Tutorials*, vol. 15, no. 3, pp. 1425–1476, 2013.

[13] P. Papadimitriou and V. Tsaoussidis, "SSVP: A congestion control scheme for real-time video streaming," vol. 51, pp. 4377–4395, 2007.

[14] L. Wang, "Research on Resource Service of Multimedia Network," *2011 International Symposium on Computer Science and Society*, pp. 4–6, 2011.

[15] Y. Jun and S. Lei, "Research on Adaptive Transmission Mechanism of Video Data," in *2015 International Conference on Computational Intelligence and Communication Networks Research*, 2015, pp. 570–573.

[16] K. L. Ferguson, "RRB-SIMD: RTP Rate-Based SIMD Protocol for Media Streaming Applications over the Internet," in *2011 Ninth Annual Communication Networks and Services Research Conference*, 2011.

[17] Institute of Telecommunication Systems, "MPG-4 and H.263 Video Traces for Network Performance Evaluation." [Online]. Available: http://www2.tkn.tu-berlin.de/research/trace/trace.html. [Accessed: 10-Oct-2018].

[18] "FFmpeg." [Online]. Available: https://www.ffmpeg.org/. [Accessed: 15-Jan-2019].

[19] J. Klaue, "Evalvid -A video Quality Evaluation Tool." [Online]. Available: http://www2.tkn.tu-berlin.de/research/evalvid/fw.html#bin. [Accessed: 05-Jan-2019].