APPROACHES FOR PROVIDING QUALITY OF SERVICE IN ...

APPROACHES FOR PROVIDING QUALITY OF SERVICE IN MULTIMEDIA NETWORKSDan Mancas 1 , Adrian Neatu 1 , Dan Tusaliu 1 , Adina Basandica 21 University of Craiova, 2 High School “G. Bibescu” CraiovaAbstract: Quality of Service (QoS) is a fast growing area of technology, being driven bythe growth of multimedia applications such as videoconference or voice over IP. In thefirst section of this paper there are presented different approaches for providing Qualityof Services in networks with multimedia traffic. In the second section there are presentedthe results of the QoS performance evaluations performed on a test network based onCisco routers.Keyword: Quality of Service, multimedia traffic, active queue management, fair queuing,resource reservation.1. APPROACHES ON QoSIt is commonly accepted, that the Quality of Service(QoS) concept is of central importance for distributedmultimedia systems. From the communications pointof view, the main concern is how to support QoSrequirements by networks, protocols, and operatingsystems. However, with respect to QoS inmultimedia systems it is necessary to consider morethan communication system and operating system,because most multimedia systems do not onlymanipulate and transmit multimedia data.Additionally, they store and retrieve multimedia data,and present them in a proper way to the user.However, the relevance of database managementsystem aspects for QoS in multimedia systems hasnot been broadly recognized.Traditional computer architecture research hasfocused primarily on the design and performance ofindividual machines. With the increasing importanceof network technology and multimedia interfaces,future architectures will span machine boundariesand will need to provide adequate support for timecriticaloperations.Video Conferencing, Video-on-Demand and IPtelephony are few successful commercial networkedapplications. Those that have timeliness constraintsare called real-time applications. Among real-timeapplications there are those that are tolerant orintolerant depending on whether they can tolerateoccasional loss. Such real-time applications arecompeting with traditional Internet applications –email, file transfer for network level resources suchas bandwidth and queue buffers. They demand highbandwidth and assurance of timeliness of datadelivery from the underlying networkThe current Internet architecture, offers a simplepoint-to-point best-effort service. Multimediaapplications (e.g., remote video-on-demand,multimedia conferencing etc.) require different typeof services and need application specific Quality ofService (QoS) to perform to the required standards.Thus, Quality of Service (QoS) gains importance inthe event of multimedia and real time applications.Many of multimedia applications are sensitive to theQoS rendered to it by the underlying networkarchitecture and their performance degrades rapidlyin the event of a failure to provide the required QoS.For a network to deliver appropriate quality ofservice, it must go beyond the best-effort servicemodel and to allow multimedia traffic to reservenetwork resources and to provide preferentialrouting.Today’s computer users are becoming more andmore sophisticated, demanding richer machineinterfaces. This is evidenced by the fact that“multimedia” has become a trendy buzzword used tohype seemingly every new computer product to hitthe marketplace. In response many researchers areinvestigating the best means to make desktop audioand video a reality, and this area is beginning tomature. The MPEG I, II, III and IV coding standardsnow enjoy widespread acceptance, and numerousvendors market hardware implementations. There arestill unresolved issues, e.g. synchronization, qualityof service (QoS) guarantees, transport and storagemechanisms, etc.

