Kvalita služby

Keď bol pred rokmi nasadený Internet, chýbala schopnosť poskytovať garantovanie kvality služby QoS v dôsledku obmedzenia výpočtového výkonu v routeroch. Preto fungoval na základnej QoS úrovni, teda best-effort. V každej správe existovali štyri bity pre typ služby a tri bity pre prioritu, ale boli ignorované. Tieto bity boli neskôr predefinované ako DSCP (DiffServ Code Points) a sú z veľkej časti používané v peer linkách moderného Internetu.

V sieťach s prepájaním paketov je QoS ovplyvňované rôznymi faktormi, ktoré sa dajú rozdeliť na ľudské a technické. Ľudské faktory zahrňujú stabilitu služby, dostupnosť služby, meškanie, informácie o užívateľovi. Technické faktory zahrňujú spoľahlivosť, škálovateľnosť, účinnosť, udržateľnosť, stupeň služby (QoS) atď.

Pri prenose paketu môže nastať veľa príčin problémov smerom od odosielateľa k príjemcovi:

• Zahodené pakety – Routre môžu zahodiť nejaké pakety v okamihu, keď majú plný buffer. Nejaké, žiadne alebo všetky pakety môžu byť zahodené v závislosti na stave siete a tak je nemožné zistiť v dostatočnom predstihu, čo sa stane. Prijímacia aplikácia môže požiadať o opakovaný prenos tejto informácie, čo môže zapríčiniť závažné meškanie v celom prenose.
• Meškanie – Prenos paketov do cieľa môže trvať dlhú dobu, pretože môžu byť zastavené v dlhých radách, alebo môžu byť prenášané cez menej priamu cestu, aby sa predišlo preťaženiu. V niektorých prípadoch môže zbytočné meškanie spôsobiť aplikácia.
• Jitter – Pakety pri prenose zo zdroja môžu prísť do cieľa s rôznym meškaním. Meškanie paketov vplýva na pozície paketov vo frontoch routerov na ceste medzi zdrojom a cieľom a táto pozícia sa líši nepredvídateľne. Táto zmena v meškaní je známa ako jitter a dokáže vážne ovplyvniť kvalitu streamovania audia alebo videa.
• Neusporiadané dodanie – Keď je súbor súvisiacich paketov smerovaný cez internet, majú jednotlivé pakety rôzne cesty, čo vyústi v rôzne meškania. Dôsledkom je, že pakety dorazia v inom poradí ako boli vyslané. Tento problém vyžaduje zvláštne dodatočné protokoly zodpovedné za usporiadanie neusporiadaných paketov na izochrónny stav hneď ako dosiahnu svoj cieľ. Toto je najmä dôležité pre video a VoIP streamy, kde je ich kvalita výrazne ovplyvnená ako latenciou, tak nedostatkom izochronicity.
• Chyba – Niekedy sú pakety nesprávne skombinované dohromady alebo poškodené. Prijímač dokáže túto chybu detegovať a následne požiada o opakovaný prenos.

Pre určité typy sieťovej prevádzky môže byť požadované definovanie kvality služby QoS, napríklad:

• Streamovanie multimédií môže požadovať garantovanú priepustnosť k zaisteniu toho, aby bola zaručená minimálna úroveň kvality.
• iPTV ponúkaná ako služba od poskytovateľa.
• IP telefonovanie alebo VoIP môžu požadovať striktné limity na jitter a meškanie.
• Video telekonferencia (VTC) požaduje nízky jitter a latenciu.
• Dedikovaná emulácia linky požaduje garantovanie priepustnosti a ukladá limity na maximálne meškanie a jitter.
• Bezpečnostne kritická aplikácia, ako je napríklad vzdialená operácia, vyžaduje garantovanú úroveň dostupnosti (nazývané tiež ako prísne QoS).
• Vzdialený správca systému môže požadovať uprednostnenie variabilného, obvykle malého množstva, SSH prevádzky s cieľom zaistiť rýchle reagovanie relácie i cez silne zaťaženú linku.
• Online hry, ako napríklad rýchle simulácie s viac hráčmi, požadujú určitú úroveň QoS. Jej nedostatok môže zapríčiniť „lagy“.

