Praktiska tillämpningar av QoS-teknologi Inlämningsuppgift till seminariekursen i datakommunikation och distribuerade system. Ola Lundgren d99eol@dtek.chalmers.se 790502-8531 Mattias Thorén d99torez@dtek.chalmers.se 790703-7233 Sammanfattning Vi har valt att som inlämningsuppgift göra en översikt över QoS-teknologi och vad den kan användas till i dagens Internet. Vi börjar med att definiera vad QoS är (och vad det inte är). Sedan fortsätter vi med att ta några exempel på applikationer där QoS i någon utsträckning är ett krav. Till slut tittar vi på existerande mekanismer som kan användas i routrar för att garantera viss QoS. Efter detta kommer en diskussion och en sammanfattning av vad vi har kommit fram till. Definitioner Förkortningen QoS står för Quality of Service. Detta begrepp används ibland lite slarvigt, som t.ex. vi har QoS i våra routrar. Vad man då menar är egentligen vi har mekanismer i våra routrar som garanterar (en viss nivå av) QoS. Quality of Service innebär fritt översatt kvalitet på nätverksuppkoppling. Med kvalitet menas att vissa krav (på bandbredd, fördröjning eller annat, se nedan) är tillgodosedda. För att uppnå detta implementeras viss teknologi i de routrar som ingår i ett nätverk där man vill kunna tillhandahålla QoS, se vidare avsnittet om QoS ur operatörssynvinkel. Enligt [1] är QoS ett sätt att garantera de krav som ställs och det tillhandahåller följande: Tillräcklig bandbredd Förbättra andelen tappade paket Undvika och styra network congestion, trafikstockning på nätverket Styra nätverkstrafiken Styra trafikprioritet Inledning Internet är idag uppbyggt med best-effort service, det vill säga att nätverksoperatörerna försöker hela tiden tillhandahålla så bra trafik som möjligt men de ger inga garantier som till exempel delay, bandbredd eller andelen paket som kommer fram. Fördelen med detta system är att det är mindre komplext, vilket gjort att paketens overhead, den del av paketet som bara innehåller information för att möjliggöra kommunikationen, och uträkningar i routrarna kunnat begränsas. Tack vare det visade det sig att denna metod var den som praktiskt innebar den genomsnittligt bästa datahastigheten.
Problemet är just att det inte ges några garantier och att alla paket behandlas precis lika. Det finns idag inte heller någon inbyggd funktionalitet för att tillhandahålla det om efterfrågan skulle finnas. I de flesta Internettillämpningar, som surfande eller email, krävs inte heller någon garanterad kommunikationsprestanda. Men i takt med att datorer och Internet utvecklats har nya applikationer i realtid blivit möjliga, för dessa applikationer kan det vara förödande om inte kommunikationen över nätverket inte garanteras till en viss nivå hela tiden. Idag finns inte heller något sett att ge viss trafik prioritet över annan, även om kunden är beredd att betala extra för att få det. Prioritet kan både vara en förutsättning för att garantier ska kunna ges och någonting som en kund efterfrågar bara för att ge generellt bättre prestanda utan garantier. QoS kan vara en metod som tekniskt tillgodoser dessa krav. Applikationer där QoS kan vara viktigt Som nämndes i inledningen är det i realtidsapplikationer som det inte är säkert att det fungerar om inte viss prestanda fungerar. Tre exempel på sådana applikationer är VoIP, samtal över ett IP-nätverk, videokonferenser, onlinespel och mobila onlinespel. En annan fördel med QoS är att det kan användas i datasäkerhet till att begränsa skadan av vissa, så kallade denial of sevice, attacker mot ett nätverk. VoIP För att det ska vara realistiskt att IP-nätverk ska ta över vanlig telefontrafik måste dessa nätverk leverera åtminstone lika bra prestanda som en vanlig telefonledning gör i dag. Det ska alltså för lokal eller samtal inom samma land vara helt perfekt, det är vad kunderna kommer att förvänta sig. När det gäller samtal till utlandet så accepteras en viss fördröjning idag så samma sak borde gälla IP-nät. Enligt [1] kan kraven specificeras tekniskt så här: Packet loss som är mindre än 1%, idealt ingen alls Maximal delay på 150 ms, men upp till 300 accepteras till andra länder Minimalt jitter, tillräcklig stor andel av paketen har standard-delay Tillräcklig bandbredd för realtidsapplikationer. Exakta siffran varierar med versionen av VoIP, i exemplet använda G.117 som kräver 80 kbps Detta är inte prestanda som man kan förvänta sig av dagens best-effort service. Så för att det ska fungera att skicka röstsamtal över ett IP-nät så måste det till någonting nytt som kan garantera det. QoS skulle kunna vara detta. Videokonferenser Rent tekniskt är detta en applikation, att skicka tvåvägskommunikation av ljud och bild, som är väldigt lik VoIP, även om de exakta prestandakraven är högre. Därför gäller samma sak här, som för VoIP, att någonting som garanterar prestanda krävs och QoS skulle kunna vara en lösning.
Onlinespel Onlinespel är en annan realtidstillämpning där kommunikationen i nätverket kan vara förödande för spelet om den inte är tillräckligt bra. Ett typiskt exempel ges i [2], det behandlar inte bara vilka kraven är utan också att de kan vara olika för olika användare. Den typen av krav som behandlas, som alla kan garanteras av QoS, är: Bandbredd, tillräckligt mycket data åt gången Latency, tillräckligt låg delay Jitter Exemplet ger förljande scenario. Det är ett onlinespel som innehåller 5 spelare, 4 av dem sitter på olika platser i Europa och den sista i Japan. Bara 3 av spelarna är relevanta för exemplet. Till att börja med har spelaren, från och med nu kallad SP, i Japan en delay på lite över 170 ms i ~95% av fallen med best-effort service. Med andra ord har den latency på 170 ms och jitter på ~5%. Vi antar att det krävs att alla spelare har en maximal latency på 100 ms och jitter på under 1% för att spelet ska fungera ordentligt. Det betyder att SP inte kan vara med om bara best-effort finns tillgängligt, både latency och jitter måste förbättras. Men, om det finns möjlighet att med QoS begära denna prestanda, eventuellt mot extra betalning, skulle SP kunna vara med. Nästa spelare sitter i Spanien och har delay på 100 ms i ~5% av fallen med best-effort. Med andra ord latency på 100 ms och 5% jitter. Inte heller i detta fall har spelaren den prestanda som krävs. Skillnaden är att i det här fallet är det bara jitter som inte är tillräckligt bra. Då kan det vara möjligt att med hjälp av QoS att begära en förbättring bara av jitter, något som borde vara billigare än att förbättra latency också. I exemplet befinner sig både spelservern och en av spelarna i Tyskland. Denna spelare har med best-effort delay på <5 ms och 1% jitter. Med andra ord redan tillräckligt bra prestanda för att klara spelets krav. Här är alltså ett exempel på när 3 användare kör samma applikation men en användare direkt klara kraven med sin uppkoppling, en behöver förbättra jitter och en behöver förbättra både sin latency och jitter. QoS kan i dessa fall vara en metod att definiera kraven på nätverket för att ge denna service. Mobilt onlinespel I ett stationärt nätverk är det alltid tiden över Internet som är avgörande eftersom den delen av kommunikationen som sker med Ethernet, över det lokala nätverket, är försumbar i sammanhänget. I ett mobilt nät är det inte säkert att så är fallet. Här kan tiden för kommunikation mellan den mobila enheten och basstationen ha stor betydelse. Ett exempel, beskrivet i [3], är ett onlinespel som kräver maximal delay på 200 ms. Om man har en delay mellan basstationen och spelservern på 140 ms krävs det med andra ord att länken mellan den mobila enheten och basstationen är max 60 ms. Här kan QoS vara en lösning för att garantera denna del av trafiken.
Säkerhet Det finns, som det nämnts ovan, en sorts attacker mot ett nätverk som kallas DoS. De bygger på att översvämma ett nätverk med nonsenstrafik. Det finns flera varianter, antingen att bara generera mer packet än nätverket klarar av eller till exempel att skicka många paket som begär uppkoppling till servrar, om då inte källan svarar när servern säger att uppkoppling är etablerad så kommer servern, om flera sådana packet kommit samtidigt, inte kunna ta emot verkliga uppkopplingsförsök. Det är det första alternativet som QoS kan hjälpa till att begränsa skada från [4]. Om alla paket, som idag, har lika stor prioritet kommer nonsenstrafiken att, om de till exempel skickas från ett nätverk med högre bandbredd, potentiellt kunna hindra alla riktigt trafik på det attackerade nätverket eftersom alla resurser går åt till att ta hand om dessa nonsenspaket. Men om det finns QoS med möjlig prioritet så kommer den trafik som har denna högre prioritet inte att påverkas av att nätverket är fullt eftersom de i vilket fall behandlas först av routrarna i nätverket. Ett potentiellt problem[5] är att QoS möjliggör en ny sorts DoS-attack. Denna attack försöker utnyttja att det finns möjlighet till prioritet i ett nätverk. Genom att bevaka trafik med hög prioritet kan metoderna för att få denna prioritet hittas. Då finns det möjlighet att konstruera egna paket som ser ut som om de har högre prioritet än de borde ha och på så sätt effektivt blockera för annan trafik. Sammanfattning Det finns idag en mängd applikationer, som röst eller spel över Internet, där det krävs en garanterad prestanda. De är också av den sorten att denna prestanda kan variera beroende på yttre omständigheter. Det gör att det idag finns en efterfrågan på operatörer att tillhandahålla denna typ av trafik. QoS-tillämpningar från operatörssynvinkel När vi i dagsläget använder vår internetuppkoppling hemma eller på jobbet blir vi knappast förvånade över att det ibland uppfattas som snabbare och ibland som långsammare. Går det långsamt kan detta bero på congestion, trafikstockning i någon del av nätverket som vår trafik routas över. Detta förvånar oss inte eftersom en Internetuppkoppling traditionellt har inneburit vad som bäst kan beskrivas med best-effort service, det vill säga att vi får den bästa service som för närvarande är möjlig. Om många vill använda nätverket samtidigt går det långsammare och långsammare, i värsta fall fylls köerna i routrarna upp och paket tappas och måste skickas om. Detta är förstås något man vill undvika. Behovet av en QoS-garanti Tillhandahållande av internettjänster är som bekant redan nu en enorm marknad med många stora och små operatörer på olika nivåer. En naturlig utveckling i ett kommersiellt nätverk är naturligtvis att dessa operatörer vill skilja på olika typer eller klasser av trafik
för att kunna erbjuda olika nivåer av uppkoppling. Förutom detta pågår hela tiden ett internationellt arbete med att få trafiken på det existerande nätverket att flyta så smidigt som möjligt och se till att ingen del av nätet blir överbelastat. Detta är en anledning till att QoS på routernivå har blivit ett stort forskningsområde. Vi ska här titta lite på några av de tekniker som används av operatörer både på deras egna nätverk och mellan varandra för att försöka garantera en viss nivå av service. Meningen med denna text är inte att gå ner på paket- och bitnivå, även om det ibland kommer att bli ofrånkomligt när vi beskriver existerande QoS-teknologi. Låt oss börja med att sätta oss in i den kommersielle operatörens synvinkel. Kvalitet och trafikklasser En kommersiell operatör vill förstås kunna klassificera olika kunders trafik för att kunna ta olika mycket betalt för olika servicenivå. Låt oss kalla nivåerna A, B och C där A innebär hög bandbredd och låg delay, B något sämre men fortfarande bättre än C och C som är vanlig best-effort. För att skilja på olika trafikklasser finns mekanismen DiffServ, eller differentiated services, i IP-protokollet. Det är helt enkelt ett fält i IP-headern som talar om vilken prioritet paketet har. I ett något förenklat scenario händer följande. En användare som betalar för C- uppkoppling skickar iväg ett paket från sitt modem eller motsvarande. Det anländer till en router som markerar det med en viss prioritet, låt oss säga 3, och skickar det vidare till en router R som ska skicka det vidare ut på Internet. I normalfallet kommer paketet bara att routas vidare till sin destination. I ett annat fall kan man dock tänka sig att ett stort antal kunder med A-uppkoppling vill skicka trafik samtidigt. Deras paket kommer då att ha högre prioritet, och om operatören har missbedömt sin kapacitet och alla A-användare vill använda nätverket samtidigt kan det i förlängningen leda till att C-användare får betydligt sämre service. Här har alltså kunderna med A-uppkoppling ansett att det är värt en extra avgift att vara garanterad en viss servicenivå (givetvis bara upp till operatörens externa kapacitet, men ändå) medan kunderna med C-uppkoppling kanske inte bryr sig så mycket om att nätverket går långsammare ibland. Detta är som sagt en förenklad situation för att illustrera hur differentiated services kan tillämpas i en kommersiell situation. Grundidén är helt enkelt att kunna prioritera vissa typer av trafik framför andra i nätverket. Det krävs såklart att alla routrar i ett nätverk har samma policy för att tolka DiffServ-fältet för att detta ska fungera. I exemplet ovan har alla användare samma service när lasten på nätverket är låg. Ett annat önskemål från en kommersiell operatör är förstås att verkligen kunna strypa bandbredden för vissa kunder till just den nivån de betalar för oavsett hur mycket av operatörens totala bandbredd som utnyttjas vid ett givet tillfälle. Att styra bandbreddsutnyttjandet i olika delar av nätverket kallas traffic shaping.
Det finns förstås andra skäl än rent kommersiella att vilja ha olika prioritetsnivåer för trafik. I en kanske inte så osannolik framtid där t.ex. SOS-samtal går över Internet med VoIP vill man naturligtvis prioritera denna trafik högre än allt annat. Även styrinformation och kontrolltrafik mellan routrar i knutpunkter ska förstås kunna prioriteras upp för att nätverket ska kunna tillhandahålla bästa möjliga service. Bästa möjliga service från det existerande nätverket är även målet med trafikstyrning som vi tittar på i nästa avsnitt. Trafikstyrning På högre nivå, låt oss säga den svenska delen av Internet, kanske man vill försäkra sig om att trafikstockningar i största möjliga mån undviks och att nätverket utnyttjas i så stor utsträckning som möjligt. Detta kallas traffic engineering. De routingprotokoll som är mest spridda idag väljer utan undantag den kortaste vägen till nästa destination när de skickar ett paket vidare. Kortaste vägen betyder här minst antal hopp, det vill säga minst antal mellanliggande routrar. Detta är dock inte alltid optimalt och kan leda till en ojämn trafikdistribution. Lösningen är att använda andra metrics (kostnad för en viss route) än bara antalet hopp. Detta gör man i vad som kallas constraint-based routing. Konceptet constraint-based routing kan enklast förklaras med att en route väljs med hänsyn till vissa krav. Ett sådant krav kommer i någon mening alltid att formuleras i termer av QoS. Man kan t.ex. alltid välja den route som i någon bemärkelse är minst lastad. Man kanske alltid vill välja den billigaste vägen om olika routes är förknippade med olika kostnad eftersom de går över olika operatörers nätverk. Ett annat krav är kanske att den route man väljer ska ha lägsta möjliga svarstid. Om alla routrar automatiskt väljer den väg som är minst trafikerad kommer trafikstockningar på vissa länkar att bli mindre vanliga. Denna typ av mekanism i routrarna är förstås ingen ersättning för en bra grunddesign av nätverket men kan säkert vara en bra hjälp för att hålla belastningen jämn. Sammanfattning Vi har nu tittat översiktligt på traffic shaping, constraint-based routing och differentiated services. Alla dessa teknologier har som mål att styra hur trafiken går på Internet för att uppfylla vissa krav på service. De leder förstås till en minimal overhead i routrarna men denna får anses vara helt klart acceptabel med tanke på de vinster man gör på att kunna differentiera trafik, både för kommersiella operatörer och för Internet som helhet.
Resultat och diskussion Behovet av garantier för nätverkskommunikation Undersökningen visar att det finns en mängd olika kommersiella applikationer där någon typ av prestandagaranti är nödvändigt för att kunna garantera den prestanda som krävs och det finns en efterfrågan från kunder på dessa applikationer. Det kanske viktigaste vi hittade i våran undersökning är att det finns ett kommersiellt behov av vissa garantier på nätverkstrafiken eftersom de applikationer som kräver detta efterfrågas av kunderna. VoIP, att helt enkelt använda Internet istället för vanliga telefonledningar, eller att ändra trafiken i dessa till IP-baserad, är någonting som det går att spara stora belopp på. Så om prestandan på denna metod skulle vara likvärdig finns det stor chans att många företag helt kommer att gå över till denna typ av telefonsystem för att tjäna pengar. Onlinespel är en annan applikation där det precis som för VoIP finns ett behov. Men problemet i detta område är att behovet till stor del kommer från unga personer med begränsade resurser som kanske inte är beredda att betala extra för extra service. Det är också enklare att bygga spel så att de kan köra över med best-effort och fortfarande fungera ordentligt. Det betyder att det inte verkar troligt att det är denna typ av applikation som kommer att innebära genombrottet för kraven på garanterade prestanda. Exemplet med onlinespelet visar att det finns tillämpningar där det inte är någon absolut prestanda som krävs utan den varierar beroende på yttre omständigheter. Det är inte någonting som är unikt för spel. Videokonferenser är en annan applikation som ofta har användare med väldigt olika förutsättning, det är att bara byta ut spelserver mot konferensserver och spelare mot deltagare i konferensen i spelexemplet för att få en rimlig situation. Detta borde betyda att det inte bara är en klass av garanterad prestanda som behövs utan flera stycken. Att prioritet av trafiken kan begränsa skada av vissa attacker är också ett argument för att det verkar troliga att detta är någonting som kommer att införs på Internet. Men det är ett argument som är svårt att bedöma i pengar, det betyder att det inte är troligt att detta argument i sig räcker för att motivera införandet av prioritet. QoS Som vi har konstaterat finns det alltså att behov av garanterad prestanda på nätverk. Resultatet av undersökningen är att QoS är en teknik som fungerar för att tillhandahålla dessa definierade garantier i ett IP-nätverk. Kommer då existerande QoS-teknologi att införas hos de stora operatörerna och på Internet inom överskådlig framtid? Det är svårt att svara på. Naturligtvis finns det nackdelar med existerande metoder för att tillhandahålla QoS som gör dem svåra eller omöjliga att implementera på det globala nätverket. I de allra flesta fall handlar det då om att den trafikmässiga overhead som införs i och med signaltrafiken blir för stor för att det ska vara värt den funktionalitet som
erhålls. När det gäller constraint-based routing som beskrevs ovan leder det även till en ökning av storleken på routingtabellerna vilket innebär högre minneskrav i routrarna. All teknologi är förstås inte heller tänkt för Internet utan kanske för mindre lokala nätverk. En metod för QoS-garanti som vi inte diskuterat i denna rapport är IntServ (Integrated Services) som använder ett signaleringsprotokoll när t.ex. en TCPuppkoppling etableras för att se till att denna uppkoppling garanteras viss QoS. Detta ska då alla routrar mellan sändare och mottagare vara medvetna om under tiden uppkopplingen existerar, vilket innebär att alla dessa routrar måste hålla denna information i minnet (till skillnad från normal routeroperation som är tillståndslös och bara rent skyfflande av paket). Detta i sig innebär att IntServ aldrig kommer att implementeras på Internet det ställer helt enkelt på tok för höga krav på minne och CPU-kapacitet i routrarna. Däremot kan IntServ lämpa sig väl för att ge prioritet åt viss trafik till exempel på ett internt företagsnätverk. Motargument mot QoS Vi har nu alltså kommit fram till att garanterad prestanda behövs och att QoS är en lämplig metod att leverera den. Men inne bär det att QoS kommer att börja användas? Det är svårare att svara på och inte någonting som är möjligt i en så här liten studie. Men det finns ett par saker som talar emot. För det första är det storleken på Internet. Om QoS ska kunna garanteras krävs det att alla routrar uppdateras för att stödja detta. Det betyder att det verkligen krävs att alla ISPföretag kommer överens om det att det är någonting som behövs. För att det ska ske är det mycket troligt att alla känner av en sådan efterfrågan från sina kunder att de alla kommer tjäna pengar på en sådan uppdatering. Även om intresseorganisationer teoretiskt har makten över hur kommunikationen ska se ut består dessa organisationer av representanter från företag som kommer att tillgodose sitt företags intresse. Det är ett vanligt argument för att uppdatering som alla i längden faktiskt skulle tjäna på inte blir av. Det andra är att det kanske inte är nödvändigt med QoS. En av anledningarna till Internets framgång är att best-effort är var tillräckligt bra för de applikationer som användes fram till bara för några år sedan. Så om Internets prestanda förbättras ytterligare så är det möjligt att behovet av QoS, eller något liknade, försvinner. Vi såg ju till exempel i onlinespelet att en av spelare inte behövde QoS för att kunna spela ordentligt. Med en generell prestandaförbättring kanske det skulle kunna gälla alla användare. Det kan helt enkelt vara så att köpa mer bandbredd blir billigare än att införa QoS. Slutsatser Vi har tittat på några applikationer som kan kräva QoS och några metoder för att tillgodose dessa krav. Denna studie är inte menad att vara tekniskt djupdykande eller uttömmande på något sätt. Vår avsikt är främst att ge en översikt och förklaring till dels vad QoS egentligen betyder och vad det kan användas till. Vi har även studerat hur det
kan implementeras i praktiken för att få en känsla för ifall det är troligt att QoS inom överskådlig framtid kommer att vara en naturlig del av vårt sätt att betrakta och använda Internet. Något säkert svar är inte lätt att ge. Vad man kan säga är att ny teknologi, åtminstone på den låga nivå som QoS verkar på, sprids långsamt på Internet. För att QoS-protokoll ska få global spridning på Internet krävs uppgradering av alla routrar. Detta introducerar även en ansenlig overhead på trafiken som kan innebära hårdvaruuppgraderingar som i dagsläget kanske inte är ekonomiskt försvarbara. Som vi har sett finns det dock reella krav på QoS från vissa specifika applikationer. Vissa hävdar att ökade nätverksresurser, och därmed minskande behov av QoS-teknologi, alltid kommer att vara billigare än att implementera den QoS-teknologi som finns. Kanske det är så, men sedan Internet fick allmän användning har tendensen varit att nya applikationer dykt upp för att fylla den bandbredd som finns. Denna tendens ser inte heller ut att vara på väg att brytas med ökande krav på realtidsmultimedia, onlinespel och Internet i mobiltelefoner. Med största säkerhet kommer QoS att implementeras på vissa delmängder av Internet och internt på vissa företagsnätverk, där så krävs. QoS-garantier från den ena änden av Internet till den andra kommer dock antagligen att låta vänta på sig. Referenser X. Xiao, L. Ni: Internet QoS: A Big Picture, IEEE Network Magazine, 1999 [1] Cisco, http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/qossol/qosvoip.htm#xtocid1, 2005-04-19 [2]6qm, http://www.6qm.org/eurov6-spring-event.php, 2005-04-19 [3] Nokia, http://www.nokia.com/nokia/0,,53722,00.html, 2005-04-19 [4] Ahamad M, http://www.gtisc.gatech.edu/currentresearch.htm, 2005-04-19 [5] Extrem network, http://www.extremenetworks.com/libraries/whitepapers/technology/security.asp, 2005-04-19 http://www.allot.com/pages/solutions_content.asp?intglobalid=43 http://www.cse.ohio-state.edu/~jain/refs/ipqs_ref.htm http://www.protocols.com/papers/voe.htm