Jak funguje řízení datových toků s QoS

Po zadání klíčového slova QoS (Quality of Service) vám česká verze Wikipedie zobrazí, že je to termín používaný pro rezervaci a řízení datových toků v telekomunikačních a počítačových sítích s přepínáním paketů. Tato definice však pokrývá příliš velkou oblast, o které by bylo možné napsat možná i rozsáhlejší brožurku. Nástroje QoS se uplatňují na různých protokolech a vrstvách ISO/OSI modelu, nejen nad IP protokolem. Také jejich použití nad různými technologiemi v sítích ISP, jako je ATM, Frame-Relay, MPLS Traffic Engineering apod. značně přesahuje rozsah tohoto článku. Proto v následujícím článku popíši jen opravdu hrubý přehled problematiky QoS v prostředí unicastového provozu světa IPv4.

K čemu je to vůbec dobré?

Běžná aplikace, například internetový prohlížeč, je poměrně odolná vůči výpadku či změně pořadí jednoho nebo i několika paketů. TCP protokol, který pracuje nad IP protokolem, zajistí opětovné odeslání takto ztracených paketů, případně zajistí jejich správné pořadí. Statická HTML stránka se tak v případě ztráty několika paketů zobrazí jen s malým zpožděním, které je nezbytné k opětovnému zaslání ztracených paketů.

Existují však aplikace, pro které kvalitativní parametry přenosu jsou důležité nebo enormně důležité. Pomineme teď případy, kdy programátor napsal aplikaci používající pro přenos dat např. UDP protokol a „pozapomněl“ se postarat o případnou ztrátu nebo přehození paketů. Typickými aplikacemi, pro které jsou kvalitativní parametry přenosu podstatné, jsou hlasové přenosy, přenosy videa, některé síťové realtime počítačové hry. K nim v poslední době přibývají i klíčové podnikové aplikace. Když totiž vyčíslíte čekání na odezvu v řádu dvou či tří sekund na operaci, vynásobíte počtem operací za den a počtem lidí, dostanete nezanedbatelný čas strávený neproduktivním čekáním. Ve chvíli, kdy takto ztracený čas dosáhne úrovně řádu člověkodnů, představuje to poměrně pádný a finančně vyčíslitelný důvod k realizaci technických opatření. O to více, že často je možné je realizovat jen správnou konfigurací zařízení, které nástroje QoS podporují.

Aplikací QoS nástrojů se nejčastěji ovlivňují následující kvalitativní parametry přenosu:

• Bandwith - šířku pásma
• Delay - zpoždění
• Jitter - kolísání velikosti zpoždění
• Packet loss - ztrátovost paketů

QoS však není jeden jednolitý nástroj pro řešení problémů se zajišťováním kvalitativních parametrů přenosu. Používá se celá řada QoS nástrojů. Jejich názvy se mohou podle dodavatele lišit, používají se nejen nad protokolem IP a je možné je zhruba rozdělit do následujících kategorií:

• Classification and marking - klasifikace resp. rozlišení a označení provozu
• Congestion management (Queuing) - správa zahlcení pomocí front
• Shaping and Policing - správa datového toku, omezování a vyhrazování
• Congestion avoidance - nástroje pro zabránění zahlcení, např. selektivním zahozením TCP paketu
• Link-efficiency - správa efektivního využití linky, obvykle se týká pomalých linek, komprese nebo fragmentace paketů
• Signaling (RSVP, QPPB)
• Ostatní

Trocha teorie

Z výše uvedených důvodů je zřejmé, že ve chvíli, kdy potřebujete zajistit šířku pásma pro určitou aplikaci nebo preferovat jeden datový tok před druhým, použijete nástroje QoS. Pokud se hovoří o QoS, musíte si mimo jiné uvědomit, že se nástroje QoS používají pro rezervaci a řízení datových toků tak, aby nedošlo ke snížení kvality síťových služeb ve stavu zahlcení sítě resp. i v situacích, kdy zahlcení sítě hrozí, avšak ještě nenastalo. QoS se tedy uplatňuje ve chvíli, kdy je síť zahlcena, nebo téměř zahlcena. Jinak se QoS neuplatňuje a pakety plynule prochází zařízením.

Druhou skutečností, kterou je nezbytné si uvědomit, pokud se rozhodnete řešit problémy v síti pomocí QoS, je fakt, že nastavení QoS nebude schopno vyřešit obecný nedostatek přenosové kapacity v síti nebo problémy v přenosové trase. Je zřejmé, že nemůžete připojit společnost s 5 tisíci zaměstnanci na linku o kapacitě 64 kb/s a je celkem lhostejné, zda s nasazeným QoS, nebo bez QoS. Stejně tak ztrátovost paketů na lince, např. způsobená radiovým rušením Wi-Fi spoje, nevyřešíte pomocí nástrojů QoS.