Tieto typy služieb sú nazývané neelastické, čo znamená, že požadujú určitú úroveň minimálnej šírky pásma a určitú maximálnu latenciu pre svoju funkčnosť. Naopak elastické aplikácie sa môžu využívať nezávisle od dostupnej šírky pásma. Ide hlavne o aplikácie hromadného prenosu súborov, ktoré sú založené na protokole TCP.

• Počas volania
• Vo volaní
• Dopredu – Keď je výdaj mechanizmu pre poskytovanie QoS nastavený, sieťový zákazníci a poskytovatelia vstupujú do zmluvného vzťahu označeného ako zmluva o stupni služby SLA (Service Level Agreement), ktorá špecifikuje garantovanie pre schopnosť siete/protokolu dávať garantované medze výkonu, priepustnosti, latencie založené na vzájomne dohodnutých meraniach, obvykle pomocou uprednostňovania prevádzky.
• Rezervovanie zdrojov – Zdroje sú rezervované v každom kroku siete pre volanie podľa jeho nastavenia. Príkladom je protokol RSVP (Resorce Reservation Protocol).

Alternatívou ku komplexnému QoS kontrolného mechanizmu je poskytovať vysoko kvalitnú komunikáciu pomocou plného prenosu cez sieť tak, že kapacita je založená na špičkovom využití zaťaženia. Tento prístup je jednoduchý a ekonomický pre siete s predvídateľným a malým prevádzkovým zaťažením. Výkon je vhodný pre mnohé aplikácie. To môže zahrňovať náročné aplikácie, ktoré dokážu kompenzovať rozdiely v šírke pásma a meškanie s veľkými buframi na prijímacej strane, čo je často možné napríklad v streamovaní videa.

Komerčné VoIP služby sú konkurencie schopné voči tradičnej telefónnej sieti, pokiaľ ide o kvalitu, i keď QoS mechanizmy na strane užívateľovho pripojenia k ISP a VoIP poskytovateľovho pripojenia k inému ISP nie sú obvykle použité. Podľa podmienky výšky zaťaženia však kvalita VoIP klesá na úroveň celulárnych telefónov alebo nižšie. Matematické výpočty ukazujú, že sieť s QoS obslúži až štyrikrát viac hovorov s určeným jitterom, než sieť bez QoS. Stupeň zahltenia na vnútorných linkách požaduje premiestnenie QoS v závislosti na počte užívateľov a ich požiadavky na prevádzku. Keďže internet dnes poskytuje služby miliónom užívateľov, je tu malá pravdepodobnosť, že plný prenos dokáže eliminovať potrebu QoS pre VoIP.

Pre úzkopásmové siete typické pre podniky a miestne vlády boli vyvinuté dve rozdielne filozofie zachádzania s paketmi.

Prvá používa IntServ filozofiu k rezervovaniu sieťových zdrojov. V tomto modeli aplikácie používajú protokol RSVP k vyžiadaniu a rezervovaniu zdroja v sieti. Zatiaľ čo IntServ mechanizmus pracoval, bolo na centrálnych routroch v širokopásmovej sieti typickej pre väčšieho poskytovateľa služieb požadované prijímať, udržovať a ukončovať tisice alebo až desaťtisíce rezervácii. Bolo jasné, že tento prístup s rastúcim stupňom rozširovania internetu nebude vyhovovať.

Druhý, v súčasnej dobe používaný prístup je DiffServ, teda diferencované služby. V DiffServ modely sú pakety označované podľa typu služby, ktorú požadujú. Ako reakciu na tieto značky môžu smerovače a prepínače používať rôzne stratégie čakania aby čo najlepšie navrhli výkon k požiadavke.

Routre s podporou DiffServ používajú viac paketových front pre čakanie paketov kvôli obmedzenej šírke pásma rozhraní. Výrobcovia routerov poskytujú rôzne možností pre nastavovanie tohto režimu tak, aby zahrňoval počty podporovaných front, relatívnu prioritu front a šírku pásma vyhradenú pre každú frontu.

V praxi to znamená, že keď musí byť paket zaslaný z rozhrania s frontami, pakety požadujúce nízky jitter (nap. VoIP alebo VTC) získavajú prioritu pred ostatnými paketmi v ostatných frontoch. Typicky je nejaká šírka pásma pridelená sieťovým kontrolným paketom (napr. ICMP a smerovacie protokoly), zatiaľ čo best-effort prevádzka získa šírku pásma, ktorá jej ostane.

