hledat:

9   Kvalita služeb ve vysokorychlostních sítích

Projekt se zabývá teoretickými i praktickými aspekty implementace služeb s definovanou kvalitou (Quality of Services, QoS) v prostředí vysokorychlostních sítí. Důraz klademe především na zajištění vysoké výkonnosti celé síťové komunikace, tedy na tzv. end-to-end performance.

Projekt má svoje internetové stránky, kde je možné nalézt naše články, prezentace, výsledky experimentů a vytvořený software. Shrnutí nejdůležitějších výstupů projektu uvádíme dále.

9.1   Implementace QoS na směrovačích Juniper

Již z předchozího období jsou nám dobře známy možnosti implementace QoS na směrovačích Cisco, na kterých je založena síť CESNET2. Jedním z dalších významných výrobců směrovačů je firma Juniper Networks. Její směrovače jsou použity na některých páteřních linkách evropské sítě Géant. V rámci sítě Géant se uvažuje o implementaci služby Premium IP, která má v podstatě zajistit prioritu určitých datových paketů vůči ostatnímu provozu. Ověřili jsme proto i možnosti implementace QoS na směrovačích Juniper.

Pro experimentální práci jsme získali směrovač typu M10, který je svým výkonem a nabídkou portů přibližně srovnatelný s modelem Cisco 7500. Všechny směrovače Juniper mají téměř stejnou hardwarovou architekturu a používají stejný operační systém JUNOS. Předpokládáme proto, že získané informace jsou platné i pro ostatní typy směrovačů.

Pro experimenty jsme použili nejnovější dostupnou verzi operačního systému JUNOS 5.0. V současné době je k dispozici novější verze, která má s ohledem na implementaci QoS navíc několik dalších funkcí. Konfigurace experimentu je znázorněna na obrázku 9.1.

Měření základních QoS charakteristik, t.j. propustnosti, ztrátovosti, zpoždění a rozptylu jsme prováděli programy RUDE/CRUDE a programem qosplot, který jsme vytvořili v rámci projektu.

Jako příklad vyhodnocené vlastnosti uvedeme algoritmus WRR (Weighted Round Robin), který směrovače Juniper používají pro obsluhu front za účelem rozdělení šířky pásma výstupního rozhraní různým třídám datového provozu. Výhodou algoritmu WRR oproti algoritmu WFQ (Weighted Fair Queueing), který používají pro stejný účel směrovače Cisco 7500, je nižší výpočetní náročnost a tím i nižší zátěž procesoru. Nevýhodou je ale to, že algoritmus WRR systematicky zvýhodňuje datové toky s vyšším obsahem delších paketů oproti datovým tokům obsahujícím převážně kratší pakety (například přenos souborů je zvýhodněn oproti hlasové komunikaci). Toto zvýhodnění však není výrazné a v praxi není proto podstatné.

Některé směrovače Cisco, například řady GSR, řeší tento problém algoritmem DRR (Deficit Round Robin), který nevyčerpaný příděl kapacity určité třídy dat z jednoho cyklu obsluhy front přičítá ve prospěch dalšího cyklu, čímž se zvýhodnění delších paketů eliminuje.

Obrázek 9.2 vlevo znázorňuje průběh propustnosti dvou datových toků, které spolu soupeří o kapacitu 100 Mb/s téhož výstupního rozhraní, na kterém není žádná konfigurace QoS. První datový tok sestával z paketů o délce 1500 bajtů (znázorněn tečkovanou čarou), druhý z paketů o délce 256 bajtů (znázorněn plnou čarou). Druhý datový tok byl aplikován v době od 5 do 25 sekund. Je vidět, že průběh propustnosti byl pseudonáhodný.

Pravá polovina obrázku znázorňuje průběh propustnosti po konfiguraci WRR tak, že každému datovému toku byla přidělena šířka pásma 50 Mb/s. Druhý datový tok byl aplikován v době od 5 do 10 sekund. Je vidět, že průběh propustnosti se ustálil a datový tok paketů o délce 1500 bajtů získal o něco větší propustnost než datový tok paketů o délce 256 bajtů.

