5GQUALITY: Demonstration of QoE Management using MPTCP and Segment Routing in SDN/NFV

As multimedia streaming services continue to grow towards 6G networks, service providers have adopted cutting- edge paradigms such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to implement traffic en- gineering solutions in order to improve the network throughput, application performance and the end-users Quality of Experience (QoE). In this demo, a novel SDN-based MPTCP/SR approach for QoE-aware multimedia services delivery for 5G networks is proposed. The aim is to increase network resources utilization, system throughput and the end-users’ QoE. To demonstrate the effectiveness of the architecture, the performance results of the QoE-aware MPTCP SDN/NFV SR-based approach, the classical MPTCP and TCP in terms of system throughput and the end-users QoE were compared. Preliminary results shows that, the proposed approach outperforms the other aforementioned methods. The results of this demo were published in [1] and [2].


I. INTRODUCTION
Software Defined Networking (SDN) for 5G systems proposes an efficient way of decoupling the data forwarding equipment and network control. In SDN, the network intelligence is centralized in the "SDN controller" which can configure network equipment (NE) to forward multimedia flows along certain paths using network protocols such as OpenFlow [3]. Using SDN, it is possible to automate many tasks within the network (e.g., routing), especially in topologies implemented like a FatTree. As an outcome, SDN-based routing is beneficial for QoE-based optimization such that, subject to resource constraints and any network topology changes, the aggregated user-expected QoE value in a 5G network domain can be achieved [4]. To cope with an increasing multimedia services (e.g. 4K/8K, video streaming and online video gaming) that require optimal throughput, Multi-Path Transmission Control Protocol (MPTCP) [5] and advanced forwarding technologies such as Segment Routing (SR) [6] have been proposed.
With MPTCP, a large multimedia flow can be sliced into multiple subflows. The subflows originating from the same MPTCP connection are then sent to their destinations through different disjointed paths in the network [7]. However, the only drawback of MPTCP, is the lack of control over the network or transmission routes from source to destination. Again, MPTCP results into the number of rules on every switch to grow tremendously and therefore causing overhead to SDN switches and the controller. It is imperative to note that, SDN switches are incapable to handle large volume of flow rules because the complex rule matching in SDN (e.g., wildcards) requires switches to store rules in a Ternary Content Addressable Memory (TCAM), which is expensive, limited in size (practically supporting 2k-20k rules) and needs high power consumption [4]. SR can eliminate the overhead imposed by large number of MPTCP subflows at SDN switches. Thanks to its capability of reducing the number of forwarding rules by encoding routing information into packet header as an ordered list of labels. Indeed, since there is no path state maintenance required in each switch or router along the service delivery path, SR can improve the scalability problem of SDN.
Following my previous work in [2], [4] and [8], this demo, present a QoE-based multipath source routing mechanism that forwards traffic through multiple disjointed paths using MPTCP and SR paradigms over an SDN/NFV -enabkled 5G system. The main objective of this demo, is to show how MPTCP and SR can facilitate efficient multipath-routing and speed up the transfer of large amount of multimedia applications between end-points while guaranteeing the end-users' QoE in SDN-based virtualized 5G networks. In addition, the demo further provides information on how the research community from both industry and academia, can make use of this novel approach in their SDN and NFV related work. The demo will illustrate the following main key features: • Increased system throughput • Increased scalability, availability and QoE optimization • Efficient utilization of network resources II. ILLUSTRATIONS OF A NETWORK PROTOTYPE FOR DEMO Fig. 1 illustrates a QoE-aware MPTCP/SR based SDN/NFV system that can achieve an optimized end-to-end QoE level for the end-users by forwarding MPTCP multimedia flows through multiple disjointed shortest paths and perform source routing using the SR paradigm. Two functional planes are identified: namely, the data plane, and the QoE-control and management plane. Every SDN switch in the data plane implements the SR paradigm for performing source routing of MPTCP subflows using segment labels.

A. Data Plane Operations and Implementations
As shown in Fig. 1, the demo is prototyped in Mininet using a FatTree topology made up of the edge, aggregation and core layers, consisting of 8, 4 and 2 SDN switches, respectively. When a client PC (that also supports MPTCP) attached to the Mininet network requests a video file, an MPTCP connection with 3 subflows is initiated. As an example, sf1:1, sf1:2 and sf1:3 indicates the number of subflows of one MPTCP connection, sf is the subflow and the indexes indicate the number of a subflow of a particular MPTCP connection. In order to guarantee the end-users QoE and the performance requirements of SDN/NFV systems, the SDN controller is responsible to check capacity availability of all connected paths within the network. It then selects the shortest paths to transmit the subflows of the same MPTCP connection.

