An Experimental QoS Manager Implementation

Transcription

1 An Experimenal QoS Manager Implemenaion Drago Žagar, Goran Marinović, Slavko Rupčić Faculy of Elecrical Engineering Universiy of Osijek Kneza Trpimira 2B, Osijek Croaia Absrac-- Qualiy of Service (QoS) in he communicaion nework becomes he mos imporan elemen for he implemenaion of new and demanding applicaions. This paper describes differen phases of he mulimedia communicaion, which includes QoS negoiaion, ranslaion, scaling and resource admission. The main principles of QoS archiecures, wih special aenion paid o QoS in IP neworks are given. Applicaions for QoS negoiaion and provision of he negoiaed QoS are developed and described. The experimenal implemenaion of he QoS sysem for serving he users by some defined characerisics (known in advance) of he received services are described and analyzed. Key-Words: - Qualiy of Service; egoiaion; Communicaion; IP eworks; QoS Manager; QoS Parameers 1 Inroducion By combining an ineraciviy and mulimedia we could obain a huge diversiy of possible services, from exended funcionaliy of curren applicaions o new virual realiy applicaions. The recen researches in digial coding and signal compression, broadband communicaions and digial signal processing ranslae he ineracive mulimedia services from vision o realiy, and herefore claim new demands on he nework infrasrucure. The specificaion of QoS parameers` values deermines he ype of service. We could disinguish a leas hree differen ypes of services: guaraneed, predicive and bes-effor [3]. The guaraneed services enable QoS guaranees because of heir specific (limied) QoS parameer values, eiher in deerminisic or in saisic represenaion. Deerminisic limiaions could be given by some single value (e.g. mean value, negoiaed value, sar value, arge value ), a pair of values (e.g. minimum and mean value, he lowes and arge qualiy ) and he inerval of values (e.g. a lower border is he minimum and a higher border is he maximum value). The guaraneed services could also deal wih saisical QoS parameer borders, as e.g. saisical border of he error level. The predicive (hisorical) services are based on he prior nework behavior, and herefore he QoS parameers will be esimaed by previous service values. The bes-effor service is based on a parial or none guaranees. The QoS parameer values are generally no necessary bu could be defined by some deerminisic or saisic border values. Mos of he currenly used nework proocols offer bes-effor services. In order o regularly operae, he services for mulimedia-neworked applicaions use resources. Resources of special ineres are resources ha could be shared beween he applicaions, he sysem and he nework, as e.g. CPU cycles or nework bandwidh. I is imporan o emphasize ha all resources ha could be shared by many processes in every layer of he Mulimedia Communicaion Sysem (MCS) could be a par of hree main sysem resources: bandwidh of he communicaion channel, buffer space and CPU power. QoS parameers specify he amoun of resources dedicaed o services, whereas queueing disciplines manage he shared resources of MCS (e.g. QoS laency parameer defines service ransmission beween he source and he desinaion by respecing he packe disribuion (bandwidh assignaion), queueing (buffers assignaion) and scheduling (CPU cycles assignaion)). The defined relaion beween QoS and he resources is buil in resource managemen in erms of differen mappings beween QoS parameers and heir relaed resources. The descripion of possible realizaion of resource managemen and resource sharing shows he relaion beween he QoS and he resources. Here we should emphasize ha he resource managemen and resource sharing are based on he ineracion beween cliens and heir resource managers. The clien requires resource assignaion by specifying QoS (his implicily includes mapping beween QoS specificaions and he requesed resource). The resource manager verifies he use of resources and decides o accep or no he reques for resource reservaion. All acive reservaions saes are saved, and sharing of every single resource is herefore guaraneed. ISSN: ISBN:

2 This paper describes an experimenal implemenaion of he QoS nework manager for serving he user wih guaraneed services on demand. Characerisics of he used media will be analyzed, and developed applicaions for negoiaion and ensuring he desired qualiy of service beween he server and cliens will be described. The main classes of developed applicaions as well as he connecions beween applicaions objecs will be described. 2 QOS EGOTIATIO If we presume ha he user has defined requess for mulimedia applicaion, hese requess should be disribued o all resource manager eniies involved in sysem. The QoS parameer disribuion requires wo services: negoiaion abou QoS parameers and QoS parameer adapaion (if differen sysem componens have differen QoS specificaions). If we wan o characerize he real negoiaion, we should define he negoiaion sides, and how hey do negoiaion. Every QoS negoiaion has wo sides. We will analyze he peer-o-peer negoiaion, which could be negoiaion beween he applicaion and he sysem, or negoiaion beween he user and he applicaion. The aim of he negoiaion process is o deerminae common QoS parameer values beween he service user and he service provider. Furhermore, we assume he QoS negoiaion where he QoS parameer values are deermined by deerminisic borders (minimum and mean value). We could disinguish several ypes of negoiaion beween he service user (caller, callee) and he service provider [3]: Bilaeral Peer-o-Peer negoiaion This ype of negoiaion, carried ou beween wo service users (peers), and he service provider, is disabled o modify he QoS value proposed by he user. Bilaeral Layer-o-Layer negoiaion This ype of negoiaion is performed exclusively beween he service user and he service provider and covers wo possibiliies: 1. Beween he local service user and he service provider; 2. Beween he main compuer-sender and he nework, e.g. when he sender wans o ransmi he mulimedia flows. Unilaeral negoiaion By his negoiaion, he service provider as well as he called user is no allowed o change he QoS proposed by he caller. This ype of negoiaion is reduced o ake i or leave i. Furhermore, his negoiaion also enables ha receiver could accep he proposed QoS alhough i canno accep all QoS parameers and so i can paricipae in communicaion only wih lower QoS. Hybrid negoiaion The broadcas/mulicas communicaion implies ha every receiving hos could have differen possibiliies han he sending hos (conference session). Therefore, he QoS parameer values could be negoiaed beween he sender hos and he nework, by using bilaeral layero-layer negoiaion and simple negoiaion beween he nework and he receiving hos. Triangular negoiaion for informaion exchange By his ype of negoiaion he user caller inroduces he iniial reques by mean values of he QoS parameers. These values could be changed by he service provider/callee across he daa pah by indicaion/reacion before seing he final value in confirm message. A he end of he negoiaion process boh sides have he same value of QoS parameers. Triangular negoiaion for bounded arge This ype of negoiaion is very similar o he former, wih disincion ha he QoS parameer values are se by wo values: he desired QoS value (mean value) and he lowes accepable value (minimum value). The arge is negoiaed abou he desired QoS value, i.e. he service provider is no allowed o change he lowes accepable QoS value (if his value canno be assured, he connecion will be rejeced), bu i could change he desired QoS value. The callee will decide abou he final QoS value, and ha value will be repored o he caller. Triangular negoiaion for agreed value In his case QoS parameers are specified hrough he minimum requesed value and he border value. The aim of his ype of negoiaion is o agree he QoS value, which is he lowes required value of he QoS parameer. The service provider could change he lowes required QoS value oward he border value. The final decision is on he callee and informs he caller by answer/acknowledgemen. Only few proocols for call esablishmen have buil in negoiaion mechanisms. ST-II (Inerne Sream Proocol, Version 2) enables an end-o-end guaraneed service hrough he Inerne. I uses riangular negoiaion for bounded values for parameers concerning a hroughpu. The parameers concerning laency are no negoiaed. 3 A EXPERIME ATAL QOS ETWORK As an experimenal QoS nework for serving he users by services on demand we have used he hree compuers conneced in he Inrane nework. To enable he effecs of differen classes of services by differen load in he nework we have used Bandwidh Conroller Version.15 bea. Two compuers were insalled as cliens and he hird one was insalled as server. All compuers were driven by he Microsof Windows OS. ISSN: ISBN:

3 The raffic on a single compuer has been moniored by Nework Traffic Analyzer, by which we have moniored he bandwidh, packe size disribuion and used proocols. To analyze he packes we have used Ehereal Nework Proocol Analyzer ver..1 and MaaTec Nework Analyzer ver On he server we have creaed a Microsof Access daabase used for user auhorizaion, definiion of predefined QoS values and some oher daa abou users. The daabase includes wo ables: services and users. Table services consis of ype, label and service prioriy, while able users consis of users daa (user name, label of aciviy, he bes allowed QoS and he maximum allowed bandwidh dedicaed o he user). During he raffic monioring all cliens were conneced o he server, and reproduced he sreaming video daa using Windows Media Player ver. 8.. The Qualiy of Service beween cliens and he server has defined by QoSServer and QoSClien applicaions. The applicaions QoSServer and QoSClien have been developed for Microsof Windows OS. For communicaions beween QoSServer and QoSClien we have used he conrol messages (Chaper V.). For he conrol of parameers se on he server we have used Traffic Conrol. To se up he negoiaed QoS we have used Traffic Conrol Inerface (TCI). To iniiae he TCI we had o call he TcRegiserClien funcion ha connecs our applicaion o TCI. Aferwards we had o se he filer for he flow. In applicaions ha use Resource ReserVaion Proocol, RSVP signalizaion calls he basic conrol in local TC (Traffic Conrol) componens by using TCI. The applicaion enabling QoS Traffic conrol (Traffic.dll) TCP/IP layer Nework inerface Packe clasifier QoS packe scheduler informaion from flowspec o creae he flow wih defined QoS parameers, and han creaes filers for direcing he seleced packe ino ha flow (known as filerspec) (Figure 1.). TC API is a programming inerface o flow conrol componens ha regulae nework raffic on he server. I enables aggregaion of raffic from many sources (on he same server) in one TC flow (e.g. all raffic for desinaion address could be placed in he same flow, regardless of he sending and receiving pors. 4 QoSSERVER QoS Server applicaion negoiaes wih users abou he desired QoS and ses he negoiaed qualiy of service beween he server and he user. This applicaion checks he daa abou he user in he daabase and compares he requesed QoS wih maximum allowed QoS for he specified user. Afer ha QoSServer negoiaes wih he user and ses negoiaed QoS beween he clien and he server (Fig. 2.). Descripion of classes and mehods CDBConn Class This class is used for connecion o and communicaion wih he daabase. CDBConn() and CDBConn(CSring sds, CSring suid, CSring spwd) are class consrucors by which he applicaion connecs o daabase. The second consrucor for parameers akes he name of he ODBC connecion for daabase (which is defined in QoSServer.ini file), as well as he username and he password. CDBUserLisDlg Class This class is used for adding and deleing users in daabase and he overview of users in daabase. CQoSServerDlg Class The class CQoSServerDlg is used o connec he server and he clien, o manage he messages coming from he clien, o check he auhorizaion of he clien and o negoiae beween cliens and he server. Ccmon Class This class is used o se he negoiaed QoS beween he server and he clien. mysocke Class This class uses Windows socke API for connecing he server and cliens. Fig. 1. Componens of Traffic Conrol The key elemen of TC is seing he parameers for flow specificaion (flowspec) and afer ha TC reas all packes from one group as one single flow. TC uses he 5 QoSCLIE T The QoSClien applicaion enables he user o define he required QoS and he ype of negoiaion wih he server. This applicaion suppors he following negoiaions: unilaeral, bilaeral layer-o-layer, riangular for informaion exchange and riangular for bounded values. ISSN: ISBN:

4 CLisCrl CLisCrlEx CQoSServerDlg CTCPMessag Daa Base CUsersLis CDBUserLisDlg CTCPMessageHandler CClienMsg CDBConn mysocke Receiving daa from QoSClien and Sending daa o QoSClien CODBCColumnInfo CTcmon Inheriance Communicaion beween Fig. 2. Relaions beween objecs in QoSServer CTCPMessage CTCPMessage CQoSClienDlg CQoSClienDlg CAdvancedParamsDlg CAdvancedParamsDlg CClienMsg CClienMsg mysocke mysocke CTCPMessageHandler CSendFlowDlg CTCPMessageHandler CSendFlowDlg Receiving daa from Receiving QoSServer daa from QoSServer and Sending daa o QoSServer CRecvFlowDlg CRecvFlowDlg Inheriance Communicaion beween Fig. 3. Relaions beween objecs in QoSClien The required QoS could be defined for incoming and oucoming flow. Because of ha QoSClien applicaion sends a reques for QoS o he server ha afer he negoiaion ses he negoiaed flow, he incoming flow (Receiving Flowspec) in QoSClien applicaion acually represens he oucoming flow on he server, and he oucoming flow (Sending Flowspec) in QoSClien applicaion represens he incoming flow on he server. Besides he basic QoS parameers here could also be defined he addiional parameers for every single flow (Fig. 3., Fig. 4.). Fig. 4. The basic QoSClien inerface ISSN: ISBN:

5 5.1 Descripion of he classes and he mehods CadvancedParmsDlg Class is used for definiion of addiional QoS parameers. CqoSClienDlg Class is used for connecion and communicaion beween he server and he clien, managemen of messages coming from he server, collecion and sending of he required QoS parameers o he server, definiion of he negoiaion mode and negoiaion wih he server abou he required QoS. CrecvFlowDlg Class is used for QoS parameers definiion for he incoming flow. CsendFlowDlg Class is used for QoS parameers definiion for he oucoming flow. Criang egodlg Class is used for definiion of he lowes accepable value of he QoS parameer for riangular negoiaion for he bounded arge. Mysocke Class uses Windows Sockes API for connecing he server o he cliens. 6 EXPERIME TAL RESULTS 6.1 The server During raffic monioring wo clien applicaions have been conneced o he server. Boh cliens played he video sream from he server. One of he applicaions had se Guaraneed class of service (Clien 1), and he second had se Bes Effor class of service (Clien 2). If he qualiy of service is no defined, all users use he necessary bandwidh (if available) for he bes possible daa ransmission. The server behaves as if all conneced flows had defined Bes-effor service. Fig. 5. and Fig. 6. show ha he engaged resources (bandwidh) on he server are larger han when he QoS parameers for he cliens are se. This difference is a consequence of Clien 1 having bandwidh se on 8. Byes/sec, using Guaraneed service, while Clien 2 has bandwidh se on 16. Byes/sec, using Bes-effor service. Figure 5. shows ha he engaged bandwidh is abou 24. Byes/sec, and in some momens i suddenly raises or falls. These changes are a consequence of differen ypes of services defined on cliens. Byes/sec :27:12 11:27:42 Packes 11:28:12 11:28:42 11:29:13 11:29:43 11:3:12 11:3:44 11:31:14 11:31:42 11:32:12 11:32:43 11:33:13 11:33:42 11:34:13 11:34:43 11:35:12 11:35:42 11:36:12 11:36:43 11:37:12 11:38:1 11:38:4 11:39:1 11:4:13 Fig. 6. Bandwidh on he server QoS se up 11:4:43 11:41:13 11:41:44 11:42:13 11:42:43 Fig. 7. Packes size disribuion QoS no se up Packes Fig. 8. Packes size disribuion QoS se up By comparing Figures 7. and 8. we can conclude ha he number of larger packes ( > 124 byes) is significanly decreased, and he number of smaller packes is increased when he QoS is se up byes byes byes byes byes > 124 byes -64 byes byes byes byes byes > 124 byes 35 Byes/sec :38:29 9:39:4 9:39:39 9:4:14 9:4:49 9:41:24 9:41:59 9:42:34 9:43:9 9:43:44 9:44:19 9:44:54 9:45:29 9:46:4 9:46:39 9:47:14 9:47:49 9:48:24 9:48:59 9:49:34 9:5:9 9:5:44 9:51:19 9:51:54 9:52:29 9:53:4 9:53:39 9:54:14 9:54:49 Fig. 5. Bandwidh on he server QoS no se up Fig 9. Flow parameers for Clien 1 ISSN: ISBN:

6 6.1 QoS parameers for Clien 1 Fig.9. shows QoS parameers defined for Clien 1. If he QoS is no defined Clien 1 parially uses he bandwidh greaer han 35. Byes/sec. Figure 9. shows ha by he defined qualiy of service he used bandwidh never exceeds 8. Byes/sec, which is he defined bandwidh value for Clien 1 (Guaraneed class). Byes/sec Fig 1. Bandwidh for Clien 1 QoS no se 6.1 QoS parameers for Clien 2 For Clien 2 he defined ype of service was Bes-effor, which uses defined parameers as direcions for qualiy of service bu does no guaranee anyhing. When he QoS is no defined, he daa are ransferred hrough he nework as bes-effor service, bu by low level nework load, as in our experimenal nework, he difference in he used bandwidh is negligible. Byes/sec :1:1 9:1:5 9:2:3 9:3:1 9:3:5 9:4:3 9:5:1 9:5:5 9:6:28 9:6:48 9:7:8 9:7:28 9:7:48 9:8:8 9:8:28 9:8:48 9:9:8 9:9:28 9:9:48 9:1:8 9:1:28 9:1:48 9:11:8 9:11:28 9:11:48 9:12:8 9:12:28 9:12:48 9:13:8 9:13:28 11:29:46 11:3:11 11:3:36 11:31:1 11:31:26 11:31:51 11:32:16 11:32:41 11:33:6 11:33:31 11:33:56 11:34:21 11:34:46 11:35:11 11:35:36 11:36:1 11:36:26 11:36:51 11:37:16 11:37:41 11:38:6 11:38:31 11:38:56 11:39:21 11:39:46 11:4:11 11:4:36 11:41:1 11:41:26 11:41:51 11:42:16 Fig.11. Bandwidh on Clien 1 QoS se up 7 Conclusion This paper deals wih qualiy of service realizaion and experimenal implemenaion in he communicaion nework. Qualiy of service is of grea ineres when ransmiing sensiive real-ime daa, as e.g. video and audio. If we could define and se he QoS parameers o achieve a prerogaive reamen of our daa, hen we could achieve he adequae qualiy for our applicaions. To achieve end-o-end qualiy of service i is very imporan ha all nework componens suppor he QoS proocols. Ineracive mulimedia services will be more and more available, bu ouside necessary hardware requess, hese new sysems will succeed only if a user inerface will be user-friendly (even he users wihou echnical knowledge), if he qualiy of service will be of saisfacory level, if he conens will be versaile and if he service price will be accepable for majoriy. I is obvious ha he users will be saisfied wih he guaraneed qualiy of service, bu his class of service allocaes maximum sysem resources and herefore i is mos expensive. If he users will no pay for he qualiy of service, hey will always ask for he bes possible QoS. Tha leads o service diminuion and o well-known bes-effor service. By inroducing he appropriae QoS accouning he QoS negoiaion will become he real mehod for QoS achievemen. This paper inroduces an experimenal implemenaion of he QoS sysem wih some guaraneed services on demand. Characerisics of he used audio and video were analyzed, and applicaions for negoiaion and ensuring he desired qualiy of service beween he server and cliens were developed. The main classes of developed applicaions as well as he connecions beween applicaion objecs were described. Experimenal measuremens show ha for some specific daa flow (video daa) wih he defined Guaraneed ype of service, parameers affecing he QoS will be mainained wihin defined borders. The idenical flow having defined Bes-effor service will receive an accepable service in he lighly loaded nework and an unaccepable service in he heavy loaded nework. References: [1] Y. Berne. eworking Qualiy of Service and Windows Operaing Sysems November 21 [2] MSD January 23 [3] Seinmez R., Klara Nahrsed. Mulimedia: Compuing, Communicaions, and Applicaions, Prenice Hall, July [4] Y. Berne, J. Sewar, R. Yavakar, D. Andersen, C. Tai, B. Quinn, K. Lee. Winsock Generic QOS Mapping,1998 [5] T. Zahariadis, C. Rosa, M. Pellegrinao, A. Bjork Lund, G. Sassinopoulos. Ineracive Mulimedia Services o Residenial Users June 1997 [6] M. Albrech, M. Kőser, P. Marini, M. Frank. Endo-end QoS Managemen for Delay-sensiive Scalable Mulimedia Sreams over DiffServ November 2 [7] A. Vogel, B. Kerhevé, G. v. Bochmann, J. Gecsei. Disribued Mulimedia and QOS: A Survey 1995 [8] W.F.Poon, K.T. Lo, J. Feng. Firs segmen pariion for video-on-demand broadcasing proocols, 22 [9] J. Peloniemi. Video-on-Demand Overview, 1995 [1]A.Iyer. A Sudy of IP QoS, hp://qos.ic.ukans.edu/sudy/mainpage.hml [11] G.Armiage. Qualiy of Service in IP eworks: Foundaions for a Muli-Service Inerne, 2 ISSN: ISBN: