QoS, Quality of Service

Av: Henrik Jaakkola, e95_hja@e.kth.se
1999-03-23


Bakgrund
    Denna rapport är ett resultat av en uppgift i modulen Telekom VS Datakom i kursen
    Telekommunikationssystem som ges på KTH. Uppgiften var att skriva en rapport om
    Quality of Service, QoS, där man sammanfattat skulle beskriva vad Qos är och varför
    det är viktigt, samt även ge exempel på hur man skulle kunna erbjuda Qos och vilka
    krav olika applikationer har.


Innehållsförteckning
    1. Quality of Service, QoS
        1.1 Fördröjning
        1.2 Jitter
        1.3 Bandbredd
        1.4 Pålitlighet
    2. Metoder för att kunna erbjuda Quality of Service
        2.1 Integrated Services/RSVP
        2.2 Differentiated Services, DS
        2.3 Traffic Engineering/Constraint Based Routing
    3. Olika applikationers krav på överföringen
        3.1 Background Class
        3.2 Interactive Class
        3.3 Streaming Class
        3.4 Conversational Class
    4. Betalningssätt


1. Quality of Service, Qos
    Idag erbjuder internet endast Best effort Service. Med det menas att all trafik leverars
    så snabbt som möjligt men det finns ingen garanti för att det skall ske inom en viss tid
    eller att paketen verkligen leveras.
    Dagens Internet erbjuder mer och mer kommersiella tjänster och dessa tjänster börjar nu
    kräva mer än vad Best effort Service kan erbjuda. De kommersiella tjänsterna börjar nu
    efterfråga säkrare och mer pålitliga överföringar och efterfrågan ökar på något som har kommit
    att kallas för Quality of Service, QoS.
    Med QoS menas många saker. Huvdsakligen när man pratar om QoS menar man precis vad
    det översatt på svenska betyder. Garanterad kvalitet på att det vi vill levera levereras och detta
    inom vissa tidsramar.
    Speciellt för realtidsapplikationer är kraven på QoS stora. Om inte överföringarna fungerar
    tillfredsställande kommer dessa applikationer att fungera mycket dåligt eller kanske inte alls.
    Andra funktioner där kraven på överföringen är höga är att Internet mer och mer används av
    användare till handel och kontoöverföringar. Här är det nödvändigt att det skall gå att kunna
    komma åt tjänsten när man behöver det. Att inte kunna betala in en räkning vi Internet pga
    att servern inte kan nås är inte något man vill upptäcka den sista dagen i månaden.

    QoS kan beskrivas med olika parametrar vilka fyra av dem dessa är dessa:

1.1 Fördröjning
    Fördröjning , är den tid det tar för den första biten att komma fram till destinationen. Ju högre
    Fördröjning det är desto mer krävs det av transport-protokollet för att kunna fungera effektivt.

1.2 Jitter
    Jitter, är variationen i Fördröjningen. Om Jittret är högt kommer det att tex för TCP-protokollet
    att betyda att oriktiga beslut baserade på RTT (Round Trip Time), tiden fram till destinationen
    och tillbaka till sändaren, kan komma att tas. Detta kommer i så fall att innebära att protokollet
    arbetar oeffektivt. För UDP-baserade realtidsapplikationer är det oacceptabelt med en hög nivå i
    Jittret, om dessa applikationer skall fungera tillfredsställande. Om så vore fallet skulle det betyda
    att vi skulle få distorsion i tex ljudöverföringar.

1.3 Bandbredd
    Bandbredd, är tiden det tar för den sista biten att leveras till destinationen eller med andra ord hur
    mycket vi kan överföra på en viss tid.

1.4 Pålitlighet
    Pålitlighet , dvs hur bra länken är. Detta kan mätas på ett antal olika sätt, tex hur stor bitfels-
    genereringen är, förlorade paket och förlorade bitar.


2. Metoder för att kunna erbjuda Quality of Service
    För att komma tillrätta med och kunna kontrollera ovanstående fyra faktorer har ett antal förslag
    till förändringar i nuvarande Internet föreslagits och diskuterats.
    Det enklaste man skulle kunna göra är att överdimensionera kapaciteten i nätverken. En sådan
    överdimension av kapaciteten skulle på ett enkelt sätt innebära att det aldrig skulle bli någon
    konkurrens av bandbredden och alla aplikationer skulle fungera bra. Dock har det under alla år
    hittills visat sig att mycket vill ha mer. Utvecklingen av applikationer sker i rasande fart och alla
    kräver mer bandbredd. Det är mycket troligt att hur stor kapacitet man än skapar kommer den
    att ätas upp av applikationer om de bara får chansen.
    Därför har även en hel del andra förslag givits och dessa är mer baserade på förändringar i
    knutpunkterna och förändringar i själva protokollen som används för att föra över data över näten.
    Internet Enginering Task Force, IETF, har föreslagit en hel del varav några är: 2.1 Integrated Services/RSVP
    Denna lösning bygger till största delen på reservation av resurer.Lösningen föreslår två nya
    service-klasser till den redan nämda Best effort Service. Dessa förslag är Guarranted Service,
    garanterad service, och Predictive Service, förutsägande(?) service. Guarranted Service är till för
    applikationer som kräver en konstant Fördröjning. Predictive Service är till för applikationer som
    sannoliktbaserat kräver en viss konstant Fördröjning.
    För att själva signaleringen mellan sändare och mottagare skall fungera har även ett förslag till
    protokoll, RSVP (Resource Reservation Protokoll) tagits fram.För att kunna använda dessa nya
    klasser krävs routrar som stödjer RSVP vilket innebär att routrar som inte gör det helt enkelt inte
    kommer att klara av ovan nämnda lösning.

