Redirection and Protocol Mechanisms in Content Delivery Network-Edge Servers for Adaptive Video Streaming

Abstract

Redirection and protocol techniques are key components of the infrastructure for Content Delivery Networks (CDNs) that aid in the delivery of Multimedia Internet services to end-consumers. Redirection methods are used to route the user’s request to the nearest edge server, minimizing distance, improving delivery times, and lowering latency. Protocol mechanisms, such as HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), and Real-Time Messaging Protocol (RTMP), are used to deliver adaptive video streaming. These protocols are designed to transfer the adaptive streaming and provide high-quality video playback. They also allow the system to adjust the video quality based on the network conditions of the Quality of Service (QoS). Inadequate transmission protocols and poorly designed redirection algorithms are two major challenges that might degrade Cloud–CDN performance. These challenges lead to excessive latency, poor quality of service, and significant packet loss that have potential influences on the user experience. In this paper, firstly, three protocols are proposed by preparing a case study on selecting the optimal protocol for replicating adaptive video streaming content. Secondly, a redirection algorithm based on the Modified Cuckoo Search Algorithm (MCSA) is proposed to provide an accurate redirecting process of selected edge servers to end-users. Test results indicate that, when hybrid FASP/HTTP protocols were chosen (from original server to replicate server and to end-users), the delivery of adaptive video streaming segments was fast with lower latency. The average estimated time needed for replicating video content based on FASP is 25% better than that needed for File catalyst and Signiant protocols. Therefore, the Cuckoo search method presents more efficient results for selecting the optimal edge server for 100 servers, which is 0.296 s, compared to the conventional algorithm, which was 13 s.

1. Introduction

Large-scale distributed edge servers are strategically placed in numerous places that are known as Content Delivery/Distribution Networks (CDNs). Both CDN and cloud computing are designed to improve the performance and scalability of web-based services. However, CDN focuses on content delivery, while cloud computing focuses on providing a wide range of computing resources over the internet. CDNs provide services that improve data transfer by boosting bandwidth and lowering access latency [1]. Distribution of object copies, request-routing mechanism, and content delivery to end-users make up a CDN’s infrastructure. A CDN’s goal is to serve content to end-users with high availability and performance. CDNs are used to distribute content such as web pages, video, audio, and software downloads [2]. They work by replicating content to multiple servers and then directing users to the server that is closest to them, reducing the time it takes for the content to be delivered. This improves the user experience while reducing the load on the original content server [3].

Furthermore, a significant amount of downstream Internet traffic is being produced by the highly successful deployment of Over-The-Top (OTT) services and CDNs for multimedia streaming applications. In addition, video usage increased by 24% in 2022, accounting for 65% of all internet traffic. For the first time, Netflix surpassed YouTube as the individual application generating the most traffic, with TikTok, Disney+, and Hulu [4]. However, according to its analysis of current usage data from over 177 service providers worldwide, Facebook, Amazon, Google, Apple, Netflix, and Microsoft continue to generate nearly half of all internet traffic, with Google and Netflix accounting for the highest volumes [5].

1.1. Research Contributions

In this paper, three contributions have been provided to develop more efficient and effective solutions:

• For proposing hybrid protocols by preparing a case study on selecting optimal protocols for replicating adaptive video streaming content over the edge networks’ servers, it is important to consider the following factors: The network topology of the edge servers is a crucial factor in determining which protocol is the most suitable. For example, if the edge servers are located in different geographical regions, a protocol that can handle large distances and network congestion would be more appropriate. The protocol chosen should be able to handle adaptive streaming and provide high-quality video playback. The chosen protocol should be able to reduce latency as much as possible. The protocol should be able to efficiently use the available bandwidth to deliver video content to users. A thorough evaluation and testing of each protocol in the edge network environment are necessary to determine the optimal protocol.
• A redirection algorithm based on Cuckoo search can be proposed to provide an accurate redirecting process of selected edge servers to end-users. The basic idea behind this algorithm is to use the Cuckoo search optimization technique to determine the optimal location of the edge servers that will provide the best performance for the end-users. The Cuckoo search algorithm can be used to find the optimal solution by mimicking the behavior of cuckoos in the natural world. In this algorithm, the edge servers are seen as cuckoos and the optimal location of the edge servers is seen as the best nest. The algorithm uses a combination of random walk and Levy flight, which is inspired by the random searching behavior of cuckoos, to explore the solution space and find the optimal location of the edge servers.
• The applied protocols mechanism and redirection algorithm can further improve the service of QoE for adaptive video streaming.

1.2. Background and Literature Review

In the following sections, an intensive survey has been made for Cloud–CDN’s protocols, mechanisms, and redirection algorithms for adaptive video streaming.

