Evaluation of Differentiated Services Policies in Multihomed Networks Based on an Interface-Selection Mechanism

Abstract

Quality of service metrics and differentiated service mechanism policies are the most important criteria to deliver essential Internet requirements, especially during user handover, due to the rapid growth of users, multimedia applications, and traffic. DiffServ routers provide per-hop behaviors to manage traffic for services, whereas their policies have been applied to several types of Internet traffic, such as hypertext transfer protocol, file transfer protocol, and content-based routing. Multihoming aims to improve the reliability, scalability, and performance of data communications networks. This paper evaluated DiffServ various policies compared in a systematic manner (in two stages) over the multihomed networks to utilize and adopt the best policy for communicating packets, and enhanced the overall performance in terms of throughput, end-to-end latency, and processing time. Moreover, the paper introduced an interface-selection technique for multihomed nodes to select a proper interface, which provides the best services and links the behaviors that this interface yields. The overall results showed how the introduced multihoming-based interface-selection mechanism managed to maintain communication with the multihomed node. Furthermore, our results showed that the DiffServ time-sliding window with a three-color marking policy achieved the best system performance compared with the remaining policies.

1. Introduction

Nowadays, there is a notable, tremendous growth in service-demanding users and devices accompanying the next era of fully connected communication systems. Unprecedented infrastructure, technologies, and applications in the communications field bring new features into view, i.e., data-hungry streams and unified ubiquitous systems, generating huge traffic [1,2,3,4,5].

Recently [1,2,3,4,5], Internet use is rising in several aspects of our everyday activities; thus, mobile and Internet usage has increased with increasing demands from people that the Internet should adapt to the requirements of their lives. As a result, people are flocking to innovative requirements such as mobility, multihoming, and ubiquity. To this end, a number of devices are being considered using a wide range of strategies with the goal of giving the communication sector the necessary support for simultaneous Internet ubiquity. This requires integrating more than one technology (e.g., multihoming and multi-interface platforms) to meet the essential requirements. The network uses an alternative interface to reroute the flow when an issue with connectivity or network condition occurs. To better manage resources and make the most of their availability, it is important to adopt the best technologies, while simultaneously integrating diverse technologies. The network interfaces differ in terms of resources and expenses as well as performance and accessibility. When it comes to wireless communication systems, connected users could choose to suggest a number of the best interfaces from those that are currently available. The served gadget may select the best QoS-aware interface(s) to acquire the best resources. All of the new types of equipment on the market aim to converge all communication channels so that all of the gadgets can access the Internet. The huge amount of data and streams is challenging for Internet capacity, which needs to accommodate various users’ demands and applications [1]. This traffic must be handed over to system parties, e.g., networks/users, to process along with overcoming the limitations compelled by data-hungry applications. QoS mechanisms offer the necessary networking capabilities for effectively managing and controlling network resources. The management of resources improves the services needed for data-demanding services and the exponentially growing user base by balancing concurrent network demand rates with resource availability. Utilizing the trade-off between cost-effectiveness and the desired QoS for users, the IntServ model proposed an Internet protocol (IP) QoS architecture; here, the network streams follow and function independently to gain the required network resources, which allows the distribution of high-quality service for every route. A certain problem that persistently arises is scalability, which is the motivation for designing and implementing DiffServ [6,7,8,9,10,11]. DiffServ aggregates flows and allocates appropriate resources depending on the per-hop behavior (PHB) design (as PHB governs the forwarding behavior assigned to a code point) and on certain established QoS standards (e.g., performance, availability, scalability, and serviceability). DiffServ manages flow based on the marking results received from each node. Hence, PHB (i.e., the forwarding behavior assigned to a DSCP) plays an important role in decision making for the entire process. It defines the policy and priority (the forwarding precedence) applied to a packet when traversing a hop (e.g., routers) in DiffServ domain, and provides a specified amount of network resources to the marked packet in relation to other traffic on the Diffserv-aware system. Furthermore, the DiffServ mechanism was proposed to deliver Internet service providers (ISPs) with an effective platform in terms of handling users’ demands and managing available resources [11]. The network domain’s core forwards each packet based on its PHB and traffic, which are determined by the DiffServ code point (DSCP) of each packet. In this paper, we integrate the key-enabling technologies and evaluate DiffServ policies using QoS packet marking to deliver adequate network handling, achieving the utmost gains from the limited resources. This work considers the need to find a service that meets the acceptable computational and procedural complexities, energy consumption, and is cost-effective. It evaluates and compares various policies of DiffServ in a systematic manner (in two stages) over the multihomed networks to utilize and adopt the best policy for communicating packets. It also enhances the overall performance in terms of throughput, end-to-end latency, and processing time. Furthermore, it introduces the interface-selectivity technique for the multihomed node, enabling the node to select the proper interface that provides the best services and link behaviors that this interface yields. The conducted experiments also aimed to study the behavior of the introduced multihoming-based interface-selection mechanism towards maintaining communication with the multihomed node. In addition, the paper investigates the best system performance using the best marking policy for the prioritized packets. The major contributions of this paper are:

