# Introduction DN provides network functionality and also the behavior of network devices. The data-plane is forward through the network, such as packets and the hardware that is used to forward it, such as, switches. The control-plane represents all logic and devices that are responsible for deciding how and to where data in the data-plane is to be sent. In SDN, network operator can manage networking elements by running software on an external server. We can easily understand SDN against traditional network by a simple example, suppose if we want to deliver a packet in the network it has to change its route multiple times for finding the optimal path. But in SDN it automatically traces the entire possible and shortest route for delivering the packets. By separating the control plane from data plane in SDN, some controller increased its flexibility in deploying new services (e.g., virtual private network, cloud computing), programmability in open API, reliability in converged IP network. In few controllers installing control software remotely from forwarding element reduces the complexity of the forwarding element but increases the dependability of the network. Real-time Online Interactive Applications (ROIA) is connecting high numbers of user applications such as multiplayer online games, simulation base e-learning etc. In ROIA the reaction of user happens virtually and immediately. ROIA provides High Quality of Service on underlying network. Resource Reservation Protocol (RSVP) is one kind of traditional technique for controlling QoS for reserving network bandwidth. It is mainly static by nature and not suitable for changing demands of ROIA dynamically. There is a problem for SDN is to design the Northbound API. It defines the communication between the controller and high-level program [1]. Packet scheduling is essential for entire supporting applications on Software-Defined Networking (SDN) model. However, on OpenFlow/SDN, QoS is only performed with bandwidth guarantees and by a wellknown FIFO scheduling. QoSFlow module adds extensions to the standard software switch (datapath) of Open Flow 1.0. During the starting time of the QoSFlow project, the specification 1.0 of Open Flow was the latest stable version and was used in the project. Even though OF 1.3 has brought a new mechanism for rate limiting, but as well as the Open Flow 1.0, we are able to use FIFO instead of other packet schedulers to achieve different treatments to the packets. The Open Flow datapath plus QoS modules form the QoSFlow datapath [2]. This datapath is a user space implementation where queues are located in the kernel space. The QoS module opens a channel with the kernel through Netlink and Packet socket families to connect both user and kernel space. Thus, the packet schedulers can be instantiated to enable traffic shaping and enqueueing of flows. The components called Traffic Shaping, Packet Schedulers and enqueueing that constructs the QoS module of the QoSFlow datapath. Network operating systems (NOX) applications will be written as centralized programs on high level of instability in network resources, unlike algorithms distributed from lower back [3,4] applications. The network operating system does not manage the network itself; It provides a programming interface with high level objects (such as CPU processing power, memory, disk storage volume, link power, etc.) of network resources, which enables network application programs to handle secure and functional complex tasks on a wide variety of networks [3]. The NOX, however, fails in providing the obligatory functions for QoS-ensured software defined networking (SDN) [5] accommodation provisioning on carrier grade provider Internet, such as QoS-vigilant virtual network embedding, end-to-end network QoS assessment, and collaborations among control elements in other domain network. # II. # Related Work Previous work on providing QoS using Open Flow has three categories. First, studies deploying dynamic QoS in an SDN environment [6], [7], [8]. Second, studies on switch diversity [9], [10], [11], [12].Third, research on network performance resulting from QoS with OpenFlow-enabled switches [13], [14]. Some of the work done in the area of SDN based on demand provisioning of network resources, is targeted towards automated, policy-based network provisioning [15,16], while the other is targeted towards traffic engineering across Wide Area Networks (WANs) [17,18]. Dynamic allocation of network resources is also required inside the data centers, and many studies address this challenge. As an example, an OpenFlowbased algorithm for allocation of bandwidth resources between virtual machines in data centers is presented in [19], while in [20] the authors describe a platform for integrated provisioning of computing, storage and network resources in data centers. However, most of the related work focuses on the service logic for QoS-aware resource provisioning, leaving out the details of how the network resources are managed and provisioned in the data plane. In some of the papers, such as [21], the authors mention that the proposed QoS architecture dependent on traffic classification and rate limiting at the edge of the network, although no description about how the reservation of logical resources inside the SDNC enforces in the forwarding devices. The work that is closest to the one presented here is [22], which defines a data plane QoS architecture for SDN based on similar principles (i.e. a combination of queues and rate limiters), but with different constraints for the resources. The current paper contains a definition of how the resources are managed inside the SDN in order to provide deterministic QoS. When monitoring the QoS it is an advantage that a network problem resulting in decayed performance will affect a whole class of flows that share some properties (i.e. routed through an overloaded device and use the same QoS class). It is sufficient to monitor a representative subset of the network flows which makes QoS Monitoring eligible for sampling. # III. # Description of the Existing Architectures Existing Architectures 1. ROIA 2. Multiple Packet Scheduler 3. NOX 1. ROIA Real-time Online Interactive Applications (ROIA) connects wide number of users who interact with the applications and with each other with proper authentication, i.e., a replication to a user's action transpires virtually and immediately. Typical representatives of ROIA are multiplayer online computer games, simulation-based e-learning, and serious gaming. Due to a large, variable number of users, with intensive and dynamic interactions, ROIA make high Quality of Service (QoS) demands on the underlying network. Furthermore, these demands may continuously change, depending on the number of users and the actual application state: in a shooter game, a high packet loss in a combat state may have fatal consequences on QoS, whereas it is less relevant when a player is exploring the terrain. ROIA Applications has two parts, a static and a dynamic part. Static part has non-changeable and landscape objects. The other one dynamic part has non-playing characters controlled by server. These objects can change their state at any time. Figure 1 shows the structure of a ROIA. In this architecture only one ROIA process serves the connected ROIA clients and a group of ROIA processes distributes among several machines. For the processing of ROIA in an infinite loop the application state executes repeatedly in real time which is called real-time loop [23]. Single loop iteration has three important steps. Firstly, the user takes input and transmits it via a network and ROIA process receives that. Then to calculate the application state we can apply the user input and processing methods to current # Global Journal of Computer Science and Technology Volume XVIII Issue III Version I 22 Year 2018 ( ) application state. After that, the loop transfers the updated state to the client. # Multiple Packet Scheduler The Open Flow data path plus QoS modules form the QoSFlow datapath. This path is a utilizer space implementation and locates in the kernel space. The QoS module opens a channel with the kernel through Netlink and Packet socket families to connect both utilizer and kernel space. Thus, the packet schedulers can be instantiated to enable traffic shaping and enqueueing of flows. Figure 2 shows the components like Traffic Shaping, Packet Schedulers and enqueueing that constructs the QoS module of the QoSFlow datapath, and their relationships. Hence, the Traffic Shaping and Packet Schedulers components administer the QoS messages receipt from control plane by splitting the bandwidth size in queues and by attaching or detaching packet schedulers for these queues, respectively. To connect the kernel, these components open a Netlink socket channel and send a Netlink message through it. The Netlink message is the type of message that Linux kernel accepts for network resources management. In this way, the QoS messages maps to Netlink messages. ? Enqueueing: It is the component responsible for operating OFPT_FLOW_MOD messages of the of protocol. This message modifies the state of the flow table, where each entry contains header fields, counters, and actions for matching packets or flow packets. The enqueueing mechanism maps flow to queues using the skb-> priority of kernel's data structure called sk_buff. This configuration establish through the use of the SO_PRIORITY option of the Packet socket family. Since user space cannot access such data structure directly. The QoS development strategy for OF enabling networks is to overcome the packet scheduling issues. The primary goal of QoSFlow is to allow control of multiple packet schedulers. In another word, QoSFlow brings the traffic control of Linux to become part of OF networks. Our proposal extends the OF protocol 1.0 and the standard data path based on it. This way, developers can deploy their applications, for instance, a control of bandwidth according to need with one or more packet schedulers on the network. Currently, QoSFlow provides control of the following packet schedulers: HTB (Hierarchical Token Bucket) [24], RED (Randomly Early Detection) [25], and SFQ (Stochastic Fairness Queuing) [26]. Currently, QoSFlow controls the following packet schedulers: HTB, SFQ, and RED where the HTB is a classfull, while SFQ and RED are classless queuing discipline. Thus, the current QoSFlow features come from these Linux kernel packet schedulers. ? HTB: It allows splitting the bandwidth according to the size of the network. By default, the Linux kernel automatically attaches a FIFO packet scheduler to each bandwidth segment. It creates logical links which are slower than the physical link. ? SFQ: This belongs to fair queuing algorithm. The SFQ schedules the packets transmission based on information about the IPv4/v6 source and destination address, and TCP/UDP source port to assign each flow to each hash bucket, on the enqueueing phase. ? RED: It drops packets in a queue gradually. It performs a tail drop like FIFO, but smartly. Such packet scheduler has a threshold value to mark packets to be discarded after queue length becomes greater than the threshold value. 3. NOX Network operating system (NOX) enables management applications to be constructed as centralized programs over high-level abstractions of network resources as an inverse to the distributed algorithms over low-level addresses [22,23]. The network operating system does not manage the network itself; it provides a programming interface with high-level abstractions of network resources (e.g., memory, disk storage volume, CPU processing power, disk storage volume, link capacity, etc.) that enable network application programs to perform complicated tasks safely and efficiently on a broad heterogeneity of networking technologies [22]. The NOX, however, fails in giving the necessary functions for QoS-guaranteed Software Defined Networking (SDN) [24] service provisioning on bearer grade provider Internet, such as Year 2018 ( ) QoS-aware virtual network seating, end-to-end network QoS measurement, and cooperation among control elements with other domain network. IV. # Comparison among the Existing ARCHITECTURES 1. ROIA a. The Response time of ROIA Quality of Service in Software Defined Networking Figure 3 shows the graph of the calculation of Response Time with ROIA [1] of Table 1. # b. Throughput of ROIA The Figure 4 shows the graph of the calculation of Throughput with ROIA [1] of Table 2. 3. # Conclusion and Future Work Software Defined Network is an emerging topic for the modern era. It is an idea which has recently reignited the interest of network researchers for programmable networks. Enabling added-value services is the major target for this work. Not only this but also ensuring the security is another purpose for this work. Software Defined Networking (SDN) enables an easy and flexible realization of existing dynamic Quality of Service (QoS) mechanisms in today's communication networks. Although SDN and, in particular, OpenFlow claims to provide a standardized interface, the existing diversity of OpenFlow enabled switches leads to different behavior for the same QoS mechanisms. As compared to the response time of existing architectures HTB packet scheduler is better. In case of throughput, SFQ packet scheduler is better. We will improve Quality of Service (QoS) in SDN by designing an efficient architecture and implement that in any network emulator. In the future, we will work with Switch Capacity, Number of Queues Impact, QoE Evaluation, and Bandwidth Isolation. Year 2018 ( ) 1![Figure 1: Structure of a ROIA and its real-time loop](image-2.png "Figure 1 :") 2![Figure 2: QoS module which has been added to the standard OpenFlow datapath ? Traffic Shaping and Packet Schedulers: These components use Netlink socket family to manipulate OFPT_QOS_QUEUEING_DISCIPLINE message type, which is a new extension of the message to represent the QoS messages in OF protocol.Hence, the Traffic Shaping and Packet Schedulers components administer the QoS messages receipt from control plane by splitting the bandwidth size in queues and by attaching or detaching packet schedulers for these queues, respectively.To connect the kernel, these components open a Netlink socket channel and send a Netlink message through it. The Netlink message is the type of message that Linux kernel accepts for network resources management. In this way, the QoS messages maps to Netlink messages.](image-3.png "Figure 2 :") 4![Figure 4: Throughput of ROIA 2. Multiple Packet Scheduler a. The Response time of Multiple Packet Scheduler Figure 5 shows the graph of the calculation of Response Time with Multiple Packet Schedulers [2] of Table3.](image-4.png "Figure 4 :") 5![Figure 5: Response Time of Multiple Packet Schedulers](image-5.png "Figure 5 :") 62![Figure 6: Throughput of Multiple Packet Schedulers](image-6.png "Figure 6 : 2 .") 7![Figure 7: Response Time of NOXThroughput of NOXFigure8shows the graph of the calculation of Throughput with NOX[27] of Table6.](image-7.png "Figure 7 :") 68![Figure 8: Throughput of NOX](image-8.png "Table 6 :Figure 8 :") 91![Figure 9: Response time of Existing Architectures b) ThroughputThe throughput of ROIA is better than of HTB, NOX, SFQ and RED packet scheduler in the transmission of first 24 packets, for other 46 packets Throughput of SFQ packet scheduler is better than ROIA, NOX, RED and SFQ packet scheduler shown in figure10.](image-9.png "Figure 9 : 1") 10![Figure 10: The throughput of Existing Architectures VI.](image-10.png "Figure 10 :") 1ThroughputNumber of(ROIA) inClientsmilliseconds(ms)50.97087100.84033Number of Clients 5 10 15 20 25 30 35 40 45 50Response Time (ROIA) ms 1.03 1.19 1.22 1.35 1.29 1.07 1.48 1.21 1.34 1.0915 20 25 30 35 40 45 50 55 60 65 700.81967 0.74074 0.77519 0.93457 0.67567 0.82644 0.74626 0.91743 0.70422 0.76923 0.86959 0.68965551.42601.3651.15701.45Figure 3: Response Time of ROIA 2Number of ClientsResponse Time (HTB) msResponse Time (SFQ) msResponse Time (RED) ms51.280.10.55102.560.21.1153.840.31.65205.120.42.2256.40.52.75307.680.63.3358.960.73.854010.240.84.44511.520.94.955012.815.55514.081.16.056015.361.26.66516.641.37.157017.921.47.7 4Number of ClientsThroughput (HTB) msThroughput (SFQ) msThroughput (RED) ms50.122060.156250.0284100.2441250.31250.05681150.366180.468750.08522200.488250.6250.113635250.61031250.781250.14204300.7323750.93750.17045350.85443751.093750.19886400.97651.250.22727451.098561.406250.25567501.2206251.56250.28408551.342681.718750.31249601.464721.8750.340905651.586782.031250.36931701.70884.2.18750.39772 3 45Number ofResponse TimeClients(NOX) ms50.7948100.983150.8542200.808250.888300.899350.9585400.97450.787500.9095550.755600.7777650.842700.7888 © 2018 Global Journals 1 © 2018 Global Journals Quality of Service in Software Defined Networking * Improving QoS in Real-Time Internet Applications: From Best-Effort to Software-Defined Networks -IEEE Xplore Document 10 April 2014 * Control of Multiple Packet Schedulers for Improving QoS on OpenFlow/SDN Networking -IEEE Xplore Document 12 December 2013 * NOX: Towards an Operating System for Networks NatashaGude submitted to CCR * Applying NOX to the Datacenter Arsalantavakoli Proc. Of SIGCOMM Hotnet Of SIGCOMM Hotnet 2009 * Software Defined Networking: Meeting Carrier Grade Requirements Dimitristaessens Proc. of IEEE Workshop on Local & Metropolitan Area Networks (LANMAN) of IEEE Workshop on Local & Metropolitan Area Networks (LANMAN) 2011 * Towards network wide QoE fairness using OpenFlow-assisted adaptive video streaming PGeorgopoulos YElkhatib MBroadbent Proc. of the 2013 ACM SIGCOMM Workshop on Future Human-Centric Multimedia Networking of the 2013 ACM SIGCOMM Workshop on Future Human-Centric Multimedia NetworkingHong Kong, China FhMN 2013. 2013 * Dynamic application-aware resource management using software-defined networking: implementation prospects and challenges TZinner MJarschel ABlenk Proc. of the 2014 IEEE Network Operations and Management Symposium (NOMS '14) of the 2014 IEEE Network Operations and Management Symposium (NOMS '14)Krakow, Poland 2014 * Tango: simplifying SDN control with automatic switch property inference, abstraction, and optimization DLazaris XTahara Huang Proc. of the 10th ACM International on Conference on emerging Networking Experiments and Technologies (CoNEXT) of the 10th ACM International on Conference on emerging Networking Experiments and Technologies (CoNEXT)Sydney, Australia 2014 * What you need to know about SDN control and data planes MKuzniar PPeresini DKostic EPFL- REPORT-199497 EPFL 2014 Tech. Rep. * VMPatrol: dynamic and automated QoS for virtual machine migrations VMann AVishnoi AIyer Proc. of the 8th International Conference on Network and Service Management (CNSM) of the 8th International Conference on Network and Service Management (CNSM)Las Vegas, USA 2012 * Taming SDN controllers in heterogeneous hardware environments ZBozakov ARizk Proc. of Second European Workshop on Software Defined Networks (EWSDN) of Second European Workshop on Software Defined Networks (EWSDN)Berlin, Germany 2013 * What you need to know about sdn flow tables," in Passive and Active Measurement, ser. Lecture Notes in Computer Science MKuzniar PPeresini DKostic J. Mirkovic and Y. Liu 2015 Springer International Publishing 8995 * Performance study of TCP flows with QoSsupported OpenFlow in data center networks PMMohan DMDivakaran MGurusamy Proc. of the 19th IEEE International Conference on Networks (ICON) of the 19th IEEE International Conference on Networks (ICON)Singapore; Singapore 2013 * Investigating isolation between virtual networks in case of congestion for a Pronto 3290 switch ANguyen-Ngoc SLange SGebert Proc. of the Workshop on Software-Defined Networking and Network Function Virtualization for Flexible Network Management of the Workshop on Software-Defined Networking and Network Function Virtualization for Flexible Network ManagementCottbus, Germany SDNFlex 2015. 2015 * PolicyCop: an autonomic QoS policy enforcement framework for software defined networks MFBari SRChowdhury RAhmed RBoutaba IEEE SDN for Future Networks and Services November 2013 * Achieving high utilization with software-driven WAN CYHong Proceedings of the ACM SIGCOMM the ACM SIGCOMMHong Kong, China 2013 * OpenQoS: an openflow controller design for multimedia delivery with end-to-end Quality of Service over Software-Defined Networks HEEgilmez STDane KTBagci AMTekalp Proceedings of the Signal and Information Processing Association Annual Summit and Conference the Signal and Information Processing Association Annual Summit and ConferenceHollywood, California, US December 2012 * Falloc: fair network bandwidth allocation in IaaS data centers via a bargaining game approach JGuo LFangming THaowen LYingnan JHai LJohn Proceedings ofthe ICNP the ICNPGotingen, Germany October 2013 * CloudNaaS: a cloud networking platform for enterprise applications TBenson AAkella AShaikh SSahu Proceedings of the 2nd ACM Symposium on Cloud Computing the 2nd ACM Symposium on Cloud ComputingCascais, Portugal 2011 * B4: Experience with a globallydeployed software defined WAN SJain ACMSIGCOMM Comput. Commun. Rev 43 4 2013 * Automated and scalable QoS control for network convergence WKim Proceedings of the INM/WREN the INM/WRENSan Jose, California, US 2010 * Dolin and others MBetts SFratini NDavis R Open Networking Foundation ONF SDN ARCH 1 June, 2014 SDN Architecture * An Architeture with Automatic Load Balancing for Real-Time Simulation and Visualization Systems MJoselli Journal of Computational Interdisciplinary Sciences 1 3 2010 * BertHubert ThomasGraf GregoryMaxwell Remco Van Mook, Martijn Van Oosterhout, Paul B * JasperSchroeder PedroSpaans Larroy Linux Advanced Routing & Traffic Control HOWTO. Linux Advanced Routing & Traffic Control April 2004 * Random early detection gateways for congestion avoidance. Networking SallyFloyd VanJacobson IEEE/ACM Transactions on 1 4 1993 * The Multiple Facets of Integration' EPaul Mckenney INFOCOM'90. Ninth Annual Joint Conference of the IEEE Computer and Communication Societies IEEE 1990 Stochastic fairness queueing * On Scalability of Software-Defined Networking -IEEE Xplore Document 14 February 2013