1.2.1. Adaptive Video Streaming and CDN

Every day, millions of videos are uploaded to the Internet. End-users from all around the world commonly request to watch a substantial chunk of these video files [6]. Adaptive video streaming is a method of delivering video material over the internet that modifies the video quality in real-time dependent on the viewer’s internet connection and device capabilities. This ensures a seamless and uninterrupted viewing experience, even on devices with limited internet or computing capacity. HTTP Live Streaming (HLS), Common Media Application Format (CMAF), Microsoft Smooth Streaming (MSS), Dynamic Adaptive Streaming over HTTP (DASH), and Adobe HTTP Dynamic Streaming (HDS) are common adaptive bitrate streaming methods. These protocols function by dividing the video into small pieces and encoding it at multiple bitrates, leaving the player to switch between them dependent on network circumstances [7,8,9]. CDNs can be utilized in conjunction with adaptive video streaming to guarantee that video equipment is delivered fast and efficiently to the users. The CDN can handle the distribution of video files to multiple locations, while the adaptive streaming technology can adjust the quality of the video on the fly. In recent years, there have been several issues that can arise with cloud-based content delivery networks that can impact the delivery of content to users. CDNs rely on a large number of servers to distribute content. Moreover, CDNs use caching to store frequently accessed content on servers closer to the user. Based on the user’s location, the CDN system routes users to the nearest server referred to as a Point of Presence (PoP). This is accomplished using a technique known as “geographic routing”, which compares the user’s IP address to the closest PoP and the system directs the user to the closest server for content delivery. As a result, the user experience is enhanced and latency is decreased [10]. In CDNs, a Cache Server temporarily stores frequently accessed content. A Proxy Server acts as an intermediary between the end-user and the origin server, forwarding requests from the end-user to the origin server and returning the responses back to the end-user. The cache server decides which data to preserve in its cache and which data to delete when its memory is full using a variety of methods, including Least Recently Used (LRU), Most Recently Used (MRU), and Least Frequently Used (LFU) [11,12].

1.2.2. Content Replication Based on Push Protocols

Content replication refers to the duplication of data or content to multiple locations to ensure its availability and consistency. In CDNs, to replicate the content over edge servers, two important protocols are considered: UDP (User Datagram Protocol) is a quick, erratic, and unordered method of data transport, whereas TCP (Transmission Control Protocol) is dependable and ordered. Where speed is important and delivery order is not essential, such as in live streaming, UDP may be utilized for video equipment. TCP, on the other hand, is more appropriate for video equipment where dependability is crucial, such as video on demand. The choice between TCP and UDP for video content delivery depends on the specific requirements of the application and the trade-off between reliability and speed. Therefore, different protocol-based application layers to push segmentation of adaptive video streaming in CDN infrastructure are proposed [13]. Their purpose was to reduce resource usage of CDN components. The optimal push protocol is selected to reduce the overhead of surrogate servers and reduce usage of the network resources. Allan et al. [14] investigated the mechanism of Server Push by employing QUIC as a primary transport protocol for multicast-assisted adaptive bitrate streaming. The proposed approach gave a significant solution that reduced the amount of established video streaming sessions and reduced the wastage of network bandwidth.

Brian et al. [15] discussed the advantage of HTTP/2, which is a popular protocol that provides several improvements over its predecessor HTTP/1.1 such as multiplexing, server push, and header compression. They designed three modular HTTP/2 server push-based strategies leveraging Multipath TCP to improve the delivery of video content in lossy environments. Their goal is to improve start-up delays and overall performance. The combination of HTTP/2 and MPTCP can provide a powerful and flexible architecture for adaptive bitrate video delivery, enabling high-quality video playback even in challenging network conditions.

Arvin et al. [16] compared application layer protocols for video transmission. They take advantage of WebSocket to support adaptive bitrate streaming, where the server can send different qualities of the video stream based on the client’s available bandwidth. One potential challenge with WebSockets over a CDN is the need to ensure that the WebSocket connection is established and maintained across all CDN edge locations. However, modern CDNs provide sophisticated WebSocket routing and load balancing mechanisms, enabling WebSocket connections to be efficiently and reliably established across the CDN. Server-Sent Events (SSE) [17] over a CDN can provide a powerful and efficient solution for real-time content delivery, enabling fast and responsive updates to be delivered to clients, regardless of their location or available bandwidth. Data transmission between original server and edge servers based on strategy protocols are summarized in

Table 1. Server’s push comparison.