Mechanizmus managementu šírky pásma by mal k projektovaniu výkonu zahrňovať:

• Tvarovanie prevádzky (limitovanie rýchlostí)
  • Token bucket
  • Leaky bucket
  • Kontrola rýchlosti TCP – umelo upravuje veľkosť TCP okna ako aj kontroluje rýchlosť vracania ACK odosielateľovi
• Plánovacie algoritmy
  • WFQ – Weighted Fair Queuing
  • Class based WFQ
  • WRR – Weighted Round Robin
  • DWRR – Deficit Weighted Round Robin
  • HFSC – Hierarchical Fair Service Curve
• Predchádzanie zápcham
  • RED, WRED – znižuje možnosť zahadzovania koncov v čakacej fronte bufferu portu a tým zaručuje zníženie TCP globálnej synchronizácie
  • Sieťová politika – značkovanie a zahadzovanie paketov presahujúcich prenosovú rýchlosť a veľkosť burstu
  • Explicitné oznamovanie preťaženia
  • Ladenie buffrov

Ako už bolo povedané, zatiaľ čo sa DiffServ používa v sofistikovaných podnikových sieťach, nebol ešte široko nasadený do internetu. Opatrenia internetových peerov sú komplexné a zdá sa, že u poskytovateľov internetového pripojenia nie je žiadne nadšenie pre zavedenie podpory QoS v rámci peeringových spojení alebo dohody na podporovaní politík.

Presvedčivým príkladom pre zavedenie QoS do internetu sú prevádzkové preťaženia. Internet sa opiera o protokoly predchádzajúce vznikaniu zápchy, zabudované do TCP, aby redukoval prenosové zaťaženie v podmienkach vedúcich k spadnutiu. QoS aplikácie ako VoIP a IPTV nemôžu používať protokol TCP pretože požadujú konštantnú prenosovú rýchlosť a nízku latenciu. Nie je teda možné znížiť ich prenosovú rýchlosť k pomoci prevencie pred spadnutím siete internet. QoS dohody o limitovaní prevádzky môžu byť ponúkané na internete a tým presadiť formovanie prevádzky, ktorá môže zabrániť preťažovaniu. Tým sú neoddeliteľnou súčasťou schopnosti internetu obsluhovať jak real-time tak no-real-time prevádzku bez zrútenia.

ATM sieťový protokol má prepracovanú štruktúru možnosti nasadenia QoS mechanizmu. Kratšie dátové jednotky a zabudovaná QoS boli význačné body pre predaj ATM v telekomunikačných aplikáciách ako je video on demand alebo VoIP.

• TOS (Typ služby) pole v IP záhlaví
• IP diferencované služby DiffServ
• IP integrované služby IntServ
• RSVP – Resorce reservation protocol
• MPLS – MultiProtocol Label Switching poskytuje 8 tried QoS
• RSVP-TE
• Frame Relay
• X.25
• Niektoré ADSL modemy
• ATM – Asynchronous Transfer Mode
• IEEE 802.1p
• IEEE 802.1Q
• IEEE 802.11e
• IEEE 802.11p
• HomePNA – domáce siete cez koaxiálne a telefónne drôty

Výskumný projekt MUSE definoval koncept QoS vo fáze 1, ktorý bol ďalej spracovaný v inom výskumnom projekte PLANETS. Táto nová myšlienka riešenia je dohodnutie sa na diskrétnej hodnote jitteru na QoS triedach, ktorá je uložená na sieťových uzloch. Vrátane best-effort boli stanovené štyri QoS triedy, dve elastické a dve neelastické. Toto riešenie má niekoľko výhod:

• Koniec-koniec meškanie a strata paketovej rýchlosti môžu byť predvídané
• Ľahká implementácia jednoduchým plánovačom a dĺžkou fronty u PLANETS
• Uzly je jednoduché overiť pre elastickosť
• Koncoví užívatelia si nevšimnú rozdiel v kvalite

Projekt MUSE vypracoval vlastné QoS riešenie, ktoré je primárne založené na:

• Využitie prevádzkových tried
• Selektívny CAC koncept
• Príslušné dimenzovanie siete