hledat:

6.3  QoS pro aplikace

Cílem projektu je ověření možností specifikace parametrů kvality služeb (Quality of Service - QoS) v ATM sítích až na úroveň koncových stanic uživatelů a ověření možností využití specifikací těchto parametrů při provozu aplikací.

Úvod

Chování distribuovaných aplikací, jejichž komponenty spolu komunikují prostřednictvím počítačové sítě, je závislé na časových charakteristikách komunikačního spojení (propustnost, zpoždění, atd.). Jde například o aplikace z oblasti videokonferencí, telefonie, ale i běžné služby typu Telnet, FTP či WWW. Uživatel aplikace samozřejmě očekává, že mu bude aplikací poskytnuta určitá kvalita služby (Quality of Service - QoS) definovaná v pojmech na aplikační úrovni (celková doba přenosu dat, počet obrázků za sekundu, atd.). Aplikace může poskytnout definovanou kvalitu služeb, pokud použitá platforma propojující její komponenty rovněž poskytuje propojení s definovanou kvalitou.

Do pojmu QoS jsou v širším smyslu zahrnuty tyto oblasti

• Typ služby (Service Category): CBR (Constant Bit Rate), VBR (Variable Bit Rate), UBR (Unspecified Bit Rate), ABR (Available Bit Rate)
• Parametry QoS: CLR (Cell Loss Ratio), CTD (Cell Transfer Delay), CDV (Cell Delay Variation)
• Popis toku dat (Traffic Description): PCR (Peak Cell Rate), SCR (Sustained Cell Rate), MCR (Minimum Cell Rate), MBS (Maximum Burst Size)

Podrobný popis výše uvedených pojmů obsahuje Traffic Management Specification 4.0 [TM4.0]

Zabývali jsme se schopností koncového zařízení ovlivnit kvalitu služeb pomocí parametrů popisujících tok dat a pomocí požadavků na sestavení spoje. Z hlediska provozu distribuovaných aplikací se jeví jako nejdůležitější parametry propustnost (PCR) a zpoždění (CTD). U těchto parametrů je zajímavé sledovat v jednotlivých konfiguracích:

• možnost specifikace parametru
• dodržení specifikované hodnoty
• vzájemné ovlivňování různých spojení se specifikovanými parametry.

Pro měření parametrů síťové komunikace existuje několik nástrojů. Jejich přehled byl vypracován v rámci projektu [CAIDA]. Z těchto nástrojů jsme se rozhodli použít program Netperf pro měření propustnosti a zpoždění na úrovni TCP a UDP, program ttcp pro měření propustnosti na úrovni ATM a běžný program ping pro měření ztrát paketů. Největší pozornost jsme věnovali ověření možnosti dané konfigurace hardware a software poskytnout síťové spojení s nastavenou propustností až na úroveň aplikace. Pro objektivni meření provozu a zejména pro kontrolu signalizace jsme použili ATM analyzátor RADCOM RC-200-C (v2.11)

Přehled ATM karet

Poznámka: Všechny uvedené karty (resp. jejich ovladače) podporují PVC, CLIP a LANE

Možnosti aplikačních rozhraní

Linux

Součástí distribuce ATM v Linuxu je API, které přímo vychází z konceptu socketů podle BSD4.3. Jsou podorována spojení tříd UBR a CBR. Parametry QoS se specifikují nestandardním způsobem, např. místo PCR jsou zadány přípustné hodnoty maximálního a minimálního toku.

IRIX ATM API

API je modelované podle socketů, vyžaduje vyplňování hodně podrobností.

Solaris - karty Fore

Součástí produktu ForeThought verze 5.x (ovladač a nástroje pro karty Fore) je rozhraní X/Open XTI API. Je modelováno podle socketu s jednodušší parametrizací než u IRIX ATM API. Nepodporuje data bez AAL5 obalu.

Solaris - karty Sun

Existují dvě samostatná API: jedno pro komunikaci s Q.2931 ovladačem a kódování/dekódování signalizačních zpráv a druhé pro vysílání a příjem dat z daného VCI/VPI. API pro signalizaci vyžaduje dobrou znalost UNI specifikace, protože není modelováno podle socket API (listen/connect/accept), ale stojí na konstrukci vlastních signalizačních zpráv. Podrobný popis není zveřejněn mimo vlastní software, firma SUN toto API považuje za dočasné. Podporována jsou spojení tříd CBR, VBR a UBR.