switching. We call this architecture a combined inputand output queued (CIOQ) switch.Both analytical and simulation studies of a CIOQswitch which maintains a single FIFO at each inputhave been conducted for various values of speedup(Iliadis and Denzel, 1990; Gupta and Georganas,1991; Oie et al., 1989; Chen and Stern, 1991). Acommon conclusion of these studies is that with S =4 or 5 one can achieve about 99% throughput whenarrivals are independent and identically distributed ateach input, and the distribution of packet destinationsis uniform across the outputs.But it has been shown that a throughput of 100% canbe achieved with a speedup of just one, if we arrangethe input queues differently. That is, HOL blockingcan be eliminated entirely using a scheme known asvirtual output queuing in which each input maintainsa separate queue for each output. It has been shownthat for independent arrivals, the throughput of an IQswitch can be increased to 100% (McKeown et al.,1996). We may draw the conclusion: Speedup is notnecessary to eliminate the effect of HOL blocking.In practice, the users are not only interested in thethroughput of a switch, but also in the latency ofindividual packets. This is particularly important if aswitch or router is to offer QoS guarantees. Packetsin an IQ switch not only contend for an output, theyalso contend for entry into the switch fabric withpackets that are destined for other outputs. We callthis phenomenon input contention. Each input candeliver only one packet into the fabric at a time; if ithas packets for several free outputs, it must choosejust one packet to deliver, holding other packetsback. This places a packet at the mercy of otherpackets destined for other outputs. This is in starkcontrast with output-queuing, where a packet isunaffected by packets destined for other outputs. Itcan be drawn the conclusion: to control the delay, amechanism to eliminate input contention is needed.While the scheduling schemes can provide a fairbandwidth allocation with complicated structures, thequeue management mechanisms, although simpleand easy to implement, usually fail to provide fairservice. The queue management schemes, such asDrop Tail and RED, are designed to control thequeue length by dropping packets when necessary. Itis well known that the widely deployed Drop Tailmethod can cause the “Lock Out” and “Full Queue”problems (Braden et al., 1998). RED, an active queuemanagement algorithm, was proposed to solve theseissues (Floyd and Jacobson, 1993). By keeping theaverage queue size small, RED avoids the biasagainst burst traffic and reduces the delaysexperienced by most flows. RED drops the arrivalpackets randomly based on the average queue size. Inthis way, it avoids the problem of globalsynchronization, where many flows reduce theirwindow size at the same time. However, like DropTail, RED doesn’t penalize unresponsive traffics. Aflow's fraction of the aggregate packet drops roughlyequals to its fraction of the aggregate arrival rate. Inother words, the percentage of packets dropping foreach flow over a period of time is almost the same.Consequently, misbehaving traffics could take up alarge percentage of the link bandwidth and starve outthe TCP friendly flows.To improve RED's capability of handlingunresponsive users, a few methods have beenproposed, for instance, Flow Random EarlyDetection (FRED) (Lin and Morris, 1997) and REDwith penalty box (Floyd and Fall, 1997). Eventhough these two router mechanisms do not requireper-flow states, they all need extra data structures tocollect certain types of state information. FREDkeeps per-active-connection states and RED withpenalty box stores information about unfriendlyflows.All the schemes discussed so far drop packetswithout examining them. A new RED mechanismcalled Stabilized RED (SRED) suggests an idea ofcomparing the arriving packet with a randomlychosen packet that recently preceded it into the buffer(Ott et al., 1999). The scheme maintains a datastructure, "Zombie List", which keeps theinformation regarding recently seen flows. TheSRED router estimates the number of active flowsbased on “Zombie List”. When a packet arrives at theSRED router, it is compared against a randomlychosen packet from the “Zombie List”. The arrivingpacket is dropped randomly based on the packetcomparison result and the estimation of the numberof active flows. The dropping probability increases ifthe active flow estimation is bigger or packetcomparison ends in matching. In this way, SREDpenalizes the unfriendly flows and controls the bufferlength independent of the number of active flows.However, this scheme needs a large “Zombie List”data structure.From the discussions above, we can see that there aregenerally two trends in search of solutions to theproblem of unfriendly flows. One trend is based onthe almost perfect fair queuing. In this group, routeralgorithms are proposed to reduce FQ’s designcomplexity while keeping FQ’s good feature of maxminfair bandwidth allocation. The other trend isbased on RED. Several methods are suggested toimprove RED’s capability of handling misbehavingusers. However, all the schemes discussed so far failto provide fairness with a minimum overhead.2. PERFORMANCE EVALUATION TESTS ONQoSAll QoS performance evaluation tests wereperformed in a Cisco based network environment,shown in figure 1.

Router 5Router 3Router 4100 BASE T100 BASE TSwitch BLAN BISDN Switch A SwitchLAN ARouter 1Router 2COMPETENCE CENTREFOR NETWORK MANAGEMENTFig 1. Test networkRouter 1 to router 4 are Cisco 2610, router 5 is aCisco 2611, and switches A and B are Cisco Catalyst2900 XL. QoS was configured on each router indifferent scenarios. The multimedia traffic wasgenerated using real time applications such asvideoconference, as well as a traffic generatordeveloped within our competence centre. Themeasurements were made using a sniffer machine.The results of the performance evaluation for CustomQueuing and Weighted Fair Queuing are presentedbelow.2.1 Custom QueuingTabel 1.Portaddr.transmittedtraffic rate AKbpstransmittedtraffic rate BKbpstransmittedtraffic rate CKbpsTx Rx Tx Rx Tx Rx20 30 30 35 35 60 4580 10 10 20 14 50 725 5 5 15 6 45 3Router configuration command:Global configuration mode:queue-list 1 protocol UDP 1 port 20queue-list 1 protocol UDP 2 port 80queue-list 1 protocol UDP 3 port 25queue-list 1 default 10queue-list 1 queue 1 limit 100 byte-count70*packet_lengthqueue-list 1 queue 2 limit 100 byte-count20*packet_lengthqueue-list 1 queue 2 limit 100 byte-count10*packet_lengthISDN Interface configuration mode:custom-queue-list 1Kbps50403020100Custom queuing - case Bport 20 port 80 port 25Transmitted BReceived BFig. 2. CQ – Protocol Distribution BThe queuing is „weighted fair“. The ftp flow passeswith the highest priority. Although, email will notlonger starve for bandwidth, the email will work(slower than http because has lower queuingpriority). For each flow, a maximum bandwidth isdefined. But no bandwidth remains unused.

