Buletinul Stiintific al Universitatii "Politehnica" din Timisoara Seria ELECTRONICA si TELECOMUNICATII TRANSACTIONS on ELECTRONICS and COMMUNICATIONS Tom 47(61), Fascicola 1-2, 2002 Developing QoS-aware Applications in LANs Daniel Zinca 1 , Virgil Dobrota 1 , Cristian Mihai Vancea 1 , Gabriel Lazar 1 1 Technical University of Cluj-Napoca, Department of Communications, 26 Baritiu Street, 3400 Cluj-Napoca, Romania, Tel/Fax:+40-264-197083 e-mail: {Daniel.Zinca, Virgil.Dobrota, Mihai.Vancea}@com.utcluj.ro, gabi_l@email.ro Abstract – One of the methods used towards End-to-end QoS (Quality of Service) is to develop QoS-aware applications. The purpose of this paper is to investigate how feasible this solution is with tools available today and to draw some conclusions from the testbed used. Keywords: QoS, IntServ, RSVP, DiffServ I. INTRODUCTION In addition to data-only applications, LANs are now facing the convergence of video and voice applications. There is the need to ensure a minimum sustenable rate and low delay and delay variation for certain applications. One possible method for solving these requirements is overprovisioning. When overprovisioning is not possible, more efficient methods can be used, grouped in two main QoS categories, as defined by IETF: Integrated Services (or IntServ) Differentiated Services (or DiffServ). There are two important issues towards the process of QoS implementation in today’s LANs. The first one is to ensure the support from the network infrastructure (routers running appropriate routing protocols, other network equipment like Layer 2 switches with IEEE 802.1D Class of Service). The second is the development of QoS-aware applications and the need for a specification (QoS API) enabling the programmers to request specific parameters from the network. Several QoS API were developed, mainly as extensions of classical socket implementations. For the Linux environment, one of the proposed implementations of a QoS API is described in [11]. Another QoS API was proposed by Microsoft as an extension to Windows Sockets [9] running on Windows 2000 operating software. Support for QoS exists in MS Windows 98 and Windows XP but in a simpler implementation. This paper is focused on describing the steps for the development of QoS applications using Microsoft’s implementation. Generally there are three perspectives of Quality of Service: the application perspective, the network perspective and the business perspective[10]. From the application perspective, QoS represents the ability to serve an application without affecting its performance or functionality. From the network perspective, QoS is represented by several parameters that can be influenced and measured: bandwidth, delay, jitter and packet loss. From the business perspective, QoS represents the resources that can be guaranteed to each user. This paper focuses on the application perspective, enabling the application/user to request specific values of QoS parameters . The remainder of the paper is organized as follows: Section II- Developing a QoS application using Windows Sockets describes the steps towards creating a QoS application, Section III- Implementing the QoS solution, describing the network testbed and commands implemented on the router and Section IV- Conclusions presenting observations based on the results for the tests performed. II. DEVELOPING A QoS APPLICATION USING WINDOWS SOCKETS The Microsoft implementation of QoS in Windows 2000 has three categories of components: - Application-Driven QoS Components - Network-Driven QoS Components - Policy-Driven QOS Components The QoS support in MS Windows 2000 is based on RSVP signalling and Admission Control Service (ACS) therefore implements IntServ. It also makes use of the IEEE 802.1D user_priority field. Also a policy-driven QoS is available. Multimedia applications make use of PATH respectively RESV RSVP messages. One example is Microsoft NetMeeting. The RSVP SP (Service Provider) is available to the user by the means of QoS API, mainly used for creating a flow of data transmitted preferentially through the network. Therefore the preferred solution in Microsoft Windows 2000 is IntServ but is possible to use DiffServ by modifying the Flowspec structure.