Směrovače Juniper poskytují programátorské rozhraní (API), umožňující posílání konfiguračních příkazů a přebírání jejich odezev dálkově po síti. Příkazy i odezvy jsou strukturovány jako XML dokumenty. Spojení může být zabezpečeno pomocí SSH.

Směrovače Juniper navíc používají operační systém založený na BSD, který umožňuje spouštění uživatelských procesů. Tyto procesy mohou komunikovat po síti jakýmkoliv protokolem. Implementace určitého typu signalizace, například komunikace s bandwidth brokerem, je proto u směrovačů Juniper mnohem jednodušší, než u směrovačů Cisco, které jsou kompletně uzavřeným systémem.

Verze operačního systému JUNOS 5.0 neposkytovala striktní prioritu vybranému datovému toku, která je potřebná pro implementaci služby Premium IP. Novější verze systému JUNOS již prioritu poskytují. Celkově lze říci, že nabídka funkcí pro implementaci QoS je srovnatelná se směrovačem Cisco 7500 a směrovač Juniper M10 by proto mohl být použit tam, kde je potřebná implementace QoS standardními metodami.

9.2   MDRR na Cisco GSR s adaptérem pro gigabitový Ethernet

Cílem tohoto experimentu bylo ověřit možnosti implementace QoS na směrovačích Cisco GSR s adaptéry pro gigabitový Ethernet, což je typická konfigurace našich hraničních směrovačů v jednotlivých přístupových místech sítě (PoP).

Konfigurace experimentu je znázorněna na obrázku 9.3. Každé PC bylo vybaveno adaptérem pro gigabitový Ethernet. Testovací tok dat 350 Mb/s generovaný na PC1 byl přiveden na port 1 s cílovou adresou PC3. Zátěžový (background) tok 800 Mb/s generovaný na PC2 byl přiveden na port 2 s fiktivní cílovou IP adresou v podsíti portu 3. Tato IP adresa byla ručně vložena do MAC tabulky směrovače. Oba datové toky tak spolu sdílely kapacitu výstupního portu 3. Oba toky sestávaly z paketů o délce 1500 bajtů.

Nejprve jsme použili operační systém IOS verze 12.0(18.5)ST, který byl na směrovači již instalován. Bohužel jsme narazili na problém, že nefungoval ping ze směrovače na PC3. Analýzou jsme zjistili, že směrovač správně odesílal ARP dotazy na IP adresu PC3, který správně odpověděl svojí MAC adresou, směrovač však již tuto odpověď nezpracoval.

Po řadě hodin ladění a opakovaném kontaktu zástupců firmy Cisco Systems jsme dospěli k závěru, že problém je pravděpodobně v nevhodné verzi systému IOS. Nahradili jsme jej proto verzí 12.0(8)S, což problém vyřešilo (šlo tedy o náhradu jedné vývojové verze - early deployment - jinou vývojovou verzí, protože ke směrovači v hodnotě asi 120 000 USD není jiný než vývojový software dodáván).

Průběh propustnosti a zpoždění testovacího toku bez konfigurace QoS jsou znázorněny na obrázku 9.4. Zátěžový tok byl aplikován v době od 5 do 10 sekund. Směrovač udržel plnou propustnost testovacího toku ještě celé dvě sekundy po startu zátěžového toku díky hromadění dat ve frontě. Zpoždění testovacího toku za tuto dobu narostlo na 0,45 sekundy. Protože celkový vstupní tok činil 1150 Mb/s a výstupní tok 1000 Mb/s, rozdíl 150 Mb/s byl akumulován ve frontě. Z toho vyplývá velikost fronty 300 Mb, t.j. 37,5 MB. Bohužel se nám nepodařilo nalézt možnost konfigurace velikosti fronty. Při skončení zátěžového toku došlo k prudkému poklesu propustnosti testovacího toku asi na 100 MB/s na dobu asi 0,7 s. Důvod tohoto jevu není znám.