B. QoE Control and Management Plane Implementations
The POX controller was extended with three functional modules, namely, the MPTCP-based flow manager module, the Traffic Engineering (TE) Segment Routing module and the QoE management module. The description of each module is as follows: 1) MPTCP-based Flow Manager: This module computes the shortest paths and then performs path allocations to the subflows. Based on the collected link information, the MPTCP module communicates with the QoE management module so that resources can be assigned to the calculated paths of subflows to meet their QoE requirements [8]. Instead of installing these subflow paths in SDN switches as forwarding rules, the SR approach is used where the forwarding table of the ingress switch is configured with an ordered list of segments [8]. The ingress switch then adds labels with an ordered list of segments to a packet header and forwards it to its destination point.
2) TE-Segment Routing Module: The computed subflow paths using the MPTCP-based flow manager have to be mapped to SR paths. The segment routing module is introduced to enhance greatly the SDN controller such that future multimedia applications can exploit its features through the NorthBound Interface (NBI). In the SR paradigm, a segment can be a logical or a physical element such as a network node (e.g., OpenFlow switch or router), network link or a packet filter. The SR path is formed by the chain of these elements which are identified by a list of segment identifiers (SIDs). The SIDs can be defined globally with domain wide significance such that it is recognized by all network nodes or it can be defined locally within a node processing the packet. The list of SIDs consists of network nodes (e.g., node segments) or specific interface node (e.g., adjacency node) [9], [4]. For example, given a multimedia flow f requested by an MPTCP client1 whose ingress node is OpenFlow switch S7 and the engress node is switch S14, then the complete path (e.g., say for subflow sf 1 with intermediate nodes {S 6 ,..S N −1 }) can be: P sf 1 ={S14→S6→S1→S3→S7}. With reference to Fig 1, this path is considered and the graph of the topology as inputs. The specific path of the subflow is mapped and the segment list is returned as an output of the assigned SR paths, the implementation details can be found in [4] and [8]. Fig 1, when the SDN controller receives a new request from the MPTCP client, it performs the path calculation through the MPTCP-based flow manager and allocates the subflows to transmission paths [4]. It then maps these subflow paths to SR paths. The SR path of the new subflow is stored in the database. The SDN controller allocates and configures the SR path to the ingress switch node using the segment label list. The controller maintains the database where all SR subflow paths are stored with their QoE requirements [8].  control and QoE estimation related to multimedia applications are achieved [8]. It further provides SDN/NFV infrastructure domain monitoring and multimedia service availability in order to enhance the QoE of the end users [4]. In order to ensure the overall system performance of a multimedia service, the QoE management module takes measurements of QoE metrics such as stalling, video quality and network metrics such as packet loss, latency, jitter and network throughput [8].

III. EXPERIMENTAL DEMONSTRATION AND SYSTEM TOOLS
To demonstrate the proposed Multipath SDN architecture shown in Fig 1, two VMs were installed with Linux (Ubuntu V16.04 LTS) and MPTCP v0.92. The Mininet V2.2.2 has been installed in one VM and used to model a topology of a datacenter network similar to that shown in Fig 1. The modeled network in Mininet consists of redundant links that can accommodate subflows splitted by the MPTCP module. The POX controller running in the second VM is extended with an implementation of MPTCP-flow manager, QoE management module and the SR module as described in section II. Two MPTCP server machines that are installed with Apache Server are attached on the Mininet network. Throughout the demonstrations, the video sequence "Big Buck Bunny" with a resolution of 1920x1080 pixels of 9 min, 56 seconds which is further segmented using GPAC MP4Box into video segments of 2, 4, 6 and 8 seconds. The "Big Buck Bunny" video is encoded using ffmpeg version 3.3.4 with the libx265 at 3 different resolutions (720p, 480p and 360p) with video encoding rate of 2.496Mbps, 1.536Mbps and 1.0888Mbps respectively. When the MPTCP is enabled, the default configurations of MPTCP V0.92 was kept intact and configured the MPTCP path manager to a full-mesh to limit each MPTCP connection to have only 3 MPTCP subflows. We use the VLC-DASH plugin [10] as the DASH client for collecting and reporting the performance of video quality and throughput during video streaming. For effective demonstration of the proposed MPTCP/SR SDN-based architecture, both TCP and MPTCP are supported at the client and server sides. Fig 2 shows the workflow when the DASH client that supports MPTCP requests a video file from the MPTCP server. Before video segments transmission starts from the server to the client, MPTCP connection is established using 7 steps as shown in Fig 2. Step 1-3, is a three-way handshake where a DASH client sends the SYN segment that contains the MP CAPABLE option. The server replies to the SYN segment with an ACK message which includes the MP CAPABLE option. For attaching the second subflow, the MPTCP client and MPTCP server then use the MP JOIN option during the handshake (Step 4-6).
Step 7 is the confirmation message containing the HMAC and ACK messages received by the DASH MPTCP client from the MPTCP server. The third subflow is attached using the MP JOIN option exchanged during the attachment of the second subflow. After the MPTCP connection between a client and server has been established, the SDN controller computes shortest paths for video subflows using the MPTCP module. It then maps the subflows paths to SR paths. At this point, the video segments are transmitted from the MPTCP server to the MPTCP client.

A. Innovative Aspects of MultipathSDN Demo
The innovation behind the demo, is the reduction of overhead to SDN switches and the controller by using MPTCP/SR in SDN/NFV-based systems where only few intermediate nodes are selected to forward packets from source to destinations. This way, installation of flow rules in SDN switches as done in previous related work are avoided. To summarize, the demo provides four innovative benefits (1) to speed up network transmission, (2) increase network throughput, (3) reduce overhead and, (4) lastly, to improve user's QoE for multimedia services in SDN-based networks.

B. Video Streaming Scenarios and a List of Items for Demo
Three video streaming scenarios under different networking conditions are demonstrated. The first demonstration shows the performance of MPTCP and SR for video quality streaming in SDN/NFV without background traffic. The second demo shows the effects of background traffic on the performance of MPTCP and SR for video streaming in SDN/NFV. The last demo indicates the performance of MPTCP and SR in SDN/NFV in terms of link utilization, with and without background traffic.

IV. CONCLUSION
We have demonstrated a QoE-aware MPTCP/SR based SDN/NFV system architecture that achieves an optimized endto-end QoE level for the end-users by forwarding MPTCP multimedia flows through multiple disjointed shortest paths and performs source routing using SR paradigm. The future work will replicate the demo and include our recent work [11] that provides bandwidth prediction schemes for defining bitrate levels in SDN/NFV-enabled adaptive streaming for 5G/6G systems. We will also investigate 5G network slicing mechanisms [12] for multimedia streaming services focusing on 4K/8K videos.