QoS-RRC: an overprovisioning-centric and load
balance-aided solution for future internet
QoS-oriented routing
Augusto Neto&Leandro Freitas&Eduardo Cerqueira&
Rui Aguiar&Danielo Gomes
#Springer Science+Business Media, LLC 2011
Abstract The concepts and designs of 4WARD project for the Future Internet involve a clean-slate architecture with various networking innovations, including a new connectivity paradigm called Generic Path (GP). In GP architecture, several facilities are designed to efficiently support complex value-added applications and services with assured Quality of Service (QoS). The GP mainly makes transparent the underlying network structure and heterogeneity, and any entities, regardless of their purpose (technology, location or architectural layer) communicate with each other in a single way via a common interface. In addition, cooperation with network-layer provisioning mechanisms is required to map data paths that are compliant with session-demanded resources (QoS requirements - minimum bandwidth and maximum delay/loss experience) in appropriate GPs. In contrast, robust and scalable QoS-provisioning facilities are urgently required as a support for efficient GP allocations. To address this need, this paper
DOI 10.1007/s11042-011-0931-x
A. Neto (*)
:
D. GomesDepartment of Teleinformatics Engineering (DETI), Group of Computer Networks,
Software Engineering and Systems (GREat), Fortaleza-CE-Brazil, Federal University of Ceará (UFC), Campus do Pici, Bloco 725, 60755-640 Fortaleza, CE, Brazil
e-mail: augusto.deti@ufc.br
D. Gomes
e-mail: danielo@ufc.br
L. Freitas
Federal University of Goiás, Informatics Institute, Bloco IMF I, Campus II, Samambaia, 74001-970 Goiânia, GO, Brazil
e-mail: leandroaf@inf.ufg.br
E. Cerqueira
Federal University of Para, GERCOM/EngComp/PPGCC/PPGEE, Rua Augusto Correa, 01, 66075-110 Belem, PA, Brazil
e-mail: cerqueira@ufpa.br
A. Neto
:
R. AguiarInstitute of Telecommunication, University of Aveiro, Campus Universitário de Santiago, 3810-193 Aveiro, Portugal
introduces the QoS-Routing and Resource Control (QoS-RRC), a set of GP-compliant facilities to meet the requirements mentioned above. RRC complements GP architecture with QoS-oriented routing, with the aid of load balancing to select paths that comply with session-demands while keeping residual bandwidth to increase user experience. To address scalability issues, QoS-RRC operates on the basis of an overprovisioning-centric approach to achieve cost-effectiveness in terms of state storage, signaling load and network operations. An initial QoS-RRC performance evaluation was carried out in Network Simulator v.2 (NS-2), which showed that there had been drastic improvements in the flow delay experience and bandwidth use among a range of relevant state-of-the-art solutions. Moreover, the impact of QoS-RRC on the user experience (compared to current IP QoS and routing standards) has been evaluated, by analyzing the main objective and subjective Quality of Experience (QoE) metrics, namely Peak Signal to Noise Ratio (PSNR), The Structural Similarity Index (SSIM), Video Quality Metric (VQM) and Mean Opinion Score (MOS).
Keywords Future internet . QoS routing . QoE . Over-provisioning . Multimedia
1 Introduction
The Information Communication Technologies (ICT) and Internet have moved beyond their traditional areas of application to scenarios where customers are increasingly demanding access to various mobile solutions and the ability to interact with services, so that harmonizing a number of technologies to provide smart sessions with best possible personalized user experience. As a result, multimedia-based applications in the Internet are mainly aimed at helping to tackle a number of modern social challenges (e.g., e-security, e-commerce, e-health, e-tourism). However, the current
best-effort paradigm is faced with a path selection with no guarantees of multimedia
packet delivery or traffic characteristics; thus it cannot support Quality of Service (QoS) requirements of smart services. Moreover, in the next few years, the limits of current Internet capability are about to be tested further by the expected growth of more services of greater magnitude, a likely increase in the interconnection of smart objects and items (Internet of Things), and the integration of the Internet with advanced systems. Its very success is now creating obstacles to future innovations in both the networking technology that lies at the core of the Internet and the services that use it.
The 4WARD [21] is a European project that addressed the issues of incorporating multiple complementary network architectures within a common object-oriented clean-slate Future Internet (FI) framework. A new connectivity paradigm called Generic Path (GP) was adopted for general inter-entity (nodes, programs, processes, etc.) communication based on FI concepts and design of 4WARD [5] (information-centric framework, autonomous in-network management and virtualization). The main objective of GP is to abstract connectivity complexity of underlying heterogeneous technologies while supporting single-way inter-entity communication, regardless of their characteristics (defined by location, and naming, among others). The GP networking facilities (the focal-point of this paper) seek to incorporate major innovations in the network to support different types of sessions with ubiquitous access and intermittent QoS-assured multi-party connections. With this goal in mind, GP-aware entities use a common interface so that they can take advantage of networking facilities for local/remote communications with demanding Quality of Experience (QoE).
architecture must interoperate with underlying networking tools to orchestrate embedded QoS facilities so as to increase user experience. Quality-oriented routing is another crucial GP requirement to cope with path selection and that comply with the QoS requirements (low rates of propagation delay, jitter and end-to-end packet loss) of demanding sessions and, hence, to increase the user perception (by reducing image blur, and blocking). In this context, cooperation with quality level-awareness control mechanisms is essential to allow the provisioning of the required network resources along the selected path [11]. However, the literature shows that existing QoS-oriented routing solutions are inefficient, mainly in terms of performance. On the one hand, per-flow approaches [4] face state storage penalties (memory) due to the resource management needed for each micro-flow. On the other hand, excessive signalings of flooding-based solutions [2, 9, 19] can jeopardize system performance with an increasing number of nodes, with regard to energy consumption and CPU overhead with networking operations [10]. Over-provisioning is a promising strategy, which allows dynamic operations with reduced signaling events. Existing solutions, such as [13], adopt an over-provisioning approach to improve network resource control, relying on intra-/inter-domain standard routing protocols for path selection. Our analysis in the literature found that there are a lack of QoS-routing solutions that employ an over-provisioning approach.
For this reason, this paper proposes the QoS-Routing and Resource Control (QoS-RRC) mechanism to improve GP architecture with robust/scalable QoS-oriented routing and resource provisioning control capabilities. An overprovisioning-centric approach is adopted by QoS-RRC to deal with scalability issues, and to ensure that network state (paths, current QoS conditions, etc.) is maintained in advance at the borders for local decisions without per-flow signaling events. In addition, a load balancing strategy integrates QoS-oriented routing so that a stable level of overall network throughput can be maintained by distributing multimedia sessions over the available paths equally. Furthermore, when compared with current systems, the whole QoS-RRC multimedia networking approach is expected to allow fast and low-cost resilience, while increasing the end-users´ perception of quality. Initial QoS-RRC performance evaluation was carried out in Network Simulator v.2 (NS-2), and showed drastic improvements in the flow delay problem and bandwidth allocation within the context of a relevant state-of-the-art solution. Additionally, the impact of QoS-RRC on the user experience, in regular Internet QoS and routing mechanisms, is also measured by analyzing QoE objective and subjective metrics, namely, Peak Signal to Noise Ratio (PSNR), The Structural Similarity Index (SSIM), Video Quality Metric (VQM) and Mean Opinion Score (MOS) of real video sequences.
The rest of this paper is structured as follows. First, we introduce the GP architecture in Section2, and describe its mechanisms and main features. Later on, in Section3, we provide an in-depth description of the QoS-RRC mechanism, including its architecture and supported functions. The findings of this work are outlined in Section4, which gives the results of the performance evaluation of QoS-RRC using the NS-2 simulator. Finally, the work is brought to an end in Section5with a concluding section summarizing the significance of these results, and suggesting recommendations for future work on this subject.
2 Overview of generic path concepts and design
inter-Entities (ETs) commutations seamlessly, without being held by the current Internet skeleton key in a clean-slate approach. An ET represents any networking element, such as an application, node and interface. In a GP-aware network, the goals are as follows:
(i) to establish the foundations for both describing and prescribing any network communication;
(ii) to provide a generic communication service model that is not restricted by any communication paradigm;
(iii) todesign architectural constructs and primitives from this framework.
The GP architecture is object-oriented and its features include: (a) recursiveness, that allows description of a communication in a self-similar way; controlled opacity and virtualization, with state and functionality at any level and accessible from any level; (b)
agnostic, relative to technology, platform and communication; and (c) modularity, providing the opportunity to establish communication contexts and federation services, among others, such as polymorphism or overloading. It should be stressed that the GP1 architecture itself is not the focal point of our scheme, and thus this section only aims to provide an overview of the main concepts of GP to allow a basic understanding of it.
2.1 GP architecture and its main features
In GP architecture, the ETs model provides a running service at any level that generalizes communication data processing, and communicates horizontally or vertically via GPs. To clarify, when mapping a typical process-based system like UNIX, an ET abstracts a process, horizontal GPs abstract inter-process communication and Vertical GPs abstract process IDs/file descriptors. In this approach, an important element is the End Point (EP), which embodies components through which ETs can access/terminate a GP. While ETs are related to the control and management of GPs (service discovery, routing, name resolution, etc.), EPs belong to data transfer and control (error control, flow control, encryption, coding, etc.).
As mentioned earlier, ETs must establish GPs to communicate. A GP comprises a set of necessary resources that provide end-to-end communication between two or more ETs, and thus a GP may map any communication level, such as an application or physical layer, and the associated resources may be completely distinct (e.g. throughput vs. Signal-to-Noise Ratio). As a wide range of services may be represented by a GP, it has to be contextualized: the aim of the communication is delimited by the Compartment (CT) in which the GP is running, and may for example correspond to a network, a protocol, an application, or procedure (local or remote). The GP type is thus associated with the CT in which it is running. For operations such as data pipelining between the resources of the GP, there is a Mediation Point (MP). This allows GP interconnection, which is essential for E2E communications. The interweaving of these elements is represented in Fig.1.
The GP representing communication at its highest level of abstraction is the end-to-end (E2E) GP, which allows a ubiquitous view of the path. As illustrated in Fig.1, GPs 1 and 2 are created to cope with the EPs of the same CTs (e.g., processes of VoIP, a P2P traffic transfer, or videoconference applications), and GPs 3 and 4 to cope with EPs of different CTs (e.g., UDP or TCP connection). At the low level, the E2E GP is formed of other GPs through a composition (called sub-GPs), each implementing a different service technology.
1
For instance, a VoIP call between 3 users would be represented by a single (end-to-end) GP (GP1), and composed of an UDP GP (GP3), 2 Wi-Fi GPs (sub-GPs 1 and 2), one WiMAX GP (sub-GP3), and all other GPs necessary for that session to be running. At the physical level (outside the GP architecture), external mechanisms (the focus of this work) are responsible for dynamically allocating network resources (QoS-aware wireless channels in the case), which are then mapped in proper MPs to allow data communications (over sub-GPs in the case). The management of the sub-GPs requires maintaining state tables with GP-specific information, described in the next.
2.2 GP management records
In 4WARD, the GP Management Resource (GPMR) is defined as a database filled with GP-specific state. All the nodes within a GP-aware network manage their GPMR locally, and each one knows where the information is saved for local retrieval or querying a server (for synchronization for instance). The GPMR has a hierarchical structure, and its implemen-tation depends on the aims of the application, that are either carried out physically at a central station or more commonly in a distributed way. The resources associated with a GP are arranged as attribute information in a GPItem object. Access to information is possible through Dials, for inspectable/configurable information. The control information filled in a GPItem includes the list of composing sub-GPs, QoS/QoE/multimedia applications parameters, and other resource capabilities (e.g., privacy or related policies). Figure 2
depicts the logical disposition of the records in the nodes.
A record maintaining the high-level GP, and depicting a relationship between these GPMRs, is introduced in [6], the Master Record (MR). The MR holds a view of all the lower-level GPs that are running and associated with the same communication. By adding the Compartment Record (CTR) as a record listing the GPMRs running in a CT, it is possible to establish a distributed hierarchical scheme. In this way, an MR points to a list of
CTRs, one for each CT in which the CT Node participates. Figure 3 depicts the basic structure of a GPMR.
At the highest level of abstraction, a GP is the result of an aggregation of lower level GPs (Sub-GPS), one for each of the technologies that the communication depends on (TCP, Ethernet, Optical Fibber, etc.). The managed resources range from statistics, such as throughput, SNR, PSNR, SSIM, VQM, MOS and end-to-end delay, to data policies, including level of packet priority and the importance of each frame of a video on the user experience. The nature of the stored information and the record structure depends on the class of the GP, and therefore, one GPMR class exists for each GP class. All the GPMR classes derive from a GPMR base class, which offers the following facilities: a list of EPs, a list of composed GPs and a set of GPItems, the changing element in the structure. The
Fig. 2 Distribution of Records in the Node
GPMR class will therefore directly depend on the GPItem Class, which will be sub-classed according to such characteristics as connection-orientation (stream vs. datagram), physical related properties (wireless vs. wired) or number of destinations (unicast vs. multicast vs. broadcast). In this way, a GP will have a number of very specific GPItems that are related to the technology or service it refers to.
The degree of management centralization that is obtained depends on the communica-tion needs and by the way these MRs are used, but the main goal is to allow all the information provisioning about any running communication that is necessary - something that is currently not being provided in an efficient and accessible way. The GPs must be mapped into physical resources (e.g. links and interfaces) to allow data propagation, which requires an efficient processing of resource control and an improvement in the user perception. In the next section, the focal point of this paper is outlined, which is the routing-enabled quality level control proposal for processing network resources as a support for an efficient GP factory.
3 Detailed description of QoS-RRC
Within the GP architecture, the QoS-RRC suite cooperates with the GP factory to fulfill the requirements of interested ETs, while preventing degradations of system performance. To achieve this, QoS-RRC complements the GP architecture with QoS-oriented intra-domain routing facility by adopting a dynamic network resource overprovisioning approach to scalability. Figure4shows QoS-RRC within the GP architecture.
QoS-RRC follows the previously discussed overprovisioning patents concerning both QoS and data path resources [16, 17], which is distinguished by allowing strong performance optimizations. In terms of QoS overprovisioning, QoS-RRC implements a dynamic over-reservation approach associated with admission control, to setup sessions meeting QoS requirements while ensuring user perception. Moreover, QoS-RRC adopts a strategy centered on information available in advance, to allow QoS-oriented intra-domain routing without broadcast and per-flow signaling events. This consists of bootstrapping network nodes with information about shortest QoS-aware data paths inside the network. Thus, routing decisions are made with a broad view of the network associated with current QoS capabilities and QoE multimedia-awareness, in contrast to existing solutions which only keep next hop information with simple metrics for cost definition, that are maintained
by excessive flooding operations. QoS-RRC on ingress borders carries out the system bootstrap upon receiving announcements of interior/egress routers noticing empty state tables (i.e., new nodes in the system). That is, an interior router booting-up triggers network borders to bootstrap the system regardless if the network in on going or not. The QoS-RRC system bootstrap follows the premise of only adding new paths and updates of existing ones (e.g., QoS conditions) in on going networks for low-cost convergence.
QoS-RRC functionalities are implemented onto QoS-RRC software agents hosted at all the nodes within a domain. Two types of QoS–RRC agents are defined to achieve scalability and low complexity. The QoS-RRC Edge (QoS-RRC-E) statefull agents are hosted on network borders (ingress and egress), pushing resource control complexity to:(i)
bootstrapping the system; (ii) over-provisioning network resources (QoS and multicast); (iii) selecting best trees to comply with session resource demands; (iv) classifying paths according to current conditions; (v) detecting congestion events; and (vi) re-routing to load balance-effect sessions over available best trees. The QoS-RRC Core (QoS-RRC-C) lightstate agents are hosted on interior (core) routers, mainly in charge of reacting to signalings originated by QoS-RRC-E agents to be deployed with simplicity: (i) flow forwarding along QoS-aware trees; (ii) enforcing network resources indicated by signalings of QoS-RRC-E agents; (iii) flooding notification to trigger the system bootstrap; (iv)
notifying locally-booked QoS-RRC-E agents (unicast) to indicate congestion conditions. The statefull approach of the QoS-RRC-E agents allows them to carry out the full complexity of intra-domain operations, leaving lightstate QoS-RRC-C agent simply to improve system performance. Moreover, periodic signalings are also allowed to, for instance, collect per-path QoS/QoE capabilities or orchestrate routing information. Finally, on-demand (not per-flow) QoS enforcement aims at installing, removing or modifying resources.
3.1 QoS-RRC architecture
The QoS-RRC architecture was designed in a modular and flexible way to establish independence between its components, which can be shared and reused in a building block approach. Moreover, this modularity enables other components to be added without significant changes in the entire systems, by only requiring the interfaces of communication and configuration of the QoS-RRC’s resources to be implemented. Figure5shows the QoS-RRC architecture with modules and interoperations accordingly.
The QoS-RRC components can be described as follows:
& RCF (Resource Controller): entry point of QoS-RRC suite, and responsible for
enforcing the amount of resources computed by the ASAC, Routing-LB and AGTree modules;
& ASAC (Advanced QoS Resource Allocation): overprovisions network resources by
coordinating bandwidth per-class over-reservations at the system bootstrap, as well as readjusting them upon needs;
& AGTree (Advanced Aggregation Tree Allocation): overprovisions multicast distribution
trees at the system bootstrap;
& Routing-LB (Routing with Load Balance): QoS-oriented routing with load balancing of
& CDR (Congestion and Dropping Detection): detects congestion in the ranks of
network routers. To carry this out, CDR interacts with the active queue management mechanism Random Early Detection (RED) [3], which was adapted to meet the required needs;
& QoS-RRC-P (QoS-RRC Protocol): provides signaling support to enable RCF to enforce
network resources required by multi-user real-time multimedia sessions. QoS-RRC-P is distinguished from existing network protocols (e.g., NSIS, RSVP, etc.) in so far as it allows a coupled enforcement of QoS and connectivity (multicast) resources, edge-to-edge operations, single-way signaling and two types of messages for simplicity, RESERVE (downstream) and RESPONSE (upstream). The optimized approach of QoS-RRC-P seeks to drastically improve the overall performance of the system, since network resources which can be managed regardless of the number of demanding users (as is usually done today by setting standards), are handled through an association of edge routers instead.
3.2 QoS-RRC functionalities
The overprovisioning-centric scheme of QoS-RRC is specified on the basis of the solution patented in [14]. The main idea consists of composing a routing table, at the system bootstrap, with a surplus of the shortest QoS-aware data paths (through the module ASAC), which include IP address of each router along the path and the corresponding QoS capabilities with regard to bottlenecks (per-class bandwidth available and rates of delay, jitter and loss, which are directly linked to the user experience). With this goal in mind, each ingress node floods the network (only upon triggering the system bootstrap) to collect this kind of information, and each visited node fills the message accordingly. The QoS bottleneck information is kept by simply updating the message with local QoS capabilities if there is less current message information. A flooding control mechanism was designed to avoid infinite looping and storage of redundant
information. For instance, each node must only inspect messages once (without its IP information being previously filled), and a limited number of hops (as in TTL control) can be assigned to avoid long paths. This flooding cycle provides information about unicast paths, which are composed of one Ingress Router (IR), a set of Core Routers (CR) and one Egress Routers (ER).
After finishing the flooding cycle described above, each ingress router takes the unicast path information to calculate surplus of shortest QoS-aided multicast path information (i.e., over-provisioning of connectivity resources). Hence, QoS-RRC imple-ments an algorithm that generates all possible QoS-aware multicast trees (through the AGTree module). Since an excessive amount of matching can be achieved, QoS-RRC-E filters the information to keep only the best ones; for instance, the trees with ingress routers in the middle are discarded to keep only those downstream for possible efficiency [7]. Moreover, QoS-RRC-E can be configured with policies and traffic engineering techniques to make improvements in the tree’s filtering. Afterwards, QoS-RRC signals each path to install multicast state accordingly.
A connectivity control mechanism is supported by QoS-RRC-E, and this allows multiple aggregating sessions in the same tree. The purpose of this aggregation technique is to reduce state and processing overhead inside the network of legacy IP multicast per-flow basis, thus allowing scalable multi-party support. Additionally, path overprovisioning also improves resilience processing, by re-routing sessions o = in other trees with local processing. For instance, dynamic network events, such as link failure or handovers, require the re-routing of sessions. The QoS-RRC-E implements re-routing seamlessly, which means connecting affected flows onto multiple paths (load-balance) without GP Factory cooperation, to prevent GP reconfiguration. Thus, QoS-RRC allows fast resilience support and intermittent communications to keep real-time mulreal-timedia sessions meeting required quality level even when there are network anomalies. In the next sections, detailed information of QoS-RRC functionalities is provided.
3.2.1 Overprovisioning-centric mechanism
The QoS-RRC suite provides QoS control support by deploying admission control and bandwidth provisioning to allow multimedia session and propagation over the appropriate GPs, while keeping overall system performance and increasing user experience. In this way, aggregated bandwidth control/prediction is adopted, since per-flow is well known to be inefficient due to the excessive control overhead. QoS-RRC controls bandwidth using our patented strategy [15], which initializes per-class over-reservations (based on parameters assigned by a network operator) and controls their re-sizing dynamically, by taking into account statistics about network conditions, resource demands and class-policies. The integration of admission control and per-class over-reservation is expected to lead to improvements in network performance, where multiple sessions and GPs can be installed without per-flow signaling. To illustrate the QoS-RRC operations, Fig.6shows a diagram, which summarizes the general sequence of events introduced by the routing-enabled real-time mulreal-timedia session quality level control approach.
is handled by the RCF component, which reacts to perform a routing decision so that it can choose a data path(s) from among all those available in the local routing table. The decision takes into account the nodes that host the entities involved in the communication (to choose path candidates) and the QoS/QoE requirements of the previously mentioned session. On the basis of the current quality level capacity of each path candidate, the RCF on QoS-RRC-E chooses the most appropriate one (through admission control verifications), accepts the real-time multimedia session and then triggers the local Mediation Point (MP) to establish the connection (setup the tunneling for aggregation). After accomplishing all the configurations, the GP factory is given feedback so that it can properly populate the GPMR and allow session propagation accordingly.
In the event of the admission control failing for all the path candidates (a procedure not shown in Fig. 6), RCF triggers ASAC local (QoS-RRC-E at ingress router), which attempts to resize the selected path with more resources available in current over-reservations, in accordance with the session demands and available QoS capabilities. After computing the new QoS configuration (i.e., over-reservation re-sizing), ASAC triggers back RCF, which then re-computes the referring session setup request. If the new configuration is enough to accommodate the session, RCF enforces resources locally, composes a RESERVE message that is properly filled and invokes QoS-RRC-P to send it downstream towards the destination of the End Point (EP). All the RCF components on QoS-RRC-C agents enforce the resources (derived from the received RESERVE message) in the same way, and invoke local QoS-RRC-P to propagate downstream the RESERVE message with required updates. Upon receiving the RESERVE message, the RCF component on QoS-RRC-E agent at the egress router (destination EP neighbor) proceed in the same way as the previous agents, composes a RESPONSE(OK) and invokes local QoS-RRC-P to send it upstream in order to feedback the source of the previous RESERVE message (i.e., ingress router), which then updates the GPMR and reports the
requesting GP Factory accordingly. The set of actions described above is generally used in major QoS-RRC functionalities, with minor changes depending on the objectives of the operation, as described in the next sections.
3.2.2 QoS-oriented routing
The QoS-RRC-E has a routing module called Routing-LB, which is responsible for computing the best routes to each new session request and performing re-routing of flows when necessary. Thus, the GP Factory (on creating a GP) must first trigger QoS-RRC, via a well-defined interface, which is expected to provide the best data path information for connecting the required flow. This request includes, among other things, information about destination and session QoS requirements, which are essential to allow appropriate routing decisions.
Composition of the routing tables The composition of the routing tables is a result of
receiving a RESERVE message with flagIactivated, which indicates the initialization of the network parameters. To demonstrate the composition of these tables, the scenario shown in Fig.7is employed, and the explanation can be outlined as follows. Upon receiving a new node notification (RESPONSE message with flag I activated), all the ingress router(s) within the system (I0 in this case) invoke the system bootstrap, which flood the network with a REVERSE(I) message. Assuming that the entire system is booting up (for simplification), each core router visited by this kind of message adds the data path indicated in the referred message to, in the local routing table. Afterwards, one message for each local outgoing interface (with local IP added appropriately) is composed, and then flooded downstream accordingly so that each node can proceed in the same way. At the end, the egress routers E5, E6 and E7 compose one RESPONSE (with flagOKactivated) as
a result of eachRESERVE(I)and signals back along the referred data path (i.e.,RESERVE (I)reverse path), and each visited node supplies the routing table with upstream data paths (towards I0).
Upstream messages (i.e., RESPONSE) can also be sent directly to the ingress router I0 (booked in each core/egress router as a result of previous RESERVE messages), so that warming and requesting reactions depending on the network context (e.g., update the quality level parameters - among them, bit-rate, delay, jitter and loss). The warming messages are used to indicate the existence of a problem in the network, which might be, for example, excessive packet drop on a router or link break. In such a case, the ingress router (I0 in the case) re-invokes session setup requests of all the affected flows, as done by the GP factory accordingly. As normally, each session request arriving trigger both, routing table look-up and admission control verifications. The routing table look-up can influence re-routing of the affected sessions, which is only accomplished after succeeding the admission control verifications. The premise of the admission control is only admitting a session request upon noticing that the new tree comply with the QoS requirements and is able to maintain the same user experience, otherwise the session is denied.
An important factor which should be mentioned, concerns the load balancing of traffic which is deployed whenever executing the best path for selecting the algorithm (in this paper, called ´Choosing the Best Way´). The algorithm always takes into account the following: i) the paths with more residual bandwidth, which introduces more resource idleness, thus less CPU and energy consumption in the routers along the path; andii)paths with fewer associated QoS conditions. On the one hand, the residual bandwidth is defined by the amount of bandwidth between what is currently reserved up to the maximum reservation limit, and is simply calculated on the basis of the reservation state booked in the QoS-RRC state tables. On the hand, the Cost is defined by the Eq.1, which characterizes the QoS conditions of a communication path (tree).
Cost¼ ðrLLÞ þ ðrDDÞ þ ðrJJÞ ð1Þ
The Cost varies from 0 to 1, and is calculated by means of the current values of loss (L), delay (D) and jitter (J) of each router within a communication path and with reference weights for each of these values (ρL,ρDandρJ respectively) consonant with the type of demanding session involved (e.g., VoIP, Video and etc.). The reference weights are defined in the ITU G.1010 standard [8], which suggests limits of acceptable delay, jitter and loss in different types of applications. For example, the communication path cost for a streaming audio alike session is defined byð0:45LÞ þ ð110
5DÞþ
ð0:45JÞ.
Both the residual bandwidth and cost of the path are calculated for each particular tree, that is, for all the path candidates. With this information available, QoS-RRC-E (Routing-LB) selects the best paths and systematically distributes the flows over them, while avoiding processing overhead and bandwidth saturation in the trees.
The best way: minimum cost maximum flow The QoS-RRC-E agent at an ingress router is
selection takes into account two criteria:i)paths with higher residual bandwidth;ii)paths with lower cost. Algorithm 1 (Choose the Way) shows the pseudo-code of the QoS-RRC routing algorithm.
Algorithm 1 shows the initialization of two QoS parameters: bit-rate and class of service, but it can be easily extended to compute other QoS and QoE parameters. Furthermore, the IP address of the destination (EP) is also requested to determine the egress router that should address the data. After the initialization of these parameters, the QoS-RRC-E agent at an ingress router only filters and selects the egress routers that reach the destination (EP). Egress routers are retrieved via support of available Exterior Gateway Protocol (EGP), such as the widely used Border Gateway Protocol (BGP) [20] for inter-domain support. Afterwards, the algorithm only filters and selects those trees that are associated with the indicated egress router(s) with higher quality than those already booked. Following this, the algorithm calculates the cost by means of Eq.1, of filtering and sorting the trees according to the amount of residual bandwidth, in descending order and according to the cost, in ascending order.
3.2.3 Congestion detection for resilience support
The QoS-RRC has a module called CDR (Congestion and Dropping Detection) for detecting congestion in the queues of the routers as well as the link break events on these devices. This module works in parallel with the LB-Routing component, by allowing a more efficient re-routing of the affected sessions (with QoS-oriented routing and load-balance).
Congestion detection The congestion in incoming and outgoing queues is one of the main
Algorithm 2 exhibits the RED algorithm integrated with CDR facilities to detect congestion as in the following:
& RED calculates the length of the queue and verifies that the threshold isAverage; & If theAverageis below Minth, the packet is queued;
& If the Averageis between Minthand Maxth, RED calculates the probability that the
packet will be discarded and performs the following actions:i)if there is a probability
P that the package will be dropped, the agent will notify the agent QoS-RRC-C, which sends a message directly to IR (QoS-RRC-E) locally booked, warning of impending network congestion. This procedure is not supported by the current RED scheme. After this, the ingress router activates the load balancing algorithm to distribute the flows and balance the overall load of the network, ii) otherwise: the packet is queued;
& Finally, if the Average is above Maxth, the algorithm performs the same action
indicated ini)and notifies the QoS-RRC-C agent eminence of congestion.
Link or router failure detection In a network, failure of links or routers can be regarded as a
result of ruptures, errors or faults caused by software or hardware. Under these conditions, QoS-RRC must re-route all the affected sessions in the system to ensure that the intermittent transmissions are kept. Hence, the RCF component of the QoS-RRC agents at all the nodes is in charge of monitoring interface operational state to detect any failures that might arise. On detecting the failure, a RESPONSE(F) (RESPONSE message withfailure
indication) message is sent directly to the locally booked ingress routers informing the IP address of the network interface that is down. After receiving this message, the ingress router checks the sessions associated with the failing router to deploy re-routing by triggering a session request for each one.
3.2.4 Load balance
Routing-LB uses the Load Balancing algorithm (Algorithm 3) to improve the allocation of network resources, by providing systematic access to multiple data paths, thus preventing
As depicted in Algorithm 3, it first finds the trees candidate between the ingress and egress router(s) associated with the session referred to, and computes the associated costs. After the costs of each tree candidate have been computed, only the trees meeting the session requirements are kept. The algorithm is also prepared with a resilience facility, by means of which it can verify link degradations or failures to further trigger re-routing of affected sessions to keep the best user’s QoE during the time. The load balance algorithm enhances QoS-RRC by providing a better sessions distribution among the available data paths. This involves:
& Enhancing network resource provisioning through efficient routing, which means
selecting data paths uniformly so as to avoid the presence of idle and overloaded routes;
& Maximizing the overall network performance by reducing the response time of the
networking operations, as well as processing on core routers;
& Avoiding an overload of network resources on data paths.
The next Section describes the performance evaluation that was carried out to analyze the impact of the QoS-RRCs functionalities on a network to establish multicast multimedia sessions.
4 QoS-RRC evaluation
The tests and evaluations performed with QoS-RRC were conducted with the aim of determining the efficiency of the mechanism when compared to other solutions. To carry this out, the functionality of the simulator NS-2 (Network Simulator version 2) [22] was extended, and data were collected with regard to the network (QoS) and the users´ (QoE) status to analyze the impact in the network performance and user perception respectively. The policy flexibility and complexity of QoS-RRC, as well as timing-related analysis (e.g., latency, CPU/memory consumption and loop-back times) were not assessed, since this would require a very different evaluation environment (e.g., prototyping) for accuracy.
The selected simulation model used a topology based on real networks with 16 nodes, a bandwidth of 10Mbps and varying link delay, jitter and losses. For the differentiation of classes, a structure based on DiffServ was used, as well as Weighted Fair Queuing (WFQ) scheduling, Token Bucket policing and Random Early Detection (RED) queue management algorithms. The system has a network entry point, the Ingress Router (IR), and three exit routers, called Egress Routers (ER). The mechanism for choosing the paths and load balancing is located in the IR, and the user requests are routed from the ERs to the IR. We considered four distinct service classes: i)Expedited Forward (EF),ii)Assured Forward 1 (AF1),iii)Assured Forward 2 (AF2) and iv) Best-effort (BE), and 250 sessions for each of those classes, comprising a total of 1000 flows. The streaming rates can have a constant data transmission of 128 Kbps or 256Kbps for each one. To make the scenario more realistic, the sessions were initialized at varying time intervals, by using a random time generator. The total duration of simulations is 60 s, as suggested for long-time multimedia sessions. Finally, to demonstrate the impact that QoS-RRC has on the user experience, both objective and subjective measurements were made by using QoE metrics in a real video. The Evalvid [1] tool was used to assess and validate the QoE evaluation for user perception. Figure8
4.1 Network-based experiments
To evaluate the re-routing capacity, load balancing and support for fault tolerance, a link break was simulated between the router input I0 and core router C1, at t = 41 s. Figure9
shows the simulation results for the utilization rate of the links for each of the selected paths, where the results revealed that paths A, B, C and D have been selected over the entire experiment by the best path selection algorithm. The Multi-User Aggregate Resource
Allocation(MARA) [12,13] was used for comparison with QoS-RRC, due to its proximity
to the QoS-RRC overprovisioning-centric approach.
From the figure referred to, the distribution of the sessions between the different data paths (i.e., A, B, C and D) can be depicted, for both QoS-RRC and MARA mechanisms. From the MARA graph, it is clear that path B is only selected from the moment that path A runs out of bandwidth capacity. The same process takes place with the other paths. When the link break event occurs, it can be observed that the MARA starts redirecting all the sessions to path D, despite the existence of other ways with low cost or with high bandwidth waste. The random session ending of each one leads to a fluctuation in the data rates of all the paths, which translates into global instability for MARA. In contrast, the simulation results of the QoS-RRC show a very different behavior for the bandwidth and provide support for fault tolerance on all the selected paths. During the simulation, all the paths experienced uniform resource utilization, with an average of 8 Mbps per link, before breaking the link, and only once reaching maximum capacity, at a time of 53 s, to compensate for losing path C. Furthermore, the impact of load balancing with QoS-routing allows QoS-RRC to allocate bandwidth uniformly on all the paths. Thus, the reduction of bandwidth waste in all the paths can provide evidence of the efficiency of QoS-RRC when compared with MARA in optimizing networking processing. For noticing the intra-domain QoE, the averaging propagation delay in each path is depicted in Fig. 10.
The results displayed in Figs. 9 and 10 show that QoS-RRC enabled a better experience in terms of delay on all the paths - with a minimum of 9 ms and a maximum of 13 ms, and with standard deviations of 0.0012, 0.0012, 0.0024 and 0.0012 for trees A, B, C and D respectively - than that of MARA - reaching ~ 27 ms peak delay, with standard deviations of 0.0049, 0.0041, 0.0072 and 0.0065 for trees A, B, C and D, respectively. The load balancing with QoS-routing enabled the QoS-RRC a uniform behavior regarding the propagation delay, even after the link break. In addition, small variations
in delay were verified, which is of paramount importance to ensure the quality of the multimedia sessions. The jitter increased by 40%, which occurred after the link break, and had an average value of 0.9 ms. Thus, the conclusions to be drawn from the network-based tests is that the supply of resources using load balancing and QoS-routing is more efficient than that of MARA (and therefore of other solutions) in terms of network performance (mean throughput) and intra-domain per-path QoE (delay) over the simulation time.
4.2 User-based experiments
In the experiments based on the user, the QoS-RRC was analyzed by means of a regular Internet setup (IP standard), configured with a default QoS per class (DiffServ) and Best-Effort Routing (OSPF). Thus, the IP Standard setup did not apply admission control or resource enforcement operations. On average, the numerical results showed that QoS-RRC did not experience packet loss and blocked only 2.8% of the video sessions. When “IP standard” configuration was used, 24% of the packets were lost from all the video sessions.
Fig. 10 Delay analysis of MARA and QoS-RRC
The Peak Signal to Noise Ratio (PSNR) metric is a more objective and traditional metric, and performs frame-by-frame comparison between the quality of the video received by the user and the original video. For a video to be considered to be of good quality from the user perspective, it must have an average PSNR of at least 30 dB. This is based on the mapping of PSNR to MOS values, as shown in Table1, where the MOS is considered to be the most popular subjective measure.
In our simulations, we use the video file“News”, provided by the Evalvid site. News for the video, the average PSNR for IP Standard configuration, was 19 dB (with standard deviation of 4.6), as illustrated in Fig.11. Furthermore, the video is considered to be poor, according to the user experience, as shown in Table 1. However, when the QoS-RRC is used, the average PSNR passed to 45 dB (with standard deviation of 1.9), thus maintaining the excellent video quality, even in periods of congestion.
To make a comparison that takes into account the structure of objects and provides a better assessment than the PSNR, the Structural Similarity (SSIM) metric was employed, which traces the sent and received images, by taking into account three HVS components: brightness, contrast and structural distortion. The SSIM index is a decimal value between 0 and 1, where 0 means there is no correlation with the original image, and 1 means it is the same image. Figure12shows the SSIM values for both mechanisms, where it is clear that QoS-RRC enables the video content in real time to be supported with an excellent level of quality throughout the experiment (SSIM of 0.99 on average), whereas when the IP Standard is used, the SSM values are around 0.63 (with a standard deviation of 0.12).
The VQM metric takes the original video and the processed video as input and verifies the multimedia quality level on the basis of human eye perception and subjectivity factors, including blurring, global noise, block distortion and color distortion. The VQM evaluation results vary from 0 to 5 values, where 0 is the best possible score. As shown in Fig.13, on average, the VQM values are 2.57 (with a standard deviation of 0.73) and 4.69 (with a standard deviation of 0.96) for IP Standard and QoS-RRC respectively.
To show the impact of the QoS-RRC (compared to IP Standard configuration) on the user point of view when the system is experiencing ~18% of congestion, some frames from a (randomly selected) video session, were captured (Table2). The benefit of the QoS-RRC is visible in the frames of the video, particularly in the image of the ballet dancer.
Objective and subjective QoE metrics results have shown the QoS-oriented abilities of QoS-RRC in establishing and re-routing real-time video content with excellent quality level over the time.
5 Conclusions and future work
This paper has shown a QoS-Routing and Resource Control (QoS-RRC) mechanism for enhancing the transport paradigm of 4WARD Future Internet concepts and design, called
PSNR (dB) MOS
> 37 5 (Excellent)
31–37 4 (Good)
25–31 3 (Fair)
20–25 2 (Poor)
< 20 1 (Bad)
Table 1 PSNR to MOS
Generic Path (GP). The QoS-RRC deploys load-balanced QoS-oriented routing operations in an overprovisioning-centric, to allow GP architecture to support real-time multimedia multi-user sessions efficiently. The QoS-routing approach of QoS-RRC dynamically selects a data path that is able to meet the QoS requirements of demanding sessions and thus guarantee best user perception, while preventing system performance degradation of per-flow operations and flooding–based solutions (mainly implemented in the state-of-the-art). The resilience support of QoS-RRC also improved the proposed solution with a RED-based congestion detection strategy, and the overprovisioning-centric cooperation envisages fast re-routing.
The simulations carried out to evaluate QoS-RRC, allowed us to demonstrate its benefits, when compared with those of related work (MARA for Network-based Experiments), as well as current Internet QoS and routing standards (User-based Experiments). In the Network-based Experiments, QoS-RRC drastically optimized delay experiences in all the selected data paths (14 ms of peak delay, whereas MARA achieved 27 ms). Moreover, QoS-RRC uniformly balanced the load in the routed paths by allowing a more residual bandwidth. In the user-based experiments, QoS-RRC introduced no packet loss, while 24% of packet loss has been traced in the IP Standard configuration. Moreover,
QoS-Fig. 12 SSIM–Video News
RRC provided evidence of real-time video content of excellent quality level, since QoE measurement analysis observed SSIM averaging 0.99, VQM of 4.69, and PSNR of 45 dB. In contrast, IP Standard configuration averaged SSIM of 0.63, VQM of 2.67 and PSNR of 19 dB.
The findings of this paper suggest that future work could be undertaken to evaluate QoS-RRC through prototyping in order to achieve more accurate results. As well as having conceived QoS-RRC in accordance with the 4WARD GP paradigm, we believe that this study offers benefits, which can be used to address current performance issues and design inter-domain features. Moreover, QoS-RRC over-provisioning approach can be improved to orchestrate wireless mesh systems, such as IEEE 802.11 s.
Acknowledgements CNPq, REDE-TIC and FAPESPA supported Eduardo Cerqueira. CNPq also supported
Augusto Neto.
References
1.“Evalvid - A Video Quality Evaluation Tool-set”, Available: http://www.tkn.tu-berlin.de/research/ evalvid/, accessed December 2010
2. Apostopoulos G, Guérin R, Kamat S”Implementation and Performance Measurements of QoS Routing Extensions to OSPF”, Proceedings of INFOCOM'99, New York, NY, March 21–25, 199
3. Braden R et al. (April 1998)“Recommendations on Queue Management and Congestion Avoidance in the Internet”. IETF RFC 2309
4. Brades R, Zhang L, Berson S, Herzog S, Jamin S (September 1997)“Resource ReSerVation Protocol (RSVP)–Version 1 Functional Specification”, IETF RFC 4094
5. Correia L, Abramowicz H, Johnsson M, Wünstel K (2011)“Architecture and design for the future internet”, 1st Edition, XXIX, 306 p., Hardcover
Table 2 Random frames from“News”with QoS-RRC and IP Standard configurations
Mechanism
Frame Number [07]
Frame Number [08]
IP Standard
(DiffServ +
OSPF)
6. Figueiredo S, Lourenço J, Aguiar RL, Neto A (2009)“Taxonomy for GP-aware mobility”. Proc. of the First International ICST Conference on Mobile Networks and Management
7. Gomes D, Agoulmine N, Bennani Y, De Souza JN (2007) Predictive connectionist approach for VoD bandwidth management. Comput Commun 30(10):2236–2247
8. ITU-T G1010, International Telecommunication Union. Series G: Transmission Systems and Media, Digital Systems and Networks, (October 2001)
9. Kannan G (May 2000) “Adaptive Selective Flooding QoS Routing“. Degree of Master Science in Computer Science
10. Manner J, Fu X (2005)“Analysis of existing quality-of-service signalling protocols”, IETF RFC 4094, May 2005
11. Mu M, Cerqueira E, Boavida F, Mauthe A (2009) Quality of experience management framework for real-time mulreal-timedia applications. Int J Internet Protoc Technol 4(1):54–64
12. Neto A, Cerqueira E, Monteiro E, Mendes P (2008)“Scalable Resource Provisioning for Multi-user Communications in Next Generation Networks”, In: IEEE Globecom 2008 Next Generation Networks, Protocols, and Services Symposium, 2008, New Orleans, LA, USA
13. Neto A, Cerqueira EA, Monteiro E, Mendes P (2008)“Scalable Multimedia Group Communications through the Over-provisioning of Network Resources”, In: 11th IFIP/IEEE International Conference on Management of Multimedia and Mobile Networks and Services Management of Converged Multimedia Networks and Services (MMNS 2008), 2008, Samos Island
14. Neto A, Curado M, Monteiro E, Mendes P (2009)“Method and apparatus for multicast tree allocation”, European Pattent Officer EP2031796 (A1), March 2009
15. Neto A, Curado M, Monteiro E, Mendes P (2009)“Method and apparatus for QoS resource reservation and configuration of multicast network resources”, European Patent Officer EP2037636 (A1), March 2009 16. Neto A, Curado M, Monteiro E, Mendes P (March 2009) “Method and Apparatus for Configuring
Bandwidth in Class-based Networks”, European Patent Office, EP 2037636A1
17. Neto A, Curado M, Monteiro E, Mendes P (March 2009)“Method and Apparatus for Multicast Tree Allocation”, European Patent Office, EP 2031796A1
18. Papadimitriou, Christos H. Steigltiz, Keneth (1998) Combinatorial Optimization Algorithms and Complexity
19. Porwal R (2005)“Adaptive Selective Flooding QoS Routing”. Indian Institute of Science
20. Rekhter Y, Li T, Hares S (January 2006)“A Border Gateway Protocol 4 (BGP-4)”. IERF RFC 4271 21. The FP7 4WARD Project,http://www.4ward-project.eu/
22. The NS-2 Home Page,http://www.isi.edu/nsnam/ns/
Augusto Neto got his PhD at the University of Coimbra (UC), Portugal, in the Department of Informatics
in the field of Computer Networks and Distributed Systems. He is also member of the Group of Computer Networks, Software Engineering and Systems (GREat) and of the IT-Aveiro. He is currently coordinator of two research projects funded by national development agencies (CNPq and FAPEG) and co-participant with several others with national and international financing.
Leandro Freitasgraduated in Computer Science from Federal University of Goiás (UFG) in 2008. During
his B.Sc., he participated on research projects in the area of Wireless Sensor Networks and Radio-Frequency Identification (RFID). He finished his M.Sc. in Computer Science at UFG in Computer Networks and Distributed Systems, more specifically in the development of a routing protocol for Future Internet, under supervision of Prof. Augusto Neto. He is currently, Assistant Professor at the Federal Institute of Goiás, and doing his Ph.D. at the UFG in the Distributed System field.
Eduardo Cerqueiragot his Ph.D. degree from University of Coimbra (Portugal) in 2008. From 2008 to
organization of many international conferences/workshops/journals. He is coordinating three CNPq funded national and international projects and participating in some EU projects.
Rui Aguiar received a Ph.D. degree in electrical engineering in 2001 from the University of Aveiro,
Portugal. He is currently an Associate Professor at the University of Aveiro and an adjunct professor at the INI, Carnegie Mellon University. He is leading a research team at the Institute of Telecommunications, Aveiro, on next-generation network architectures and protocols. His participation in European cooperative research is extensive. His current research interests are centered on the implementation of advanced wireless networks, systems, and circuits, with special emphasis on QoS and mobility aspects. He has more than 250 published papers in those areas. He has served as technical and general chair of several conferences, such as ICNS’05, ICT’06, ISCC’07. He is currently a member of ACM, and a Senior Member of IEEE.
Danielo Gomesreceived his PhD degree in Réseaux et Télécomms from the University of Evry, France, in