Pokusili jsme se rozdělit kapacitu výstupní linky na 35 % pro testovací tok a 65 % pro zátěžový tok konfigurací algoritmu MDRR. Pakety testovacího toku jsme posílali s IP prioritou nastavenou na 1 (TOS bajt měl hodnotu 0x20). Pakety zátěžového toku měly standardní IP prioritu 0. Použili jsme následující konfiguraci:

interface GigabitEthernet0/2
 ip address 195.113.147.33 255.255.255.248
 no negotiation auto
 tx-cos group1
!
cos-queue-group group1
 precedence 1 queue 1
 queue 0 65
 queue 1 35

Průběh propustnosti a zpoždění testovacího toku s konfigurací MDRR byly úplně stejné jako bez konfigurace MDRR. Rozdělení kapacity linky tedy nepracovalo. Pravděpodobnou příčinou bylo překročení kapacity front "tofab", ještě před přepínačem paketů (switching engine), kterých je pro pakety určitého rozsahu velikostí vždy omezený počet. Oba použité datové toky sestávaly z paketů téže délky, což bylo bohužel nutné, protože použitá PC nebyla dostatečně výkonná, aby vygenerovala velký datový tok i v kratších paketech.

Pokusili jsme se přidat algoritmus WRED, který sice slouží primárně k prevenci synchronizace řízení toku dat u paralelních TCP spojení, ale lze jej použít i k zahazování paketů podle objemu přicházejících dat. Použili jsme následující konfiguraci:

cos-queue-group group1
 precedence 0 random-detect-label 0
 precedence 1 random-detect-label 1
 random-detect-label 0 1000 2000 1
 random-detect-label 1 2000 3000 1

Průběh propustnosti a zpoždění testovacího toku s konfigurací MDRR a WRED jsou znázorněny na obrázku 9.5. Propustnost testovacího toku byla udržena i při aplikaci zátěžového toku, s výjimkou krátkého poklesu na konci zátěžového toku. Udržení propustnosti však nebyla zásluha algoritmu MDRR. Protože jsme zkonfigurovali algoritmus WRED tak, že bylo dosaženo pravděpodobnosti zahození paketů zátěžového toku rovné 1 při naplnění fronty, kdy teprve začínalo zahazování paketů testovacího toku, bylo vždy zahozeno tolik paketů zátěžového toku, aby prošel celý testovací tok, bez ohledu na jeho objem a přidělený díl kapacity linky.

Změnili jsme rozdělení kapacity linky na 30 % ku 70 % a nastavili jsme stejný rozsah naplnění fronty a odpovídajících pravděpodobností zahození paketů pro oba toky:

cos-queue-group group1
 random-detect-label 0 100 200 1
 random-detect-label 1 100 200 1

Průběh propustnosti a zpoždění testovacího najdete na obrázku 9.6. Nyní se již funkce algoritmu MDRR projevila, testovacímu toku dat byl přidělen přesně požadovaný díl kapacity linky. Lze si všimnout i nižšího zpoždění v době aplikace zátěžového toku díky nižším limitům oblasti zahazování paketů v konfiguraci WRED.

9.3   Vliv QoS charakteristik sítě na přenos MPEG videa

Jednou z perspektivních aplikací počítačových sítí jsou multimediální přenosy s vysokou kvalitou. Pro tyto přenosy se většinou používá kódování ve formátu MPEG (MPEG1, MPEG2 nebo MPEG4). Požadovaná šířka pásma se pohybuje v řádu jednotek až desítek Mb/s a je tedy relativně malá vzhledem ke kapacitě páteřních linek současných sítí, které se pohybují v řádu jednotek Gb/s. Multimediální přenosy jsou však potřebné i mezi body připojenými nižší kapacitou na linkách, které mohou mít vyšší ztrátovost. Příkladem může být přenos přednášky ze sálu, jehož připojení k Internetu bylo zajištěno dočasně instalovaným bezdrátovým zařízením. Zajímali jsme se proto o vliv QoS charakteristik sítě na multimediální přenosy ve formátu MPEG.