MS WindowsNT

Podpora ATM je součástí Winsock 2 API.

Základní srovnávací testy

Základní testy zahrnovaly:

• ověření funkčnosti PVC, IP over ATM (CLIP) a emulace LAN (LANE)
• ověření použitelnosti utilit a konfiguračních nástrojů se zřetelem na možnost specifikovat třídu služeb a parametry toku dat
• změření skutečné hodnoty propustnosti v zavislosti na definovaném PCR
• ověření implementace signalizace, možnost vytvořit SVC dané třídy a parametrů

Poznámka: Ve stanici SUN byl adaptér FORE 200E alternativně zaměněn za SunATM v2.1.

Ve všech případech bylo zjištěno, že adaptéry, jejich ovladače a dodané nástroje mají vlastnosti podle dokumentace. Při těchto testech byl aktivní vždy nejvýše jeden kanál se specifikovanými parametry QoS.

Některé z dalších testů

Kanály CBR (UBR) s rozdílným PCR

Hledali jsme jednoduchý test, který by odhalil rozdíly mezi jednotlivými adaptéry. Jedním z takových testů je měření současného toku v kanálech třídy CBR nebo UBR s rozdílným PCR.

Ovlivňování dvou kanálů

Z tabulky je zřejmé, že QoS u adaptéru Fore200E je prakticky nepoužitelné. Zcela analogické chování bylo sledováno při snaze definovat parametry PCR v prostředí LANE.

Ověřování provozních parametrů u adaptéru ENI-155p v prostředí MS Windows

Jako problémové se ukázalo nastavení Transmit Rate při CLIP, a to nastavení pro SVC podle IP adresy druhé strany. Zatímco při nastavení Default Transmit Rate jak v LANE, tak v CLIP se vytváří SVC s PCR (Peak Cell Rate) zadané hodnoty, v případě omezení podle IP adres se vytvoří SVC třídy UBR bez omezení a rychlost odesílání dat reguluje adaptér. Omezování funguje bez problémů, přenáší-li se data jen po jednom SVC. Jakmile se přenáší data po dvou omezených SVC současně, celkové množství přenášených dat není rovno součtu obou kanálů (jak by se dalo očekávat), ale je výrazně nižší - viz graf na obrázku 6.5.

V testovacím zapojení CLIP bylo nastaveno omezení na směrovač A 2 Mb/s a na směrovač B 1 Mb/s a přenášel se 23 MB velký soubor protokolem FTP z Windows NT stanice na unixové servery připojené za směrovači.

Napřed byl spuštěn přenos na server A (2 Mb), po chvíli spuštěn přenos téhož souboru na server B (1 Mb). Množství přenášených dat, místo aby stouplo na 3 Mb/s, v ten okamžik pokleslo. Po ukončení přenosu na server A se množství přenášených dat ustálilo na nastavený 1 Mb/s. Příčinou "zubů" směrem dolů je stránkování Windows NT.

Ověřování provozních parametrů u adaptéru Fore 200E v prostředí Solaris

Ve verzi softwaru ForeRunner 5.2 je možné nastavovat provozní parametry pomocí příkazu lappqos. V LANE je možné zadat Peak Rate pro spojení určené kombinací IP adresy příjemce/protokolem/portem. Testovali jsme omezení podle IP adresy příjemce v zapojení podle obrázku 6.7.

Při testu jsme nastavili omezení 2 Mb/s na server A a 10 Mb/s na server B. Zjistili jsme, že (stejně jako v případě adaptéru ENI-155p) omezování funguje bez problému, pokud se přenáší data jen po jednom SVC. Jakmile se přenáší data po dvou omezených SVC současně, celkové množství přenášených dat není rovno součtu obou kanálů (jak by se dalo očekávat), ale je výrazně nižší - viz graf na obrázku 6.8.

Jde o přenos 23 MB velkého souboru protokolem FTP. Napřed byl spuštěn přenos pomalejším spojením (2 Mb/s), o chvíli později přenos rychlejším spojením 10 Mb/s. Celkové množství přenášených dat v tu chvíli stouplo jen na 4 Mb/s místo na očekávaných 12 Mb/s.