Custom queuing - case CIP precedence bandwidth distribution -case B50504040Kbps3020Kbps302010100port 20 port 80 port 2507 3 0Transmitted BReceived BTransmitted BReceived BFig. 3. CQ – Protocol Distribution CThe ftp port has the highest priority, although thebandwidth it uses can nod be greater than themaximum imposed by the CQ parameters (bytecount) configuration. The rest of the bandwidth isdistributed “fair” to the other flows in such a way,that no one will starv for bandwidth.2.2 Weighted Fair QueuingTable 2.Ipprec.transmittedtraffic rate AKbpstransmittedtraffic rate BKbpstransmittedtraffic rate CKbpsTx Rx Tx Rx Tx Rx7 30 30 40 37 60 333 10 10 13 13 50 170 5 5 15 4 45 4Router configuration command:ISDN Interface configuration mode:fair-queueWFQ is QoS signaling aware.8 + 4 + 1 = 13.The bandwidth is ~56Kbps. Therefore, the reservedbandwidths are:56 x 8/13 = ~34;56 x 4/13 = ~17;56 x 1/13 = ~4;Fig. 4. WFQ - Distribution B.The second flow (IP priority = 3) does not use theentire bandwidth that was reserved for him, so thisremaining bandwidth is used by the first flow (IPpriority = 7). This was an automated WFQ decision.KbpsIP precedence bandwidth distribution -case C60504030201007 3 0Transmitted CFig. 5. WFQ - Distribution C.Received CNo flow can use more than the bandwidth that wasreserved for it at the interface configuration time. So,no flow will starv, if the device was properlyconfigured.REFERENCESBraden, B. etc, (1998) Recommendations on queuemanagement and congestion avoidance in theInternet. IETF RFC (Informational) 2309.Chen, J.S.-C. and Stern, T.E.(1991). Throughputanalysis, optimal buffer allocation, and trafficimbalance study of a generic nonblocking packetswitch. IEEE J. Select. Areas Communications,vol. 9, no. 3, p. 439-49.

Floyd, S. and Jacobson, V. (1993). Random EarlyDetection Gateways for Congestion Avoidance.IEEE/ACM Transaction on Networking, 1(4), pp397-413.Floyd, S., and Fall, K., (1997) Router Mechanisms toSupport End-to-End Congestion Control. LBLTechnical report.Partridge, C., et al. A fifty gigabit per second IProuter. IEEE/ACM Transactions on Networking.Gupta, A.L. and Georganas N.D.(1991) Analysis ofa packet switch with input and output buffers andspeed constraints. Proc. InfoCom ‘91, BalHarbour, FL, p.694-700.Iliadis I. and Denzel W.E. (1990) Performance ofpacket switches with input and output queuing.Proc. ICC ‘90, Atlanta, GA, p.747-53.Karol M., Hluchyj M., Morgan S. (1987). Inputversus output queuing on a space-division switch.IEEE Transactions on Communications, vol. 35,pp. 1347-1356.Lin, D. and Morris, R. (1997). Dynamics of randomearly detection. Proceedings of ACMSIGCOMM’97, pp 127-13.McKeown, N., Izzard, M., Mekkittikul, A., Ellersick,W., and Horowitz, M. (1996). The Tiny Tera: APacket Switch Core. Hot Interconnects V,Stanford University.McKeown, N., Anantharam, V., Walrand, J. (1996)Achieving 100% Throughput in an input-queuedswitch. Infocom ‘96.Oie Y., Murata M., Kubota K., and Miyahara H.(1989). Effect of speedup in nonblocking packetswitch. Proc. ICC ‘89, Boston, MA, p. 410-14.Ott, T., Lakshman, T. and Wong, L. (1999). SRED:Stabilized RED. Proceedings of INFOCOM’99.