Konfigurace experimentu je znázorněna na obrázku 9.7. Vysílající PC bylo vybaveno kartou Optibase MPEG MovieMaker 200, přijímající PC mělo kartu Optibase Videoplex Xpress. Obě karty pracovaly s formáty MPEG1 a MPEG2 v rozměrech SIF, QSIF, Full-D1 a Half-D1. Karta Moviemaker 200 může vysílat data ve formátu MPEG1 kódovaná v reálném čase ze vstupu S-video nebo může použít již zakódovaná data ve formátu MPEG1 nebo MPEG2 uložená v souboru na disku. Použili jsme různé kombinace uvedených formátů s různými rychlostmi posílaných datových toků. Dále uvedená pozorování se ve všech případech v podstatě shodovala.

Vysílající a přijímající počítače byly propojeny přes směrovač pracující pod operačním systémem Linux. Na tomto směrovači jsme instalovali program NIST Net pro emulaci QoS charakteristik sítě. Program umožňuje nastavit požadovanou propustnost, ztrátovost a zpoždění, včetně jeho rozložení.

Ztrátovost paketů se podle očekávání ukázala jako kritický parametr. MPEG přenos bez zabezpečovacího kódu (FEC) netoleruje vůbec žádné ztráty paketů. Například při datovém toku 10 Mb/s v paketech o délce 1500 bajtů znamená nastavená ztrátovosti 0,02 % jeden ztracený paket každých asi 6 sekund přenosu. Tento jediný ztracený paket byl při pozorném sledování viditelný jako pixelizace. Používali jsme poměrně dynamické scény z demonstračního klipu firmy Optibase. Je pravděpodobné, že u méně dynamických scén by efekt byl méně viditelný. Efekt pozorovaný při ztrátovosti 0,02 % a 0,1 % je znázorněn na obrázku 9.8, resp. na obrázku 9.9.

Na druhou stranu, MPEG přenosy se ukázaly být velmi odolnými vůči zpoždění i vůči rozptylu. Zpoždění až do 1 sekundy, což je více než je obvyklé v reálných sítích, bylo zcela bez problémů.

Obrázek 9.10 znázorňuje průběh ztrátovosti na bezdrátové lince Praha-Poděbrady, který jsme změřili v průběhu pěti dnů. Ztrátovost se pohybovala trvale okolo 1,7 %. Neměli jsme bohužel možnost vyzkoušet multimediální přenos přes tuto linku, je však pravděpodobné, že přenos by byl při zjištěné citlivosti na ztráty paketů velmi problematický. Předpokládáme, že stav lze zlepšit také použitím jiného dekodéru na přijímací straně. Pokud by například dekodér v případě výpadku signálu zobrazil raději duplicitní datový snímek místo poškozeného snímku, subjektivní dojem by byl zřejmě lepší.

9.4   Simulace protokolu TCP

Zatímco v předcházejících částech jsme se věnovali experimentům pro tzv. pasivní QoS, kde jde o ochranu datového přenosu před vlivem jiných datových přenosů, dostáváme se nyní do oblasti end-to-end performance neboli tzv. proaktivní QoS. Jeho cílem je získání co nejvyšší propustnosti mezi koncovými body jejich vhodnou konfigurací, případně vhodnou konfigurací sítě. Následující práce stále pokračují, prezentujeme zde proto průběžné výsledky.

Více než 95 % objemu dat je dnes v Internetu přenášeno protokolem TCP. Tento protokol byl navržen v době, kdy sítě pracovaly na mnohem nižších rychlostech než nyní. Ukazuje se, že použití protokolu TCP v rozlehlých vysokorychlostních sítích s sebou přináší určité problémy. Jednou z možností studia těchto problémů je simulace protokolu, během níž můžeme vyzkoušet situace, jejichž testování v reálné síti je obtížné.