• The paper introduces a reliable system, supplying a sufficient solution for the associated end nodes (the mobile-service-demanding user serving equipment) during handovers.
• It presents a study of different DiffServ mechanism policies. It studied the effects of deploying each policy into various interfaces (the portals that connect nodes to the Internet network), and the increased overall network performance when nodes managed to switch between them (to acquire better performance necessarily) according to their availability.
• It studies the overall performance and feasibility of deploying several policies with the single-homed and multihomed networks/nodes (site and host multihoming) while the availability of resources was fluctuating. It compares the performance of the influential parameters.

The remainder of the paper is organized as follows: in Section 2, the multihoming, the quality of service (QoS), and DiffServ mechanisms were concisely explained. The QoS mechanisms we discussed thoroughly are based on communication performance enhancement with the principle of multihoming and condition-awareness, according to the availability of resources. We study the feasibility of integrating these strategies within the communication network to guarantee that the served users receive the best end-to-end QoS. Section 3 describes the system methodology. It explains the feasibility of multiple interfaces with multihoming and demonstrates how this strategy can increase the reliability of communication and improve the overall network performance. Section 4 includes the implementation setup and the results, exploring the performance of the multihomed network using a DiffServ mechanism with a different policy. Finally, Section 5 summarizes the conclusion.

2. Background

This section briefly introduces the multihoming network and the related differentiated service technologies.

2.1. Multihoming

Single-homing, in which the single-homed network employs one Internet service provider (ISP) to access all the targeted ends, was the initial method for gaining access to the Internet. Due to increased demand, the resource constraint makes end-to-end routes scarce. By providing the necessary services and enhancing the speed, stability, and performance of services to the nodes, the multihoming technique creates a dependable multipath system with superior performance [12]. The multihoming model (shown in Figure 1) is able to prevent connection failure, provide user accessibility, multihoming viability, and ISP choice. The performance of the communication networks can be improved by using multihoming in conjunction with mobile IP to obtain robust and scalable networking to achieve the necessary Internet ubiquity.

Users of several networks who use multiple ISPs, known as multihoming, demand a variety of services. The customer prioritizes the best ISP after comparing the services offered by several ISPs, regarding cost, security, and QoS. The use of numerous ISP connections by the end node to establish dependable Internet access is known as “multi-homing”, which is becoming more popular for networks and end nodes. The node will maintain its continuous Internet connection using another related Internet provider in the event of a connection failure or deficiency of the service provider. Additionally, this approach offers a load-balancing mechanism with the possibility of dividing traffic among the pool of available related ISP links. It is worth noticing that the multihoming technique provides the necessary mechanisms to select the optimal route whenever more than one route is available, as well as accompanying processes to provide alternate routes in the event of a connection failure by diverting traffic to an available connection [12]. Thus, establishing a solid connection and a flawless handover is crucial.

2.2. Differentiated Service (DiffServ)

DiffServ is a series of techniques that let ISPs offer diverse services to different kinds of clients and provides them with prioritized required traffic [12,13,14,15,16,17,18,19]. It is set up to offer a modular response to IP QoS objectives for a range of applications. The architecture of DiffServ specifies a scalable mechanism for classifying and managing network traffic. The service-categorization protocols on the Internet can be used and scaled for traffic streaming and marking of packets [20,21]. Here, we explain the architecture of DiffServ and its mechanisms.

2.2.1. DiffServ Architecture

A DiffServ domain is a group of DiffServ nodes that can deliver the same service and have PHBs on each of them [11]. There are two known DiffServ architecture classifications; one is based on the position of the nodes in the network and the second is based on traffic direction:

(1)

Node positions

There are two sorts of nodes in the network: boundary nodes (BN) at the edges of the domain edges and core nodes (CN) within the domain, as shown in Figure 2. The BNs link a DiffServ domain to another as well as to other non-DiffServ domains (N). Within the same DiffServ domain, the CN only links other CNs or BNs.

(2)

Traffic direction