Ověřování QoS parametrů u adaptéru Olicom RapidFire6162

Adaptéry Olicom RapidFire616x podporují UNI 4.0 a QoS, což jsme testovali v prostředí LANE. Tyto testy byly prováděny v ATM síti s přepínači LS1010 firmy Cisco Systems (ASP PCQ) a zároveň přepínačem FORE LE155 proti směrovačům Cisco série C7000, jak je uvedeno na obrázku 6.9. V této části ATM sítě byl na ATM přepínačích nakonfigurován PNNI směrovací protokol.

Testování spočívalo v požadování různých tříd (CBR, VBR ...) a QoS parametrů (prostřednictvím tzv. profilů provozu) a sledováním skutečných parametrů vytvořených SVC.

Bylo ověřeno, že adaptéry jsou schopny vytvořit spojení na základě údajů specifikovaných v "traffic profiler" SVC v ATM síti s odpovídajícími parametry pro třídy CBR, VBR a UBR. Virtuální okruh třídy ABR se vytvořit nepodařilo, vždy se namísto třídy ABR použil implicitní profil (aktuálně UBR bez omezení PCR). To může být způsobeno jak použitím ASP PCQ v ATM přepínačích (které mají omezenou podporu ABR), tak tím, že směrovače, proti kterým byly testy prováděny, nepodporují ABR třídu služeb. Je také možné, že problémy mohou být mezi Fore a Cisco zařízeními. Zachován byl také požadovaný parametr Maximum Burst Size při vytváření okruhů třídy VBR. Parametr CDVT na ATM přepínačích je dán implicitní hodnotou na daném rozhraní a při konfiguraci ATM adaptéru jej nelze specifikovat.

Zpoždění a rozptyl zpoždění na páteřní ATM síti

Za účelem ověření schopnosti páteřní sítě efektivně poskytovat přenosovou službu aplikacím, které vyžadují při přenosu dat velmi malé přenosové zpoždění nebo jeho rozptyl (například pro emulaci pevných okruhů, interaktivní hlasové aplikace, vzdálené řízení v reálném čase a podobně), jsme provedli pokusy, sledující chování těchto veličin při různých hodnotách celkového zatížení sítě.

Protože jsme neměli k dispozici žádné specializované přístroje schopné změřit sledované veličiny přímo na rozhraní mezi uživatelským zařízením a sítí (UNI), použili jsme pro tato měření PC kompatibilní počítače s operačním systémem Linux, ATM adaptéry typu Efficient Networks ENI-155p a k tomuto účelu zvlášť vytvořený aplikační program. Tento postup na jedné straně přináší snížení přesnosti popisu samotné sítě vlivem průchodu dat běžným ATM adaptérem, který nemá možnost značkování příchozích či vysílaných ATM buněk časovými údaji, a softwarovým zpracováním v operačním systému. Na druhé straně však poskytuje realističtější odhad chování celé datové cesty mezi dvěma aplikačními programy. Pro měření byla zvolena trasa Brno-Praha se spojením typu CBR, toto spojení bylo na každé straně vedeno přes jeden páteřní a jeden přístupový přepínač ATM.

Typické průběhy naměřeného přenosového zpoždění ATM buněk jsou znázorněny v následujícím grafu (na vodorovné ose je vynesen čas vyslání buňky v sekundách od počátku experimentu, na svislé ose je doba přenosového zpoždění ATM buňky v milisekundách). V čase 101,3 sekundy bylo spuštěno na měřené trase zátěžové spojení typu UBR, které generovalo provoz odpovídající plné kapacitě páteřní linky Praha-Brno, kdežto předchozím měřeným buňkám konkuroval běžný provoz (okolo 40 Mb/s).

Nejmenší přenosové zpoždění změřené během testů bylo 3,226 milisekundy, 99,99 % všech buněk dosáhlo zpoždění menšího než 4,2 milisekundy. Zjištěný rozptyl zpoždění kolem jedné milisekundy ukazuje, že páteřní síť ATM, která byla vybudována v rámci projektu TEN-155 CZ, je schopna podporovat aplikace citlivé na parametry přenosového zpoždění a zaručit jim požadovanou kvalitu služeb i v situaci celkového přetížení jiným provozem. Během testů docházelo přibližně u jedné buňky ze 40 tisíc k extrémnímu zpoždění většímu než 30 milisekund. Odhalení a případné odstranění příčiny tohoto jevu bude součástí plánu práce projektu na příští období.