Vybudovali jsme proto simulační pracoviště založené na prostředí programu ns2 a vytvořili jsme informační webovské rozhraní s ukázkami jednoduchých simulačních úloh. Ns2 je volně šiřitelný, a to včetně zdrojových textů. Začátky jeho vývoje sahají do osmdesátých let. Od této doby se intenzivně pracuje na zlepšování jeho simulačních schopností a na implementaci nových standardů, například pro bezdrátové sítě. Dostupnost zdrojových textů také umožňuje nahlédnout do tajů implementace různých protokolů. Základní balík ns2 implementuje téměř všechny nejpoužívanější protokoly a mechanismy. Otevřenost projektu ns2 umožňuje implementaci dalších protokolů, koncových aplikací nebo strategií pro zpracování paketů ve směrovačích.

Ns2 má dva programovací prostředky - C++ a skriptovací jazyk OTcl. Objekty v datové cestě (agenty, fronty, linky, atd.) jsou vzhledem k efektivitě implementovány v C++. K ovládání těchto objektů a ke specifikaci topologie je určen skriptovací jazyk OTcl. Tento způsob umožňuje jednoduše a pružně měnit prostředí simulace bez nutnosti dalšího překladu.

Soustředili jsme se na nastavení simulačního prostředí pro realistickou simulaci protokolu TCP s možností získávání informací o dynamice protokolu. To znamená informaci o průběhu propustnosti, o změnách okénka řízení zahlcení na straně vysílače, o změnách RTT a další údaje.

Úkol vyžadoval vytvoření řady skriptů a úpravy simulačních objektů v jazyce C++. Pracujeme i na možnosti dynamické parametrizace řízení zahlcení, tedy na možnosti měnit parametry použitého algoritmu AIMD (Additive Increase Multiplicative Decrease) v průběhu spojení. To umožní studovat chování modifikací protokolu TCP v rozlehlých vysokorychlostních sítích, kde standardní algoritmus řízení zahlcení vzhledem k velkému objemu dat na trase již nestačí.

Na obrázku 9.11 je ukázka průběhu okénka řízení zahlcení (cwnd, horní část obrázku) a průběhu limitu mezi fází slow start a congestion avoidance (ssthresh, spodní část obrázku) jednoho TCP spojení. Zpracováváme technickou zprávu na dané téma.

9.5   Analýza chování protokolu TCP ve vysokorychlostních sítích

Vysílač protokolu TCP musí regulovat rychlost posílání segmentů tak, aby nedošlo k přeplnění vyrovnávací paměti na straně přijímače nebo v některém ze směrovačů na cestě. Regulace se provádí omezováním množství odeslaných a dosud nepotvrzených dat (outstanding window, owin), která mohou být v daném okamžiku na trase. K tomuto účelu používá protokol TCP dva mechanismy, viz obrázek 9.12.

Mechanismus řízení datového toku se stará o přizpůsobení rychlosti posílání segmentů rychlosti přijímače. Přijímač průběžně informuje vysílač o zbývajícím volném místě ve své vyrovnávací paměti (receive window, rwnd). Musí platit owin<=rwnd.

Kromě toho vysílač podle různých typů signálů o blížícím se či již nastalém zahlcení sítě vypočítává svůj další interní limit pro velikost aktuálního okénka (congestion window, cwnd). Tomuto mechanismu se říká řízení zahlcení. Musí platit owin<=cwnd.

Standardní velikost vyrovnávací paměti pro jednotlivé TCP spojení je u současných operačních systémů nastavena obvykle na 64 kB, a to jak na straně vysílače, tak na straně přijímače. Této velikosti také odpovídá maximální velikost okénka během spojení. Pro rozlehlé vysokorychlostní sítě, mající velikou kapacitu dat, která mohou být v kterémkoliv okamžiku na trase, je tato velikost vyrovnávací paměti nedostatečná a je potřeba ji zvětšit.