Based on traffic direction, BNs serve as ingress and egress [22,23,24]. The ingress node ensures the compatibility of the incoming stream with the service-level specification (SLS) that exists between the ingress node and the other domains that are linked. The SLS can include expected throughput, delay, and limitations of points where the service is supplied, and shows the services’ scope, the traffic profiles that should provide the requested service, and the disposition of traffic submitted beyond the specified profile, marking, and shaping services provided [24].

2.2.2. DiffServ Mechanism

The mechanism of DiffServ categorizes packets and regulates traffic, which is conducted at the interior and frontier routers. It divides packets into classes and forwards them based on those classes specified within the header. Each forwarding class obtains resources by provision and priority [25]. This part discusses the key features of the DiffServ service agreement and DiffServ code point (DSCP):

(1)

DiffServ service agreement

By using a service-level agreement (SLA) [26,27], clients and ISPs have a confidential agreement. This contract is crucial in determining the services’ particular specifications provided to the clients. Moreover, DiffServ network supplies a specific type of service according to the packets QoS in a variety of ways, including the use of IP precedence bit settings in IP packets or source/destination addresses. According to the QoS specification, the network classifies and marks policy traffic, and performs intelligent queuing. DiffServ IP improvements intended to qualify scalable service discrimination to Internet services [11]. A wide range of various services may be built from a small and well-defined set of equipment deployed in network nodes. End-to-end or intra-domain services are available; they include services that can meet the required quantitative performance-based requirements (e.g., bandwidth (BW) and latency) or relative performance-based requirements (e.g., class recognition).

(2)

DiffServ Code Point

Figure 2 shows how the linked DiffServ domain connects the four different domains, one of which is the DiffServ domain. Based on the DiffServ code point definition in [17,24,26], DiffServ nodes (i.e., CNs and BNs) should provide a proper PHB to packets. When the capability of the CNs is limited (functionality shortage), BNs must instead perform traffic conditioning functionality. Every IP packet contains a short pattern of bits called a DiffServ code point (DSCP) [28]. The DSCP is specified in the IPv4 service type and the traffic class octet of IPv6. DiffServ field is a typical arrangement for the 6-bit field of these octets. The DSCP value is written as ‘xxxxxx’, with one ‘x’ being 0 or 1, whereas the default PHB is ‘000000’, which is required in each node; the queuing default behavior will be enacted when the connection becomes available.

The DSCP protocol can send 64 different code points: Pool 1, ‘xxxxx0’, which has 32 code points for activities; pool 2, ‘xxxx11’, which contains 16 code points; and pool 3, ‘xxxx01’, which contains 16 originally available code points [14]. To maintain backward compatibility with IP precedence, the minimum set of code points from pool one is assigned, and they map to certain PHBs. There is no other backward compatibility [29,30,31].

The per-hop behavior (PHB) is the external DiffServ node’s perceptible forward-behavior application to a specific DiffServ behavior aggregate (BA). The specified resources to a BA are defined by PHB, which is conducted through buffer management and packet scheduling. The PHB concept is based on behavior characteristics relevant to service policy rather than the provisioning mechanism [14].

To summarize, DiffServ design allows a wide range of services to be provided. Clients at DiffServ edges receive services as SLSs. The availability of consistent administration and configuring tools used for supplying and monitoring several routers is essential to providing services. DiffServ working group standardizes small-numbered PHBs, suggesting DSCPs for each of them. Existing PHBs will not be upgraded before more PHBs are standardized. The PHBs defined in the request for comments (RFC) 2474, 2597, and 2598 provide a comprehensive toolkit for handling differential packets [32].

3. Methodology

The performance of networks is interface-based, which requires various resources and consequent costs, as the users’ required QoS is related to cost-effectiveness. The interface performance changes based on the priority we set and on the preferable policy/services it delivers. In wireless communication networks, the associated users nominate the best available interfaces and their suitability according to specific conditions [33]. The node can adopt the best interface(s) to obtain the best network resources and support its QoS. There are six various DiffServ policies:

• Time-Sliding Window with two-Color Marking (TSW2CM): A committed information rate (CIR) is used as well as a two-drop precedence. When the CIR is exceeded, the lesser priority is employed probabilistically.
• Time-Sliding Window with three-Color Marking (TSW3CM): CIR, peak information rate (PIR), and three-drop precedence are used in this method. When the CIR is exceeded, the medium drop precedence is adopted, and when the PIR is exceeded, the lowest drop precedence is adopted.
• Token Bucket (TB): Two-drop precedence is used with a CIR and committed burst size (CBS). If, and only if, an arriving packet is larger than the token bucket, it is given lower priority.
• Single-Rate Three-Color Marker (srtcm): To pick among the possible three-drop precedence options, the CIR, CBS, and excess burst size (EBS) are used.
• Two-Rate Three-Color Marker (trtcm): To pick among the possible three-drop precedence options, the CIR, CBS, PIR, and peak burst size (PBS) are used.
• Null does not degrade the quality.