Feature	HTTP/2 Server Push	WebSockets	QUIC	Server-Sent Events (SSE)
Connection Type	Unidirectional	Bidirectional	Bidirectional	Unidirectional
Connection Establishment	TCP connection	TCP connection	UDP connection	TCP connection
Data Transfer	Pushed resources	Real-time updates	Real-time updates	Real-time updates
Multiple Resources	Yes	No	Yes	No
Browser Compatibility	Widely supported	Widely supported	Limited support	Widely supported
Server Compatibility	Requires HTTP/2 server	Requires server-side WebSocket support	Requires QUIC-enabled server	Requires SSE server support
Performance	Faster than HTTP/1.1	Low latency, low overhead	Low latency, reduced round trips	Low overhead, reduced latency
Use Cases	Static resources, application resources	Real-time applications, gaming, chat	Streaming media, real-time applications	Real-time updates, news feeds, stock tickers

[13,14,15,16,17].

1.2.3. Redirection Algorithm

A redirection algorithm in Cloud–CDN is a set of instructions that determine how to redirect a client’s request in a network to one of the selective edge servers. Analysis of CDN performance related to the redirection mechanism was studied by Sitorus et al. [18]. Several algorithms were used, including the Geographical algorithm Domain Name Server (GeoDNS), Round Robin (RR), Weighted Round Robin (WRR), and Least Connection (LC). The study aimed to evaluate the performance of these algorithms in terms of response time and load balancing. The results of the study showed that the GeoDNS algorithm performed the best in terms of response time, and in terms of load balancing, the WRR algorithm performed the best. However, the choice of algorithm may depend on the specific needs of a particular application or network.

Ran et al. [19] focused on the key issue of server selection. Therefore, the selection process is one of the key technologies in distributed systems, including CDN, Mobile CDN, and Cloud Computing. The server selection mechanism is designed to support user mobility and maximize user-perceived service quality. The results show that the delay in the packets has been reduced and the quality of the video streaming service has improved. This proposal provided efficiency and scalability for the mobile CDN system.

Taleni et al. [20] discussed the guarantee of QoE for video streaming on the cloud. To ensure quality of experience, video streaming over the Internet requires a high bandwidth. However, the Internet does not guarantee latency and packet loss. They integrated Load Balancing Routing Protocol (LBRP) as an adaptive routing protocol for SDN-Based Clouds, which is to enhance the user experience of video streaming. The protocol achieves routing by taking into account various parameters, including link capacity and re-routing non-real-time traffic towards under-utilized links. LBRP is able to optimize the distribution of network bandwidth, improving the throughput and reducing the delay of the video stream.

The proliferation of CDN services has made it challenging to manage basic network resources effectively. Yijing et al. [21] proposed a machine learning-based approach, which provides an effective solution for detecting CDN domain names and acceleration nodes accurately. The method leverages the basic principles and workflow of CDN and considers multiple features and attributes of CDN services. The proposed approach is essential for ensuring the security and reliability of the network and enabling effective resource management.

Boubakr et al. [22] discusses Information-Centric Networking (ICN) as a potential design for the future internet, which uses content names instead of host addresses, decouples content from its original location, and enables in-network caching. The authors suggested a distributed architecture and a hybrid cache concept. By moving the most popular content to the network’s perimeter and maintaining the least popular content in the center, the suggested strategy attempts to choose the best location for that content in the content store. The results show that the proposed mechanism outperforms the existing mechanism according to efficiency.

Based on the gap that has been detected in this section, a hybrid protocol for broadcasting video content and the efficient redirection process based on the Modified Cuckoo Search Algorithm (MCSA) is proposed, which overcomes the above-mentioned issues. The main motivation of this research is to select an optimal edge server for the end-users’ request (i.e., reduce waiting time) and minimize resource usage by deploying the videos across the edge servers to the corresponding client’s request in an efficient way.

The remaining sections of this paper are structured as follows: Details of the suggested protocols and proposed redirection algorithm are described in Section 2. In Section 3, the experimental results are depicted. The results, discussion, and comparison of the findings are explained in Section 4, and Section 5 concludes the main outcomes and provides recommendations for future investigation.

2. Research Methodology

This section describes the fundamental components of the Cloud–CDN system and mechanisms. The CDN mechanisms are original server protocols for video content distribution across edge servers and the redirection algorithm, which routes the end-users to the closest edge server. We also explain the problem statement and the solution of the proposed cloud–CDN system.

2.1. Problem Statement

CDNs are designed to overcome the limitations of traditional networks, and provide better Internet service to end-users by improving availability, performance, and security while reducing latency and costs [23]. Moreover, some common issues can be encountered in the infrastructure of CDNs regarding resource usage of networks. The inadequate transmission protocol that is used to replicate a copy of video content on edge servers plays a crucial role in the performance of the CDN. This can lead to some issues such as high latency, poor quality of service, and high packet loss, which can negatively impact the user experience [24]. An inaccurately designed algorithm for redirecting the end-user’s request to the appropriate edge server has a significant effect on the performance of the CDN [25].