Optimalizace TCP nad ATM okruhy třídy UBR

Práce na optimalizaci TCP přenosů nad ATM spojeními třídy UBR je pokračováním pokusů započatých již v minulém roce, kdy byl hlavním předmětem zájmu vliv velikosti vyrovnávacích pamětí pro TCP v komunikujících systémech na průchodnost TCP spojení. V posledním období jsme zkoumali především závislost průchodnosti TCP spojení na velikosti TCP segmentů. Potřeba takové optimalizace je vyvolána především tím, že adaptéry dosud běžně nepodporují třídu ABR (Available Bit Rate), která je díky podpoře řízení toku pro spolehlivé přenosy vhodnější než UBR. Dalším důvodem pro optimalizaci je nedokonalá implementace funkcí pro manipulaci s pakety (datovými jednotkami AAL5) v dostupných ATM přepínačích.

Pokusná měření byla prováděna na počítačích s operačním systémem Linux a ATM adaptéry typu Efficient Networks ENI-155p pomocí programu ttcp. Velikosti TCP segmentů měřeného spojení byly ovlivňovány pomocí nastavování maximální velikosti paketu (MTU - Maximum Transmission Unit) na odchozím rozhraní vysílajícího počítače. Pro měření byla zvolena trasa Brno-Praha, UBR spojení bylo na každé straně vedeno přes jeden páteřní a jeden přístupový přepínač ATM.

Ačkoli přesný průběh závislosti výkonu TCP na velikosti segmentu se poněkud mění podle velikosti a charakteru (např. plynulý nebo nárazový) ostatního provozu v síti, následující graf tuto závislost dobře ilustruje (na vodorovné ose je vynesena maximální velikost TCP segmentu, na svislé ose je průměrná přenosová rychlost TCP spojení v kilobytech za sekundu). Hodnoty v tomto grafu byly naměřeny na lince Praha-Brno na pozadí běžného provozu (asi 40 Mb/s).

Údaje získané z těchto měření ukazují, že nejvhodnější hodnoty maximální velikosti TCP segmentu (MSS) se pohybují mezi 700 a 1200 oktety. Jsou tedy mnohem menší, než standardní velikost MTU pro IP na ATM (RFC 1577) a významně menší než MTU emulace LAN typu 802.3, která je dnes využívána v páteřní síti TEN-155 CZ jako linková vrstva pro provoz IP.

Aplikace

Jedním z hlavních cílů projektu je navrhnout a ověřit reálné aplikace, které by používaly vlastností QoS. Programový balík ForeThought obsahuje program lappqos, který dovoluje specifikovat třídu služby a PCR pro LANE v závislosti na cílové IP adrese. Tento nástroj by mohl umožnit praktické použití QoS v aplikaci, např. FTP server s rozdílně definovaným tokem dat do vnitřní a vnější části sítě. Bohužel, jak ukazuje výše uvedený výsledek testu, není s typem Fore200E možné provozovat současně více kanálů s rozdílným PCR.

Závěr

Dosud byly testovány ATM adaptéry Fore 200E, Efficient ENI-155p a Olicom RapidFire6162 a částečně SunATM.

Ukázalo se, že starší modely Fore 200E a ENI-155p nepodporují QoS, mají jen možnost nastavení provozních parametrů (traffic parameters). Testováním funkčnosti těchto adaptérů jsme dospěli k závěru, že jsou vhodné pro běžný UBR datový provoz včetně využití virtuálních sítí nad ATM (LANE či CLIP) a dá se u nich (s výhradami) použít omezení maximální rychlosti přenášených dat, např. pro zamezení ztráty ATM buněk v síti (víme-li, že rychlost ATM sítě je nižší než rychlost rozhraní adaptér-síť).

V dalším pokračování projektu plánujeme zahrnout do testů i prostředí SGI IRIX, dokončíme srovnávací testy pomocí pokusných aplikací napsaných v API a soustředíme se na novější adaptéry, které podporují rozhraní UNI 4.0 a QoS - např. na Olicom RapidFire616x a nové verze adaptérů (ForeHE, SunATM v3.0).

předchozí

obsah

následující