The DiffServ technique (as shown in Figure 3) is based on marking packets at the network’s edge by the demanded performance and then treating the packets differently at the network’s nodes based on the markings. The network offers QoS by categorizing traffic into multiple groups, each of which is defined by a code point. To differentiate traffic with various PHBs, DSCP is applied to the IP header of a packet. In a router, PHB describes packet-forwarding procedures. They make no guarantees about the amount of BW gained, or latency. It is just a way of identifying which types of traffic receive better treatment than others. A packet’s DSCP is associated with a traffic class and virtual queuing.

Furthermore, experimental simulations were conducted using NS2 to compare the performance of DiffServ-marking policies. The traffic class at the edge routers classifies the packets marking them whereas the core router forwards/drops them. In virtual queuing, there are two virtual queues, queue-IN and queue-OUT, both managed by the random-early-detection (RED) algorithm discipline. RED was developed to avoid congestion for packet-switched networks. The edge router categorizes packets based on the algorithm used; that is, the action to take with packets is to drop them and queue them IN or OUT. The parameters for the virtual RED queues have been set based on studies [34] about web traffic (

Table 1. Queue-IN and queue-OUT parameters.

Virtual RED Queues	Maximum Threshold	Minimum Threshold	Maximum Packet-Marking Probability
queue-IN	30	10	0.02
queue-OUT	24	8	0.10

).

The core router schedules traffic packets and it determines the deleted packets from the specified queue. We used scheduling to reduce the computational load on the core device by prioritizing queue-IN over queue-OUT. With PQ, we have configured the queue-IN to behave similarly to a high-prioritized queue with QoS, and the queue-OUT to behave similarly to a low-prioritized queue without QoS. Since the higher-priority scheduling services correspond to the queue-IN category (whenever there are packets present), PQ can lead to the starvation of the lower-priority queue (queue-OUT).

4. Simulation Results

This section includes the evaluation of various DiffServ policies used with multiple interfaces. It studies system performance when applying the interface-selection mechanism, considering the important parameters.

4.1. Setup

The general simulation scenario and topology used in the experiment are depicted in Figure 4. The source node generates the traffic flows with the default best-effort mechanism. The traffic flow of each interface (I) (which is linked to an access point (AP) with a different ISP) is marked with a DiffServ policy and a code point. The network domain’s core forwards each packet based on its PHB and traffic, which are determined by the DSCP of each packet. The source node is connected to the edge network that injects traffic into the core network. Then, each marked packet is examined at the DiffServ CN in the core network. Accordingly, the CN sends information to the multihomed destination across the core network. The performance of the received traffic is examined using the QoS DiffServ traffic, which is implemented over the network to be received at the multihomed destination and has more than one interface to communicate with the CN and to compare the overall results.

The introduced mechanism of interface selectivity considers the QoS offered by each interface. The simulation results compares all policies by implementing them within a DiffServ mechanism individually. The interface(s) selectivity takes into consideration the parameters influencing the interface(s) selectivity, based on the path characteristics that the targeted interface(s) are connected to. The proposed mechanism should give the node the ability to maintain the communication in the multihomed node along with the handover between the access points. Moreover, the mechanism should maintain throughput at a certain level and reduce overall end-to-end latency.

The simulations were carried out using a network simulator (NS2) [35,36,37]. As mentioned previously, simulation time was 4 s for examining the throughput of all of the policies, whereas a longer time of 35 s was set for the throughput examination of the best three policies to achieve the best accuracy. Dedicated interfaces are assumed for each policy in multihoming scenarios.

4.2. DiffServ Policies Investigation

In the beginning, we explored various policies concerning throughput, end-to-end latency, and processing time to find the policy to use with DiffServ via the connection route. Accordingly, the network performance was investigated and compared to those of different DiffServ policies, using one policy over the link. The six policies, i.e., TSW2CM, TSW3CM, TB, srtcm, trtcm, and null, have distinct parameters that govern packet precedence and priority except for null which performs a non-policy strategy. We studied their performance individually over DiffServ and address differences in overlaying performance values altogether for throughput, end-to-end latency, and processing time to state the optimal policy.