2.2 Differentiated Services, DS
    DS bygger på att sätta olika prioritet beroende på vilken sorts applikation det är som för över data.
    Detta görs genom att man använder ToS-fältet i IP-headern för att ge pakteten olika prioritet.
    Routrar som stödjer denna lösning ser helt enkelt efter vilken prioret paketen har och kan baserat
    på detta ta beslut om hur viktigt det är att paketen routas iväg snabbt.
    Det som är bra med denna lösning är att routrar som inte stödjer denna lösning ändå kan skicka
    vidare paketen och även fast att det inte sker efter önskvärd prioritet så sker det i alla fall.

2.3 Traffic Engineering/Constraint Based Routing
    Denna lösning är till för att dirigera vart trafiken över näten skall skickas. Med hjälp av Traffic
    Engineering undviker man stockning och överbelastning i näten. Detta sker genom att paketen
    dirigeras en annan väg om en sådan är möjlig. Constraint Based Routing är ett verktyg för att få
    denna lösning att fungera. Målen med Constraint Base Routing är att dels välja en väg för paketen
    som uppfyller målet för QoS och dels att optimera användningen av nätverket. För att detta skall
    kunna fungera måste routrar uppgraderas så att de kan ge information om hur en länk fungerar
    och kunna räkna ut andra vägar som skall kunna tas.


3. Olika applikationers krav på överföringen
    Olika applikationer ställer olika krav på överföringen och dess kvalitet. Med dagens Best Effort
    Service behandlas, i routrar, alla paket lika och ingen hänsyn tas till huruvida ett visst paket
    behöver leveras snabbare än ett annat. Genom att implementera Qos kan olika applikationer få
    olika prioritet och på detta sätt görs det möjligt att få en bättre överföring, i alla fall om man har
    råd att betala för den, för vissa applikationer.

    Inom UMTS, Universal Mobile Telecommunicatine Systems, har definerats fyra olika klasser för att
    separera applikationers krav på Internet. Dessa är:

3.1 Background Class
    Background Class, som är klassen som motsvarar vad Internet erbjuder idag. Applikationer
    som inte är så beroende av tidsfaktorn finns i denna klass. Användaren av dessa applikationer
    är typiskt en dator som kör i bakgrunden. Exempel är Mail, SMS och andra aplikationer som
    används för att ladda ner data där det inte nödvändigtvis behöver vara alltför hög överföringshastighet.

3.2 Interactive Class
    Interactive Class, är klassen för applikationer där användaren vill ha någorlunda hyfsad överföring.
    RTT, Round Trip Time, är betydande samt även pålitligheten måste vara ganska god.
    Exempel på applikationer är nätsurfning.

3.3 Streaming Class
    Streaming Class, är klassen där applikationer som använder realtidsöverföringar i en riktning. Mer
    exakt när en användare sitter och tittar på Video eller lyssnar på ljud. I denna klass är det viktigt att
    Jittret inte är stort.

3.4 Conversational Class
    Conversational Class, är klassen för realtidsöverföringar i båda riktngarna, tex en videokonferens
    eller eller parter som pratar med varandra. Detta är den mest krävande klassen. Fördröjningen får inte
    vara hög och Jittret måste vara lågt.


4. Betalningssätt
    Hur kan man då ta betalt för tjänster? Det finns flera olika alternativ. Nedan listas några som oftast
    förekommer:

    - Tidsbaserad kostnad, är den som tex idag används vid telefontjänster.
    - Volymbaserad kostnad, är när man tar betalt beroende på hur mycket data som förs över.
    - Kostnad per Service, är när man tar olika betalt beroende på vilken service som används.
      Kan idag hittas i GSM:s SMS.
    - Fast Kostnad, är helt enkelt en kostnad som är fast och oberoenda av hur mycket man
      använder tjänsten.

    Med QoS kan man utöka alternativen för betalningssätt och beroende på vad det är kunden vill
    ha specificera ett mer komplext betalningssätt. Man kan ta betalt baserat på kundens
    specifikation av hur kunden vill ha de olika parametrarna, Fördröjning, Jitter, Bandbredd och
    Pålitlighet. Att sätta upp olika matematiska formler för detta är nog relativt enkelt, men att sedan
    mäta och ta ut rätt kostnad för dem är praktiskt svårt. Dock kan man med QoS som sagt
    mer kundindividuellt, rent teoretiskt i all fall, ta betalt på olika sätt.


5. Referenser
 
    Internet QoS: the Big Picture
    Av Xipeng Xiao, Michigan State University, Oktober 1998
    http://www.cse.msu.edu/~xiaoxipe/papers/inet.qos.bigpicture.pdf

    Quality of Service in the Internet: Fact, Fiction, or Compromise?
    Av Paul Ferguson, Cisco Systems, and Geoff Huston, Telstra Internet, Juli 1998
    http://www.employees.org:80/~ferguson/inet_qos.htm

    An Introduction to UMTS
    By Ove Bergren, February 1999.
    http://gls.it.kth.se/courses/telecom_docs/stuff/berggren.html

    Kursen Telekom VS Datakom:s hemsida
    Av Björn Pehrson och Jan Ohdnoff
    http://gls.it.kth.se/courses/finger/