Zvýšení velikosti vyrovnávací paměti na kapacitu trasy lze provést třemi způsoby: ručně pro jedno TCP spojení na úrovni aplikace, ručně pro všechna TCP spojení na úrovní operačního systému a automaticky pro jednotlivá TCP spojení. V každém případě je potřeba na úrovni operačního systému zapnout window scaling option umožňující použití okének větších než 64 kB a nastavit maximální velikost vyrovnávací paměti. Například v  operačním systému Linux to provedeme následujícími příkazy (příklad pro limit 8 MB):

sysctl -w net/ipv4/tcp_adv_win_scale=1
sysctl -w net/core/rmem_max=8388608
sysctl -w net/core/wmem_max=8388608

Ruční nastavení pro jedno TCP spojení si musí provést aplikace sama, musí být tedy upravena. V jazyku C to lze provést příkazy (příklad pro nastavení na 2 MB):

int size=2097152;
setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (char *)&size, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (char *)&size, sizeof(int));

Ruční nastavení pro všechna TCP spojení na úrovni operačního systému má výhodu v tom, že funguje s každou aplikací, kterou není potřeba upravovat. Nevýhoda je však v plýtvání paměti, protože pouze některá TCP spojení skutečně potřebují velikou vyrovnávací paměť. Příklad opět pro operační systém Linux, čísla udávají po řadě minimální, standardní a maximální velikost vyrovnávací paměti, kterou operační systém přiděluje jednotlivým spojení podle heuristiky na základě okamžité spotřeby paměti a podle dalších konfiguračních parametrů: (příklad pro počáteční nastavení na 2 MB)

sysctl -w net/ipv4/tcp_rmem="4096 2097152 8388608"
sysctl -w net/ipv4/tcp_wmem="4096 2097152 8388608"

Je zřejmé, že pro server, který má otevřeny řádově stovky TCP spojení, je toto řešení neúnosné. Pro více či méně automatickou konfiguraci pro jednotlivá TCP spojení existuje několik alternativních rozšíření jádra operačního systému v podobě patchů nebo pomocných démonů, vyvinutých v rámci výzkumných projektů. Na zlepšování těchto mechanismů se stále pracuje.

Bohužel zvětšení vyrovnávacích pamětí a tím i okénka vysílače nestačí k zajištění spolehlivé vysoké propustnosti v rozlehlých vysokorychlostních sítích. Je potřeba jednak upravit algoritmus řízení zahlcení na vysílači a jednak analyzovat a vyřešit celou řadu jevů, ke kterým při vysokorychlostních přenosech dochází.

Této oblasti se v současné době intenzivně věnujeme. Některé z jevů lze analyzovat rozborem toku paketů zachyceného programem tcpdump. Data jsou analyzována programem tcptrace po ukončení spojení. Další možností je real-time analýza stavových proměnných udržovaných rozšířením jádra web100.

Zhotovili jsme několik skriptů, které umí zkorelovat informace získané z těchto dvou zdrojů. Například obrázek 9.13 znázorňuje v jednom grafu průběh rwnd (horní část grafu) získaný z toku dat odchyceného programem tcpdump a průběh cwnd (dolní část grafu), získaný přes programátorské rozhraní k rozšíření web100. Na obrázku je vidět moderování okénka rwnd, které provádí TCP přijímač v Linuxu za účelem prevence zahlcení sítě náhlými dávkami dat od vysílající aplikace. Obdobnou moderaci provádí i vysílač se svým počítaným okénkem cwnd.

Užitečné je také provést odhad volné kapacity trasy. Nástroje pro tento účel jsou předmětem aktivního výzkumu. Příkladem jsou programy pathload a ABwE. Průběžné výsledky budou prezentovány na konferenci PFLDnet 2003 počátkem příštího roku.

9.6   Další probíhající aktivity

Zúčastnili jsme se přípravných jednáních evropské aktivity PRT (Performance Response Team). V jejím rámci jsme navrhli vytvoření "End-to-End Performance Cookbook", na jejíž obsahové části pracujeme. V prosinci proběhne schůzka o dalším postupu aktivity PRT v roce 2003. Předpokládá se účast Dante a NREN z pěti zemí (Česko, Irsko, Velká Británie, Švýcarsko, Itálie).

předchozí

obsah

následující