4.2.1. Throughput of Generating Packets at CN

Figure 5 depicts the throughput of producing packets of all the policies (each one apart) with a single-interface destination. The three shown lines denote the throughputs of TSW3CM, TB, and trtcm policies. They achieve the best three throughput values out of all the policies as they are the only apparent throughputs. The other policers are hidden as they achieve exceedingly small values comparatively. To this end, it can be inferred that the three policies outperform all the other policies, resulting in the best throughput.

4.2.2. The End-to-End Latency and Processing Time in Intermediary Nodes

We merged the statistics of the end-to-end latency and the processing time as they yielded identical results in both situations. Figure 6 indicates that the null has the shortest processing time in intermediary nodes (0.272 ms) due to the theory of the null’s non-policy status even when the queue is full, i.e., it acts as though no policy was established.

However, the former findings reveal that the processing time for the other policies varies; TSW2CM has the highest value (0.288 ms) as it spends a long time because of its long parameters and communication process. TB and srtcm have the same value (0.282 ms), proportionally. TSW3CM has a small processing time of 0.278 ms, whereas trtcm has a reasonable value of 0.28 ms. As demonstrated in Figure 4 and Figure 5, it is clear that TSW3CM, TB, and trtcm achieve the best values of throughput, latency, and processing time out of all DiffServ policies, comparatively.

4.3. Investigation of the Best Three Policies (Multi-Interface)

We examined the performance of the top three policies identified in the previous section over a multihomed network such that every policy has its path and dedicated interface. They begin the simulation using the best-effort mechanism, then each policy switches the path into another interface with another policy upon connection failure.

4.3.1. Throughput of Generating Packets at CN

Figure 7 shows the same start for the three policies with the best effort in the first 5 s. The traffic must explore the entire network, looking for an adequate path to go over whenever the link fails at the fifth second; as the throughput drops and starts recovering again, it must select another valid path (using another policy) or postpone recovery, resulting in greater latency. In comparison to the other policies, the TSW3CM policy provides the maximum throughput.

4.3.2. The End-to-End Latency and Processing Time in Intermediary Nodes

Similarly, the three policies start with the best effort. Figure 8 depicts the processing time, which represents the approximate end-to-end delay. The starting time for best effort requires a long time, and then we observe differences in the latency of these policies. TB causes the highest value of latency, whereas TSW3CM provides a latency that is approximate to trtcm which provides the lowest latency.

Figure 8 shows the results of process time, i.e., 0.2818 ms, 0.2817 ms, and 0.2816 ms for TB (the highest), TSW3CM (low), and trtcm (the lowest), respectively.

These findings are summarized in

Table 2. The best three policies’ performance comparison.

Parameters	The Best Effort/TB Traffic	The Best Effort/trtcm Traffic	The Best Effort/TSW3CM Traffic
Average end-to-end latency and processing time	High, around 0.2818 ms.	The lowest, around 0.2816 ms.	Relatively low, around 0.2817 ms.
Throughput (after best effort)	Worst start, worst, sharp drops	Good start, better	Good start, the best, gradual drop
Jitter (after best effort)	High start, decrease gradually Steady, worst	Same start Steady, lower	Same start Steady, lower (equal to trtcm)

, where the best policies are compared based on performance.

Based on Table 2 and the figures, the comparative performance of DiffServ policies is comprehensively demonstrated. It is concluded that the TSW3CM policy gives acceptable values for the examined parameters; hence, it is the best policy to use with the DiffServ mechanism, for both single-homed and multihomed linked nodes.

5. Conclusions

This paper thoroughly studied various DiffServ policies, exploring the effects of adding each policy into a different multihoming-based interface, and how the overall network performance would be increased if the node managed to switch between them according to their availability. The overall results showed how the switching mechanism defined in this paper managed to maintain ongoing communication between the CN and the multihomed node, and how the overall performance of the network was improved almost perfectly, showing which policy’s performance was the best; the results indicated the worthiness of the proposed mechanism. Furthermore, the findings revealed a complete comprehension of DiffServ policies and studied the performance. It was discovered that the null policy provides the best end-to-end latency of all the examined policies as the packets are not processed in the end routers. However, we noticed that the TSW3CM policy provides acceptable end-to-end latency, process time at the intermediator nodes, and jitter, in addition to achieving the best throughput in producing packets at the CN. It is confidently concluded that TSW3CM is the best policy to adopt with the DiffServ mechanism. Further work might be conducted to privatize and prioritize Internet traffic in the future.