2.2. Problem Solutions

Researchers have recently focused on solving the aforementioned issues. Different protocols to quickly deploy the adaptive video streaming segments onto surrogate servers are proposed. The WebDAV protocol has been selected as an optimal protocol to replicate the video contents. This is due to its ability to efficiently transfer small segments of DASH [13]. Moreover, Quick UDP Internet Connections (QUIC) is employed as the principal transport protocol for low-latency streaming protocols in IP multicast topologies. It makes use of mABR streaming and HTTP/3 server push methods to boost scalability and minimize the number of open streaming sessions, thus conserving bandwidth [14]. Although the redirection mechanism has been considered by [26], they aimed to provide an algorithm based on the qualitative and quantitative characteristics of different sources for selecting the most suitable alternative edge server. PROMETHEE is one of the most extensively utilized strategies in this respect. A transparent redirection mechanism for CDN surrogate servers is proposed in [27], where the TCP session handoff mechanism is considered as a transparent redirection.

2.3. General System

The proposed system is a distributed computing system that involves multiple components to support the delivery of services to end-users. The proposed system’s components are original servers, edge computing servers, network connection mode, and end-users, as presented in Figure 1.

2.3.1. Server Distribution Mechanism

An original server, also known as a content service provider, is a server that contains the original copy of a website or web application’s content, such as HTML, images, videos, and other media. When a user requests a resource from a website, the request is sent to the original server, which in turn will respond according to the requested resource. The original server is a physical server or it can be a virtual machine hosted in a data center or cloud environment. It is responsible for generating dynamic content, processing user input, and handling back-end logic. The original server in this work can also be used as a central storage for multimedia content that is accessed and shared by multiple users. These multimedia files are stored in databases, file systems, or other types of storage.

In a server provider, to distribute the multimedia content (video and audio), we need a distribution protocol (server push mechanism) to replicate these contents to the optimal edge servers. Therefore, according to the investigations that have been done in Section 2, FASP [28], File Catalyst protocol (FCP) [29], and Signiant [30] have been tested as distribution protocols to select the optimal and most efficient protocol. These protocols must be configured to transmit an adaptive video streaming from the original to the edge server. The CDN system adopts these protocols to duplicate the segmentation of adaptive video streaming.

2.3.2. Edge Servers

The edge servers are located at the edge of the network. The benefit of the edge server is being close to the end-users, reducing latency and improving performance. They are typically used to cache content and deliver it to users without having to fetch videos from a more distant server. The configuration of edge servers can vary depending on the specific requirements for a particular application or service. The edge servers have been configured according to two mechanisms. In the first mechanism, a copy of the video is to be stored and each edge server is aware of the availability of the video content over the other servers by considering the synchronization mechanism. In the second mechanism, these edge servers will take the responsibility of replying to the client’s request with the requested video content. These servers have also been configured to listen to the broadcast of FASP, File Catalyst protocol, and Signiant protocols from the original servers.

2.3.3. Network Connection and Quality of Service (QoS)

There are various techniques that have been used to manage network traffic and prioritize certain types of data, which ensure that the critical applications receive the necessary resources and network bandwidth for optimal performance. QoS is important in networks where different types of traffic, such as voice, video, and data, are competing for limited network resources. Furthermore, QoS can be implemented at various levels of the network, including network connection levels, and cellular and wireless networks. QoS for network connections typically involves configuring network devices, routers, switches, and firewalls. They prioritize certain types of traffic based on their characteristics, such as the type of application, the size of the data packets, and the source and including destination addresses. Consequently, QoS can help to ensure that critical applications receive the necessary network bandwidth and resources for optimal performance, while minimizing delays, packet loss, and other network issues.

2.3.4. End-Users

End-users are users that receive services from original servers and edge servers. On the client-side, end-users typically interact with the user interface of the service or application, and their satisfaction with the performance, usability, and functionality of the service can greatly impact their overall experience. This is why network service and application providers often focus on optimizing their offerings to meet the needs and expectations of end-users.

2.4. Content Transfer Protocols

The adapted methodology for this case study was started by investigating the recent protocols that are recommended for this system. It was found that there was an issue regarding the arrival time, which included the delay of video streaming segments. Therefore, depending on the investigation results, three protocols have been proposed to solve this delay issue. These protocols are FASP, File Catalyst protocol (FCP), and Signiant. They are considered as the most adequate protocols for delivering adaptive video streaming segments. These protocols have been selected based on delay time (protocols with a minimum arrival time). In Figure 2, the proposed protocols between the original and edge servers in a cloud–CDN are described.