V následující části budou popsány tři základní architektury QoS jak jsou definovány a v současnosti používány:

• Best-effort services
• Integrated services (IntServ)
• Differentiated services (DiffServ)

Best-effort services

Pokud použijete architekturu Best-effort services, což by se dalo přeložit jako metoda největší snahy, bude se síť snažit doručit pakety co nejrychleji a nejefektivněji ze zdroje k cíli. Nebude se rozlišovat, zda se jedná o „užitečné“ pakety hlasového hovoru nebo streamované video zcela nesouvisející s náplní naší práce. Takové nastavení však nezaručuje žádnou kvalitu služby. Jestliže je síť s takto nastavenou QoS strategií zahlcena, pak poté co ji dojdou buffery, začne zahazovat pakety podle strategie. Paket, pro který není k dispozici buffer, zahodí - tail drop.

Pokud v síti s touto architekturou chcete řešit její zahlcení, můžete realizovat opatření vedoucí k omezení nežádoucího provozu, např. vypojením stanic trvale zahlcující síť p2p provozem, které síť přenáší nebo zvětšit šířku pásma. Prvé řešení je v praxi jen stěží realizovatelné na síťové úrovni, protože uživatel zatěžující síť nežádoucím provozem obvykle produkuje také legitimní provoz, který potřebuje ke své práci. Taková opatření je pak možné realizovat spíše na úrovni správy OS a aplikací, případně administrativním opatřením, než odpojením stanice. Druhá volba má zásadní nevýhodu, a tou je finanční náročnost. Výhodou této architektury je značná škálovatelnost a to, že nevyžaduje žádné použití nástrojů QoS, tedy snadné nasazení.

Integrated services (IntServ)

Další architekturou je Integrated services, která je popsána v RFC 1633. Nástroje IntServ definují signalizační proces, pomocí kterého mohou jednotlivé datové toky požadovat rezervaci přenosového pásma a požadovaného zpoždění. Jedná se o signalizaci od zdroje k cíli, zajišťující rezervaci přenosového pásma a nastavení zpoždění po celé cestě od zdroje k cíli. K tomu, aby bylo možné garantovat šířku pásma a požadované zpoždění, musí architektura zajišťovat minimálně dvě funkce. Prvou je Resource reservation (rezervace zdrojů) a druhou je Admission control (řízení přístupu). Resource reservation signalizuje jednotlivým síťovým komponentám, kolik pásma a jaké zpoždění požaduje pro přenos od zdroje k cíli. Admission control pak rozhoduje, zda takto signalizované požadavky akceptuje nebo zamítne.

Nastavení Quality of Services (QoS).

V současnosti je architektura IntServ v prostředí IP realizován a implementován protokolem RSVP dle RFC 2205-2215. V síti, kde máte plně nasazený protokol RSVP, zdrojová aplikace signalizuje požadavek na zajištění potřebného pásma s požadovaným zpožděním. Příkladem budiž aplikace pro přenos hlasu, která signalizuje směrem k hlasové bráně požadavek na rezervaci pásma 120 kb/s se zpožděním Low Delay. Tento požadavek obdrží první směrovač po cestě, který vyhodnotí, zda je možné požadavku vyhovět a pokud ano, pošle jej na další směrovač. Každý ze směrovačů po cestě si dočasně vyhradí takto rezervovanou šířku pásma a čeká na potvrzení rezervace. Jakmile požadavek dojde k cíli a ten jej akceptuje, pošle zpět potvrzení rezervace. V té chvíli každý ze směrovačů po cestě dočasně vyhrazenou šířku pásma finálně rezervuje pro tento datový tok. Aplikace pak nadále periodicky signalizuje požadavek po celou dobu trvání přenosu, jinak by byla rezervace po určité době zrušena.

RSVP se uplatní především tam, kde požadavky na parametry přenosu jsou zásadní pro funkčnost aplikace. Asi nejviditelnější případem je přenos videa. Přenos videa je značně citlivý na ztrátu paketu. Zjednodušeně řečeno je to proto, že při zobrazení videa v závislosti na použitém kodeku, se následující snímek s výjimkou klíčových snímků většinou počítá z některého z předchozích snímku a tedy jeho ztráta může vést k tomu, že uživatel musí počkat na další klíčový snímek. Další aplikací, kde se RSVP uplatní, jsou krizové situace, kdy na síti zavládne panika a je nezbytné zajistit chod klíčových systémů za každou cenu.

Bohužel RSVP má i některé nevýhody. Je to problematická škálovatelnost, kdy rezervace jsou prováděny pro jednotlivý datový tok a pro tento jsou také zasílány periodické obnovovací rezervační zprávy. Tyto problémy je možné z části překonat, jak výkonem síťových komponent, dnešní směrovače nemají problém zvládat desítky tisíc RSVP toků, tak i slučováním několika zpráv do jediné RFC2961-RSVP Bundle Message. Můžeme asi říci, že pro zajištění kvality videokonferenčního provozu v rámci WAN sítě jedné organizace se jedná o použitelný a vhodný protokol. Obdobného výsledku však můžeme dosáhnout i vhodným použitím architektury DiffServ.

Differentiated services (DiffServ)

V současnosti nejpoužívanější architekturou je DiffServ. Jedná se o následníka IntServ architektury. Zatímco IntServ architektura je z hlediska svého konceptu postavená jako signalizace a rezervace od zdroje k cíli, je DiffServ model postaven na myšlence kategorizace provozu do jednotlivých tříd (CoS - Class of Service) pro které jsou nástroji QoS zajištěny kvalitativní parametry přenosu. Tyto parametry jsou definovány konzistentně v rámci DiffServ domény. Jsou však uplatňovány na jednotlivých směrovačích nezávisle. DiffServ architektura je z hlediska svého chování postavena na myšlence preferování určitého provozu před jiným a parametry jsou spíše relativní, než absolutní.

Architektura DiffServ je definována v několika RFC. Nejdůležitějšími jsou: RFC 2475 definuje architekturu, RFC 2474 obsahující detailní popis DSCP pole v IP hlavičce, RFC 2597 Assured Forwarding PHB group definující 12 tříd a standardní způsoby jejich užití, RFC 2598 pro Expedite Forwarding třídu pro low latency provoz. Celý proces je pak možné zjednodušeně popsat následovně. Paket přichází na hraniční směrovač, kde je na hraničním směrovači označen odpovídající značkou v IP hlavičce, v položce ToS. DiffServ používá pro označování prvních 6 bitů v položce ToS, přičemž položka ToS je osmibitová a bity 6 a 7 jsou nepoužity. Pakety mohou také vstupovat do domény již označeny, například IP telefon umí správně označit pakety hlasového hovoru a signalizace, a pokud toto zařízení považují za důvěryhodné, tak akceptují tuto značku. V opačném případě realizují přeznačení paketu dle vlastní politiky. Paket pak cestuje od jednoho směrovače k druhému směrem k cíli. Každý ze směrovačů po cestě uplatňuje k dané třídě provozu svou politiku, nezávisle na ostatních směrovačích - PHB Per Hop Behaviour. Technicky je možné nastavit libovolné chování na jednotlivých přepínačích - vlastní PHB, které by však pro správnou funkci mělo být konzistentní v celé doméně. Existují však i standardizované PHB definované v RFC, Expedited Forwarding (EF) RFC 2598 aassured forwarding (AF) RFC 2597. Pokud paket prochází několika DiffServ doménami, pak je nezbytné zajistit konzistentní přístup k paketům, případně realizovat vzájemné mapování jednotlivých vlastních PHB

Z hlediska užití je v současnosti DiffServ architektura asi rozšířenější než IntServ. Velmi často se při nasazení uplatňuje strategie rozdělení do několika málo tříd, kdy vyhradíte EF pro hlasový provoz, pak definujete třídu pro kritické firemní aplikace a třídu pro ostatní aplikace. Někdy je vhodné také definovat třídu pro „nežádoucí provoz“ a tu omezit tak, aby uživatelům fungovala, ale byla dostatečně pomalá. Taková strategie je obvykle účinnější než prostý zákaz, který se často obchází tunelování v HTTP resp. HTTPS protokolu. Při návrhu QoS pro naše velké zákazníky, jsme si v IBM ověřili, že je nesmírně užitečné používat sofistikovanou metodiku návrhu a mít zkušenosti s jejím návrhem na všech vrstvách ISO/OSI modelu, nejen nad IP.

Výše byly popsány základní architektury pro nasazení QoS v síti. S rozvojem aplikací vyžadujících garantované parametry přenosu a současným trendem „přenosu čehokoliv pomocí IP protokolu“ bude požadavek na zajištění kvality služby stoupat. Z technické problematiky se tak stává obchodní. To výrazně zvyšuje motivaci i případné prostředky pro investice pro nasazení nástrojů QoS.

Autor pracuje jako IT Architect v divizi Global Technology Services ve společnosti IBM Česká republika.