2.4.1. FASP (Fast and Secure Protocol)

FASP is a file transfer protocol that is designed to facilitate high-speed, reliable, and secure data transfers over wide area networks (WANs). It is commonly used in industries that require large-scale data transfer, such as media and entertainment, healthcare, scientific research, and government agencies. FASP is available as a standalone software application, called Aspera Connect, which allows users to transfer files using the FASP protocol. It is also available as a plugin for popular file transfer tools such as FTP and SCP, which allows users to seamlessly integrate FASP into their existing workflows. FASP achieves high transfer speeds by optimizing network bandwidth utilization and minimizing latency. It achieves security by using encryption to protect data in transit and authentication to ensure that only authorized users can access the data. Overall, FASP has become a popular choice for organizations that need to transfer large amounts of data quickly and securely over long distances, and it has helped to overcome some of the limitations of traditional file transfer protocols such as FTP and SCP.

2.4.2. FCP (File Catalyst Protocol)

FCP is designed to enable high-speed file transfer over IP networks, especially for large files and data sets. Unlike TCP-based protocols, FCP is a UDP-based protocol that operates in parallel with other network traffic. This allows it to achieve high transfer rates, while minimizing network latency and avoiding congestion. It also includes various features to ensure reliability and security of file transfers, such as error detection and correction, packet-level resends, and encryption. FCP is optimized for high-speed data transfer, and it operates in parallel with other network traffic, which allows it to maximize bandwidth utilization and minimize network latency and congestion. FCP uses a combination of techniques to optimize transfer speeds, including parallel packet transmission, dynamic congestion control, and adaptive packet sizing.

2.4.3. Signiant

Signiant is a high-speed data transfer protocol designed for securely transferring large files and data sets over long distances. It uses patented acceleration technology to optimize transfer speeds, regardless of network conditions, while maintaining security and reliability. Overall, Signiant is a powerful and flexible data transfer protocol that is well-suited for large-scale, high-speed transfers over long distances. Its combination of speed, security, and reliability features make it a popular choice for a variety of industries and applications, including media and entertainment, healthcare, scientific research, and government agencies.

2.5. Redirection Algorithm

Adaptive routing algorithms make decisions based on real-time information about the state of the network and servers, which means they can choose the optimal replica server at any given moment. However, this also means that adaptive algorithms require more bandwidth and computational resources to continuously monitor and exchange information about the state of the network and servers. On the other hand, non-adaptive routing algorithms do not consider the current state of the network and servers when making routing decisions. Instead, they use a predetermined set of rules or metrics to select a replica server. Non-adaptive algorithms are less complex and do not require real-time monitoring of network and server states, which means they consume less bandwidth and computational resources. The choice between adaptive and non-adaptive routing algorithms depends on the specific requirements of the system, such as the desired level of performance, scalability, and fault tolerance. In general, adaptive algorithms are better suited for systems that require high performance and scalability, while non-adaptive algorithms are more suitable for simple, low-resource systems or applications that are not highly sensitive to performance.

In this work, an adaptive algorithm to select the optimal replica server is proposed based on modified CSA. The Cuckoo Search (CS) algorithm is considered as an efficient swarm-intelligence-based algorithm [31].

The mathematical model of the modified cuckoo search algorithm is explained as follows:

Let f(X) be the objective function to be optimized, where X_i = (x1, x2, …, xn) represents the solution or position in the search space, and n is the dimensionality of the problem.

Generate an initial population of cuckoo search algorithm with random positions X = (x1, x2, …, xn) within the defined search space. Evaluate the fitness of each cuckoo in the population using the objective function f(X).

For each cuckoo, update its position X by performing a Lévy flight, which is a random walk with a heavy-tailed distribution. The new position X′ is given by:

X′ = X + Lévy(λ) ∗ (X − Xbest)

(1)

where Lévy(λ) is a random number drawn from a Lévy distribution with parameter λ, Xbest is the position of the best cuckoo in the population, and ∗ denotes element-wise multiplication [32,33].

Our modification is based on many parameters of the testbed such as (Throughput, CPU usage, Memory consumption, QoS (delay, jitter, packet lost)). To be adaptively rout for an optimal edge server, some thresholds have been used to minimize the response time using CSA. First of all, we put a condition with a maximum throughput to retrieve all servers that is greater than 95%. Then, another condition has been made by minimizing CPU usage less than to 60%. Finally, we have taken into account the memory consumption by selecting those edge servers that have memory consumption of less than 40%. The modified pseudo code of CSA is written in Algorithm 1.

Algorithm 1. Modified Cuckoo Search Algorithm

1: Objective function f(X), X= (f(x1, x2, …, xd)T 2: Generate initial population of n host nests Xi           (i = l, 2, …, n) 3: While t < Max iterations do 4:          Get a cuckoo randomly by Levy flights 5:          Evaluate its quality/fitness Fi 6:          Choose a nest among n (say, j)                            randomly 7:          If Fi > Fj then 8:              Replace j by the new solution; 9:          End If 10:      Get (max_Throughput, min_cpu, min_memory) 11:      If max_Throughput [i] > 95 then 12:            max_Throughput [j] = max_Throughput [i] 13:      Else If min_cpu [i] < 60 then 14:            min_cpu [j] = min_cpu [i] 15:      Else If min_memory [i] < 40 16:            min_memory [j] = min_memory [i] 17:      End If 18:      Keep the best solutions

The general flowchart of the proposed adaptive video streaming system based on MCSA is presented in Figure 3. First, all input parameters are initialized in the virtual CDN Linux-based platform, such as the number of servers, routers, and clients. Then, the optimal protocol is chosen to transmit video content to the edge servers from the original server. To select the optimal edge server, the MCSA is performed based on some conditions. Finally, with critical QoS parameters, the client’s request is redirected to a select optimal edge server as shown in Figure 4.

3. Experimental Results

This section describes the implementation process of the proposed mechanisms in the CDN scenario; the testbed implementation has been taken from [13]. It includes two subsections: a selective hybrid protocol and optimal redirection bases on the Modified Cuckoo Search Algorithm.

3.1. Optimal Push-Protocol Selection

In this study, the hybrid protocol includes one of the selective distribution content protocols that delivers video content to end-users from the original server to the edge server. In a selective hybrid protocol, the sender first establishes a connection with the edge server using a connection-oriented protocol, such as the File Catalyst, Signiant, and FASP. Once the video content arrives to the edge server, the receiver can establish connection with one of the closest edge servers through HTTP. This allows an efficient transfer of data while maintaining the reliability of a connection-oriented protocol.

An experiment was conducted for one minute of video [34,35]. This video is segmented according to MP4Box [36] for a segment length equal to 2 s; the details of the parameters of the experimental process are explained in

Table 2. Experimental process parameters.

Parameter	Value
Video size	270 MB
Streaming time	60 s
Total number of clips	2
Channel used	Wi-Fi and Wire Connection
Channel bandwidth	Shaped to varied Mbps
Packet size	1500 bytes (MTU)

. The arrival time is calculated based on a timer from sending the video segment data until received by the edge server. In Figure 5, the arrival time versus packet loss is depicted for the File Catalyst, Signiant, and FASP protocols. The impact of packet loss is considerably observed in the File Catalyst and Signiant protocols due to many retransmissions of the video packets.

The same test has been conducted for different segment sizes; in this experiment, each segment size has chunked into 10 MB. Figure 6 shows that the FASP recorded better results than the File Catalyst and Signiant. Moreover, the File Catalyst resulted in less delay in transmitting large segments than the Signiant.

Another test has experimented with 30 video segments with a duration of 2 s per segment that have been sent to monitor the maximum throughput usage of the used protocols (File Catalyst, Signiant, and FASP). A significant variation can be observed in the throughput of the protocols when transmission time is affected by packet loss of 5%. For the File Catalyst protocol, a remarkable delay of the arrived segments has been observed as there were many packets lost. This leads to longer transmission duration as shown in Figure 7.

While retransmission can help mitigate the effects of packet loss, it can also introduce additional delays and network traffic, as packets are re-sent multiple times. Consequently, it is important to make balance between reliability and performance when implementing retransmission in a network. Figure 8 demonstrates the retransmission number of packets when segments are sent over the network to edge server.

3.2. Cuckoo Search Algorithm Based Optimal Edge Server Redirection

In this test, we performed a simulated network based on a virtualized network over Linux. This simulation is configured using python script to generate 100 edge servers, which presents the CDN. In

Table 3. Proposed Testbed simulation results.

Edge Server	CPU Usage	Memory Usage	Connected Users	RoutesNumber	Throughput	Delay	Packet Loss	Jitter
1	62	72	4	3	97	2.656	5.55904	0.203345
2	87	76	35	1	92	1.583	7.04032	2.6157047
3	94	53	14	2	93	2.131	1.68278	0.8825650
4	67	76	54	3	92	3.465	9.92742	0.7340152
5	87	51	71	2	99	2.636	0.41238	2.3412498
6	80	46	25	3	96	2.305	8.50534	1.7710537
7	71	71	92	3	96	0.626	6.82522	3.7686835
8	67	58	7	2	92	1.770	1.95282	1.0805983
9	88	44	33	3	94	3.156	5.61545	1.3142494
10	88	72	21	3	95	2.672	0.40681	1.7904575
11	79	58	51	3	94	5.163	5.02267	1.1969529
12	58	66	91	1	95	2.019	1.19856	0.7944980
13	86	38	69	1	93	3.677	1.91542	3.4175009
14	50	77	77	3	90	1.064	4.72987	2.1251593
15	55	75	40	2	91	1.886	1.02411	3.3074925
16	64	56	96	1	99	5.124	0.04153	0.7678096
17	85	32	24	3	95	2.356	1.74254	1.6210663
18	63	74	16	1	95	0.738	2.77767	1.0086972
19	67	76	32	3	90	2.719	0.41380	0.2929830
20	86	56	59	2	96	5.386	0.38923	1.2865177
21	72	77	53	2	98	2.293	7.43302	0.5658469
22	71	66	0	1	92	3.923	6.42011	0.7887767
23	85	70	81	3	92	3.178	4.84003	0.9049112
24	90	56	91	2	92	0.496	7.25845	0.9695515
25	65	77	54	1	98	3.210	9.74832	1.3263711
26	68	67	53	1	93	2.936	2.00207	0.6449393
27	69	59	41	3	92	5.241	9.91450	4.5584150
28	53	74	98	1	92	2.225	5.59221	0.8731677
29	94	76	76	1	95	3.547	7.49273	0.7943601
30	71	48	43	3	93	5.543	9.72444	0.7880591
31	45	67	79	2	97	4.983	4.78968	0.9317921
32	61	34	0	1	99	3.951	2.09689	2.2209607
33	95	61	3	1	92	1.471	9.95664	2.6814748
34	59	43	77	3	97	1.185	5.76176	2.0959199
35	94	57	80	1	95	4.097	8.46127	0.4377711
36	55	35	77	3	98	3.050	2.04565	0.5642432
37	79	52	39	1	96	0.940	6.43975	1.7110371
38	77	55	12	1	99	4.345	8.64923	2.2476081
39	49	58	3	3	90	1.459	0.70297	1.9571320
40	85	43	17	3	95	4.182	9.10534	3.9156667
41	54	30	100	3	99	1.562	5.85966	2.2277996
42	57	31	38	3	90	1.383	7.79804	0.6399891
43	61	40	57	3	92	0.169	1.41964	0.621365
44	95	50	10	3	94	4.521	8.38024	0.4518034
45	55	30	38	1	98	1.536	4.55761	3.0727309
46	58	74	55	1	94	5.432	7.89317	0.1484519
47	71	44	93	3	91	5.090	9.54736	3.9396016
48	56	49	13	2	92	5.114	0.23758	0.7929116
49	87	60	61	2	99	4.302	7.56559	3.6293776
50	76	72	11	3	93	1.994	4.94734	1.1073077
51	95	73	22	1	90	1.247	4.88104	2.8503866
52	80	61	36	3	94	2.839	5.09008	0.4079483
53	54	42	61	2	98	5.828	9.78237	2.9530578
54	50	77	69	1	96	1.023	9.43731	2.8074353
55	68	34	73	3	89	3.606	4.18095	2.7206562
56	53	62	17	3	91	3.304	4.35364	1.7564632
57	51	71	92	1	96	2.048	5.14230	4.7477940
58	53	52	64	1	90	5.603	7.75086	0.7668703
59	95	26	45	1	94	5.113	0.34248	0.3609865
60	77	38	29	2	97	1.000	1.30531	0.8615625
61	83	76	47	3	89	0.566	1.78553	0.8100614
62	92	40	49	2	94	4.282	1.61013	2.9607700
63	56	50	88	3	93	0.918	4.88269	1.1687555
64	48	56	32	2	95	1.460	7.16725	0.2467752
65	51	45	69	3	89	1.382	3.55064	2.4037668
66	50	72	83	1	91	4.348	1.54139	0.8550973
67	69	58	39	2	91	5.163	4.94259	2.3305362
68	62	72	30	3	95	1.566	0.56683	4.0479767
69	56	58	11	1	90	2.740	0.24556	0.7166811
70	95	67	84	2	93	0.643	2.38984	2.7502833
71	85	32	31	3	97	3.064	3.26898	0.0149043
72	94	26	10	1	92	3.995	7.38077	2.2560714
73	62	68	60	1	97	2.695	2.52409	1.9707387
74	54	77	14	3	89	4.909	8.83199	6.6727779
75	90	75	67	3	94	3.446	7.68378	0.6288889
76	66	47	46	1	95	0.255	9.41012	0.4337908
77	79	65	99	3	99	0.402	7.53776	0.7917249
78	54	47	6	3	94	1.287	9.06339	3.3683369
79	87	77	0	2	92	3.834	0.01897	3.9577402
80	82	37	18	3	97	2.746	5.04830	6.4923354
81	48	70	4	2	98	5.877	5.54697	4.4193902
82	94	53	69	1	94	0.712	2.99590	4.8421968
83	79	65	66	1	90	4.759	1.92578	1.2787296
84	58	38	91	3	92	2.035	9.33461	0.4830292
85	87	59	60	2	98	1.000	0.32271	1.4024168
86	61	46	46	1	94	2.933	7.25489	0.6195066
87	74	33	25	1	93	2.196	9.27590	3.0574970
88	85	62	29	2	97	2.485	7.24906	1.1583382
89	69	50	13	1	99	4.468	9.64836	0.9202245
90	62	24	25	2	99	3.997	5.41173	2.7490257
91	77	76	88	2	90	2.229	0.98957	1.2524622
92	76	64	65	1	98	5.011	3.17172	0.3187478
93	85	27	32	3	90	4.639	5.05382	0.1886412
94	65	73	29	2	94	2.755	0.57919	4.6637723
95	76	45	11	2	89	0.791	4.63834	1.4766862
96	68	51	48	3	90	0.000	2.35439	0.0833337
97	77	46	71	3	92	2.839	6.59114	2.2687105
98	89	35	87	1	89	1.735	6.57669	3.1555948
99	63	49	87	1	95	2.106	4.25138	3.0403892
100	53	51	37	2	89	4.572	8.05649	2.2761992

, the server’s parameters (CPU usage, memory usage, and number of connected users) and network parameters (Throughput and QoS) are given.

Based on the testbed result information provided in Table 3, which includes CPU Usage, Memory Usage, Connected Users, Routes number, Throughput, Delay, Packet Loss, and Jitter, the testbed has been designed to optimize network performance by selecting minimum CPU and memory usage, maximizing network throughput, and reducing network latency and packet loss. The acceptable ranges for performance metrics such as CPU usage, memory usage, delay, packet loss, and jitter may vary depending on the system performance. By reducing CPU and memory usage, the testbed allocates more resources to network processing, which helps to improve the overall network performance. Select maximum network throughput can handle more data traffic and increase the speed at which video data are transmitted across the network. Overall, the goal of this testbed is to select the optimal edge server that provides the best performance for user experience video streaming.

To obtain selected optimal edge server using proposed MCSA, we calculated the efficiency for different edge server’s size, including (10 folds, 20 folds to 100 folds) as shown in Figure 9. A significant reduction of delay time is observed when the redirection algorithm is applied.

4. Results and Discussion

All push-based protocols are designed to deliver video segments to the client proactively, which means that the server sends the segments without waiting for the client to request them. Those protocols minimize the delay between the time the segment is available on the server and the time it is available to the client. All push-based protocols require the server to have knowledge of the client’s buffer state to avoid sending unnecessary segments.

The reason behind the selection of the FASP protocol is that it always uses the maximum throughput to transfer the network packets and makes the network condition stable with a minimum packet loss rate. As a result, no degradation occurs in transferred data bitrates as displayed in Figure 7 and Figure 8.

One advantage of the cuckoo search algorithm is that it does not require any gradient information or assumptions about the distribution of the objective function. This makes it suitable for optimizing complex, non-linear functions in high-dimensional search space. According to test results using MCSA, the average delay time was used to select an optimal edge server among other servers, which is quickly available for users and provides a high-quality video playback streamed video.

The delay time of push-based protocol is equal to 0.00015 s when the proposed algorithm is used for 10 servers while equal to 1.1 s for the conventional algorithm. Moreover, the average delay time for 100 servers is equal to 13 s and 0.296 s with and without MCSA, respectively, as illustrated in Figure 9.

5. Conclusions and Future Outlook

The aim of this research was to improve the performance of Cloud–CDNs for end-users and cloud users who stream video and download multimedia content over the internet. A modified CSA approach was used to select edge servers, ensuring that users could receive faster service by accessing the nearest neighbor server via the shortest path determined using the MCS algorithm. This approach led to a significant increase in network performance. Several protocols were evaluated in terms of speed, security, and scalability, with FASP found to work the fastest while preserving content quality to meet user requests and provide a good QoE. Another advantage of the proposed system is its ability to handle rising requests without server downtime, as the user’s request can select the optimal edge server. The proposed redirection algorithm based on MCSA showed a 25% reduction in the delay time in test results. For future work, the research plan to utilize other heuristic algorithms to optimize edge server selection for various scenarios. Additionally, deep learning techniques may be employed to reduce the delay of transmitted segments and enhance overall Cloud–CDN performance.