Wykorzystanie aktywnego zarządzania kolejkami do utrzymywania bardzo krótkich kolejek pakietów w routerach

POLITECHNIKA ŚLĄSKA WYDZIAŁ AUTOMATYKI, ELEKTRONIKI I INFORMATYKI ROZPRAWA DOKTORSKA Wykorzystanie aktywnego zarządzania kolejkami do utrzymywania bardzo krótkich kolejek pakietów w routerach Łukasz Artur Chróst Promotor: dr hab. inż. Andrzej Chydziński prof. nzw. w Politechnice Śląskiej Gliwice, 2013

Spis treści Spis treści i 1 Wprowadzenie 5 1.1 Motywacja............................ 5 1.2 Oryginalne osiągnięcia..................... 10 1.3 Teza rozprawy......................... 11 2 Przegląd algorytmów AQM 12 2.1 Mechanizmy kolejkowania pakietów.............. 14 2.1.1 Mechanizm PQM.................... 14 2.1.2 Mechanizmy AQM................... 15 2.1.3 RED........................... 15 2.1.4 ARED.......................... 17 2.1.5 SRED.......................... 17 2.1.6 GRED.......................... 17 2.1.7 AN AQM........................ 17 2.1.8 BLUE.......................... 18 2.1.9 CHOKe......................... 18 2.1.10 AVQ........................... 19 2.1.11 PI............................ 19 2.1.12 REM........................... 20 2.1.13 CoDel.......................... 21 2.2 Mechanizmy szeregowania pakietów.............. 22 2.2.1 WRED.......................... 22 2.2.2 RIO........................... 22 2.2.3 SFQ........................... 23 2.2.4 SFB........................... 23 2.2.5 Mechanizm CBQ.................... 23 2.2.6 WFQ........................... 24 i

SPIS TREŚCI ii 3 Analiza kolejki z losowym odrzucaniem pakietów 26 3.1 Model kolejki.......................... 28 3.2 Długość kolejki w chwili ukończenia obsługi......... 28 3.3 Stacjonarny rozkład długości kolejki.............. 34 3.4 Poziom strat pakietów i przepustowość............ 36 3.5 Przykłady numeryczne..................... 37 4 Testy wzorcowe algorytmów AQM 45 4.1 Model sieci........................... 48 4.1.1 Topologia........................ 48 4.1.2 Przepustowości łączy i czasy propagacji........ 48 4.1.3 Wymiarowanie buforów................. 49 4.2 Wzorce transmisji........................ 50 4.2.1 Liczba przepływów................... 50 4.2.2 Źródła transmisji.................... 51 4.2.3 Wariant TCP...................... 52 4.2.4 Transmisja pakietów w przeciwnym kierunku..... 52 4.2.5 Czas symulacji..................... 52 4.3 Metryki............................. 53 4.4 Testy dodatkowe........................ 53 4.4.1 Sprawiedliwość pomiędzy przepływami........ 53 4.4.2 Dodatkowy scenariusz przepustowości i opóźnienia.. 54 4.4.3 Topologia parkingowa................. 54 4.4.4 Oscylacje połączeń TCP................ 54 4.5 Przykładowe wyniki....................... 56 5 Środowisko do symulacji równoległych 60 5.1 Istniejące rozwiązania...................... 62 5.1.1 Środowiska typu SSI.................. 62 5.1.2 Oprogramowanie typu middleware........... 64 5.1.3 PDNS - Parallel/Distributed NS............ 64 5.2 Architektura nowego systemu................. 65 5.2.1 Serwer systemu symulacji............... 66 5.2.2 Uniwersalny parser topologii i aplikacji........ 68 5.2.3 Szeregowanie zadań środowiska ns-2.......... 70 5.3 Ocena wydajności środowiska LGS4Ns2............ 73 5.3.1 Prezentacja wyników.................. 73 6 Zastosowanie podejścia deterministycznego 76

SPIS TREŚCI iii 6.1 Dynamiczny algorytm Drop Tail (FRDT)........... 77 6.1.1 Opis algorytmu..................... 77 6.1.2 Ocena wydajności mechanizmu FRDT........ 79 6.1.3 Charakterystyki wyjściowe............... 80 6.1.4 Zbiorcza analiza porównawcza............. 81 6.1.5 Podsumowanie..................... 86 6.2 Mechanizm AQM z perceptronem (DPB)........... 86 6.2.1 Zastosowanie sztucznych sieci neuronowych w AQM. 87 6.2.2 Opis algorytmu..................... 88 6.2.3 Ocena działania..................... 91 6.2.4 Zbiorcza ocena wydajności............... 92 6.2.5 Stabilizacja kolejki................... 103 6.2.6 Porównanie z algorytmem REM............ 105 7 Podsumowanie 109 Bibliografia 111 Wykaz skrótów 119 Wykaz symboli 121 Spis rysunków 124 Spis tabel 128

Rozdział 1 Wprowadzenie 1.1 Motywacja W dzisiejszym Internecie występuje pewne fundamentalne niedopasowanie mechanizmów kontroli przeciążenia, wbudowanych w protokół transportowy TCP, i mechanizmów kolejkowania pakietów, występujących w warstwie sieci i implementowanych w ruterach, internetowych. Niedopasowanie to ma przyczyny historyczne. Multipleksacja statystyczna pakietów polegająca na tym, że pakiety wchodzące losowo do węzła sieci są dodawane do prostej kolejki w kolejności nadejścia i transmitowane dalej zgodnie z regułą FIFO, jest obecna w Internecie od jego początków. Multipleksacja statystyczna wymaga oczywiście zastosowania w węzłach buforów przeznaczonych na takie kolejki. Zadaniem tych buforów jest krótkotrwałe przechowywanie losowych spiętrzeń pakietów docierających do węzła i uniknięcie w ten sposób strat pakietów, spowodowanych niemożliwością ich natychmiastowej transmisji łączem wyjściowym. A zatem bufory w węzłach sieci powinny być najczęściej prawie puste i zapełniać się tylko w wyjątkowych sytuacjach, tzn. przypadkowych, dużych spiętrzeń ruchu. W połowie lat osiemdziesiątych wprowadzono w Internecie pierwszy zbliżony do dzisiejszych mechanizm kontroli przeciążenia sieci w protokole TCP. Oczywiście były ważne powody do jego wprowadzenia, jednak mechanizm ten wykorzystuje w inny sposób bufory w węzłach Internetu. Mianowicie, nadawca korzystający z protokołu TCP zwiększa liniowo szybkość transmisji pakietów dopóki jest to możliwe, tzn. do momentu W literaturze polskiej można spotkać zarówno formę angielską router jak i spolszczoną ruter. W dalszej części pracy wykorzystana jest forma ruter, które zdaje się dominować w nowych publikacjach. 5

ROZDZIAŁ 1. WPROWADZENIE 6 przeciążenia sieci. Wówczas bufor rutera znajdującego się na ścieżce od nadawcy do odbiorcy zapełnia się i następuje utrata pakietu lub pakietów. Utrata pakietu jest z kolei sygnałem do nadawcy TCP, aby zmniejszył szybkość wysyłania pakietów (zwykle o połowę). Po zmniejszeniu szybkości transmisji o połowę, nadawca znowu zaczyna zwiększać liniowo szybkość wysyłania pakietów, aż do wystąpienia kolejnej straty i tak dalej wykres szybkości transmisji nadawcy przypomina zęby piły. Jak łatwo zauważyć, taki mechanizm kontroli przeciążenia pozostaje w konflikcie z pierwotnym przeznaczeniem buforów w węzłach sieci (zobacz rysunek 1.1). Bufor powinien służyć do przechowywania chwilowych spiętrzeń ruchu i być przeważnie prawie pusty. Tymczasem protokół TCP cały czas próbuje go zapełnić, szukając w ten sposób maksymalnej dostępnej szybkości transmisji. Rysunek 1.1: Konflikt pomiędzy mechanizmem kontroli przeciążenia a mechanizmem kolejkowania w ruterze. Oczywistą konsekwencją takiego stanu rzeczy jest fakt, że długości kolejek w węzłach są duże, a to przekłada się na niepotrzebne opóźnienia pakietów w węzłach. Ponadto występuje kilka innych, bardziej subtelnych negatywnych efektów. Na przykład, może występować synchronizacja zębów piły pomiędzy wieloma nadawcami TCP efekt ten nazywamy globalną synchronizacją źródeł TCP. Łatwo go wytłumaczyć tym,

ROZDZIAŁ 1. WPROWADZENIE 7 że w momencie przepełnienia bufora może zostać utracona cała seria pakietów pochodzących od różnych nadawców TCP. A zatem całe grupy nadawców redukują równocześnie o połowę szybkości transmisji, następnie równocześnie zaczynają ją zwiększać i tak dalej. Właśnie w celu likwidacji tych negatywnych zjawisk w Internecie zaproponowano ideę aktywnego zarządzania kolejkami pakietów w ruterach (ang. Active Queue Management AQM), przedstawioną na rysunku 1.2. Polega ona na tym, że ruter może odrzucać prewencyjnie pakiety, zanim bufor się zapełni, w celu poinformowania źródeł TCP o zbliżającym się przeciążeniu i konieczności zredukowania przez nie szybkości nadawania. W ten sposób teoretycznie ruter może utrzymywać kolejkę na bardzo niskim poziomie. Rysunek 1.2: Idea działania algorytmu AQM. Podstawowa trudność w konstrukcji algorytmu AQM polega na tym, że utrzymywana kolejka powinna być krótka, ale nie pusta. Pusta kolejka powoduje, że łącze wyjściowe nie przesyła pakietów i dochodzi do marnowania zasobu. Krótką kolejkę jest bardzo łatwo otrzymać, np. odrzucając wszystkie przychodzące pakiety. Oczywiście, rozwiązanie takie nie jest interesujące, gdyż nie ma wtedy żadnej transmisji. Znacznie trudniej jest utrzymać krótką, ale niezerową kolejkę. Im krótsza ma ona być, tym zadanie robi

ROZDZIAŁ 1. WPROWADZENIE 8 się trudniejsze i przypomina balansowanie na krawędzi. Jeżeli odrzucimy za mało pakietów, kolejka urośnie ponad zakładany cel. Jeżeli jednak odrzucimy tylko trochę więcej pakietów niż należy, źródła TCP zbytnio zredukują szybkość transmisji i za chwilę kolejka spadnie do zera. Zaprojektowane do tej pory algorytmy AQM wykorzystują różne techniki utrzymywania krótkich kolejek. Najczęściej zakłada się, że każdy przychodzący pakiet może być odrzucony z pewnym prawdopodobieństwem. Prawdopodobieństwo to może zależeć o wielu różnych parametrów obliczonych na podstawie aktualnej długości kolejki, aktualnej intensywności strumienia wejściowego, historii długości kolejki, historii intensywności strumienia wejściowego, historii okresów pustej kolejki, historii okresów przepełnienia bufora, historii procesu odrzucania pakietów, pomocniczych obiektów takich jak wirtualne kolejki itd. Do tej pory zaproponowano już wiele algorytmów aktywnego zarządzania kolejkami [4, 5, 15, 29, 33, 34, 43, 44, 47, 49, 50, 58, 59, 60, 67, 70, 73, 74, 75, 79, 80]. Najważniejsze z nich zostaną omówione w rozdziale 2. Chociaż każdy z nich dość dobrze realizuje podstawowy cel, tzn. redukcję średniej długości kolejki znacznie poniżej poziomu przepełnienia bufora, to posiadają one kilka irytujących wad. Te właśnie wady skłoniły autora rozprawy do poszukiwań nowych, lepszych algorytmów AQM. Po pierwsze, wiele algorytmów co prawda dobrze redukuje średnią długość kolejki, jednak chwilowa jej długość podlega dużym wahaniom, tzn. duża jest wariancja długości kolejki. (Typowe wahania tego rodzaju są pokazane na rysunkach 6.18-6.20). Wahania długości kolejki w węzłach są niekorzystne, gdyż wprowadzają zmienność w opóźnieniu dostarczania pakietów (ang. delay jitter). Ponadto, jeżeli średnia długość kolejki jest niska, to wahania długości powodują pojawianie się pustego bufora, a więc marnowanie przepustowości łącza wyjściowego. Po drugie, część algorytmów wymaga skomplikowanej parametryzacji, przy czym znaczenie niektórych parametrów trudno wyjaśnić intuicyjnie. Nawet w podstawowym algorytmie RED, jeżeli chcemy utrzymywać kolejkę na poziomie 100 pakietów, pojawia się pytanie, czy powinniśmy ustawić parametry progowe na 50 i 150 pakietów czy też na 80 i 120 pakietów? Albo jak uzyskać średnią kolejkę równą 100 pakietów w algorytmie AVQ, w którym podaje się jedynie parametr ϕ, nie mający bezpośredniego związku z kolejką? Administrator sieci komputerowej nie powinien być zmuszony do szczegółowych studiów nad konstrukcją algorytmu AQM. Po trzecie, nawet te algorytmy, które posiadają możliwość ustawiania

ROZDZIAŁ 1. WPROWADZENIE 9 docelowej długości kolejki, często osiągają tę długość kolejki bardzo niedokładnie (np. średnia długość kolejki na rysunku 6.18 przekracza 150 zamiast zadanej 100) lub dopiero po długim czasie (w przykładzie pokazanym na rysunku 6.19 zabiera to aż 60 sekund). Po czwarte, niektóre algorytmy zachowują się niestabilnie w tym sensie, że raz sparametryzowane osiągają dobrą wydajność w niektórych scenariuszach obciążeń i opóźnień w sieci, jednak przy zmianie warunków (np. zmiana liczby przepływów lub ich czasów RTT) zaczynają działać bardzo źle. A zatem celem rozprawy było zaproponowanie algorytmu AQM, który byłby łatwy i intuicyjny w parametryzacji, utrzymywał dokładnie zadaną średnią długość kolejki, minimalizował wahania długości kolejki oraz był mało wrażliwy na zmiany w scenariuszach obciążeń i opóźnień sieci. Innym ważnym celem było to, by algorytm ten potrafił zapewnić dobre wykorzystanie przepustowości łącza nawet przy utrzymywaniu bardzo krótkich kolejek (np. rzędu 30 pakietów). Wszystkie te cele realizuje algorytm DPB zaproponowany w drugiej części rozdziału 6. Aby starannie przetestować rozważane w pracy algorytmy AQM należało zaproponować też zestaw testów wzorcowych algorytmów AQM, który spełniałby dwa warunki: (a) odzwierciedlał najbardziej typowe scenariusze przeciążenia, opóźnienia, topologie i charakterystyki ruchu w Internecie, (b) zawierał rozsądną liczbę takich scenariuszy (tzn. aby było możliwe przeprowadzenie tych testów w rozsądnym czasie). W pracy udało się zaproponować zestaw takich testów wzorcowych (rozdział 4). Aby ograniczyć do minimum subiektywny wpływ autora na postać tych testów, zostały one przygotowane w analogiczny sposób do zaproponowanych wcześniej (przez innych naukowców) testów wzorcowych protokołu TCP. Zaproponowane testy stanowią właściwie uzupełnienie testów TCP o elementy konieczne do testowania AQM. Nawet w swojej podstawowej postaci zestaw testów wzorcowych zawiera dziesiątki scenariuszy, który powinny być zbadane. W celu obliczenia całkowitej liczby koniecznych eksperymentów, tę liczbę scenariuszy należy pomnożyć przez liczbę testowanych algorytmów AQM, przez liczbę powtórzeń każdego eksperymentu (np. w celu zmiany ziaren generatorów liczb pseudolosowych symulatorów), wreszcie przez liczbę różnych różnych

ROZDZIAŁ 1. WPROWADZENIE 10 ustawień parametrów (np. liczbę różnych długości kolejki). Daje to w efekcie dużą liczbę eksperymentów symulacyjnych, w praktyce bardzo trudną do przeprowadzenia przy ręcznym definiowaniu i uruchamianiu eksperymentów symulacyjnych. Dlatego w ramach pracy konieczne było zbudowanie zintegrowanego systemu do automatycznego konfigurowania, przeprowadzania i opracowywania wyników testów symulacyjnych AQM w rozproszonym środowisku obliczeniowym (tzn. przy wykorzystaniu wielu osobnych komputerów lub wielu procesorów w ramach jednej maszyny). System ten, o nazwie LGS4ns2, został opisany w rozdziale 5. Wreszcie, ostatnim przedstawionym tu wynikiem jest analiza modelu kolejki z mechanizmem AQM. Model ten jest tylko pewnym przybliżeniem mechanizmów AQM i nie uwzględnia wszystkich czynników wpływających na ich działanie, jednak jest i tak dokładniejszy i bardziej ogólny niż modele proponowane wcześniej. Ponadto ma on też pewien głęboki, uniwersalny sens, który może spowodować jego przydatność w innych niż AQM obszarach. 1.2 Oryginalne osiągnięcia Podsumowując to, co zostało powiedziane wyżej, w rozprawie przedstawione są następujące oryginalne osiągnięcia: Propozycja algorytmu DPB nowatorskiego mechanizmu AQM potrafiącego zapewnić dobre wykorzystanie przepustowości łącza nawet przy utrzymywaniu bardzo krótkiej kolejki, łatwego do parametryzacji, utrzymującego dokładnie zadaną średnią długość kolejki i zapewniającego niewielkie wahania długości kolejki (rozdział 6, [22]). Zaproponowanie zestawu testów wzorcowych do oceny porównawczej algorytmów AQM (rozdział 4, [21]). Zbudowanie zintegrowanego systemu do automatycznego konfigurowania, przeprowadzania i opracowywania wyników testów symulacyjnych algorytmów AQM w rozproszonym środowisku obliczeniowym z wykorzystaniem symulatora ns-2 (rozdział 5, [20, 13]). Zbadanie analityczne modelu kolejki z mechanizmem AQM, wyprowadzenie wzorów na długość kolejki i przepustowość, podanie przykładów obliczeniowych (rozdział 3, [25]).

ROZDZIAŁ 1. WPROWADZENIE 11 Ponadto, w wyniku przeprowadzonych prac powstało kilka dodatkowych publikacji opisujących różne szczegółowe i poboczne aspekty poruszanej tematyki, [18, 19, 10, 12, 11, 23, 24, 26]. W szczególności, artykuł [18] opisuje rozszerzenie środowiska testowego zaproponowanego dla mechanizmów AQM w celu umożliwienia badania mechanizmów szeregowania danych, wykorzystywanych przez technologię WiMAX. Artykuł [19] opisuje metodę pozwalającą na zapewnienie jakości usług w wielopoziomowych sieciach bezprzewodowych przy wykorzystaniu mechanizmów zarządzania kolejkami. W pracy [10] dokonano analizy zachowania różnych mechanizmów AQM w przypadku współpracy z protokołem TCP w wariancie NCR. Z kolei w pracy [12] zaproponowano wykorzystanie mechanizmu ECN w protokole TCP NCR dla różnych scenariuszy współpracy z AQM. Artykuł [11] rozszerza [10] o porównanie zachowania mechanizmów AQM w różnych scenariuszach przeciążeń generowanego przez źródła TCP NCR. 1.3 Teza rozprawy Przedstawiona w rozdziale 6 konstrukcja algorytmu DPB oraz wyniki przeprowadzonych na nim testów dowiodą następującej tezy. TEZA: Możliwe jest zaprojektowanie algorytmu AQM, który zapewnia wysoki poziom wykorzystania łącza, utrzymuje precyzyjnie zadaną, bardzo niską średnią długość kolejki, zapewnia niewielkie wahania długości kolejki i jest jednocześnie łatwy w konfiguracji.

Rozdział 2 Przegląd algorytmów AQM W rozdziale przedstawiono przegląd różnych mechanizmów aktywnego zarządzania kolejkami. Do tej pory zaproponowano wiele różnych mechanizmów tego typu. Propozycje pojawiły się nie tylko w ramach literatury przedmiotu, ale również w postaci gotowych implementacji na urządzeniach sieciowych, rozszerzonych o instrukcje obsługi tych urządzeń. Autorzy różnych algorytmów AQM próbują rozwiązać rozmaite problemy powstające w przypadku wystąpienia przeciążeń na ruterach. Wśród najpopularniejszych kwestii, którymi się zajmują są: Wysoki stopień wykorzystania dostępnej przepustowości łączy. Do rozwiązania tego problemu przeznaczone są algorytmy RED, ARED, BLUE, GREEN, LDCL. Stabilność kolejek i opóźnień w sieci, wynikających z zastosowania mechanizmów kolejkowania (REM, PI, DRED, CoDel, AN-AQM). Sprawiedliwy podział pasma pomiędzy przepływy, np. CHOKe. Dokładny opis wielu algorytmów kolejkowania i ich porównanie można znaleźć m.in. w [6, 14, 41, 44]. W [45] Braden et al. rozróżniają dwie kategorie algorytmów zarządzania pakietami w buforach: algorytmy kolejkowania, których podstawowym zadaniem jest zarządzanie długością kolejki oraz algorytmy szeregujące, które decydują o kolejności wysyłania pakietów z wielu kolejek. Zarządzanie długością kolejki pakietów w buforze jest ważnym elementem sieci, mającym bezpośredni wpływ na opóźnienie i wariancję opóźnienia. Zastosowanie mechanizmu stabilizującego kolejkę na niskim poziomie pozwala osiągnąć wysoki poziom usług sieciowych w tych kategoriach. Mechanizmy kolejkowania można podzielić na dwie klasy: 12

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 13 algorytmy pasywnego zarządzania kolejkami PQM (ang. Passive Queue Management), algorytmy aktywnego zarządzania kolejkami AQM (ang. Active Queue Management), Pasywne mechanizmy zarządzania kolejką odrzucają pakiety tylko wtedy, kiedy bufor jest całkowicie zapełniony. Podejście to ma trzy zasadnicze wady, które dotyczą transmisji generowanych za pomocą źródeł TCP korzystających z okien przeciążeniowych [45]: Zapełnienie bufora możliwość utrzymywania się przez dłuższy czas stanu pełnej lub pawie pełnej zajętości bufora, znacznie zwiększa opóźnienia pakietów. Zawłaszczenie sieci odrzucanie całych sekwencji pakietów może prowadzić do monopolizacji pasma przez jeden bądź większą liczbę strumieni. Powoduje dysproporcje w podziale zasobów sieciowych. Powstanie fluktuacji mechanizm odrzucania serii pakietów w momencie przeciążenia leży u podstaw globalnej synchronizacji strumieni TCP [58]. Rozwiązaniem problemu przepełnienia bufora jest prewencyjne odrzucanie pakietów, aby nie dopuścić do jego zapełnienia. Odrzucenie pakietu (bądź też jego oznaczenie poprzez wykorzystanie mechanizmu ECN) pozwala powiadomić nadawcę TCP o występującym (lub zbliżającym się) w sieci przeciążeniu, na wczesnym jego etapie. Na podstawie uzyskanej w ten sposób informacji źródła TCP ograniczają szybkość nadawania. Prawdopodobieństwo prewencyjnego odrzucenia pakietu rośnie wraz ze wzrostem poziomu przeciążenia. Idea ta jest wykorzystywana w aktywnych algorytmach zarządzania kolejką. W przeciwieństwie do podejścia polegającego na odrzucaniu pakietów dopiero w momencie, w którym nie mieszczą się w buforze, prewencyjne odrzucanie pakietów wprowadza mechanizm sprzężenia zwrotnego informującego nadawców o zbliżającym się przeciążeniu, zanim nastąpi przepełnienie bufora. Najczęściej stosowaną metodą wyboru, które z pakietów prewencyjnie odrzucić, jest wybór losowy. Podejście to pozwala uniknąć sytuacji, w której wszystkie źródła jednocześnie redukują szybkość nadawania, co w założeniu eliminuje problem globalnej synchronizacji [34]. Algorytmy aktywnego zarządzania kolejkami mają za zadanie zapewnić wysoki poziom

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 14 wykorzystania łącza i zmniejszenia wprowadzanego opóźnienia, a także rozwiązywać problem synchronizacji i zawłaszczania sieci. 2.1 Mechanizmy kolejkowania pakietów Chwilowe spiętrzenia pakietów w sieci są nieuniknione [76]. Kolejkowanie pakietów w ruterach ma na celu buforowanie chwilowych spiętrzeń ruchu. Dlatego ważne jest, aby w stanie stabilnym utrzymywać średni bądź niski poziom zajętości bufora. W przeciwnym wypadku, w sytuacji przeciążenia zostanie odrzuconych więcej pakietów, co prowadzi do globalnej synchronizacji źródeł TCP oraz zmarnowania zasobów wykorzystanych przez pakiety na drodze do rutera, gdyż pakiety odrzucone będą musiały zostać retransmitowane. Ponadto protokół TCP znacznie lepiej radzi sobie w sytuacji pojedynczych strat, niż w przypadku utracenia sekwencji pakietów. Krótka kolejka w ruterze nie wprowadza również dużych opóźnień do transmisji pakietów, co jest szczególnie ważne dla aplikacji czasu rzeczywistego. Mechanizmy PQM nie pozwalają sterować długością kolejki, ale ze względu na prostotę pozostają do dzisiaj najczęściej wykorzystywaną metodą zarządzania pakietami w buforach. Mechanizmy AQM charakteryzują się większą złożonością, niemniej rozwiązują większość przedstawionych problemów. Z tego też powodu stają się coraz popularniejsze. Dodatkowo mogą one obsługiwać funkcję jawnego powiadamiania o przeciążeniu (ECN) co znacząco pozwala obniżyć poziom strat w sieci i zredukować opóźnienia, a zwłaszcza wariancje opóźnienia. 2.1.1 Mechanizm PQM Podstawą działania algorytmów PQM jest kolejka FIFO (ang. First In, First Out). Maksymalna długość kolejki jest stała i ograniczona wielkością bufora. W sytuacji, w której napływający pakiet nie zmieści się w buforze, następuje odrzucenie pakietu. Istnieje kilka strategii wyboru, który pakiet zostanie odrzucony (nie zawsze jest to pakiet napływający). Różne mechanizmy PQM zaczerpnęły swoją nazwę w zależności od strategii działania, którą wykorzystują: Mechanizm odrzucania ogona kolejki (ang. Tail Drop, także Drop Tail) DT jest najpopularniejszym mechanizmem klasy PQM. Jak nazwa wskazuje, odrzucane są wszystkie nadchodzące pakiety, które nie mieszczą się w buforze.

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 15 Mechanizm odrzucania z czoła kolejki (ang. Front Drop, także Drop Front) DF w przypadku nadejścia pakietu, który nie mieści się w buforze, następuje odrzucenie pakietu z czoła kolejki w celu zwolnienia dla niego miejsca. Mechanizm ten skutkuje szybszym powiadomieniem nadawcy TCP o utracie pakietu, niż w przypadku mechanizmu DT. Mechanizm losowego odrzucania z kolejki (ang. Random Drop) w przypadku nadejścia pakietu, który nie mieści się w buforze, następuje losowy wybór pakietu do odrzucenia spośród pakietów znajdujących się w kolejce. Mechanizm podmiany pakietu w celu zwolnienia miejsca dla nadchodzącego pakietu, odrzucany jest pakiet na ostatniej pozycji w kolejce. Podstawową zaletą mechanizmów klasy PQM jest ich łatwa implementacja i minimalna złożoność obliczeniowa. 2.1.2 Mechanizmy AQM Podobnie jak w przypadku mechanizmów PQM, mechanizmy AQM wykorzystują kolejkę FIFO, której długość ograniczona jest wielkością bufora. Jednak w przeciwieństwie do wcześniej opisanych mechanizmów, pakiety odrzucane są nie tylko w momencie przepełnienia bufora ale również wcześniej. Różne mechanizmy AQM stosują różne metody decydowania które pakiety i w którym momencie odrzucić. 2.1.3 RED Pierwszym zaproponowanym mechanizmem klasy AQM, był mechanizm wczesnego odrzucania pakietów (ang. Random Early Detection, RED) [34]. RED szacuje aktualny poziom obciążenia sieci wykorzystując średnią długość kolejki q avg. Wartość ta obliczana jest metodą wykładniczej średniej kroczącej po nadejściu pakietu do kolejki. Algorytm korzysta z dwóch wartości progowych: min th oraz max th, które są wykorzystywane do wyznaczenia trzech stanów pracy. Jeżeli średnia długość kolejki jest mniejsza niż min th wszystkie pakiety są buforowane. Powyżej wartości max th wszystkie pakiety są odrzucane. W przedziale [min th, max th ] pakiety są odrzucane (bądź oznaczane) z prawdopodobieństwem p B : q avg min th p B = p max. max th min th

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 16 Prawdopodobie stwo odrzucenia pakietu 1 p max min th max th rednia d ugo kolejki Rysunek 2.1: Prawdopodobieństwo odrzucenia pakietu w algorytmie RED. Wykres funkcji P w zależności od średniej długości kolejki przedstawia rysunek 2.1. Parametr p max odpowiada prawdopodobieństwu odrzucenia na poziomie max th. Wydajność tego mechanizmu zależy od doboru wartości parametrów konfiguracyjnych, wskazówki na temat sposobu ich wyznaczania można odnaleźć w [30, 33, 34, 41]. Średnia długość kolejki obliczana jest ze wzoru: q avg (t) = (1 w)q avg (t 1) + w q t, (2.1) gdzie q t jest długością kolejki w chwili t, a w parametrem wagowym 0 < w < 1. Wartość współczynnika w stanowi o szybkości reagowania na zmiany przez algorytm RED. Alternatywne metody obliczania średniej długości kolejki, zwiększające sprawność mechanizmu w sytuacji nagłych, krótko i długotrwałych zmian, przedstawiono w [5, 80]. Modyfikacje można znaleźć również w [30, 33, 59]. Podstawowa wersja algorytmu RED, szczególnie źle skonfigurowana, może mieć następujące wady: niską przepustowość, wysokie fluktuacje opóźnienia i niesprawiedliwy podział zasobów. W pracy [52] Low et al. zauważył, że mechanizm kontroli przepływu oferowany przez RED przestaje być stabilny, jeżeli czasy RTT są duże lub jeżeli sieć się rozrasta. Brak stabilności algorytmu w różnych sytuacjach został opisany w [17, 32, 53, 54, 63]. Prace [14, 53] nawet kwestionują przewagę RED nad algorytmem DT.

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 17 Ważniejsze modyfikacje algorytmu RED obejmują trzy kolejno przedstawione algorytmy. 2.1.4 ARED W algorytmie ARED (ang. Adaptive RED), na podstawie obserwacji średniej długości kolejki zmienia się wartość parametru p max. Wartość ta jest redukowana, aby odrzucać pakiety z mniejszym prawdopodobieństwem, jeżeli długość kolejki jest niewielka. Kiedy q avg oscyluje wokół wartości max th, prawdopodobieństwo odrzucenia rośnie [33]. 2.1.5 SRED Algorytm SRED (ang. Stabilized RED) ma na celu stabilizację długości kolejki niezależnie od liczby przepływów. Do obliczenia prawdopodobieństwa odrzucenia pakietu, oprócz aktualnej długości kolejki, wykorzystuje się szacowaną liczbę przepływów. Liczbę tę oszacowuje się utrzymując listę ostatnio widzianych przepływów. Algorytm oferuje mniejszą przepustowość w sytuacji, gdy liczba przepływów jest niewielka [59]. Poza tym, mechanizm szacowania liczby przepływów oraz utrzymywania ich liczby byłby w praktyce bardzo kłopotliwy, szczególnie w ruterach szkieletowych, gdzie liczba przepływów może być rzędu setek tysięcy. 2.1.6 GRED Algorytm GRED (ang. Gentle RED) ma na celu łagodniejsze traktowanie pakietów przychodzących w trakcie małego przeciążenia lub w okresie kiedy przeciążenie dopiero się zaczyna. W praktyce mechanizm GRED implementowany jest w postaci dwóch dodatkowych parametrów konfiguracyjnych: flagi włączającej ten mechanizm oraz wartości granicznej p max. Ustawienie flagi na 1 powoduje, że pakiety napływające w przedziale długości kolejki od min th do max th odrzucane są z prawdopodobieństwem narastającym liniowo od 0 do p max, a w przedziale długości kolejki od max th do 2 max th prawdopodobieństwo odrzucenia pakietu narasta liniowo w zakresie od p max do 1. 2.1.7 AN AQM Algorytm AN (ang. Adaptive Neuron) został zaproponowany w artykule [67]. Algorytm szacuje prawdopodobieństwo odrzucenia nadchodzących

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 18 pakietów w oparciu o sieć neuronową z adaptacyjnym doborem wag. W procesie uczenia neuronu wykorzystuje się technikę uczenia bez nadzoru, zgodnie z regułą Hebba (ang. Hebbian learning). Sygnały wejściowe są wypracowywane na podstawie błędu długości kolejki e(k) oraz znormalizowanego poziomu błędu j(k), opisanych następującymi równaniami: e(k) = q t Q 0, j(k) = r t C 1, gdzie r t jest długością kolejki, Q 0 stanowi docelową długość kolejki, r t jest równy zagregowanej przepływności obserwowanej na wejściu routera, natomiast C jest przepustowością łącza wyjściowego. Algorytm AN wykorzystuje 6 wejść bazujących na aktualnych i poprzednich wartościach wyliczonych poziomów błędu. 2.1.8 BLUE Algorytm BLUE [29], w przeciwieństwie do wielu innych, nie wymaga złożonej konfiguracji. Wartość prawdopodobieństwa odrzucenia p B jest zwiększana o stałą wartość p d w momencie przepełnienia bufora. Gdy kolejka jest pusta, p B jest zmniejszane o stałą p i, która spełnia warunek p i < p d. Zmienna p B jest aktualizowana przy zmianach długości kolejki, jednakże nie częściej niż z góry ustalony czas, zwany czasem zamrożenia (ang. freeze time). Jeżeli wartość prawdopodobieństwa p dla danego strumienia osiągnie wartość równą 1, oznacza to, że nadawca nie reaguje na informacje o przeciążeniu. Taki strumień jest oznaczany jako nieelastyczny i ogranicza się dla niego prędkość wypuszczania pakietów. Zakładając, że charakter ruchu na wejściu rutera nie zmieni się, wartość p będzie dążyć do wartości zapewniającej maksymalną utylizację łącza wyjściowego. Porównanie BLUE z pozostałymi algorytmami AQM można znaleźć w [78]. Rozwiązania zaproponowane w mechanizmie BLUE znalazły zastosowanie w mechanizmie SFB. Mechanizm BLUE wykorzystuje trzy parametry konfiguracyjne: p i, p d oraz czas zamrożenia, nie pozwala więc jawnie wskazać docelowej długości kolejki. 2.1.9 CHOKe Choke (ang. CHOse and Keep for responsive flows, CHOse and Kill for unresponsive flows) [60, 73] jest algorytmem ukierunkowanym na zapewnienie sprawiedliwego podziału przepustowości łącza między poszczególne

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 19 przepływy. Nadchodzący pakiet jest porównywany z losowo wybranym pakietem z kolejki i odrzucany, jeżeli oba należą do tego samego przepływu. Pakiet będący w buforze, dla którego porównanie wypadło pozytywnie, również jest odrzucany. W przeciwnym wypadku pakiet jest odrzucany z prawdopodobieństwem wyliczanym zgodnie z algorytmem RED. Przychodzący pakiet może zostać porównany z większą liczbą losowo wybranych pakietów z kolejki, co znacznie poprawia sprawiedliwość w sytuacji dużego natężenia ruchu UDP. Modyfikacja algorytmu nazwana Self Adjustable CHOKe została przedstawiona w [47]. Zmiana polega na automatycznym dobieraniu liczby pakietów, które zostaną porównane z przychodzącym pakietem. Ponadto, jeżeli pakiet ma zostać odrzucony, stosuje się algorytm wypychania w odniesieniu do pakietów należących do tego samego przepływu. 2.1.10 AVQ W algorytmie AVQ (ang. Adaptive Virtual Queue) [49, 50] wprowadza się ideę wirtualnej kolejki. W chwili odebrania pakietu umieszcza się go w buforze i dodaje żeton do kolejki wirtualnej. Bufor jest opróżniany z prędkością łącza wyjściowego C, natomiast kolejka wirtualna jest opróżniana wolniej, z szybkością ϕ C. Najczęściej współczynnik ϕ = 0.95. Jeżeli w momencie odebrania pakietu długość wirtualnej (a nie prawdziwej) kolejki przekracza maksymalną, zadaną wartość, pakiet jest odrzucany. Algorytm umożliwia utrzymanie średniej długości kolejki na niskim poziomie, co ogranicza wprowadzane opóźnienia. Wykorzystanie przepustowości łącza wyjściowego dąży do wartości parametru ϕ. Podobnie jak w przypadku mechanizmu BLUE, AVQ nie pozwala w jawny sposób ustalić docelowej długości kolejki. Algorytm AVQ został opisany w postaci pseudokodu na listingu 2.1. 2.1.11 PI Mechanizm PI (ang. Propotional Integral) AQM [43, 44] próbuje utrzymać stałą, referencyjną długość kolejki, Q 0, zadaną jako parametr algorytmu. W tym celu wykorzystuje ideę regulatora PI, w którym prawdopodobieństwo odrzucenia wyliczane jest proporcjonalnie do aktualnej długości kolejki i całki z długości do chwili obecnej, zgodnie ze wzorem: p B (T k ) = a [q(t k ) Q 0 ] bqt k 1 + p B T k 1, (2.2)

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 20 1 dla każdego odebranego pakietu : 2 q virt = max(q virt Ĉ(t t 1), 0) / odśwież długość k o l e j k i w i r t u a l n e j / 3 4 j e ż e l i q virt + s p > b to : 5 odrzuć p a k i e t z k o l e j k i r z e c z y w i s t e j 6 w przeciwnym razie : 7 q virt = q virt + s p / odśwież długość k o l e j k i w i r t u a l n e j / 8 koniec warunku 9 10 C = min(ĉ + αϕc(t t 1), C) 11 Ĉ = max(c αb, 0) 12 t 1 = t 13 14 Stałe : 15 C = przepustowość ł ą c z a 16 b = rozmiar bufora k o l e j k i w i r t u a l n e j 17 α = współczynnik wygładzania 18 ϕ = współczynnik wykorzystania ł ą c z a 19 20 Zmienne : 21 Ĉ przepustowość ł ą c z a wirtualnego 22 t czas 23 t 1 czas p r z y j s c a poprzedniego pakietu 24 q virt długość k o l e j k i w i r t u a l n e j 25 s p rozmiar odebranego pakietu 26 C zmienna pomocnicza Listing 2.1: Algorytm AVQ przedstawiony w formie pseudokodu gdzie a, b, T, Q 0 to parametry konfiguracyjne dobierane w zależności od szybkości łącza, RTT, liczby przepływów, itp. W przeciwieństwie do wielu innych mechanizmów, moment wyznaczenia nowej wartości prawdopodobieństwa jest niezależny od zdarzeń i przypada co stały czas T, T k oznacza k-te wystąpienie okresu T. 2.1.12 REM W algorytmie REM (ang. Random Exponential Marking) [4], poziom przeciążenia jest szacowany wykorzystując tzw. koszt k l, który następnie użyty jest do wyznaczenia prawdopodobieństwa odrzucenia. Koszt jest ustalany na podstawie różnicy między szybkością transmisji danych wejściowych

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 21 r t, a przepustowością łącza wyjściowego C oraz różnicy między aktualną zajętością bufora q t i wartością docelową poziomu zajętości bufora Q 0, zgodnie ze wzorem: k l (t + 1) = max(0, k l (t) + γ REM (α REM (q t Q 0 ) + r t C)). Parametr α REM jest współczynnikiem wagowym umożliwiającym obliczenie kosztu, natomiast γ REM wyznacza krok estymacji kosztu. Prawdopodobieństwo oznaczenia (lub odrzucenia) p B jest obliczane ze wzoru p B (t) = 1 Φ kl(t), gdzie Φ jest stałą spełniającą warunek Φ > 1. REM gwarantuje utrzymanie niskiego poziomu zajętości kolejki przy efektywnym wykorzystaniu łącza wyjściowego. Podobnie jak RED, wymaga odpowiedniej konfiguracji w celu uzyskania dobrej wydajności. Rozwinięcia i poprawki algorytmu można znaleźć w [28]. 2.1.13 CoDel Autorzy [58] przyjmują, że dotychczasowe mechanizmy AQM nawiązujące do RED działają w oparciu o błędne założenie polegające na traktowaniu każdego spiętrzenia pakietów w ten sam sposób. Proponują oni wprowadzenie rozróżnienia pomiędzy dobrą kolejką, pozwalającą na rozładowanie chwilowych spiętrzeń, i złą kolejką, w której spiętrzenie ma nie tyle charakter chwilowy, co oscylacyjny bądź ciągły. Proponowany przez nich mechanizm CoDel (ang. Controlled Delay) próbuje rozwiązać problem oscylacji długości kolejki (zwany również migotaniem buforów), poprzez zróżnicowanie sposobu odrzucania pakietów w zależności od tego, w którym ze stanów znajduje się obecnie kolejka. W celu rozwiązania tego problemu autorzy nie tyle obserwują długość kolejki, co mierzą czas t pkt pakietów w kolejce. Wyznaczana jest wartość t min oznaczająca najmniejszą wartość t pkt w przedziale czasu o długości t int, gdzie t int początkowy ustalony jest na 100ms. Po upłynięciu czasu t int sprawdzany jest warunek t min > 5ms. W przypadku dłuższego minimalnego czasu pobytu wartość t int jest zmniejszana i następuje odrzucenie pakietu. W przeciwnym wypadku t int resetowane jest do poziomu początkowego. W przypadku gdy t min 100ms, mechanizm odrzuca wszystkie pakiety w okresie t int. Wartości t int zmniejszane są zgodnie z kolejnymi wyrazami ciągu: 100ms, 100 2 ms, 100 3 ms, 100 4 ms, (2.3)

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 22 Mechanizm ten pozwala na redukcję problemu oscylacji kolejki w buforze, jednak daje słabe wyniki w przypadku przepływów o małych rozmiarach pakietów. 2.2 Mechanizmy szeregowania pakietów Algorytmy szeregowania pakietów wykorzystują więcej niż jedną kolejkę. Kolejki te są obsługiwane w kolejności wyznaczonej przez pewien regulamin, co umożliwia różne traktowanie różnych przepływów, strumieni czy klas ruchu. Mechanizmy te znajdują zastosowanie w sytuacji, gdy oczekiwane jest zachowanie jakości usług (ang. Quality of Service, QoS), np. w rozwiązaniach typu DiffServ [7]. Mechanizmy szeregujące wykorzystywane są do zapewnienia zróżnicowanej obsługi klasom ruchu, aby zapewnić różny priorytet w dostępie do zasobów. Pakiety są klasyfikowane według przyjętego klucza i umieszczane w odpowiedniej kolejce. Każda kolejka może być zarządzana zgodnie z wybranym algorytmem np. DT, RED, PI, czy AVQ. Algorytm szeregowania decyduje o kolejności oraz częstości obsługi danej kolejki. 2.2.1 WRED WRED (ang. Weighted RED) [8] jest rozwinięciem algorytmu RED umożliwiającym zróżnicowaną obsługę klas ruchu. Każdej klasie przydziela się kolejkę RED parametryzowaną różnymi wartościami progów min th oraz max th oraz maksymalnego prawdopodobieństwa odrzucenia p max. Różnice w konfiguracji pozwalają ograniczać ruch o mniejszym priorytecie. 2.2.2 RIO Algorytm RIO (ang. RED In/Out) bazuje na mechanizmie RED. Tryb In algorytmu działa dla pakietów, które przychodzą z prędkością mniejszą lub równą prędkości gwarantowanej dla klasy połączenia, do której należą. Tryb Out działa dla pakietów, które przychodzą z większą prędkością. Dla trybów In i Out zdefiniowane są różne wartości progowe w taki sposób, że tryb Out oznacza o wiele większe prawdopodobieństwo odrzucenia. Wykresy funkcji prawdopodobieństwa odrzucenia przedstawia rysunek 2.2.

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 23 2.2.3 SFQ SFQ (ang. Stochastic Fairness Queueing) [48] polega na przydzielaniu nadchodzących pakietów do różnych kolejek FIFO, tak aby rozdzielić aktywne przepływy. Kolejki są opróżniane w sposób zapewniający sprawiedliwy podział pasma. Przy dużej liczbie aktywnych połączeń, do jednej kolejki może zostać przydzielonych więcej przepływów. Klucz według którego przepływy są klasyfikowane do poszczególnych kolejek zmienia się za pomocą funkcji mieszającej (ang. hash function). 2.2.4 SFB Oryginalny algorytm BLUE nie rozróżnia pakietów pomiędzy poszczególnymi strumieniami i traktuje je wszystkie jednakowo. Dlatego pojedynczy strumień, który nie reaguje na informacje o przeciążeniu, może zająć całą kolejkę i wypchnąć pakiety należące do strumieni, których nadawcy redukują prędkość nadawania. Odmiana SF BLUE (ang. Stochastic Fair BLUE) [31] miesza poszczególne strumienie i wylicza wartość prawdopodobieństwa odrzucania, bądź oznaczania, niezależnie dla każdego klucza. Jeżeli nie ma kolizji między wartościami kluczy, algorytm zapewnia sprawiedliwy podział zasobów między aktywne strumienie. W przypadku kolizji kluczy, algorytm jest sprawiedliwy stochastycznie. W przeciwieństwie do algorytmu SFQ, SFB może zostać zaimplementowany z wykorzystaniem filtru Bloom a [39] zamiast tablicy mieszającej, co znacznie zmniejsza ilość przechowywanych danych, a przez to zapotrzebowanie na pamięć w sytuacji, kiedy liczba strumieni jest duża. 2.2.5 Mechanizm CBQ Algorytm CBQ (ang. Class-Based Queueing) [35] pozwala dzielić przepustowość łącza w określonych proporcjach między zdefiniowane klasy ruchu. Klasy te mogą tworzyć strukturę hierarchiczną, a więc możliwe jest wstępne klasyfikowanie pakietów w zależności od jednego parametru (np. interfejsu sieciowego, z którego pochodzą), a następnie przypisanie ich do klas w zależności od innego parametru (np. aplikacji, która ruch generuje). Przedstawiono to na rysunku 2.3. Klasy należące do tej samej hierarchii klas obsługiwane są za pomocą algorytmu karuzelowego (ang. Round Robin).

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 24 Prawdopodobie stwo odrzucenia pakietu 1 p max Prawdopodobie stwo odrzucenia pakietu 1 p max min th max th rednia d ugo kolejki (a) RED In min th max th rednia d ugo kolejki (b) RED Out Rysunek 2.2: Prawdopodobieństwo odrzucenia pakietów algorytmie RIO a) dla trybu In b) dla trybu Out. ruter A 40% 60% B www ssh www ftp smtp 60% 40% 30% 25% 45% Rysunek 2.3: Podział pasma za pomocą algorytmu CBQ. 2.2.6 WFQ Mechanizm WFQ (ang. Weighted Fair Queueing) [48] umożliwia dodanie wag do poszczególnych kolejek FIFO odpowiadający klasom ruchu. Im niższa waga, tym kolejka jest obsługiwana rzadziej. Algorytm ten można wykorzystać na dwa sposoby. W celu uzyskania sprawiedliwego podziału przepustowości łącza stosuje się strategię polegającą na dynamicznym zmniejszaniu wag poszczególnych klas wraz ze wzrostem liczby i rozmiaru generowanych przez nie pakietów. Podobnie jak w przypadku mechanizmu SFQ, można zastosować klasyfikację opartą o funkcję mieszającą.

ROZDZIAŁ 2. PRZEGLĄD ALGORYTMÓW AQM 25 W celu uzyskania zadanego podziału przepustowości łącza pomiędzy zadane klasy ruchu wagi ustala się na stałe. Wadą tego rozwiązania jest brak kontroli nad opóźnieniem generowanym przez mechanizm szeregujący.

Rozdział 3 Analiza kolejki z losowym odrzucaniem pakietów Jak zostanie pokazane w tym rozdziale, można przeprowadzić analizę systemu kolejkowego, w którym prawdopodobieństwo odrzucenia pakietu zależy od obserwowanej długości kolejki w momencie przyjścia pakietu. W algorytmach AQM wykorzystuje się wiele różnych funkcji, zwanych dalej funkcjami odrzucającymi, mapujących obserwowaną długość kolejki na prawdopodobieństwo odrzucenia pakietu do niej przybywającego. W przypadku algorytmu RED jest to funkcja liniowa, GRED podwójnie liniowa, REM wykładnicza. Dla przedstawionej tu metody analitycznej nie ma znaczenia typ zastosowanej funkcji odrzucającej. Zakładając, że process napływania pakietów do kolejki jest procesem Poissona, możliwe staje się rozwiązanie równań opisujących rozkład długości kolejki. Możliwe jest również obliczenie całkowitego poziomu strat pakietów w systemie a więc i osiąganej przepustowości systemu kolejkowego. Pomimo bogatej literatury zajmującej się tematyką aktywnego zarządzania kolejkami, niewiele prac wykorzystuje analityczne podejście do AQM jako systemu kolejkowego. W przypadku większości opracowań podstawowym narzędziem służącym do opisu i oceny działania systemów AQM są modele zbudowane przy pomocy różnorodnych symulatorów zdarzeń dyskretnych. (Najczęściej spotykanymi środowiskami są narzędzia Network Simulator ns-2 [82], ns-3 [83], [86] czy też OMNeT++ [85]). Jest to dosyć zrozumiałe, ponieważ złożony charakter zachowania protokołu TCP w rzeczywistym środowisku sieciowym prawie uniemożliwia stworzenie dla TCP modelu analitycznego, na podstawie którego udałoby się uzyskać wyniki zbliżone do rzeczywistych (chociaż podejmowane są różne próby). Pomimo, że zastosowanie symulatorów pozwala na zbliżenie się modelu do rzeczywistego 26

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 27 zachowania TCP, środowisko symulacyjne nie pozwala na dogłębną analizę zachowania algorytmów zarządzania kolejkami. Wcześniejsze artykuły poświęcone klasycznej analizie mechanizmów AQM to dwie publikacje: [9] oraz [40]. W pierwszej publikacji autorzy prezentują model kolejki zarządzanej mechanizmem RED, w którym napływ pakietów modelowany jest jako process Poissona z pakietami przychodzącymi w grupach. Ich czas obsługi opisany jest rozkładem wykładniczym. Dodatkowo, model przedstawiony w artykule zakłada, że prawdopodobieństwo odrzucenia pakietu przez mechanizm RED jest stałe dla wszystkich pakietów napływających w jednej grupie. Założenie to nie powoduje dużego poziomu błędu oszacowania, o ile funkcja odrzucająca ma małą zmienność. Autorzy publikacji nie wskazują w jaki sposób uzyskać rozkład stacjonarny π dla łańcucha Markowa; wskazują jedynie, że rozkład ten odbiega od rozkładu dla algorytmu Drop Tail. W dalszej części rozdziału pokazane zostanie, że można zbudować model uwzględniający ogólny rozkład czasów obsługi oraz dowolną postać funkcji odrzucającej, bez konieczności stosowania przybliżeń. Druga praca, [40], dotyczy analizy mechanizmu odrzucania pakietów w oparciu o rozszerzony model kolejki GI X /M/1. Autorzy stosują technikę rozrzedzania procesu przyjmowania pakietów, polegającą na wydłużaniu okresów pomiędzy kolejnymi napływającymi pakietami w wyniku odrzucania niektórych pakietów na wejściu. W pierwszym kroku, przestrzeń wszystkich możliwych długości kolejek dzielona jest na m + 1 przedziałów: [0, L 1 ), [L 1, L 2 ),..., [L m, b]. W ramach każdego przedziału [L i, L i+1 ] prawdopodobieństwo odrzucenia pakietu jest stałe i równe d i. Następnie tak zdefiniowany ciąg prawdopodobieństw przekładany jest na rozrzedzony proces napływu poprzez wprowadzenie gęstości czasów pomiędzy kolejnymi wejściami do kolejki (A i (t)), gdzie indeks i oznacza, że kolejka ma długość [L i, L i+1 ]. Pozwala to na zastosowanie klasycznej metody analizy kolejki GI X /M/1 (autorzy nie podają szczegółów). Niestety, uzyskane rezultaty trudno zastosować do modelowania rzeczywistego systemu. Wyznaczenie rozkładów A i (t) obarczone jest dużym błędem wynikającym z ich przybliżonej natury. Dodatkowo znalezienie ich możliwe jest tylko w przypadku modelowania pod-wykładniczych rozkładów czasu napływu. Metoda zaprezentowana w dalszej części rozdziału korzysta z innego podejścia niż w pracach [9] oraz [40]. Warto jeszcze wspomnieć, że są też podejmowane próby analizy mechanizmów TCP i AQM metodą teorii sterowania zamiast teorii kolejek.

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 28 Wydaje się jednak że, zwłaszcza w przypadku AQM, teoria kolejek oferuje najbardziej naturalny język i narzędzia do rozwiązywania problemów. 3.1 Model kolejki Prezentowany model wykorzystuje pojedyncze stanowisko obsługi z jedną kolejką. Proces napływu zadań do kolejki modelowany jest procesem Poissona o intensywności λ. Czas obsługi opisany jest rozkładem z dystrybuantą F ( ). Każde zadanie napływające do systemu może być zablokowane z prawdopodobieństwem d n, gdzie n to rozmiar kolejki (z uwzględnieniem pozycji zajętej na stanowisku obsługi) w momencie nadejścia zadania. Wielkość bufora zadań jest ograniczona i wynosi b, co można też przedstawić w postaci: d n = 1, dla n b. (3.1) Funkcja odrzucająca d n nie jest wyspecyfikowana w żaden sposób i może przybrać dowolną formę. Przedstawiony model systemu będzie nazywany dalej M/G/1/b(AQM), jako rozwinięcie nazwy systemu o ograniczonym buforze, M/G/1/b, w konwencji Kendalla. Powodem do narzucenia ograniczenia długości bufora, a tym samym ograniczenia liczby zadań w systemie, jest chęć jak najlepszego odwzorowania rzeczywistych systemów, w których urządzenia dysponują ograniczoną wielkością pamięci wykorzystywaną w celu przechowywania pakietów. Dodatkowo, wprowadzenie tego ograniczenia gwarantuje istnienie stacjonarnego rozkładu długości kolejki. P będzie oznaczać prawdopodobieństwo a X(t) zajętość systemu (kolejki oraz stanowiska obsługi) w momencie t. 3.2 Długość kolejki w chwili ukończenia obsługi Niech X n, n = 1, 2,, będzie długością kolejki obserwowaną tuż po ukończeniu obsługi n-tego zadania. Z (3.1) wynika, że dla każdego n, X n < b. Zajmijmy się poszukiwaniem rozkładu X n, to jest: π k = lim n P(X n = k), 0 k b 1. (3.2)

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 29 Dzięki temu, że ciąg X n jest ergotycznym łańcuchem Markowa, możemy obliczyć π k poprzez rozwiązanie układu równań: gdzie liczba π k = b 1 j=0 π j p j,k, 0 k b 1, b 1 j=0 π j = 1. (3.3) p j,k = P(X n+1 = k X n = j), 0 j, k b 1, (3.4) opisuje prawdopodobieństwo przejścia łańcucha X n. Zadanie znalezienia rozkładu stacjonarnego X n możemy rozwiązać poprzez wyznaczenie wartości p j,k. W tym celu wprowadzimy definicję: Q n,k (u) oznacza prawdopodobieństwo, że w przedziale czasu (0, u] dokładnie k zadań zostanie przyjętych do systemu, przy założeniu, że X(0) = n i że pierwsze zadanie opuści system dopiero po czasie u. Oczywiście, pierwsze nadchodzące zadanie jest blokowane z prawdopodobieństwem d n, ale kolejne zadanie blokowane jest z prawdopodobieństwem d n+1 (jeśli pierwsze zadanie weszło do systemu), lub z prawdopodobieństwem d n w przypadku, gdy pierwsze zadanie zostało zablokowane. Wraz z napływem kolejnych zadań opis staje się skomplikowany i ściśle zależy od historii akceptacji oraz odrzuceń zadań poprzednich. Jeżeli przez a n,k oznaczymy prawdopodobieństwo, że k zadań zostało przyjętych do systemu w czasie obsługi jednego zadania, to mamy: a n,k = 0 Q n,k (u)df (u), (3.5) Korzystając z wielkości a n,k możemy otrzymać następującą reprezentację p j,k : a 1,k, jeżeli j = 0, 0 k b 1, p j,k = a j,k j+1 jeżeli 1 j b 1, j 1 k b 1, 0 w innych przypadkach. (3.6) Wzór (3.5) pokazuje, jak bardzo różni się model analityczny systemu kolejkowego typu M/G/1/b(AQM) od modelu dla systemu M/G/1/b. Przykładowe opracowanie dla tego drugiego można odnaleźć w [72]. Zgodnie z klasycznym modelem, współczynniki (3.5) zależą wyłącznie od wartości k i są niezależne od początkowej zajętości kolejki. W przypadku naszego modelu, ich postać jest znacznie bardziej złożona, w zależności od Q n,k (u).

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 30 Należy nadmienić, że w przypadku modelu klasycznego, Q n,k (u) redukuje się do prostej formuły Poissona. Gdyby istniała możliwość obliczenia Q n,k (u), możliwe byłoby również obliczenie p j,k. Niech q n,k (s) oznacza transformatę Laplace dla Q n,k (u): q n,k (s) = Zachodzi następujące twierdzenie: 0 e su Q n,k (u)du. (3.7) Twierdzenie 1.W systemie kolejkowym M/G/1/b(AQM) prawdziwym jest: gdzie q n,k (s) = k 1 i=0 c n+i ki=0, n 0, k 0, (3.8) (s + c n+i ) c n = λ(1 d n ). (3.9) (W celu uproszczenia notacji, używamy konwencji w której 1 i=0 = 1) Dowód Twierdzenia 1. Wykorzystując wzór na prawdopodobieństwo całkowite z uwzględnieniem czasu przyjścia pierwszego zadania, uzyskujemy taki układ równań dla n 0, k > 0: Q n,k (u) = u 0 λe λv( d n Q n,k (u v) + (1 d n )Q n+1,k 1 (u v) ) dv. (3.10) Pierwszy składnik pod całką odpowiada przypadkowi, w którym pierwsze napływające zadanie zostaje zablokowane i nie ma wpływu na zajętość kolejki. Drugi składnik odpowiada przypadkowi, w którym pierwsze napływające zadanie zostaje przyjęte i nowy rozmiar kolejki wynosi n + 1. Podobnie, wykorzystując wzór na prawdopodobieństwo całkowite z uwzględnieniem czasu nadejścia pierwszego zadania, dla n 0, k = 0, otrzymujemy: Q n,0 (u) = u 0 λe λv d n Q n,0 (u v)dv + e λu. (3.11) Pierwszy składnik pod całką odpowiada sytuacji, w której pierwsze nadchodzące zadanie zostaje zablokowane i system pozostaje pusty, podczas gdy drugi czynnik odpowiada sytuacji, w której nie wstąpił napływ zadań w czasie u. Stosując transformatę Laplace do równań (3.10) oraz (3.11), otrzymujemy: λ q n,k (s) = d n q n,k (s) s + λ + (1 d λ n)q n+1,k 1 (s), n 0, k > 0, (3.12) s + λ

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 31 oraz λ q n,0 (s) = d n q n,0 (s) s + λ + 1, n 0. (3.13) s + λ Dalej, z (3.12) otrzymujemy: a z (3.13) q n,k (s) = c n s + c n q n+1,k 1 (s), n 0, k > 0, (3.14) q n,0 (s) = 1 s + c n, n 0. (3.15) Metodą indukcyjną można łatwo sprawdzić, że (3.14) oraz (3.15) prowadzą do (3.8), co kończy dowód. Aby obliczyć Q n,k (u) konieczne jest obliczenie transformaty odwrotnej do transformaty Laplace dla równań q n,k (s). Dzięki założeniu (3.1), dla wartości n b równanie (3.8) przyjmuje postać: q n,k (s) = 0, k 1, (3.16) oraz q n,0 (s) = 1 s, (3.17) co można zapisać jako Q n,k (s) = 0, k 1, (3.18) oraz Q n,0 (s) = 1. (3.19) Przeprowadzenie transformacji odwrotnej dla q n,k (s) dla wartości n < b również nie stanowi większego problemu, ponieważ znana jest postać transformaty odwrotnej dla (3.8). Niech D n,k (s) oznacza mianownik w (3.8): k D n,k (s) = (s + c n+i ). (3.20) i=0 W pierwszej kolejności koniecznym staje się przedstawienie (3.8) w postaci: L D n,k (s) = (s + c j) α j, (3.21) j=1 gdzie L oznacza liczbę różnych pierwiastków D n,k (s) a c j jest jego pierwiastkiem występującym α j razy w D n,k (s). Stosując ten zapis uzyskujemy postać:

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 32 gdzie res s= c j [ ] L Nn,k Q n,k (u) = res s= c j j=1 D n,k (s) esu, (3.22) to residuum w punkcie c j oraz N n,k = k 1 i=0 c n+i. (3.23) Residuum w równaniu 3.22 można łatwo obliczyć używając następującej granicy: res s= c j N n,k D n,k (s) esu = 1 (α j 1)! lim s c j d α [ j 1 (s + c j ) α ] j N n,k e su. (3.24) ṣ α j 1 D n,k (s) Jeśli każdy pierwiastek c j występuje wyłącznie 1 raz (tzn. α j = 1 dla każdego j) to: N n,k N n,k res s= c j D n,k (s) esu = D n,k ( c j) e c j u (3.25) oraz Q n,k (u) = L j=1 N n,k D n,k ( c j) e c j u = k i=0 N n,k D n,k ( c n+i) e c n+iu. (3.26) Stosując równania (3.21) (3.26), głównym zadaniem staje się wyodrębnienie różnych pierwiastków D n,k (s) i wyznaczenie liczby ich wystąpień. Stopnień skomplikowania tego zadania zależy od postaci funkcji odrzucającej. Funkcje różnowartościowe dają łatwe rozwiązania, w przeciwieństwie do funkcji składających się z kilku płaskich części, które to znacząco wpływają na złożoność zadania. Poniższy przykład pokazuje wyniki obliczeń dla funkcji odrzucającej składającej się z części płaskich oraz różnowartościowej. Przykład funkcja odrzucająca RED Funkcja odrzucająca RED (jej kształt przedstawiony został na rysunku 2.1) opisana jest przez dwa parametry: wartość progową b 0, 0 b 0 < b, oraz prawdopodobieństwo p 0, 0 < p 0 1, tak że d b0 = 0, d b 1 = p 0. Wykorzystując te dwa parametry, funkcja odrzucająca RED może być przedstawiona w następujący sposób: 0, jeżeli 0 n b 0, d n = vn + w, jeżeli b 0 < n < b, 1, jeżeli n b, (3.27)

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 33 gdzie v = p 0 b b 0 1, w = p 0b 0 b b 0 1. (3.28) Zadanie polega na wyznaczeniu D n,k (s) dla funkcji odrzucającej (3.27) zapisanej w postaci (3.21). W tym celu możemy wykorzystać równanie (3.20), a następnie policzyć wszystkie otrzymane pierwiastki D n,k (s) oraz ich krotności. Jak widać, funkcja odrzucająca (3.27) składa się z dwóch części płaskich: dla n b 0 oraz dla n b. Obie z nich powodują zwielokrotnienie pierwiastków w (3.20). Co więcej, w równaniu (3.20) pojawia się przesunięty indeks. Zamiast c n, mamy c n+1 dla każdego czynnika (3.20), gdzie i zależy od k. Wynika z tego, że liczba różnych pierwiastków oraz ich krotności zależą od n, k, oraz ich pozycji w relacji do b 0 i b. Konieczne jest rozważenie wszystkich możliwości. Wykonując ten krok otrzymujemy: (s + c 0 ) b 0 n+1 (s + c b ) k b+n+1 b 1 i=b 0 +1 (s + c i), dla k > b n, n < b 0, D n,k (s) = (s + c b ) k b+n+1 b 1 i=n(s + c i ), dla k > b n, n b 0, (s + c 0 ) b 0 n+1 n+k i=b 0 +1 (s + c i), dla b 0 n k b n, n < b 0, n+k i=n (s + c i ), dla b 0 n k b n, n b 0, (s + c 0 ) k+1, dla k b 0 n. (3.29) Wszystkie pierwiastki występujące w tej reprezentacji są różne. Dla przykładu, w pierwszej linii mamy następujące pierwiastki: c 0, c b, c b0 +1,..., c b 1, (3.30) krotności ich występowania wynoszą odpowiednio: b 0 n + 1, k b + n + 1, 1,..., 1. (3.31) Zamiast rozwiązywania równań (3.21) (3.26), można też wykorzystać oprogramowanie komputerowe do obliczeń symbolicznych, mające wbudowane wsparcie dla obliczenia transformaty odwrotnej równania (3.20).

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 34 3.3 Stacjonarny rozkład długości kolejki Możliwe jest nie tylko obliczenie rozkładu długości kolejki w momentach wyjścia pakietu, ale również rozkładu stacjonarnego długości kolejki: P k = lim P(X(t) = k), t 0 k b, (3.32) gdzie X(t) to długość kolejki w chwili t. Oznaczając obciążenie systemu poprzez: gdzie m F = średni czas obsługi = można udowodnić następujące twierdzenie: ρ = λm F, (3.33) 0 xdf (x), (3.34) Twierdzenie 2. W systemie M/G/1/b(AQM) stacjonarny rozkład długości kolejki przyjmuje postać: P k = π k/(1 d k ), 0 k b 1, (3.35) π 0 /(1 d 0 ) + ρ P b = 1 b 1 i=0 π i /(1 d i ) π 0 /(1 d 0 ) + ρ. (3.36) Metoda obliczenia rozkładu π k została już pokazana w części poprzedniej. Dzięki temu, równania (3.35) oraz (3.36) mogą być od razu użyte w celu uzyskania wyników numerycznych. Dowód Twierdzenia 2. Niech X n oznacza długość kolejki obserwowanej w momencie nadejścia n-tego napływającego zadania (zarówno zaakceptowanego jak i zablokowanego) i niech P k oznacza jego rozkład graniczny: P k = lim n P(X n = k), 0 k b. (3.37) Zgodnie z własnością PASTA (zob. [42], str. 391), wiemy że: P k = P k, 0 k b. (3.38) To sprowadza dowód do obliczenia P k dla 0 k b. Niech ˆX n oznacza zajętość kolejki obserwowaną w momencie przyjścia n-tego zaakceptowanego zadnia, i niech ˆπ k oznacza jego rozkład graniczny: ˆπ k = lim n P( ˆX n = k), 0 k b 1. (3.39)

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 35 Oczywiście, rozkłady P k i ˆπ k są różne. Z drugiej strony, ˆXn < b jest zawsze prawdziwe. Zgodnie z twierdzenie Burke a (zob. [71], str. 7), otrzymujemy: ˆπ k = π k, 0 k b 1. (3.40) Niech Pk oznacza graniczny rozkład długości kolejki obserwowanej w momencie napłynięcia n-tego zadania (niezależnie od jego akceptacji lub blokady) przy wyłączeniu kolejek równych b. Wtedy P k oraz Pk są proporcjonalne w przedziale 0 k b 1, w szczególności: dla pewnej stałej c. Z drugiej strony: gdzie z Połączenie P k = oraz (3.41) prowadzi do: P k = c P k, 0 k b 1. (3.41) ˆπ k, 0 k b 1, (3.42) (1 d k )h h = b 1 i=0 ˆπ i 1 d i. (3.43) b P k = 1, (3.44) k=0 b 1 k=0 P k = 1, (3.45) c + P b = 1, (3.46) w którym konieczne jest teraz obliczenie wartości c. Prawdopodobieństwo, że system jest pusty równe jest: gdzie ρ c to przenoszone obciążenie systemu P 0 = P 0 = 1 ρ c, (3.47) ρ c = ρ(1 P B ), (3.48) a P B oznacza prawdopodobieństwo zablokowania i odrzucenia pakietu b P B = d k P k. (3.49) k=0

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 36 Warto zanotować, że z (3.41) wynika, że prawdopodobieństwo blokady w opisywanym systemie jest różne od prawdopodobieństwa wystąpienia przepełnienia bufora (P B P b ). Po przepisaniu (3.47) uzyskujemy: P B = 1 1 P 0. (3.50) ρ Łączne wykorzystanie (3.50), (3.49), (3.41) oraz (3.46) prowadzi do: b 1 k=0 d k cp k + 1 c = 1 1 cp 0 ρ (3.51) i, w konsekwencji, 1 c = P0 + ρ ρ b 1 k=0 d. (3.52) kpk Uwzględniając równanie (3.41) otrzymujemy: P k Pk = P0 + ρ ρ b 1, 0 k b 1, (3.53) i=0 d i Pi natomiast stosując (3.46) otrzymujemy: P b 1 = 1 P0 + ρ ρ b 1. (3.54) i=0 d i Pi Dalej, uwzględnienie (3.42) prowadzi nas do: P k = ˆπ k /(1 d k ) ˆπ 0 /(1 d 0 ) + ρh ρ b 1, 0 k b 1, (3.55) i=0 d iˆπ i /(1 d i ) P b = 1 h ˆπ 0 /(1 d 0 ) + ρh ρ b 1 i=0 d iˆπ i /(1 d i ). (3.56) To w połączeniu z równaniami (3.38) and (3.40) kończy dowód. 3.4 Poziom strat pakietów i przepustowość Poza rozkładem długości kolejki dwie inne charakterystyki są istotne z praktycznego punktu widzenia: poziom strat pakietów oraz przepustowość systemu. Parametry te są szczególnie istotne jeżeli chcemy modelować zachowanie algorytmu AQM w ruterze internetowym.

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 37 Poziom strat pakietów, będziemy definiować jako ułamek pakietów odrzuconych, obserwowany w przebiegach długoterminowych. Jest on tożsamy z prawdopodobieństwem blokowania zadań napływających do systemu, P B. Można go łatwo policzyć wykorzystując równanie (3.50), w oparciu o P 0 = P 0 uzyskane przy pomocy Twierdzenia 2 Przepustowość systemu jest tożsama ze średnim natężeniem ruchu wyjściowego i równa się: γ = λ(1 P B ). (3.57) Dlatego też może być obliczona przy wykorzystaniu (3.50) oraz Twierdzenia 2. 3.5 Przykłady numeryczne 0.8 Prawdopodobieństwo odrzucenia 0.6 0.4 0.2 NI REM RED GRED 0 1 2 3 4 5 6 7 8 9 Rozmiar kolejki Rysunek 3.1: Funkcje odrzucające wykorzystane w przykładach numerycznych. Zaprezentujemy teraz rozkłady długości kolejek i poziomu strat pakietów przy różnych obciążeniach systemu i w przypadku zastosowania różnych funkcji odrzucających. Zakładamy, że czas obsługi zadania d jest stały i równy 1. Dobierając wartość parametru λ można modyfikować obciążenie systemu ρ = λd. Rozróżnimy trzy przypadki: (a) ρ = 1 (system nasycony),

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 38 (b) ρ = 2 (system przeciążony), (c) ρ = 0.5 (system niedociążony), (czyli przy wartościach parametru λ = 1, λ = 2 oraz λ = 0.5). Przyjęto również, że b = 10, oraz że wykorzystane zostaną cztery funkcje odrzucające: (A) Funkcja odrzucająca RED: 0 jeżeli n 3, d n = 0.11917n 0.35752 jeżeli 3 < n < 10, 1 jeżeli n 10. (B) Wersja łagodna funkcji RED (GRED): d n = (C) Funkcja odrzucająca REM: 0 jeżeli n 1, 0.04460n 0.04460 jeżeli 1 < n < 7, 0.24414n 1.44140 jeżeli 7 n < 10, 1 jeżeli n 10. 0 jeżeli n 4, d n = 0.54085e n+4 + 0.54085 jeżeli 4 < n < 10, 1 jeżeli n 10. (D) Niemalejąca funkcja odrzucająca (NI): 0.08387n + 0.41936 jeżeli n 5, d n = 0 jeżeli 5 < n < 10, 1 jeżeli n 10. (3.58) (3.59) (3.60) (3.61) Powyższe funkcje zostały przedstawione na rysunku 3.1. Wszystkie wymienione funkcje odrzucające (A) (D) zostało starannie sparametryzowane w celu wymuszenia na nich utrzymania średniej długości kolejki na poziomie 3 zadań dla ρ = 1. (Fakt ten zostanie skomentowany w dalszej części rozdziału). W tabeli 3.1 oraz na rysunku 3.2 zaprezentowano wyniki numeryczne dla wartości parametru ρ = 1. W szczególności, tabela 3.1 opisuje stacjonarną średnią długość kolejki, odchylenie standardowe długości kolejki, poziom strat oraz prawdopodobieństwa wystąpienia pustego i pełnego bufora. Na

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 39 Średnia Odch. Poziom Prawdop. Prawdop. dł. kol. stand. strat, P B pust. sys., P 0 pełn. buf., P b RED 3.0000 1.8877 9.1281 10 2 9.1281 10 2 1.4669 10 4 GRED 3.0000 2.0517 9.9384 10 2 9.9384 10 2 3.8145 10 4 REM 3.0000 1.8329 8.9339 10 2 8.9339 10 2 2.3479 10 4 NI 3.0000 3.0283 2.4802 10 1 2.4802 10 1 2.5923 10 2 Tabela 3.1: Podstawowe parametry wyjściowe opisujące zachowanie funkcji odrzucających (A)-(D) dla ρ = 1. PRAWDOPODOBIEŃSTWO 0.2 0.15 0.1 0.05 PRAWDOPODOBIEŃSTWO 0.2 0.15 0.1 0.05 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (A) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (B) PRAWDOPODOBIEŃSTWO 0.2 0.15 0.1 0.05 PRAWDOPODOBIEŃSTWO 0.25 0.2 0.15 0.1 0.05 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (C) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI Rysunek 3.2: Rozkłady prawdopodobieństwa długości kolejek w dowolnych momentach czasu dla ρ = 1 dla różnych funkcji odrzucających: (A) RED, (B) GRED, (C) REM, (D) NI. (D) rysunku 3.2 przedstawiono szczegółowe stacjonarne rozkłady długości kolejki. Można zaobserwować, że zarówno poziom strat pakietów jak i odchylenie standardowe kolejki różni się znacząco w zależności od funkcji odrzucającej. Dzieje się tak nawet w sytuacji, w której średnia długość kolejki jest taka sama. Przykładowo, poziom strat pakietów dla funkcji odrzucającej NI wynosi około 25%, podczas gdy w przypadku funkcji odrzucającej mechanizmu

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 40 RED jest to zaledwie 9%. W ogólnym przypadku, im bardziej funkcja odrzucająca skoncentrowana jest w pobliżu małych długości kolejek, tym większy jest poziom strat pakietów oraz odchylenie standardowe długości kolejki. W omawianym przypadku prawdopodobieństwo wystąpienia pustej kolejki oraz przepełnienia systemu jest takie samo. Wynika to oczywiście z faktu, że ρ = 1. Średnia Odch. Poziom Prawdop. Prawdop. dł. kol. stand. strat, P B pust. sys., P 0 pełn. buf., P b RED 7.1458 1.4367 0.50002 4.4488 10 5 3.4385 10 2 GRED 7.7890 1.2363 0.50001 2.2334 10 5 5.0057 10 2 REM 7.1327 1.6627 0.50003 5.2932 10 5 7.4634 10 2 NI 9.3721 0.7457 0.50000 3.0466 10 6 4.9997 10 1 Tabela 3.2: Podstawowe parametry wyjściowe opisujące zachowanie funkcji odrzucających (A)-(D) dla ρ = 2. W tabeli 3.2 oraz na rysunku 3.3 przedstawiono wyniki dla ρ = 2. W przeciwieństwie do poprzedniego scenariusza, w wypadku wystąpienia przeciążenia systemu wyraźnie widać, że prawdopodobieństwo odrzucenia pakietu jest prawie takie samo dla wszystkich funkcji odrzucających. Wynika to z faktu, że w przeciążonym systemie bardzo rzadko występują okresy bezczynności (zob. P 0 ), i prawdopodobieństwo odrzuceń zbliża się do najmniejszej możliwej wartości: 1/2. A zatem mamy tu sytuację, w której otrzymano 4 systemy o takim samym poziomie strat pakietów, lecz o zupełnie różnych rozkładach długości kolejki. W przypadku funkcji odrzucającej NI wartość odchylenia jest bardzo niska. Można na tej podstawie wnioskować, że możliwe jest stworzenie takiej funkcji odrzucającej, która pozwalałaby na utrzymanie średniej długości kolejki na przewidywalnym poziomie (w rozumieniu małej wariancji długości kolejki), ale kosztem dużego poziomu strat. W tabeli 3.3 oraz na rysunku 3.4 przedstawiono wyniki dla wartości parametru ρ = 0.5. Z praktycznego punktu widzenia przypadek ten jest najmniej interesujący, jako że dla ρ 1 kolejka jest stabilna nawet bez zastosowania funkcji odrzucającej. Jednakże nawet w przypadku niskich wartości ρ, wybór i zastosowanie odpowiedniej funkcji odrzucającej może mieć pozytywny skutek w zależności od postawionego celu. Dla przykładu, funkcja NI mogłaby być wykorzystana do utrzymania bardzo niskiej

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 41 0.3 0.4 PRAWDOPODOBIEŃSTWO 0.25 0.2 0.15 0.1 0.05 PRAWDOPODOBIEŃSTWO 0.3 0.2 0.1 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (A) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (B) PRAWDOPODOBIEŃSTWO 0.2 0.15 0.1 0.05 PRAWDOPODOBIEŃSTWO 0.5 0.4 0.3 0.2 0.1 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (C) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI Rysunek 3.3: Stacjonarne rozkłady prawdopodobieństwa długości kolejek dla ρ = 2 dla różnych funkcji odrzucających: (A) RED, (B) GRED, (C) REM, (D) NI. (D) Średnia Odch. Poziom Prawdop. Prawdop. dł. kol. stand. strat, P B pust. sys., P 0 pełn. buf., P b RED 0.74083 0.92341 1.9870 10 3 5.0099 10 1 1.7082 10 8 GRED 0.72134 0.89813 1.0099 10 2 5.0504 10 1 3.7643 10 8 REM 0.74387 0.92902 1.1513 10 3 5.0057 10 1 2.5920 10 8 NI 0.39380 0.68022 3.8635 10 1 6.9317 10 1 7.9364 10 7 Tabela 3.3: Podstawowe parametry wyjściowe opisujące zachowanie funkcji odrzucających (A)-(D) dla ρ = 0.5 długości kolejki (oczywiście kosztem znacznego zwiększenia poziomu strat pakietów). W celu weryfikacji poprawności otrzymanych wyników numerycznych uzyskanych przy wykorzystaniu twierdzeń 1 oraz 2, przeprowadzono szereg symulacji, wykorzystując w tym celu symulator zdarzeń dyskretnych OMNeT++ [85]. Użyto kilka różnych funkcji odrzucających oraz zestawów parametrów konfiguracyjnych. We wszystkich przypadkach wystąpiła wy-

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 42 0.6 0.6 PRAWDOPODOBIEŃSTWO 0.5 0.4 0.3 0.2 0.1 PRAWDOPODOBIEŃSTWO 0.5 0.4 0.3 0.2 0.1 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (A) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (B) 0.6 0.8 PRAWDOPODOBIEŃSTWO 0.5 0.4 0.3 0.2 0.1 PRAWDOPODOBIEŃSTWO 0.6 0.4 0.2 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI (C) 0 2 4 6 8 10 DŁUGOŚĆ KOLEJKI Rysunek 3.4: Rozkłady prawdopodobieństwa długości kolejek w dowolnych momentach czasu dla ρ = 2 dla różnych funkcji odrzucających: (A) RED, (B) GRED, (C) REM, (D) NI. (D) soka zbieżność pomiędzy wynikami uzyskanymi w drodze symulacji oraz metodami analitycznymi. Przykładowe zestawienie wyników otrzymanych na oba sposoby dla funkcji odrzucającej RED i ρ = 1 zostało zaprezentowane w tabeli 3.4. Rozkład długości kolejki został stworzony na podstawie zapisu zajętości kolejki obserwowanej w momencie przyjścia 10 8 zadań (co odpowiadało 10 minutom pracy symulatora). Jak wspomniano wcześniej, parametry funkcji odrzucających zostały dobrane tak, żeby średnia długość kolejki wynosiła 3 dla ρ = 1. Jest to doskonały przykład ilustrujący, że funkcja odrzucająca stanowi narzędzie o bardzo dużych możliwościach. Zamiast średniej docelowej długości kolejki, możliwe jest uzyskanie jednakowego poziomu strat pakietów. Pojawia się w tym miejscu pytanie: w jakim zakresie możliwy jest dobór wartości tych dwóch parametrów? Wartości graniczne są tożsame z naturalnymi ograniczeniami narzuconymi przez system o ograniczonej długości kolejki bez funkcji odrzucającej. Dla przykładu, dla ρ = 1 oraz b = 10, analiza

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 43 Uzyskana Wyniki Wyniki charakterystyka analityczne symulacyjne Średnia długość kolejki 3.0000 2.9991 Odch. standard. kolejki 1.8877 1.8873 Poziom strat 9.1281 10 2 9.1227 10 2 P 0 9.1281 10 2 9.1312 10 2 P 1 1.5684 10 1 1.5691 10 1 P 2 1.7822 10 1 1.7832 10 1 P 3 1.8217 10 1 1.8215 10 1 P 4 1.6764 10 1 1.6760 10 1 P 5 1.2088 10 1 1.2090 10 1 P 6 6.6513 10 2 6.6455 10 2 P 7 2.7031 10 2 2.6974 10 2 P 8 7.7614 10 3 7.7407 10 3 P 9 1.4733 10 3 1.4650 10 3 P 10 1.4668 10 4 1.4577 10 4 Tabela 3.4: Zestawienie wyników analitycznych oraz symulacyjnych dla funkcji odrzucającej RED, wartość ρ = 1. prostego modelu kolejkowego z ograniczoną pojemnością bufora daje średnią stacjonarną długość kolejki 5,0650 a poziom strat 0,05085. Wynika z tego, że przy wskazanych wartościach parametrów, możliwe jest stworzenie systemu o średniej długości kolejki w zakresie [0; 5, 0650] lub systemu o poziomie strat mieszczącym się w przedziale [0, 05085; 1]. Poprawianie znanych algorytmów AQM (np. RED, GRED, REM) bądź też ewentualne rozwinięcie nowych mechanizmów AQM w oparciu o wyniki przedstawione w tym rozdziale może być dokonywane na co najmniej dwa sposoby. Przede wszystkim, możliwe staje się wykorzystanie modelu analitycznego w celu porównania kilku różnych funkcji odrzucających pod kątem ulepszenia interesującej nas charakterystyki pracy algorytmu. Dla przykładu, dla ρ = 1 najlepszą funkcją odrzucającą spośród czterech przedstawionych w bieżącym rozdziale jest funkcja REM. Z wyników zawartych w tabeli 3.1 wynika, że funkcja odrzucająca REM pozwala osiągnąć najniższy poziom strat pakietów (i dzięki temu najwyższy poziom wykorzystania przepustowości łącza) i przy okazji zapewnia stabilizację opóźnień wynikających z kolejkowania pakietów na poziomie porównywalnym z pozostałymi mechanizmami. Wynik ten potwierdzają również badania przedstawione

ROZDZIAŁ 3. ANALALIZA MODELU KOLEJKOWEGO 44 w rozdziale 6. Oczywiście własność ta niekoniecznie będzie prawdziwa w przypadku zastosowania innych wartości ρ. Dodatkowo jest możliwe, że istnieją inne funkcje odrzucające, oferujące wyższą wydajność niż mechanizm REM. Twierdzenie 2 nie daje możliwości wskazania kształtu takiej funkcji wprost. Możliwe jest jednak jej znalezienie poprzez wykonanie pewnej liczby eksperymentów polegających na weryfikacji różnych kształtów funkcji, w oparciu o program komputerowy stanowiący implementację twierdzenia 2 w jednym z języków programowania. Po drugie, w tym rozdziale pokazano możliwość znalezienia kilku różnych funkcji odrzucających dających ten sam rezultat w zakresie utrzymania żądanej średniej długości kolejki. Podobnie ma się sprawa w przypadku innych charakterystyk wyjściowych mechanizmów AQM; możliwe staje się wyszukiwanie funkcji odrzucających, które utrzymają zadaną szybkość transmisji, poziom strat pakietów czy też ograniczą wariancję kolejki pakietów. Co więcej, funkcje odrzucające mają jeszcze większe możliwości: definiując ich kształt, można pokusić się o kontrolę wszystkich tych parametrów na raz (oczywiście tylko w pewnym zakresie). Możliwe jest również uzyskanie różnych charakterystyk wyjściowych w zależności od poziomów obciążenia systemu. Przykładowo, możliwe jest wyszukiwanie funkcji odrzucającej pozwalającej na utrzymanie docelowej długości kolejki na poziomie 2 dla ρ = 1 oraz na poziomie 3 dla ρ = 1, 2. Metoda analityczna przedstawiona w niniejszym rozdziale ma również pewne ograniczenia, jeśli ma być użyta do oceny rzeczywistych mechanizmów AQM implementowanych w ruterach internetowych. Głównym powodem dla tego stanu rzeczy jest fakt, że w pełni funkcjonalny mechanizm AQM wykorzystuje i współpracuje z innymi mechanizmami, nie uwzględnionymi w tym modelu. Przede wszystkim, funkcje odrzucające mogą brać pod uwagę więcej argumentów niż chwilowa długość kolejki. Dla przykładu, rzeczywista implementacja mechanizmu RED bazuje na długości kolejki obliczonej w postaci wykładniczej średniej kroczącej, która wiąże w sobie zarówno chwilową zajętość bufora jak również dane historyczne. Analityczne rozwiązanie modelu systemu AQM opartego o średnią (a nie chwilową wartość) długość kolejki wydaje się być na razie poza zasięgiem możliwości.

Rozdział 4 Testy wzorcowe algorytmów AQM Od czasu wprowadzenia mechanizmu RED, algorytmy aktywnego zarządzania kolejkami cieszą się ciągłym zainteresowaniem, nie tylko w zakresie unikania przeciążeń w sieci, ale również jako część bardziej złożonych mechanizmów, w tym mechanizmów szeregowania pakietów. Głównym powodem takiego stanu rzeczy jest fakt, że zastosowanie standardowego mechanizmu kolejkowania opartego na odrzucaniu pakietów po zapełnieniu bufora wprowadza wiele niechcianych efektów. Globalna synchronizacja przepływów TCP, migotanie buforów (ang. bufferfloat), niepełne wykorzystanie przepustowości łączy, czy też wysokie i nierównomierne opóźnienia są często wymieniane w literaturze. Autorzy nowych propozycji w zakresie mechanizmów AQM prześcigają się w redukcji lub też całkowitej likwidacji niektórych z tych efektów. Niestety, przeglądając literaturę można odnieść wrażenie, że niektóre algorytmy rozwiązując problemy, nawet odnosząc w wybranym zakresie ogromny sukces, zupełnie nie nadają się do zastosowania w rzeczywistych sieciach, ze względu na pogorszenie wyników dla parametrów i topologii sieci innych, niż używane w testach. W związku z tym, że różne algorytmy AQM poprawiają często różne aspekty pracy sieci, wydaje się konieczne utworzenie pewnego uniwersalnego zestawu scenariuszy testowych, który umożliwiałby porównanie różnych algorytmów, o różnych celach, w jednym, spójnym środowisku testowym. Jednocześnie konieczne jest stworzenie listy parametrów pozwalających na dokonanie obiektywnej oceny działania ocenianych mechanizmów. Ewaluacja kilku różnych algorytmów AQM w środowisku testowym wykorzystującym rzeczywiste urządzenia sieciowe nastręcza bardzo wiele 45

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 46 problemów, o ile w ogóle jest możliwa. Bardzo trudno jest odtworzyć warunki sieciowe dla środowisk złożonych nawet z kilkudziesięciu komputerów, z których każdy generuje ruch w postaci kilku przepływów. Dlatego większość autorów wykorzystuje do tego celu symulatory zdarzeń dyskretnych. Wykorzystanie dedykowanego oprogramowania do symulacji, takiego jak Network Simlator (ns-2 oraz ns-3), OMNeT++ czy też OPNET umożliwia szybką weryfikację zachowania projektowanego algorytmu, ale rodzi wiele niebezpieczeństw, np: 1. Przeprowadzenie testów dla scenariuszy sieciowych mało prawdopodobnych w rzeczywistym świecie. 2. Nie przeprowadzenie testów dla scenariuszy, które w istocie często występują w rzeczywistości. 3. Przeprowadzenie przez różnych naukowców z pozoru podobnych testów, które jednak różnią się krytycznymi szczegółami, wpływającymi na wyniki. 4. Wykorzystanie niewłaściwych parametrów do oceny działania badanych algorytmów. (Należy ze szczególną uwagą wybrać, które metryki powinny być użyte w celu oceny danego rozwiązania oraz które powinny być wykorzystane w celu porównania projektowanego mechanizmu z już istniejącymi). Doskonałym przykładem zagrożenia pierwszego typu jest ocena działania algorytmów w scenariuszu równoczesnego przesłania plików o wielkości 1MB przy użyciu warstwy transportowej TCP na łączu o pojemności 1Mb/s przez 100000 użytkowników. Oznaczałoby to konieczność oczekiwania około 10 dni (każdy przepływ miałby do przesłania jedynie około 700 pakietów, nie licząc retransmisji). Wydaje się, że nawet znaczna przewaga konkretnego mechanizmu AQM w tak przesterowanym środowisku nie jest interesująca ze zdroworozsądkowego punktu widzenia. Trzeci z wymienionych problemów objawia się niemożliwością porównania wyników prezentowanych w różnych artykułach. Standardowo, większość artykułów wykorzystuję topologię typu ciężarek (ang. dumbbell), jednak: stosowane są różne pojemności łączy oraz różne czasy propagacji, różni autorzy stosują różne warianty protokołów transportowych (TCP Reno, TCP Cubic, TCP New Reno, SACK, UDP),

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 47 charakterystyka przepływów wynikająca z modelu warstwy aplikacji jest inna w każdej publikacji, wartości innych parametrów konfiguracyjnych są wzajemnie niespójne (rozmiary pakietów, poziomy przeciążenia sieci, obecność lub brak transmisji w przeciwnym kierunku). Oczywiście, można uzasadnić konieczność wprowadzania nowych, niestandardowych testów, czy też wykorzystania nietypowych metryk do oceny zachowania nowego algorytmu AQM, w szczególności w sytuacji, w której nowo projektowany algorytm rozwiązuje nierozwiązany bądź niespotykany dotąd problem. Jednak wyniki takie powinny być uzupełnione wynikami otrzymanymi przy użyciu testów standardowych. Jeszcze stosunkowo niedawno podobny chaos panował w zakresie ewaluacji nowych wersji protokołu TCP. Wreszcie grupa przedstawicieli świata nauki i przemysłu teleinformatycznego pod kierownictwem Andrew [2] zaproponowała zestaw testów wzorcowych mechanizmów TCP. Zaproponowany zestaw ma ułatwić społeczności związanej z rozwojem nowych wariantów TCP ich ocenę. Środowisko bardzo dobrze przyjęło nową propozycję i została ona wykorzystana w wielu późniejszych pracach. Omawiana propozycja składa się z definicji topologii, charakterystyk testowych przepływów oraz zestawów parametrów wyjściowych podlegających ocenie. Szczegółowo scharakteryzowano większość parametrów opisujących testy, niezależnie od wykorzystanego oprogramowania. Zaprezentowane zestawy parametrów są też wciąż uzupełniane. Jako że zadaniem algorytmów AQM jest współpraca z mechanizmami TCP, metodologia oceny tych pierwszych powinna być ściśle powiązana z metodologią oceny TCP. Można wręcz stwierdzić, że jest to wymaganie podstawowe w przypadku wszelkich prób definiowania testów wzorcowych AQM. W niniejszym rozdziale zaprezentowano uzupełnienie wyżej wspomnianych testów wzorcowych TCP w postaci zestawów parametrów dla mechanizmów AQM, które nie są tam zdefiniowane. W stosunku do cytowanego materiału, ograniczono również liczbę obowiązkowych testów. W opinii autora konieczne jest zachowanie kompromisu pomiędzy wysoką reprezentatywnością wyników a nakładem pracy koniecznym do ich uzyskania. Wszystkie testy opisane w niniejszym rozdziale podzielone są na dwie kategorie: testy wymagane oraz dodatkowe. Wszystkie opisy, w których nie zdefiniowano wprost kategorii należą do zestawu testów wymaganych.

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 48 Rysunek 4.1: Topologia typu dumb-bell. 4.1 Model sieci 4.1.1 Topologia Podstawowe testy wykorzystują topologię typu dumb-bell, zaprezentowaną na rysunku 4.1. Topologia ta charakteryzuje się występowaniem pojedynczego łącza stanowiącego wąskie gardło w sieci. Mechanizm AQM podlegający ewaluacji znajduje się w ruterze A i z jego wyjścia są odczytywane dane pomiarowe. Proponowany zestaw testów nie dotyczy wzajemnego wpływu różnych mechanizmów AQM, dlatego również ruter B powinien pracować w oparciu o ten sam mechanizm kolejkujący. 4.1.2 Przepustowości łączy i czasy propagacji Proponujemy dwa scenariusze przepustowości i czasów propagacji z [2]: 1. Access Link wszystkie łącza na rysunku 4.1 mają przepustowość 100Mb/s, jednokierunkowe czasy propagacji wynoszą odpowiednio: N1-RA: 0m, N2-RA: 12ms, N3-RA: 25ms, N4-RB: 2ms, N5-RB: 37ms, N6-RB: 75ms,

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 49 RA-RB: 2ms. Ustawienia te dystrybuują czas RTT w sieci w przedziale od 8ms w przypadku komunikacji N1-N4, do 204ms w przypadku komunikacji na ścieżce N3-N6. Zapewniona jest w ten sposób weryfikacja algorytmu AQM w środowisku o różnych czasach RTT. 2. Data Center- wszystkie łącza posiadają przepustowość 1Gb/s, jednokierunkowe czasy propagacji wszystkich łączy wynoszą 1ms. Scenariusz modeluje lokalne centrum obliczeniowe składające się z 6 węzłów połączonych szybkimi łączami wspomaganymi pracą 2 ruterów. 4.1.3 Wymiarowanie buforów Rozmiar bufora to istotny parametr w przypadku rozpatrywania mechanizmów AQM w ruterach. Zastosowanie dużych buforów pozwala na zwiększenie wykorzystania przepustowości łączy, może jednak powodować powstawanie bardzo dużych i zmiennych opóźnień. Z kolei zastosowanie buforów zbyt krótkich powoduje niski poziom wykorzystania przepustowości łączy. Najczęściej wykorzystywaną metodą oszacowania wymaganej wielkości bufora, stosowaną przez producentów ruterów, jest reguła BDP (ang. Bandwidth Delay Product). Wymaganie co do rozmiaru bufora określane jest jako iloczyn przepustowości i średniego opóźnienia. Średnie opóźnienie nie jest precyzyjnie zdefiniowane, przyjmuje się po prostu 100ms. Raina i Wischnik [62] pokazali, że podejście to jest mniej efektywne od zastosowania krótszych kolejek w przypadku współistnienia połączeń TCP o różnych wielkościach okien nadawczych. Gorinsky z zespołem [37] przekonuje, że wielkość bufora równa 2L, gdzie L to liczba łączy wejściowych rutera jest wystarczająca. Appenzeller et al. [3] sugeruje, że w przypadku ruterów szkieletowych możliwe jest jeszcze większe ograniczenie wielkości bufora. Wischnik i McKeown [77] przekonują, że zmniejszenie buforów nawet do kilkudziesięciu pakietów może być niejednokrotnie wystarczające i niekoniecznie powoduje duże obniżenie poziomu wykorzystania łącza. Z drugiej strony Djadhere et al. [27] wskazał na wiele problemów wynikających z zastosowania bardzo krótkich buforów, w szczególności związanych z dużym poziomem strat pakietów. W związku z tym zaleca jednak zachowanie reguły BDP. W związku z powyższym, przyjmujemy tu konserwatywne zastosowanie reguły BDP. Możliwe jest też zastosowanie innego bufora, ale w dodatko-

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 50 wych testach bądź też w przypadku badań, których podstawowym celem jest ocena skutków zmiany wielkości bufora. 4.2 Wzorce transmisji Podczas opracowywania zestawu wzorcowych testów AQM konieczne jest uwzględnienie wielu aspektów dotyczących symulowanych transmisji danych. Niektóre z tych aspektów to: typ transmisji z punktu widzenia aplikacji, na przykład HTTP, FTP, CBR, warstwa transportowa wykorzystywana podczas transmisji - TCP, UDP, inne aspekty opisujące transmisję na poziomie aplikacji, np. zapotrzebowanie na przepustowość, czas trwania jednostkowej transmisji, liczba przepływów, wariant TCP, jednokierunkowy bądź dwukierunkowy charakter transmisji, poziom przeciążenia sieci. W związku z tym, że [2] skupia się na ocenie wydajności TCP, konieczne jest dostosowanie wykorzystywanych tam wzorców transmisji do potrzeb oceny AQM. 4.2.1 Liczba przepływów Dokument opisujący metodologię testowania TCP nie wskazuje w jaki sposób należy wyznaczać liczbę przepływów w pojedynczym eksperymencie. W związku z powyższym wprowadzamy tu definicję stopnia przeciążenia sieci, oznaczającego dostępną przepustowość sieci obserwowaną przez hipotetycznego użytkownika końcowego. Proponujemy cztery stopnie przeciążenia: brak przeciążenia, łagodne przeciążenie, średnie przeciążenie, silne przeciążenie. Całkowita liczba przepływów określa stopień przeciążenia i wynosi N t = C/r b, gdzie C to przepustowość wąskiego gardła a r b to przepływność pojedynczego połączenia w przypadku równomiernego podziału łącza. Poniżej zdefiniowano sugerowane wartości r b dla czterech stopni przeciążenia:

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 51 łącze nieprzeciążone: r b = 10Mb/s, łagodne przeciążenie: r b = 1Mb/s, średnie przeciążenie: r b = 500kb/s, silne przeciążenie: r b = 100kb/s. Jeżeli np. C = 100Mb/s i aktywnych jest 100 połączeń, to przepływność każdego z nich będzie wynosiła maksymalnie 1M b/s. A zatem jest to scenariusz łagodnego przeciążenia. Innymi słowy, dla łącza 100M b/s brak przeciążenia uznajemy przy liczbie przepływów do 10, łagodne przeciążenie przy liczbie przepływów równej 100, średnie przeciążenie przy liczbie przepływów 200 i silne przeciążenie przy liczbie przepływów równej 1000. Powodem odstąpienia od kryterium przeciążenia bazującego na poziomie strat pakietów (przez niektóre źródła wskazywanym jako dobry sposób oceny przeciążenia), na korzyść kryterium opartego na obserwowanej przepływności połączeń jest fakt, że poziom utraty pakietów jest silnie zależny od zastosowanego mechanizmu AQM. Poziom strat pakietów wydaje się bardziej odpowiedni do opisu wyników symulacji, niż do jej parametryzacji. 4.2.2 Źródła transmisji Przepływy TCP o rozmiarze pakietu 1500B powinny stanowić 90% wszystkich przepływów. Pozostałe 10% przepływów powinno składać się z przepływów TCP o rozmiarze pakietu 536B. Zarówno przepływy o pakietach wielkości 1500B jak i 536B powinny być równomiernie rozłożone pomiędzy wszystkie 9 ścieżek transmisyjnych, czyli N1-N4, N1-N5,..., N3- N6. W przeciwieństwie do [2], nie naciskamy na wykorzystanie bardzo złożonych generatorów mających na celu dokładne odwzorowanie zachowania aplikacji HTTP w celu nałożenia schematu zachowań na część przepływów TCP. Generatory ruchu bazujące na odtwarzaniu wektorów zachowań powstałych w wyniku analizy zapisów rzeczywistych transmisji HTTP nie są doskonałe i dotychczas nie wykazano ich przewagi nad rozwiązaniami prostszymi. Sugerowany sposób symulacji polega na podziale przepływów o pakietach 1500B na dwie grupy: 25% z nich powinno być traktowanych jako przepływy krótkotrwałe, a pozostałe powinny być traktowane jako przepływy o długim czasie trwania. Przepływy krótkotrwałe uruchamiane są losowo, zgodnie z procesem Poissona. Ich długość definiowana jest wielkością danych do przesłania

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 52 (liczba bajtów). Rozmiar danych ma rozkład Pareto, gdzie wartość średnia avg = 50kB a współczynnik kształtu α = 1.3 (zob. [57]). Intensywność procesu Poissona dobrana jest tak, że średnia długość czasu ON (przesyłanie krótkiego pliku) i średnia długość czasu OFF (brak przepływu pliku) są równe, z czego wynika, że λ = r b /(2avg). W testach dodatkowych 10% wszystkich przepływów N t to przepływy wykorzystujące protokół transportowy UDP. Przepływy UDP operują na pakietach o długości 1000B, wysyłanych przez o aplikację CBR (Constat Bit Rate). Częstość ich wysyłania wynika z dobranej wartości r b. Tak jak w poprzednich przypadkach, przepływy UDP powinny być równomiernie rozłożone pomiędzy wszystkie dziewięć ścieżek transmisji. Pozostałe 90% wszystkich przepływów to opisane wcześniej połączenia TCP o rozmiarach pakietów 1500B i 536B, w takich jak podane wyżej proporcjach. 4.2.3 Wariant TCP Praktycznie wszystkie współczesne systemy operacyjne implementują mechanizm selektywnych potwierdzeń (SACK - Selective Acknowledgment) TCP. Dlatego wydaje się kluczowe, żeby mechanizm SACK był włączony. Jedynie specyficzna potrzeba powinna skutkować wyłączeniem tego mechanizmu, ale tylko dla pewnej liczby przepływów. 4.2.4 Transmisja pakietów w przeciwnym kierunku Wpływ transmisji w kierunku przeciwnym do badanej transmisji TCP opisywany jest, między innymi, w [33, 65]. Należy pamiętać, że protokół TCP przesyła z powrotem do nadawcy pakiety potwierdzeń (ACK). Ponadto założyliśmy, że obydwa rutery, w obu kierunkach mają zaimplementowany mechanizm AQM. Z tych powodów symulacja ruchu wstecznego jest konieczna. W celu symulowania ruchu wstecznego w tle proponowane jest użycie transmisji UDP (CBR, pakiety o długości 1000B), stanowiących 10% wszystkich przepływów. Intensywność ruchu CBR powinna bazować na wybranej wartości parametru r b. Dodatkowe testy mogą operować na dodatkowej liczbie przepływów UDP, powodując obciążenie tła równe średniemu obciążeniu sieci. 4.2.5 Czas symulacji Każda symulacja powinna trwać co najmniej 100 sekund. Wszystkie metryki wyjściowe powinny być obliczane od 30-tej sekundy symulacji.

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 53 Opóźnienie zbierania wyników ma na celu ograniczenie wpływu warunków początkowych symulacji i umożliwia zbadanie algorytmu w stanie ustalonym sieci. 4.3 Metryki W każdym przebiegu symulacji, dla łącza stanowiącego wąskie gardło sieci (RA RB), zbierane będą poniższe statystyki: Zagregowana przepływność wszystkich przepływów (a więc poziom wykorzystania przepustowości łącza). Średnia długość kolejki (lub średni błąd długości kolejki, jeżeli badany algorytm pozwala na ustawienie docelowej długości kolejki). Odchylenie standardowe długości kolejki. Zagregowany poziom strat pakietów. Dodatkowo można oceniać poziom strat pakietów z większą granulacją (np. osobno dla każdego przepływu). W testach dodatkowych ciekawa jest ocena poziomu strat na poziomie pojedynczych przepływów UDP. Wynika to z faktu, że utrata pakietów ma zupełnie inny wpływ na transmisje UDP, niż na TCP. W przypadku zbierania statystyk utraty pakietów z granulacją na poziomie pojedynczych przepływów, możliwe staje się określenie współczynnika sprawiedliwości pomiędzy przepływami dla algorytmu AQM w kontekście odrzucania przez niego pakietów. 4.4 Testy dodatkowe Oprócz opisanych wcześniej dodatkowych zestawów parametrów do wykorzystania w trakcie porównawczej ewaluacji algorytmów klasy AQM, poniżej wskazane są inne możliwe rozszerzenia godne uwagi, wraz z podaniem ich skróconego opisu. 4.4.1 Sprawiedliwość pomiędzy przepływami Dodatkową metryką, która może podlegać ocenie, jest sprawiedliwość podziału dostępnej przepustowości pomiędzy przepływy danych. Sprawiedliwość powinna być mierzona na podstawie przepływności osiąganej przez

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 54 badane przepływy. Ocenie podlegają dwie grupy przepływów: długowieczne przepływy TCP (FTP) oraz długowieczne UDP (CBR), o ile są uwzględnione w symulacji. Agregowana przepływność powinna być mierzona osobno dla każdego przepływu pod obserwacją. W celu określenia współczynnika sprawiedliwości należy posłużyć się indeksem Jain a ([46], [51]), osobno dla przepływów TCP oraz UDP: J(x 1, x 2,, x n ) = ( n ) 2 x i i=1 n, (4.1) n x 2 i i=1 gdzie x i to zmierzona przepływność pojedynczego przepływu a n to liczba przepływów. 4.4.2 Dodatkowy scenariusz przepustowości i opóźnienia Transoceanic link- wszystkie łącza z topologii dumbbell mają przepustowość 1Gb/s, opóźnienia propagacji są zgodne ze scenariuszem Access Link, poza łączem RA-RB, stanowiącym wąskie gardło. Jednokierunkowy czas propagacji na tym łączu wynosi 65ms. Scenariusz ten pozwala na ocenę algorytmu AQM w środowiskach o wysokiej wartości iloczynu przepustowości i opóźnienia. 4.4.3 Topologia parkingowa Uruchomienie dodatkowych symulacji przy wykorzystaniu topologii przedstawionej na rysunku 4.2. Badany algorytm AQM zaimplementowany jest na wszystkich ruterach. Zgodnie z [2], poziome łącza, stanowiące wąskie gardła sieci, mają przepustowość 100Mb/s, podczas gdy łącza pionowe mają pojemność 1Gb/s. Wszystkie łącza wprowadzają jednokierunkowe opóźnienie propagacji o wartości 10ms, co skutkuje jednakowym czasem RTT (60ms) dla wszystkich przepływów. 4.4.4 Oscylacje połączeń TCP Floyd i Kohler [36] wskazują na problem oscylacji występujących w przypadku przepływów o długim czasie życia. W szczególności problem ten występuje w przypadku transmisji w tle na ścieżce powrotnej, w wyniku

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 55 Ruter A Ruter B Ruter C Ruter D Rysunek 4.2: Topologia parkingowa. której następuje opóźnienie i gromadzenie pakietów potwierdzeń. Skutkuje to nie tylko spadkiem prędkości transmisji obserwowanych połączeń, ale również możliwych do zaobserwowania oscylacji długości kolejki w badanym ruterze. Przekłada się to na zwiększone odchylenie standardowe długości kolejki. W celu zbadania mechanizmów AQM pod kątem wpływu na opisywane zachowanie, konieczne jest stworzenie nowego scenariusza testowego. Wykorzystuje on topologię opisaną w sekcji 4.1, ale liczba przepływów nie jest już zdefiniowana zgodnie z zasadami przedstawionymi w sekcji 4.2. Zamiast wprowadzać cztery stałe wartości odpowiadające N t, należy stopniowo zwiększać liczbę przepływów począwszy od wartości r b na poziomie 2Mb/s aż do r b na poziomie 50kb/s, ze skokiem co 50 przepływów. Wszystkie przepływy to przepływy TCP wykorzystujące 1500-bajtowe pakiety (FTP). Symulacje powinny skupić się na wyznaczeniu odchylenia standardowego długości kolejki. W wyniku otrzymana zostanie krzywa opisująca odchylenie standardowe długości kolejki w zależności od liczby przepływów. W przypadku większości obecnych mechanizmów AQM obserwuje się trzy wyróżniające się fazy zachowań, odpowiadające trzem poziomom przeciążenia sieci. Faza łagodnego przeciążenia (lub jego braku) kończy się wyraźnym, skokowym wzrostem wariancji obserwowanej długości kolejki. Następnie występuje obniżenie wartości wraz z przejściem systemu do stanu dużego przeciążenia. Opisywany scenariusz znajduje również zastosowanie w przypadku

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 56 testowania zdolności samo-konfigurujących, adaptatywnych mechanizmów AQM do automatycznego dostosowania się do zmiennych warunków pracy. 4.5 Przykładowe wyniki Niniejsza sekcja prezentuje przykładowe wyniki porównania 4 mechanizmów AQM w oparciu o zaproponowane testy wzorcowe. Wyniki pochodzą ze środowiska testowego implementującego opisane testy za pomocą symulatora zdarzeń dyskretnych ns-2. Do celów demonstracyjnych wybrany został jeden scenariusz, Access Link. Zgodnie z regułami przedstawionymi w sekcji 4.2, liczba przepływów wynosi odpowiednio: dla systemu nieprzeciążonego N t = 10, w przypadku lekkiego przeciążenia N t = 100, w przypadku średniego przeciążenia N t = 200, w przypadku dużego przeciążenia N t = 1000. Porównanie obejmuje cztery popularne algorytmy AQM: ARED, AVQ, PI oraz REM. Algorytmy PI oraz AVQ zostały sparametryzowane tak, by docelowa długość kolejki wynosiła 100 pakietów. Wartość min th oraz max th dla algorytmu ARED zostały ustawione odpowiednio na 50 i 150 pakietów. Otrzymane wartości podstawowych metryk opisanych w sekcji 4.3 zostały zaprezentowane w tabeli 4.1. Dodatkowo zbadano współczynnik sprawiedliwości podziału pasma pomiędzy przepływy danych dla zachłannych przepływów TCP typu FTP. Został on obliczony w 1-sekundowym oknie przy wykorzystaniu indeksu Jain a. Wyniki pogrupowane zostały w oparciu o liczbę przepływów wykorzystanych w danej symulacji. Wyniki zostały zaprezentowane na rysunkach 4.3 4.6. Można zaobserwować, że algorytm AVQ oferuje najwyższy poziom sprawiedliwości w przypadku średniego przeciążenia, ale zupełnie nie radzi sobie w przypadku wyższych przeciążeń. Stopień przeciążenia sieci wydaje się mieć znikomy wpływ na pozostałe algorytmy, a w szczególności na algorytm ARED.

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 57 Algorytm ARED AVQ PI REM Liczba przepływów Zagregowana przepływność (Mb/s) Średnia długość kolejki (pakiety) Odchylenie standardowe długości kolejki Poziom strat (%) 10 91.52 28.8 43.1 0.03 100 99.6 74.7 32.54 1.51 200 99.82 97.9 30.6 3.84 1000 99.81 166.8 43.7 15.33 10 60.21 86 76 0.76 100 81.16 111 34 3.91 200 80.63 117 20.5 6.4 1000 80.87 108 29.75 7.15 10 86.37 12.5 26.5 0.03 100 99.98 92.2 38.7 1.4 200 99.96 102.3 33.6 3.83 1000 99.95 173.9 82.8 15.39 10 95.86 69.3 49.8 0.02 100 99.85 160 43.6 1.37 200 99.95 149 37.1 4.02 1000 99.78 160 49.2 16.12 Tabela 4.1: Porównanie podstawowych metryk wydajnościowych dla różnych mechanizmów AQM 0.8 0.7 Sprawiedliwość (indeks Jain'a) 0.6 0.5 0.4 0.3 0.2 20 40 60 80 100 120 140 Czas [s] Rysunek 4.3: Sprawiedliwość podziału pasma pomiędzy zachłanne przepływy FTP. Scenariusz obejmuje 100 równoległych przepływów.

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 58 0.8 0.7 Sprawiedliwość (indeks J ain'a) 0.6 0.5 0.4 0.3 0.2 20 40 60 80 100 120 140 Czas [s] Rysunek 4.4: Sprawiedliwość podziału pasma pomiędzy zachłanne przepływy FTP. Scenariusz obejmuje 200 równoległych przepływów. 0.6 Sprawiedliwość (indeks Jain'a) 0.5 0.4 0.3 0.2 20 40 60 80 100 120 140 Czas [s] Rysunek 4.5: Sprawiedliwość podziału pasma pomiędzy zachłanne przepływy FTP. Scenariusz obejmuje 400 równoległych przepływów danych.

ROZDZIAŁ 4. TESTY WZORCOWE ALGORYTMÓW AQM 59 0.5 Sprawiedliwość (indeks Jain'a) 0.4 0.3 0.2 0.1 20 40 60 80 100 120 140 Czas [s] Rysunek 4.6: Sprawiedliwość podziału pasma pomiędzy zachłanne przepływy FTP. Scenariusz obejmuje 800 równoległych przepływów.

Rozdział 5 Środowisko do symulacji równoległych Symulator zdarzeń dyskretnych Network Simulator 2 (ns-2) [82] jest najpopularniejszym symulatorem zdarzeń dyskretnych wykorzystywanym do zastosowań naukowych w dziedzinie sieci komputerowych. Oprogramowanie to, oprócz wbudowanego wsparcia dla wielu popularnych technologii i protokołów sieciowych, cechuje się ogromną łatwością w implementacji rozszerzeń. Scenariusze symulacyjne ns-2 wykorzystują język programowania Tcl, który jest otwartym językiem ogólnego przeznaczenia. Oprogramowanie ns-2 jest rozszerzonym interpreterem języka ns-2 oraz tworzy środowisko uruchomieniowe dla programów napisanych w tym języku. W ramach środowiska zapewnione są nowe klasy, obiekty oraz metody dedykowane do tworzenia scenariuszy symulacyjnych. Symulator ns-2, poza rozszerzeniem języka Tcl o elementy modelu sieci, rozszerza go również poprzez wprowadzenie paradygmatu oprogramowania zorientowanego obiektowo (ang. OOP - Object Oriented Programming). Jak pokazano w rozdziale 3, ocena działania sieci z wykorzystaniem modeli matematycznych pozwala na uzyskanie przybliżeń rzeczywistości poprzez rozwiązywanie złożonych równań analitycznych. Niestety, trudno jest stworzyć model matematyczny uwzględniający pełną złożoność rzeczywistego środowiska, nie wspominając o tym, że model taki będzie zwykle zbyt trudny do rozwiązania analitycznego. Z tego powodu narzędzia symulacyjne rozszerzają bądź zastępują podejście analityczne, zwłaszcza w przypadku uwzględniania dużej liczby elementów w złożonych środowiskach. Niestety, tworzenie modeli symulacyjnych również ma swoje wady. 60

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 61 W szczególności, w przeciwieństwie do modelu analitycznego, pojedyncze uruchomienie symulacji nie pozwala na uzyskanie pełnego opisu systemu. Próba wykrycia przy użyciu symulatora zjawisk rzadko występujących bądź też nietypowych wymaga wielokrotnego uruchamiania symulacji z różnymi wartościami parametrów. Poza potrzebą przeprowadzenia symulacji wielu różnych scenariuszy, wykorzystanie generatorów pseudolosowych często rodzi konieczność wielokrotnego uruchamiania pojedynczego scenariusza dla różnych wartości startowych generatorów pseudolosowych. Wiarygodna ocena systemu przy użyciu symulatora wymaga niekiedy dziesiątek bądź wręcz setek uruchomień. Jak pokazujemy w tym rozdziale, czas potrzebny na uzyskanie wyników można skrócić poprzez równoległe wykonywanie pojedynczych zadań wchodzących w skład zestawu uruchomieniowego. Współczesne klastry, superkomputery, czy też inne duże systemy obliczeniowe typu rozproszonego, takie jak systemy przetwarzania sieciowego (ang. grid computing), pozwalają na połączenie setek czy wręcz tysięcy różnorodnych zasobów w celu stworzenia środowiska obliczeniowego służącego do rozwiązania złożonych, wymagających czasowo problemów. Dlatego właśnie systemy tego typu stają się coraz popularniejsze w środowisku naukowym. Niestety, stworzenie aplikacji działającej w środowiskach tego typu wymaga od twórcy oprogramowania dużej wiedzy specjalistycznej, związanej ze specyficznym sposobem organizacji kodu, obsługi wyjątków, równoważenia obciążenia czy też wykorzystania zmieniających się w czasie zasobów obliczeniowych. Niejednokrotnie utworzenie takiej aplikacji wymaga od autora poświęcenia większej ilości czasu niż samo zdefiniowanie problemu. Dodatkowym problemem związanym z tworzeniem kodu symulacyjnego przystosowanego do uruchamiania w środowiskach równoległego przetwarzania sieciowego jest sekwencyjny charakter symulacji. W przypadku równoległego wykonania symulacji samo środowisko symulatora musi być zaprojektowane i zaprogramowane z myślą o platformach wieloprocesorowych czy też wielordzeniowych. Prawidłowo utworzony program opisujący model symulacyjny powinien umożliwić wykorzystanie wszystkich zasobów sprzętowych. Co więcej, twórca oprogramowania musi zapewnić prawidłowe zarządzanie zasobami współdzielonymi (takimi jak systemy plików, czy też pamięć operacyjna i tymczasowa, ang. swap space). Nieprawidłowa implementacja w tym zakresie może prowadzić w najlepszym razie do widocznych błędów symulacji, a w najgorszym do uzyskania błędnych wyników, pomimo prawidłowego modelu.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 62 Konieczne jest zapewnienie prawidłowego przepływu danych pomiędzy procesorami, przypisywania (ang. pinning) zadań do konkretnych jednostek obliczeniowych [81] oraz wydajnego i bezpiecznego procesu rejestrowania danych wyjściowych. 5.1 Istniejące rozwiązania Istniejące rozwiązania problemu można podzielić na dwie grupy: systemy wykorzystujące spójny obraz systemu (ang. SSI) - Single System Image oraz modyfikacje symulatora ns-2. Rozwiązania znajdujące się w pierwszej grupie stanowią punkt wyjściowy dla opracowania nowego środowiska symulacyjnego bazującego na ns-2. Warto również wspomnieć o rozwijanym następcy symulatora ns-2, symulatorze Network Simulator 3 (ns-3). Posiada on wbudowane wsparcie dla rozpraszania obliczeń w oparciu o mechanizm MPI. Wymaga on co prawda specyficznego podejścia do tworzenia kodu symulacyjnego, jednak fakt wprowadzenia tego mechanizmu w postaci jednej z podstawowych funkcji symulatora jest godny uwagi. W tej pracy zdecydowano się jednak na wykorzystanie symulatora ns-2 z uwagi na to, że obecna wersja symulatora ns-3 nie oferuje jeszcze oczekiwanego poziomu wiarygodności wyników oraz nie posiada pełnego wsparcia dla modelowania mechanizmów AQM. 5.1.1 Środowiska typu SSI Spójny obraz systemu (zwany dalej SSI) to mechanizm programowy zapewniający wrażenie korzystania z jednego systemu operacyjnego, który uruchomiony jest na grupie komputerów tworzących klaster lub system przetwarzania sieciowego. Istnieje kilka rozwiązań typu SSI, np. MOSIX, OpenSSI, Kerrighed, LinuxPMI, IBM z/vm oraz HP NonStop. Ich implementacja w postaci rozszerzeń systemu operacyjnego (poza HP NonStop) czyni z nich narzędzia mogące służyć do celu podziału zadań pomiędzy rozproszone zasoby obliczeniowe. Jak wcześniej wspomniano, system HP NonStop znacząco odbiega od pozostałych pod względem architektury. Dodatkowo, HP NonStop wraz z IBM z/vm działa na niższym poziomie i zapewnia rozpraszanie całych, wirtualnych instancji systemów operacyjnych. Rozwiązania OpenSSI, Kerrighed oraz LinuxPMI nie są już aktywnie rozwijane i jako takie nie współpracują ze współczesnymi dystrybucjami systemu operacyjnego Linux. Z tego powodu w niniejszej sekcji szerzej przedstawione zostanie system MOSIX.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 63 Poza systemami SSI, niniejszy przegląd prezentuje również dwa istniejące rozwiązania programowe typu middleware, pozwalające na stworzenie zestawu oraz jednoczesne, równoległe uruchomienie grupy symulacji sieciowych. MOSIX MOSIX, stanowiący rozwiązanie najdłużej istniejące na rynku spośród prezentowanych, został zaprojektowany i zaimplementowany na Uniwersytecie Hebrajskim w Jerozolimie w 1997 roku [55]. Jest to system zarządzania klastrem typu SSI, pracującym w oparciu o maszyny działające pod kontrolą systemu operacyjnego Linux. Najnowsze wersje systemu (MOSIX-3x) są kompatybilne z jądrami systemu w wersji 3.10. MOSIX stanowi warstwę programową niskiego poziomu, która dla uruchamianych aplikacji widoczna jest jako zwykły, niemodyfikowany system operacyjny. System ten umożliwia automatyczne wykrywanie zasobów w sieci. Wymagania co do komputerów stanowiących potencjalne węzły klastra nie są surowe: możliwe jest połączenie maszyn o różnej liczbie procesorów (rdzeni) o różnej prędkości, rozmiarze pamięci oraz zestawie urządzeń wejścia/wyjścia. Jego podstawową zaletą jest brak konieczności wykonywania jakichkolwiek modyfikacji w kodzie aplikacji w celu przenoszenia, startowania, czy też przypisywania im zasobów pochodzących z różnych węzłów. MOSIX w sposób przezroczysty migruje pojedyncze procesy (ale nie wątki) pomiędzy dostępnymi zasobami obliczeniowymi. Możliwe jest uruchomienie zarówno aplikacji wsadowych jak i aplikacji wymagających interakcji z użytkownikiem. Liczba zadań, które mogą być jednocześnie uruchomione w ramach systemu ograniczona jest wyłącznie przez standardowe mechanizmy jądra Linux i wynosi około 30000 procesów dla wszystkich użytkowników, co nie stanowi realnego ograniczenia. System MOSIX jest narzędziem komercyjnym, wymagającym wykupienia licencji. Dodatkowo ma on pewne ograniczenia, np. rozpraszane aplikacje powinny być jednowątkowe, co może dyskredytować część implementacji symulatora zdarzeń dyskretnych. Zaletą systemu MOSIX jest to, że nie tylko zasoby obliczeniowe są spójne pomiędzy maszynami wewnątrz klastra: również część zasobów dyskowych stanowi wspólny, ogólnodostępny zasób klastra. Ułatwia to zarządzanie zarówno kodem rozpraszanych aplikacji jak również znacząco upraszcza proces zbierania wyników. Niestety, bez zastosowania dodatkowej warstwy oprogramowania, to programista musi pamiętać o odpowiednim nazewnictwie plików w celu zmniejszenia prawdo-

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 64 podobieństwa ich nadpisania. W praktyce MOSIX w omawianym zastosowaniu (uruchomienie dużej liczby równoczesnych sesji tego samego programu, ale z różnymi zestawami parametrów wejściowych) zwalnia użytkownika wyłącznie z tworzenia narzędzia wywołującego aplikacje na zdalnych komputerach, nadal jednak na użytkowniku spoczywa oprogramowanie metod pozwalających na wzajemną separację oraz izolację uruchomionych zadań. 5.1.2 Oprogramowanie typu middleware W celu stworzenia spójnego, wydajnego środowiska implementującego zestaw testów wzorcowych opisanych w rozdziale 4 rozpatrywano możliwości wykorzystania już istniejących rozwiązań tego typu. Jedną z rozpatrywanych możliwości było środowisko GRIA IST [87]. Niestety rozwiązanie to wymaga zastosowania lokalnego zarządcy zadań oraz pełnej warstwy pośredniczącej (np. implementowanej przez MOSIX). Innym rozpatrywanym rozwiązaniem było środowisko BOINC [1], służące do prowadzenia obliczeń rozproszonych przy użyciu dobrowolnie udostępnionych zasobów. Środowisko to wykorzystywane jest w wielu popularnych projektach, np. w projekcie Seti@Home. Niestety, w przypadku zastosowania tej warstwy pośredniczącej, konieczne byłoby napisanie symulacji w postaci niezależnej aplikacji, bez możliwości wykorzystania symulatora zdarzeń dyskretnych. Pomimo braku odpowiedniego, gotowego oprogramowania typu middleware, wydaje się że podejście reprezentowane przez tę grupę rozwiązań jest najodpowiedniejsze do zastosowania w przypadku poszukiwanego rozwiązania. 5.1.3 PDNS - Parallel/Distributed NS Jak dotąd powstało kilka prób modyfikacji kodu źródłowego środowiska ns-2 mających na celu umożliwienie wykorzystania wielu rdzeni/procesorów w trakcie pojedynczej symulacji. Podobnie, istnieje kilka rozwinięć mających na celu przeniesienie symulatora ns-2 na rozproszone środowiska obliczeniowe. Jedynym takim rozwiązaniem, które zostało szeroko zaakceptowane wśród badaczy, jest rozwiązanie stworzone przez zespół pracujący na uniwersytecie w Georgii [84]. Utworzone przez nich środowisko Parallel/Distributed NS pozwala na równoległą symulację różnych segmentów sieci przy użyciu zasobów rozproszonych pomiędzy różne dostępne procesory lub rdzenie. Rozwiązanie to korzysta ze zmienionego mechanizmu szeregowania

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 65 Modu wczytywania scenariuszy (ns/tcl) Instancja symulatora Ns-2 Zarz dca procesu symulacji Repozytorium plików topologii i scenariuszy Skrypty przetwarzania ko cowego System zarz dzania baz danych Rysunek 5.1: Architektura systemu LGS4Ns2. zadań symulatora, który wykorzystuje konserwatywny, blokujący algorytm synchronizacji, zapobiegający cofnięciom czasu symulacji. Implementacja tego typu możliwa jest dzięki faktowi, że mechanizm szeregujący w ns-2 jest postaci wymienialnego obiektu dziedziczącego po abstrakcyjnej klasie bazowej. Największą wadą środowiska PDNS jest to, że nie jest już ono aktywnie rozwijane. Nowe wersje ns-2 wprowadziły wiele ulepszeń i poprawek w stosunku do wcześniejszego kodu. Niestety PDNS nie zapewnia kompatybilności z nowymi wersjami. 5.2 Architektura nowego systemu Wykorzystanie mechanizmów proponowanych w poprzednich sekcjach wiązało się z koniecznością każdorazowej implementacji części aplikacji symulatora bądź też wymagało stworzenia nowego środowiska symulacyjnego od zera. Tymczasem, jak wspomniano na początku rozdziału, celem było wykorzystanie symulatora ns-2 rozszerzając go o moduł zarządzania zasobami oraz system rozpraszania zadań pomiędzy zasoby obliczeniowe. Dlatego został zaproponowany nowy system. Architektura proponowanego systemu o nazwie LGS4Ns2 została zaprezentowana na rysunku 5.1. System składa się z trzech warstw odpowiedzialnych za uruchamianie pojedynczych symulacji, komunikację sieciową oraz zarządzanie wieloma symulacjami. Zdecydowano się na implementację systemu w architekturze klient-serwer. Całość pojedynczej symulacji im-

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 66 plementowana jest po stronie serwera, a warstwa zarządzania symulacjami stanowi klienta żądającego uruchomienie kolejnych instancji symulatora. Typowo skutkuje to powstaniem konfiguracji z jednym klientem i wieloma serwerami. Możliwe jest również uruchomienie całego systemu na pojedynczej maszynie obliczeniowej, zamiast kilku połączonych siecią. Pozwala to w pełni wykorzystać zasoby obliczeniowe pojedynczego komputera. 5.2.1 Serwer systemu symulacji Każda instancja serwera symulacyjnego składa się z dwóch części: implementacji symulatora zdarzeń dyskretnych ns-2 oraz zestawu plików symulacji. Standardowa biblioteka skryptów Tcl środowiska ns-2 została rozszerzona w celu uproszczenia procesu tworzenia, konfiguracji i uruchomienia równoległych symulacji. Zasady, w oparciu o które przystąpiono do zadania, zostały opisane w kolejnej części rozdziału. Podejście programistyczne Ns-2 natywnie nie wspiera wykorzystanie architektury wielowątkowej oprogramowania. Oczywiście, można pokusić się o tworzenie własnych modułów ns-2 wykorzystując takie podejście (pozwala na to język programowania), ale inne, oryginalne części symulatora nie będą z tego podejścia korzystać. Dodatkowo natura symulatora zdarzeń dyskretnych powodowałaby, że przyspieszenie możliwe do osiągnięcia w wyżej opisany sposób nie byłoby znaczące w stosunku do całości symulacji (pomijając jednostkowe i bardzo specyficzne sytuacje). Z drugiej strony, typowe podejście do badań symulacyjnych polega na wielokrotnym wykonywaniu tego samego kodu symulacji przy jednoczesnej zmianie parametrów wejściowych opisujących scenariusze, takich jak liczba przepływów, poziom błędów transmisji, parametry pracy algorytmów zarządzania kolejkami, itd. Dodatkowo wiele przebiegów symulacji pracuje w oparciu o te same scenariusze, jednak zmieniane są wartości początkowe generatorów liczb pseudolosowych, w celu uzyskania większego poziomu ufności wyników. Osobne symulacje oparte na tym samym pliku skryptowym opisującym środowisko mogą z powodzeniem być uruchamiane równolegle, nawet na pojedynczej maszynie, ale trzeba zapewnić ich izolację. Osiąga się to poprzez zapewnienie poniższych wymagań: W1: Symulacje różnią się od siebie w sposób nie wymagający zmiany skryptów uruchomieniowych czy też rekompilowania aplikacji symulatora.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 67 W2: Każda instancja symulacji wykorzystuje własne pliki przebiegu symulacji (ang. trace files) oraz osobną przestrzeń dla plików tymczasowych. W3: Podsumowanie wszystkich symulacji wykonywane jest po zakończeniu całości procesu (w oparciu o pliki przebiegu symulacji). Konieczne jest zapewnienie braku wyścigu przy zapisie plików wyjściowych. Pierwsze wymaganie jest prawdopodobnie najważniejsze, jako że konieczność ciągłej zmiany skryptów symulacji, czy też aplikacji symulatora, utrudniłaby znacząco zarządzanie kolejnymi symulacjami i należałoby zabezpieczyć się przed ryzykiem powstawania wyścigów. Na szczęście wymaganie W1 jest łatwe do spełnienia: środowisko symulacyjne (skrypty i aplikacja) powinny mieć stałą postać, pozwalającą na definiowanie wartości parametrów przy użyciu mechanizmów takich jak parametry wykonania aplikacji czy też zmienne środowiskowe. W języku Tcl dostępnych jest kilka gotowych do użytków modułów przetwarzania złożonych zestawów parametrów uruchomieniowych. Istnieje wiele sposobów zapewnienia rozdzielności wyjść symulacji. Wykorzystano dwie z tych metod: poprzez zapewnienie unikalności nazw plików oraz rozdzielność drzew katalogów. Nazwy plików wyjściowych generowanych bezpośrednio przez symulator ns-2 lub też jawnie utworzonych przez skrypty Tcl pochodzą od wartości parametrów konfiguracyjnych przekazanych do aplikacji. Podejście takie świetnie nadaje się do wykorzystania w przypadku prostych symulacji, w których zmieniany jest jeden parametr. Na przykład, można w ten sposób uruchomić serię symulacji algorytmu AQM ustalając kolejne wartości docelowej długości kolejki. Podejście polegające na wiązaniu nazw plików z wartościami parametrów konfiguracyjnych staje się niewystarczające w przypadku dużych symulacji, w których zmienianych jest wiele parametrów na raz, skutkuje bowiem powstaniem bardzo długich i niezrozumiałych nazw. Dlatego w przypadku prezentowanego środowiska wartości części parametrów konfiguracyjnych wykorzystywane są do utworzenia nazw katalogów tworzących drzewo hierarchiczne, a pozostałe (np. wartości startowe generatorów pseudolosowych) wykorzystane są podczas tworzenia nazw plików. To użytkownik decyduje, w jaki sposób zostanie utworzone drzewo katalogów. Dzięki temu ma on możliwość skonfigurowania hierarchii dla niego najwygodniejszej i spójnej dla wszystkich uruchomień symulacji. Podsumowanie zbiorcze dla grupy wyników może być generowane w dwóch trybach: po zakończeniu wszystkich symulacji bądź też przy

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 68 wykorzystaniu dodatkowego mechanizmu pracującego w tle, którego zadanie polega na zbieraniu wyników w trakcie wykonywania. Pierwsze podejście wiąże się z koniecznością stworzenia dodatkowego programu (skryptu), który po zakończeniu symulacji dokonuje przejścia wszystkie pliki tymczasowe w celu przefiltrowania i agregacji wyników w formie pojedynczego pliku podsumowującego. Drugie podejście nie wymaga stosowania dedykowanego mechanizmu filtrującego - podsumowanie uaktualniane jest po zakończeniu każdej pojedynczej symulacji, przy wykorzystaniu jednego współdzielonego pliku wynikowego. Niestety, w związku z tym, że różne symulacje mogą zakończyć się równocześnie, konieczne jest zabezpieczenie się przed uszkodzeniem lub sfałszowaniem wyników z powodu równoczesnej próby zapisu do współdzielonego zasobu. Dodatkowy problem stanowi niepełność przetwarzanych danych, znacząco utrudniająca obsługę błędów. Opisywane środowisko symulacyjne wykorzystuje oba opisane sposoby zapisu danych wyjściowych: pojedynczy przebieg symulacji uruchomiony na jednym procesorze, poza zapisaniem w pliku przebiegu symulacji, po jej skończeniu dokonuje filtracji oraz agregacji jak największej liczby parametrów. Dane te zapisywane są w pliku podsumowania specyficznego dla pojedynczego przebiegu. Po zakończeniu wszystkich symulacji uruchamiany jest proces zewnętrzny, który przegląda przez wszystkie podsumowania pojedynczych przebiegów i na ich podstawie tworzy raport końcowy. Podejście takie pozwala na wykorzystanie stabilnego rozwiązania, w którym część przetwarzania jest ściśle związana ze scenariuszem symulacji a końcowe podsumowanie generowane jest bez potrzeby przetwarzania surowych danych przejściowych. Dzięki specyfikacji interfejsu przejściowego, służącego do wymiany danych przejściowych, generator podsumowania końcowego ma postać niezależną od części związanej z przetwarzaniem scenariusza. 5.2.2 Uniwersalny parser topologii i aplikacji Dzięki implementacji wymagań opisanych w poprzedniej sekcji, środowisko ns-2 zostało rozszerzone o zestaw skryptów języka Tcl znoszących konieczność tworzenia dedykowanego skryptu dla każdej symulacji. W odróżnieniu od oryginalnego środowiska ns-2, opisywane środowisko symulacyjne dynamicznie tworzy skrypty symulacyjne w oparciu o definicje topologii sieci oraz scenariusza aplikacji znajdujących się w zewnętrznych plikach konfiguracyjnych o prostej strukturze. Interpretacja każdego z tych plików może być dodatkowo modyfikowana poprzez zmianę wartości domyślnych parametrów poprzez użycie parametrów linii poleceń.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 69 1 2 2 2 0 R1 100Mb 2ms DropTail """ 3 1 R2 100 Mb 2ms DropTail "" error" 4 R1 R2 10Mb 40ms RED 0 " thresh_ 50" Listing 5.1: Przykładowy plik opisu topologii. Cyfry z lewej strony oznaczają numery wierszy i nie są częścia pliku. 1 1 0 0 0 2 1 cbr1 0 UDP T r a f f i c /CBR 25 125 "packetsize_ 1500" p a c k e t S i z e 1500 r a t e 20Mb" 3 1 cbr1 1 LossMonitor Listing 5.2: Przykładowy plik opisu scenariusza. Liczby z lewej strony oznaczają numery wierszy i nie są częścią pliku. W proponowanym rozwiązaniu przebieg każdej symulacji rozpoczyna się od wczytania pliku opisu topologii oraz pliku opisu scenariusza, opcjonalnej modyfikacji wybranych parametrów wejściowych na podstawie danych z linii komend, uruchomienia specyfikacji oraz końcowego przetwarzania danych wyjściowych w celu wygenerowania podsumowania. Proponowane środowisko nie jest powiązane z konkretną wersją symulatora ns-2, o ile zachowana zostanie kompatybilność wersji języka Tcl. Odróżnia to proponowane rozwiązanie od systemów takich jak opisywany wcześniej PDNS, który wymaga stworzenia osobnej wersji dla każdej wersji ns-2. Twórcy środowiska ns-2 bardzo rzadko decydują się na przejście na nowe wersje języka Tcl, co sprawia, że opisywane środowisko symulacyjne jest stabilne nawet w przypadku częstych zmian symulatora ns-2. Przykładowa zawartość pliku opisu topologii została zaprezentowana na listingu 5.1. Zaprezentowana topologia zbudowana jest z dwóch węzłów i dwóch ruterów. Węzły połączone są łączami o przepustowości 100Mb/s i czasie propagacji 2ms z ruterami, każdy do jednego z nich (linie 2, 3). Rutery połączone są łączem o pojemości 40Mbs/s i czasie propagacji wynoszącym 40ms. W ruterach zainstalowany jest mechanizm aktywnego zarządzania kolejkami RED (linia 4). Jak pokazano w liniach 3 oraz 4, możliwe jest wprowadzanie dodatkowych elementów opisu łączy. W przypadku łącza N1-R2 dodano model błędów, a w przypadku łącza R1-R2 sparametryzowano algorytm RED. Opisywane środowisko symulacyjne pozwala również na tworzenie w pełni funkcjonalnych topologii bezprzewodowych

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 70 oraz mieszanych, dzięki czemu świetnie nadaje się do opisu sieci różnych typów. W typowym zastosowaniu środowisk symulacyjnych wykorzystuje się niewielką liczbę topologii (zob. rozdział 4), ale za to dużą liczbę scenariuszy ruchu wykorzystujących te topologie. Klasyczne podejście do tworzenia opisów scenariuszy w ns-2 wymaga od autora tworzenia osobnych skryptów uruchomieniowych dla każdego z nich. Środowisko opisywane w niniejszym rozdziale rozdziela opisy topologii i scenariuszy od właściwych skryptów symulacyjnych. Aby to osiągnąć, poza modułem wczytującym opisy topologii dodano również moduł wczytywania opisów scenariuszy przepływów. Przykładowy opis scenariusza został zaprezentowany na listingu 5.2. Możliwości modułu wczytywania scenariuszy zbliżone są do modułu wczytywania topologii: poza podstawową konfiguracją możliwe jest dodanie parametrów nietypowych oraz ich późniejsza modyfikacja poprzez parametry linii poleceń. Uniwersalny skrypt uruchomieniowy środowiska wczytuje zawartość obu plików (topologii i scenariusza), na ich podstawie uruchamia symulację, zbiera wyniki oraz dokonuje ich końcowej interpretacji. Przetwarzanie końcowe można sparametryzować w celu wybrania wymaganych parametrów wyjściowych. Dostępne jest wiele standardowych parametrów, takich jak uzyskiwany poziom wykorzystania przepustowości łącza, przepływności uzyskiwane przez pojedyncze przepływy czy też poziomy strat pakietów wraz ze statystykami kolejek na ruterach. W szczególności dostępne są wszystkie parametry wyjściowe opisane w rozdziale 4. Dodatkowo, dla większości zbieranych statystyk skrypt generuje bezpośrednie dane do tworzenia wykresów (przy użyciu programu gnuplot). 5.2.3 Szeregowanie zadań środowiska ns-2 W sekcji 5.1 zaprezentowano przegląd istniejących rozwiązań, które można wykorzystać do rozwiązania problemu zarządzania rozproszonymi zasobami obliczeniowymi w celu przeprowadzenia równoległych symulacji środowiska sieciowego. Niestety, żadne z rozwiązań nie nadawało się w pełni do wykorzystania. Oczywiście zastosowanie klastra typu SSI może w dużym stopniu pomóc w kwestii równoważenia obciążenia systemu, jednak jego instalacja jest dosyć złożona i nie daje on możliwości rozwiązania problemów na poziomie opisywanym w poprzedniej sekcji. Z drugiej strony, prezentowane zewnętrzne rozwiązania typu middleware nie sprawdzają się w specyficznym symulacji sieciowych z wykorzystaniem środowiska ns-2.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 71 Z tego powodu zdecydowano się na utworzenie własnego rozwiązania klasy middleware, czerpiąc zarówno z pomysłów zastosowanych w rozwiązaniu MOSIX i innych. Powstałe rozwiązanie, pozwala na zarządzanie kolejkami zadań, szeregowanie zadań oraz uruchamianie ich zarówno zdalnych, rozproszonych maszynach obliczeniowych jak i lokalnie przy wsparciu wielordzeniowych czy też wieloprocesorowych maszyn. Zachowana jest również kompatybilność z rozwiązaniami typu SSI. LGS4Ns2 zaprojektowane zostało z myślą o wygodzie użytkownika, dlatego poza interfejsem tekstowym wyposażone zostało w graficzny interfejs użytkownika dostępny w postaci aplikacji WWW. Instalacja środowiska nie wymaga rekompilacji jądra systemu oraz nie wprowadza konieczności rekonfiguracji systemu na poziomie konta administratora. Co więcej, nie jest nawet wymagana praca w oparciu o jeden system operacyjny, choć konfiguracja pozwalająca na korzystanie różnych systemów operacyjnych wymaga większego nakładu pracy niż w przypadku zachowania spójnego środowiska, złożonego z maszyn pracujących pod kontrolą systemu operacyjnego Linux. LGS4Ns2 może być również zastosowane do rozpraszania obliczeń innych aplikacji, które nie oferują natywnego wsparcia w tym zakresie. Przykładowo, system prezentowany w niniejszym rozdziale został też wykorzystany w pracach opisanych w [38] oraz [64]. System LGS4Ns2 stworzono w oparciu o standardowe narzędzia programowe o otwartych licencjach. Główna część, odpowiedzialna za dodawanie, kolejkowanie i szeregowanie i zdalne wykonywanie zadań składa się z pojedynczego programu napisanego w języku Python. Skrypt ten wykorzystuje dedykowaną bazę danych opartą na jednym z dwóch systemów zarządzania bazami danych: MySQL lub PostgreSQL. Zastosowanie podejścia modułowego pozwala na łatwe dodanie wsparcia dla innego systemu zarządania bazami danych. W stosunku do systemu, na którym uruchomiony będzie system zarządzający, wymagana jest dodatkowo dostępność klienta SSH. Graficzny interfejs użytkownika stanowi osobny, opcjonalny moduł rozszerzeń i można zainstalować go na zewnętrznym serwerze. Moduł GUI wykorzystuje zestaw skryptów języka PHP. Pozwalają one na konfigurację systemu, zarządzanie kolejką zadań oraz monitorowanie stanu ich wykonania. Wyłącznym wymaganiem co do maszyn wykorzystywanych jako węzły obliczeniowe jest działająca instalacja serwera SSH z włączonym modułem bezpiecznej transmisji plików (SFTP). Dodatkowo wspierane są mechanizmy takie jak spójny system plików (wspierane są rozwiązania oparte o NFS oraz CIFS) oraz limity środowiska wykonania systemu

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 72 operacyjnego Linux. Wsparcie dla obu mechanizmów nie jest wymagane, ale zastosowanie spójnego systemu plików, zwłaszcza w formie rozwiązania NFS, pozwala znacząco zredukować czasy potrzebne na przygotowanie symulacji i agregacji danych. Wsparcie dla limitów środowiska pozwala na uniknięcie kłopotów wynikających z niedostatecznej liczby zasobów na maszynach obliczeniowych. Główny moduł LGS4Ns2 odpowiada za: Przygotowanie środowiska binarne kopie symulatora ns-2, skrypty oraz pliki wejściowe rozsyłane są pomiędzy maszynami obliczeniowymi. Szeregowanie zadań i ich zdalne uruchamianie w zależności od dostępności zasobów i priorytetów zadań. Zebranie wyników częściowych i zgromadzenie ich na jednej maszynie. Uruchomienie procesu końcowego przetwarzania wyników. Statyczna lista zdalnych maszyn obliczeniowych definiowana jest w pliku konfiguracyjnym zarządcy środowiska. W pliku tym określa się również maksymalną liczbę zadań możliwych do uruchomienia na każdej z maszyn. Informacja ta jest traktowana wyłącznie jako górne ograniczenie - system automatycznie dostosuje się do lokalnego przeciążenia jednej z maszyn i ograniczy liczbę wykonywanych na niej zadań. Zwolnienie zasobów spowoduje uruchomienie nowego zadania z kolejki i zablokowanie zasobów aż do jego zakończenia. W przypadku błędu wynikającego z braku wolnych zasobów zadanie wraca do kolejki i w późniejszym czasie zostaje podjęta próba jego ponownego uruchomienia na innej maszynie. Typowa konfiguracja systemu ogranicza maksymalną liczbę równoległych zadań na zdalnym komputerze do liczby dostępnych rdzeni procesora. System zarządzający przyjmuje listę zadań do wykonania, która identyfikowana jest w postaci grupy zadań. Po zakończeniu wykonania wszystkich zadań w grupie, uruchamiany jest specjalny proces mający na celu wygenerowanie wyników końcowych. Zapisywane są one we wcześniej zdefiniowanym katalogu końcowym. Dodatkowo wszystkie wyniki (pośrednie oraz końcowe) zapisywane są w bazie danych, dzięki czemu możliwe jest ich szybkie przetworzenie, na przykład przy wykorzystaniu środowiska Matlab.

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 73 Opisywany parametr CPU Węzeł główny 4x Intel Xeon 3.2GHz HT System operacyjny Linux kernel 2.6.22-14 Karta sieciowa Dyski twarde Węzły robocze 2x Intel Core 2 6600 RAM 6GB 2GB DDR2 Linux kernel 2.6.21 and 2.6.24 (różne dystrybucje) Intel 80003ES2LAN 1Gb Adaptec 5445 RAID; 4 high-end HDs, striped vol. RTL8111/8168B 1Gb Tabela 5.1: Konfiguracja sprzętu wykorzystywanego do symulacji. 5.3 Ocena wydajności środowiska LGS4Ns2 Wszystkie symulacje zostały wykonane w oparciu o pojedynczy węzeł zarządzający, który dodatkowo dysponował zasobami obliczeniowymi wykorzystywanymi do uruchomienia symulacji. Oprócz węzła głównego, wykorzystano 4 bezdyskowe maszyny obliczeniowe, połączone z węzłem głównym przy użyciu dedykowanego przełącznika sieciowego D-Link SRW2008. Konfiguracja sprzętowa komputerów wykorzystanych w celach obliczeniowych przedstawiona została w tabeli 5.1. Symulacje testowe wykonano w trzech grupach: (A) Wykorzystano tylko węzeł główny. (B) Wykorzystano cały klaster obliczeniowy. (C) Wykorzystano wyłącznie maszyny zewnętrzne. W przypadku wszystkich trzech grup wykonano ten sam zestaw zadań symulacyjnych, złożonych z grup od 20 do 140 przebiegów symulacji (pojedynczych uruchomień skryptu). 5.3.1 Prezentacja wyników Na wykresach 5.2 oraz 5.3 przedstawiono zagregowane czasy wykonania zadań na klastrze obliczeniowym. Można zaobserwować, że węzły zdalne wykonały obliczenia w czasie znacząco krótszym niż w przypadku

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 74 Czas [s] 1000 500 4 węzły - grupa C 4 węzły - grupa A 8 węzłów - grupa B 8 węzłów - grupa C 12 węzłów - grupa B 0 0 20 40 60 80 100 Liczba zadań Rysunek 5.2: Wpływ liczby zadań symulacyjnych na czas przeprowadzenia symulacji. Symulacje nie generują na wyjściu plików z zapisami przebiegu. wykorzystania zasobów obliczeniowych węzła głównego. Wynik ten był oczekiwany, jako że węzły zdalne zwolnione były z konieczności przeprowadzania kosztownych zapisów na dysk twardy oraz obsługi lokalnych serwisów (np. systemu bazy danych). W wyniku powyższego, praktycznie cała dostępna moc obliczeniowa (CPU oraz pamięć) przeznaczona była dla aplikacji symulatora. Łatwo zauważyć spadek czasu oczekiwania na wyniki wraz ze wzrostem liczby wykorzystywanych węzłów obliczeniowych. Można spodziewać się, że efekt ten utrzyma się do momentu przeciążenia możliwości komunikacyjnych węzła zarządcy. Pozytywny efekt wykorzystania bezdyskowych węzłów pracujących w oparciu o system plików NFS jest częściowo zdegradowany przez konieczność zarządzania fizycznymi dyskami w węźle głównym. Nie zmienia to jednak faktu, że wykorzystanie wyłącznie bezdyskowych węzłów zdalnych daje lepsze rezultaty niż w przypadku zaangażowania węzła głównego w obliczenia symulacyjne. Efekt ten spowodowany jest specyficzną konfiguracją klastra sieciowego - do połączenia węzłów wykorzystano dedykowane, wysokowydajne łącza komunikacyjne. Pomimo, że teoretycznie liczba operacji potrzebnych do zakończenia symulacji na węzłach zdalnych i lokalnym zarządcy jest taka sama, nie można pominąć wpływu architektury serwera (x86 64) na wykonywanie obliczeń. W przypadku operacji zapisu na dysku

ROZDZIAŁ 5. ŚRODOWISKO DO SYMULACJI RÓWNOLEGŁYCH 75 4000 3000 4 węzły - grupa C 4 węzły - grupa A 8 węzłów - grupa B 8 węzłów - grupa C 12 węzłów - grupa B Czas [s] 2000 1000 0 0 20 40 60 80 100 Liczba zadań Rysunek 5.3: Wpływ liczby zadań symulacyjnych na czas przeprowadzenia symulacji. Każda symulacja generuje na wyjściu od 100MB do 1200MB danych, średnia wielkość pliku wyjściowego wynosi 600MB. mechanizm DMA powoduje chwilowe blokowanie dostępu do magistrali pamięci również dla tych aplikacji, które z dysku nie korzystają. Wpływa to na ogólny wzrost czasu wykonania wszystkich operacji uruchomionych w węźle lokalnym. Rozdzielenie operacji dostępu do dysku (wliczając w to buforowanie i szeregowanie zapisów) od procesów obliczeniowych (jak ma to miejsce w przypadku zastosowania węzłów zewnętrznych) pozwala na znaczące podniesienie wydajności systemu. Wyraźny jest również wpływ mechanizmu agregacji danych w celu ich późniejszego przetworzenia. Na wykresie 5.3 przedstawiono wyniki dla symulacji generujących średnio 600MB danych wyjściowych, natomiast wykres 5.2 odpowiada sytuacji, w której dane wyjściowe nie były generowane. W pierwszym przypadku przeprowadzono jedynie agregację danych, bez ich dalszego przetwarzania (nie przeprowadzono procesu filtracji). Wyniki te wyraźnie pokazują poważną wadę symulatora ns-2, który nie pozwala na wstępne filtrowanie wyników w trakcie symulacji i wymusza zebranie pełnego zapisu przebiegu symulacji.

Rozdział 6 Zastosowanie podejścia deterministycznego Od czasu wprowadzenia mechanizmu RED, praktycznie wszystkie późniejsze propozycje mechanizmów AQM działy w oparciu o wyliczanie prawdopodobieństwa odrzucania pakietów. W momencie napływu pakietu do kolejki, ruter podejmuje decyzję o jego odrzuceniu, oznakowaniu (o ile wspierany jest mechanizm ECN) lub przyjęciu, wykorzystując mechanizm generatora liczb pseudolosowych. Metoda wykorzystująca losowe odrzucanie daje mechanizmom AQM przewagę w stosunku do klasycznych kolejek FIFO ponieważ, w przeciwieństwie do tych drugich, nie dyskryminuje transmisji o charakterze impulsowym, w których to przypadku spiętrzenie pakietów szybko narasta do poziomu przekraczającego pojemność bufora. Co więcej, podejście probabilistyczne do odrzucania pakietów zapobiega w oczywisty sposób globalnej synchronizacji przepływów TCP. A jednak podejście to może nie być najlepsze w wielu wypadkach. Jak zostanie pokazane w niniejszym rozdziale, w przypadku kiedy docelowa długość kolejki jest bardzo niska (np. 30 pakietów), podejście probabilistyczne skutkuje pojawieniem się wielu negatywnych efektów. W szczególności obserwuje się ograniczenie wykorzystania przepustowości łącza. Ponadto w przypadku zmniejszenia docelowej długości kolejki do bardzo małej wartości w ramach konfiguracji mechanizmów AQM, wiele z nich nie jest w stanie utrzymać zadanej długości, o ile nie zostanie wprowadzony dodatkowy mechanizm (np. zmniejszenie dostępnej wielkości bufora). Głównym osiągnięciem opisywanym w niniejszym rozdziale jest propozycja dwóch różnych, nowych mechanizmów aktywnego zarządzania kolejkami, które są w stanie zapewnić wysokie wykorzystanie przepustowości 76

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 77 łączy, przy jednoczesnej znaczącej redukcji opóźnień w sieci oraz znaczącej redukcji zmienności tych opóźnień. W przypadku obu algorytmów kluczowa okazała się zmiana sposobu wyznaczania pakietów do odrzucenia. W szczególności algorytmy te odchodzą od podejścia probabilistycznego i skupiają się na deterministycznym wyznaczeniu liczby pakietów, które należy przyjąć do bufora przed wykonaniem kolejnego odrzucenia. Podejście to pozwala też na rezygnację z zastosowania generatora liczb pseudolosowych w celu implementacji mechanizmu w rzeczywistym urządzeniu. W przypadku obu nowych mechanizmów zaprezentowano badania porównujące wyniki ich pracy w stosunku do mechanizmów AQM pozwalających na bezpośrednie określenie docelowej średniej długości kolejki (ARED, REM oraz PI). 6.1 Dynamiczny algorytm Drop Tail (FRDT) 6.1.1 Opis algorytmu W tej części pracy pokazany zostanie nowy mechanizm aktywnego zarządzania kolejką, zwany Frequency Reinforced Drop Tail (FRDT). W założeniu, mechanizm ten ma za zadanie podtrzymanie wysokiego poziomu wykorzystania łącza przy jednoczesnej stabilizacji długości kolejki na określonym (niskim) poziomie. Ponadto, mechanizm FRDT eliminuje problem polegający na konieczności przeprowadzenia długotrwałego procesu konfiguracji, mającego na celu dopasowanie ich działania do specyfiki zastosowania. Algorytm FRDT wymaga podania wyłącznie dwóch parametrów wejściowych: docelowej długości kolejki Q 0 (przekładającego się na opóźnienie kolejkowania) oraz przepustowości łącza stanowiącego wąskie gardło. W praktyce wymagane jest podanie tylko tej pierwszej wartości, ponieważ przepustowość łącza jest parametrem pracy rutera i jest stała. Dodatkowo FRDT samodzielnie ustala rzeczywistą wartość dostępnej przepustowości łącza poprzez obserwację maksymalnej osiąganej przepływności w czasie pełnego obciążenia. Parametr konfiguracyjny służy wyłącznie szybszemu dopasowaniu się mechanizmu do rzeczywistych warunków. Czyni to Q 0 jedynym wymaganym parametrem konfiguracyjnym. Jest to duża zaleta tego algorytmu. W przeciwieństwie do pozostałych, nie jest konieczna jego

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 78 wcześniejsza, niejednokrotnie złożona, parametryzacja w celu dostosowania do specyfiki sieci. Jak już powiedziano, moduł FRDT nie wykorzystuje mechanizmów losowych w celu odrzucania pakietów. Mechanizm ten wykorzystuje nowy parametr n d, zdefiniowany następuąco: n d 1 oznacza liczbę pakietów przyjętych do kolejki (o ile się zmieszczą w buforze), po której nastąpi odrzucenie pakietu. Innym słowy, po każdym odrzuceniu pakietu wyznaczany jest przedział czasu (mierzony liczbą napływających pakietów), po którym zostanie odrzucony kolejny pakiet. Ponadto, do odrzucania pakietów wykorzystany jest drugi mechanizm. Dynamiczne dobierany jest rozmiar maksymalny kolejki Q d, powyżej którego wszystkie nadchodzące pakiety zostaną odrzucone. Drugi mechanizm może skutkować wyrzuceniem z kolejki pakietów już do niej przyjętych, w szczególności w przypadku, gdy q t > Q d, gdzie q t to rozmiar kolejki obserwowany w momencie obliczenia nowej wartości Q d. Wartości Q d oraz n d obliczane są po każdym odrzuceniu pakietu lub grupy pakietów (w wyżej wymienionym przypadku). Skutkuje to wykonywaniem obliczeń z różną częstością, zależną od chwilowego obciążenia sieci. Wartość n d obliczana jest zgodnie z następującymi regułami: n d (t) + 4, jeżeli r t < C, n d (t + 1) = n d (t), jeżeli r t = C, (6.1) n d (t) 1, jeżeli r t > C, gdzie r t to wartość szybkości napływu pakietów do rutera obserwowana od poprzedniego obliczenia n d do danej chwili, a C to przepustowość łącza. Wartość Q d obliczana jest przy zastosowaniu następujących reguł: Q d (t) 1.1, jeżeli r t < C, q avg 4Q 3 0, Q d (t), jeżeli r t < C, q avg > 4 Q d (t + 1) = Q 3 0, Q d (t) 0.81, jeżeli r t > C, q avg > 4Q (6.2) 3 0, Q d (t) 0.9, jeżeli r t > C, q avg 4Q 3 0, gdzie Q 0 to docelowa długość kolejki (podawana w postaci parametru konfiguracyjnego), oraz q avg (t) = q avg(t 1) + q t. (6.3) 2 Jak widać zaproponowany mechanizm jest dość prosty, jednak już przy jego pomocy można uzyskać dość interesujące wyniki. Związane jest to z wykorzystaniem podejścia deterministycznego.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 79 6.1.2 Ocena wydajności mechanizmu FRDT Symulacje uwzględniają podstawowe dwa scenariusze Access Link oraz Data Center opisane w rozdziale 4. W obu scenariuszach wykorzystywana jest standardowa topologia typu dumbbell z dwoma ruterami, A i B, w której wąskim gardłem jest łącze A-B. Sieć zbudowana jest z sześciu węzłów N1- N6 połączonych z ruterami łączami o przepustowościami 100Mb/s. Źródła TCP zlokalizowane są w węzłach N1-N3 i prowadzą transmisję do węzłów N4-N6 wykorzystując równomiernie wszystkie dziewięć możliwych ścieżek transmisji. Wszystkie węzły pracują w oparciu o protokół transportowy TCP. 90% połączeń wykorzystuje pakiety o długości 1500B. Pozostałe 10% połączeń wykorzystuje pakiety o długości 536B. Połączenia te są dodatkowo podzielone: 75% z nich oraz pozostałe połączenia wykorzystujące 536- bajtowe pakiety stanowi długotrwałe przepływy TCP (FTP). Pozostałe 25% przepływów o pakietach długości 1500B imituje ruch HTTP: transmisja obejmuje dużą liczbę małych plików. Transmisje te są uruchamiane zgodnie z procesem Poissona, z natężeniem odpowiadającym poziomowi r b. Rozmiar plików ustalany jest zgodnie z regułą opisaną w rozdziale 4. Wartości startowe generatorów liczb pseudolosowych środowiska symulacyjnego były ustawiane losowo przy każdym uruchomieniu. Każdy scenariusz uruchomiony został 10 razy z różnymi wartościami inicjującym parametry losowe. Wyniki stanowią średnią wyników uzyskanych w pojedynczych symulacjach. Porównanie z innymi mechanizmami W porównaniu wykorzystano cztery algorytmy: ARED, REM, PI oraz FRDT. Tabela 6.1 pokazuje parametry konfiguracyjne algorytmu ARED wykorzystane w trakcie symulacji. Wartości tych parametrów zostały dobrane w celu maksymalizacji osiąganych przepływności. W przypadku parametrów REM oraz PI jedyny skonfigurowany parametr to średnia wielkość pakietu została ustalona na poziomie 1312B (taki średni rozmiar występuje w proponowanym wzorcu transmisji). Bufor we wszystkich symulacjach miał pojemność 953 pakiety, co wynika z reguły BDP. Wartości parametrów konfiguracyjnych dla średniej docelowej długości kolejki 100 pakietów zostały zaprezentowane w tabeli 6.2 Jak się okazuje, tak duży bufor nie będzie tu wykorzystywany z powodu zastosowania mechanizmów AQM, jednak przyjmujemy go z powodu popularności metody BDP

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 80 Nazwa parametru Wartość queue in bytes false adaptive true interval 0.1 mean pktsize 1312 Tabela 6.1: Parametryzacja mechanizmu ARED. Wartości nie wymienione w tabeli przyjmują domyślne wartości środowiska ns-2.34. AQM: nazwa parametru wartość ARED:thresh 75 ARED:maxthresh 125 PI:qref 100 REM:pbo 100 FRDT:qref 100 Tabela 6.2: Parametryzacja docelowej długości kolejki (100 pakietów) dla mechanizmów AQMs wykorzystywanych w symulacjach. 6.1.3 Charakterystyki wyjściowe Względny współczynnik błędu długości kolejki Względny współczynnik błędu długości kolejki ɛ q wskazuje na zdolność utrzymania docelowej długości kolejki skonfigurowanej dla każdego z algorytmów AQM i jest równy: ɛ q = Q 0 Q mean Q 0, (6.4) gdzie Q 0 to zadana długość kolejki a Q mean to średnia zmierzona długość kolejki. Pomiar wartości średniej długości kolejki Q mean rozpoczyna się w 30 sekundzie symulacji w celu odrzucenia stanów nieustalonych wynikających z automatycznej konfiguracji mechanizmów AQM. Wykresy ɛ q wykorzystują skalę logarytmiczną ze względu na fakt, że niektóre z porównywanych mechanizmów zupełnie nie są w stanie utrzymać skonfigurowanych wartości. Odchylenie standardowe długości kolejki Odchylenie standardowe długości kolejki, podobnie jak jej średnia długość, było liczone począwszy od 30 sekundy symulacji.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 81 Rysunek 6.1: Odchylenie standardowe długości kolejki w scenariuszu Access Link. Wykorzystanie przepustowości łącza Wykorzystanie przepustowości łącza opisane jest jako procent r agg /C, gdzie r agg to średnia przepływność obserwowana przez stanowisko obsługi, a C to przepustowość łącza stanowiącego wąskie gardło. 6.1.4 Zbiorcza analiza porównawcza W bieżącej sekcji zaprezentowano porównawczą analizę wydajności czterech mechanizmów AQM (ARED, REM, PI oraz FRDT) w różnych warunkach pracy sieci. Każda charakterystyka wyjściowa generowana była w dwóch scenariuszach Data Center, Access Link oraz w czterech przypadkach obciążenia, od 10 do 1000 przepływów. (zob. sekcja 4.2) Stabilizacja opóźnienia Na wykresach 6.1 oraz 6.2 zaprezentowano możliwości stabilizacji długości kolejki pakietów oferowane przez badane mechanizmy AQM. Pomimo gorszych wyników w przypadku słabo obciążonej sieci w scenariuszu Access Link, algorytm FRDT gwarantuje znacząco lepszą stabilność opóźnień kolejkowania w większości badanych scenariuszy.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 82 Rysunek 6.2: Odchylenie standardowe długości kolejki w scenariuszu Data Center. Wykorzystanie łącza Na wykresach 6.3 and 6.4 pokazano poziom wykorzystania pojemności łącza oferowany przez różne mechanizmy AQM. Można zaobserwować, że mechanizm FRDT oferuje podobne do innych wykorzystanie łącza. Poziom strat pakietów Istotność poziomu strat pakietów z punktu widzenia nowoczesnych wariantów protokołu TCP jest szeroko dyskutowana w literaturze. Wynika to z faktu, że współczesne implementacje TCP wyposażone są w mechanizm potwierdzeń selektywnych, które zmniejszają negatywny wpływ strat pakietów. Niezależnie od tego, nie wszystkie systemy wyposażone są w ten mechanizm i dlatego straty pakietów mogą mieć negatywny wpływ na rzeczywistą transmisję: pomimo dużego obciążenia łączy, prędkość transmisji obserwowana przez końcowego użytkownika może być stosunkowo niewielka. Sytuacja taka występuje wtedy, kiedy mechanizm TCP wykonuje wielokrotne retransmisje z powodu nie otrzymania potwierdzenia odbioru pojedynczych pakietów. Na wykresach 6.5 oraz 6.6 przedstawiono średni poziom strat pakietów w analizowanych mechanizmach AQM. Można zauważyć, że w przypadku

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 83 Rysunek 6.3: Wykorzystana przepustowość łącza w scenariuszu Access Link. Rysunek 6.4: Wykorzystana przepustowość łącza w scenariuszu Data Center.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 84 Rysunek 6.5: Średni poziom strat pakietów w scenariuszu Access Link. Rysunek 6.6: Średni poziom strat pakietów w scenariuszu Data Center.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 85 Rysunek 6.7: Względny współczynnik błędu długości kolejki w scenariuszu Access Link. scenariuszy o niskim poziomie przeciążenia, poziom odrzuceń pakietów w przypadku FRDT jest wyższy niż w przypadku pozostałych mechanizmów. Warto jednak zauważyć, że nadal jest bliski 1% i nie ma istotnego wpływu na osiąganą szybkość transmisji. Z kolei dla lekkich i średnich przeciążeń w scenariuszu Data Center nowy algorytm oferuje znacznie mniejszy poziom strat. Utrzymanie docelowej długości kolejki Na wykresach 6.7 oraz 6.8 zaprezentowano wartość względnego współczynnika błędu długości kolejki oferowaną przez badane mechanizmy AQM. Jak widać, algorytm FRDT ogólnie dobrze radzi sobie z utrzymaniem średniej długości kolejki w okolicach wartości konfigurowanej (100 pakietów), jednak w przypadku braku przeciążenia oraz małego przeciążenia w scenariuszu Data Center algorytm REM jest od niego wyraźnie lepszy. W przypadku scenariusza Access Link, mechanizm FRDT daje świetne wyniki przy braku przeciążenia sieci oraz dużego przeciążenia sieci. Jednak w zakresach małych i średnich przeciążeń proponowany mechanizm się nie sprawdza.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 86 Rysunek 6.8: Względny współczynnik błędu długości kolejki w scenariuszu Data Center. 6.1.5 Podsumowanie Jak pokazano, algorytm FRDT najlepiej nadaje się do stosowania w sieciach o parametrach zbliżonych do wariantu Data Center. Jego wydajność w takich sieciach nie różni się specjalne od oferowanej przez inne mechanizmy w zakresie od średniego do dużego przeciążenia sieci. Niestety, mechanizm FRDT prezentuje również pewne negatywne efekty w przypadku zastosowania w środowisku typowym (Access Link). Sugeruje to, że ten algorytm, prosty i przydatny do niektórych rozwiązań, może nie być wystarczający do osiągnięcia celu zawartego w tezie rozprawy, szczególnie jeśli rozpatrywać wszystkie poziomy przeciążenia sieci w typowym środowisku pracy mechanizmów AQM. W związku z powyższym podjęto próbę zaprojektowania innego mechanizmu AQM, dającego dobre rezultaty niezależnie od scenariusza, w którym pracuje. 6.2 Mechanizm AQM z perceptronem (DPB) W niniejszej sekcji zaprezentowano inny nowy mechanizm aktywnego zarządzania kolejką, nazwany Deterministic Perceptron Based AQM (DPB).

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 87 W przypadku algorytmu DPB liczba pakietów, które mają być przyjęte do systemu przed dokonaniem kolejnego odrzucenia wyznacza jest przy użyciu perceptronu opisanego w dalszej części rozdziału. Parametrami wejściowymi sterującymi pracą algorytmu są: natężenie ruchu w sieci oraz aktualna długość kolejki. Podobnie do mechanizmu FRDT, algorytm DPB posiada tylko jeden parametr konfiguracyjny: docelową średnią długość kolejki. 6.2.1 Zastosowanie sztucznych sieci neuronowych w AQM Istnieje kilka mechanizmów AQM wykorzystujących sztuczne sieci neuronowe (SSN). Różnią się one pod względem złożoności, liczby i rodzaju parametrów wejściowych. Różnice w sposobie ich działania nie ograniczają się wyłącznie do parametryzacji, ale są przede wszystkim dostrzegalne w stopniu skomplikowania architektury SSN, na której bazują. Cho et al. [16] oraz Rahnamai et al. [61] proponują zastosowanie dynamicznych, wielowarstwowych sieci, podczas gdy Sun et al. proponuje wykorzystanie kilku różnych konstrukcji [66, 67, 68, 69], bazujących na pojedynczym neuronie adaptatywnym. Wydajna implementacja złożonych sztucznych sieci neuronowych, które mają być uruchomione na typowym, współczesnym sprzęcie sieciowym może być bardzo utrudniona. Dotyczy to zwłaszcza urządzeń sieciowych małej skali, przeznaczonych do użytku domowego. Z drugiej strony, prostsze rozwiązania wykorzystujące sieci neuronowe o małej złożoności świetnie nadają się do implementacji nawet na urządzeniach o ograniczonych możliwościach obliczeniowo-pamięciowych. Dobrym reprezentantem tej grupy mechanizmów jest algorytm AN-AQM, zaproponowany w pracy [67]. Mechanizm ten dobrze sprawdza się w scenariuszach o wysokim poziomie przeciążenia. Niestety, jak pokazano w pracy [56], mechanizm ten nie oferuje dobrych rezultatów w scenariuszach o małym i średnim poziomie przeciążenia czy scenariuszach, w których przeciążenie nie występuje. Niezależnie od powyższego, praca [67] stanowi dobry punkt wyjściowy do konstrukcji wydajniejszych algorytmów AQM, gdyż prezentuje szczegółowy przegląd parametrów i zmiennych mogących stanowić elementy wektora wejściowego dla perceptronu.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 88 6.2.2 Opis algorytmu Algorytm DPB ma na celu podtrzymanie wysokiego stopnia wykorzystania dostępnej przepustowości przy jednoczesnym utrzymywaniu niskiego opóźnienia kolejkowania oraz stabilnej (tzn. podlegającej niewielkim wahaniom) długości kolejki. W związku z tym, że mechanizm DPB próbuje rozwiązać kilka różnych problemów, został on zaprojektowany zgodnie z paradygmatem programowania dynamicznego: mechanizm wykorzystuje dwa moduły: moduł unikania przeciążenia i wczesnego odrzucania pakietów (CAED - Congestion Avoidance with Early Drops) oraz moduł zapewniający utrzymanie średniej długości kolejki (T AQ 0 - Target Average Queue Length Enforcement Module). Zadaniem pierwszego modułu jest utrzymanie jak największej przepływności podczas gdy zadaniem drugiego jest utrzymanie długości kolejki na zdefiniowanym poziomie. Maksymalizacja prędkości transmisji W odróżnieniu od mechanizmu FRDT, wartość n d jest obliczana dynamicznie na podstawie wartości zwracanej przez klasyfikator wykorzystujący pojedynczy perceptron. Procedura uczenia poprzez wsteczną propagację błędu wykonywana jest po każdym odrzuceniu pakietu, ale nie rzadziej niż co 10ms. Przeliczenie wartości wejściowych dla perceptronu przeprowadzane jest po każdym odrzuceniu pakietu, również w przypadku odrzuceń niekontrolowanych przez moduł CAED (np. przepełnienie bufora). Schemat budowy modułu CAED został przedstawiony na rysunku 6.9. Działanie modułu CAED kontrolowane jest przez funkcję F (x) zdefiniowaną jako: 6 F (x) = x i ω i, (6.5) i=0 gdzie x i to kolejne wejścia perceptronu a ω i to wagi dla wejść. Wartości wejść wyliczane są na podstawie dwóch głównych wskaźników błędu: błędu oszacowania długości kolejki oraz normalizowanego błędu prędkości transmisji zdefiniowanych jako: e t = Q 0 q t, (6.6) C r j t = t 1, jeżeli r t > 0, 0, w przeciwnym wypadku, (6.7)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 89 Rysunek 6.9: Schemat działania modułu CAED. Licznik wyzwalania odrzuceń pakietów obliczany jest przy wykorzystaniu wyjścia perceptronu posiadającego 6 wejść. Wyjście funkcji przejścia modyfikowane jest każdorazowo przy wykorzystaniu uczenia ze wsteczną propagacją błędów. gdzie e t to błąd oszacowania długości kolejki, q t to zmierzona długość kolejki, Q 0 to docelowa długość kolejki, j t oznacza normalizowany błąd prędkości transmisji, r t to obserwowana przepływność na wejściu do kolejki (zliczane są tylko pakiety, które nie zostały odrzucone) a C to przepustowość łącza wyjściowego. Na podstawie tych wartości, wektor wejściowy dla perceptronu zdefiniowany jest podobnie jak w [67]: x 1 = e t e t 1, x 2 = e t, x 3 = e t 2e t 1 + e t 2, x 4 = j t j t 1, x 5 = j t, x 6 = j t 2j t 1 + j t 2, (6.8) i x i (0; 1). W celu wyznaczenia wag dla wejść sieci neuronowej wykorzystywany jest proces uczenia w sprzężeniu zwrotnym ze wsteczną propagacją błędu: ω i (t + 1) = ω i (t) + d i y i, (6.9) gdzie d i są stałymi determinującymi szybkość procesu uczenia neuronu (d 1 = d 2 = d 3 = 0.0001, d 4 = d 5 = d 6 = 0.001) a y i to raportowany błąd propagacji wstecznej:

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 90 0.01 e t ω i F (x), jeżeli e t > 0, y i = 0.01 e t ω i F (x), w przeciwnym przypadku. (6.10) Jak można oczekiwać, j t 0 i e t 0 przez większość czasu. W związku z tym zostały wprowadzone dodatkowe ograniczenia na ω i (0; 10) w celu ochrony algorytmu przed destabilizacją, opisane w dalszej części rozdziału. Ostatecznie, wartość funkcji wyjściowej perceptronu wykorzystywana jest do ustalenia nowej wartości częstości odrzucania pakietów n d, zgodnie z następującą regułą: n d (t) 1.1, jeżeli F (x) > 0, n d (t + 1) = (6.11) n d (t) 0.9, jeżeli F (x) 0. Sądząc po elementach wektora wejściowego sieci neuronowej, moduł CAED powinien rozwiązywać zarówno problem niepełnego wykorzystania dostępnej przepustowości jak i zapewnić utrzymanie długości kolejki na skonfigurowanym poziomie. Niestety, CAED radzi sobie dobrze jedynie z pierwszym zadaniem. CAED nie radzi sobie z utrzymaniem średniej długości kolejki, jeżeli Q 0 ustawione jest poniżej pewnej wartości progowej. Wartość ta zależy od scenariusza symulacji, a w szczególności od liczby przepływów TCP oraz rozkładu czasów RTT dla przepływów. Przyczyn tego efektu należy szukać w definicji j t Nie wszystkie pakiety trafiające do rutera są brane pod uwagę podczas obliczania wartości j t, uwzględniane są wyłącznie pakiety zaakceptowane. W związku z tym, przez większość czasu długość kolejki spada poniżej wartości docelowej i dlatego j t < 0. Z kolei to doprowadza do sytuacji, w której wartości ω i powiązane z e t są o kilka rzędów wielkości mniejsze od wartości bazujących na j t. Ciekawą własnością algorytmu CAED jest to, że w przypadku dobrania docelowej długości kolejki poniżej wartości optymalnej dla danego scenariusza, CAED przesteruje się tak, że błąd kolejki nie będzie miał wielkiego wpływu na wartość funkcji wyjściowej. Potrzebny jest jednak inny mechanizm, który zagwarantuje utrzymanie wartości skonfigurowanej. W dalszej części rozdziału pokazano, że podobny problem występuje również w przypadku algorytmu REM. Wymuszanie zachowania długości kolejki Jak wspomniano w poprzedniej sekcji, zaprezentowany klasyfikator liniowy nie jest w stanie utrzymać skonfigurowanej docelowej długości kolejki,

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 91 jeżeli zostanie ona ustawiona poniżej pewnej wartości (mocno zależnej od scenariusza testowego). W związku z tym wprowadzono dodatkowy mechanizm (T AQ 0 ) mający wymusić zgodność uzyskiwanych wyników z zadanymi parametrami wejściowymi. Na długość kolejki nakładane jest dodatkowe ograniczenie Q d, Q d [Q 0, b], gdzie b to rozmiar bufora. Q d ustalane jest w oparciu o zmienną pomocniczą Q avg. Wartość Q avg obliczana jest w każdym momencie, w którym pakiet wchodzi do kolejki: Q avg (t + 1) = Q avg(t) + q t. (6.12) 2 Pakiet zostanie przyjęty do kolejki, jeżeli długość kolejki nie przekracza Q d, lub odrzucony w przeciwnym razie. W przypadku odrzucenia pakietu, moduł CAED otrzymuje informację o konieczności przeprowadzenia uczenia zwrotnego. W przypadku przyjęcia pakietu do kolejki, wartość Q d obliczana jest zgodnie z: Q d (t) 4, jeżeli Q avg > Q 0, Q d (t + 1) = Q d (t), jeżeli Q avg = Q 0, Q d (t) + 1, jeżeli Q avg < Q 0. (6.13) Pomimo, że moduł CAED nie ma bezpośredniego wpływu na działanie T AQ 0, moduł T AQ 0 wpływa bezpośrednio na moduł CAED na dwa sposoby. Pierwszy z nich, wskazany wyżej, polega na wywoływaniu procesu uczenia perceptronu w przypadku odrzucenia pakietu. Drugi polega na niewielkiej destabilizacji mechanizmu CAED, które działa pozytywnie na cały system: dodatkowe odrzucenia pakietów wynikające z działania T AQ 0 mają nieliniowy charakter (w przeciwieństwie do odrzuceń inicjowanych przez CAED). Nieliniowy charakter tych strat powoduje okresowo drobny wzrost wartości wag dla wejść powiązanych z e t, przy jednoczesnym obniżeniu wag dla wejść powiązanych z j t. Dzięki temu CAED może szybciej reagować na zmieniające się warunki w sieci. 6.2.3 Ocena działania Symulacje uwzględniają dwa scenariusze Access Link oraz Data Center opisane w rozdziale 4. W obu scenariuszach wykorzystywana jest standardowa topologia typu dumbbell z dwoma ruterami, A i B, w której wąskim gardłem jest łącze A-B. Sieć zbudowana jest z sześciu węzłów N1-N6 połączonych z ruterami łączami o przepustowościach 100Mb/s. Źródła TCP zlokalizowane są na węzłach N1-N3 i prowadzą transmisję

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 92 do węzłów N4-N6 wykorzystując wszystkie dziewięć możliwych ścieżek transmisji. Wszystkie węzły wykorzystują protokół transportowy TCP. 90% przepływów przesyła pakiety o długości 1500B a pozostałe 10% pakiety o długości 536B. Przepływy te są dodatkowo podzielone: 75% przepływów wykorzystujących pakiety 1500B oraz pozostałe przepływy wykorzystujące pakiety 536-bajtowe stanowią długotrwałe przepływy TCP (FTP). Pozostałe 25% przepływów pakietów o długości 1500B imitują ruch HTTP: transmisja obejmuje dużą liczbę małych plików. Transmisje te są uruchamiane zgodnie z procesem Poissona, z natężeniem odpowiadającym poziomowi r b. Rozmiar plików ustalany jest zgodnie z regułą opisaną w rozdziale 4. Wartości startowe generatorów liczb pseudolosowych środowiska symulacyjnego były ustawiane losowo przy każdym uruchomieniu w celu zapewnienia weryfikowalności i powtarzalności wyników. Każdy scenariusz uruchomiony został 10 razy z różnymi wartościami parametrów losowych. Wyniki stanowią wartość średnią parametrów wyliczonych w pojedynczych symulacjach. Porównanie z innymi mechanizmami Podobnie jak w przypadku algorytmu FRDT, do porównania wykorzystano cztery algorytmy umożliwiające w miarę bezpośrednie ustalenie kolejki docelowej, tzn.: ARED, REM, PI oraz DPB. Tabela 6.1 przedstawia wartości konfiguracyjne algorytmu ARED wykorzystane w trakcie symulacji. Konfiguracja pozostałych mechanizmów jest taka, jak wcześniej prezentowana: w przypadku parametrów REM oraz PI jedyny parametr dotyczył średniej wielkości pakietu i został ustalony na poziomie 1312B (jest to zgodne ze wzorcem transmisji). Bufor pakietów we wszystkich symulacjach ma pojemność 953 pakiety. Wartości konfiguracyjne docelowych długości kolejek zostały zaprezentowane w tabeli 6.3. 6.2.4 Zbiorcza ocena wydajności W tej sekcji zaprezentowano porównanie wydajności algorytmów AQM w różnych warunkach sieciowych. Każdy scenariusz został uruchomiony dla czterech różnych docelowych długości kolejek: 15, 30, 50 i 100 pakietów.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 93 (a) (b) (c) Rysunek 6.10: Względny błąd średniej długości kolejki spowodowany przez mechanizmy AQM w scenariuszu Access Link. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 94 (a) (b) (c) Rysunek 6.11: Względny błąd średniej długości kolejki spowodowany przez mechanizmy AQM w scenariuszu Data Center. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 95 (a) (b) (c) Rysunek 6.12: Odchylenie standardowe długości kolejki w scenariuszu Access Link. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 96 (a) (b) (c) Rysunek 6.13: Odchylenie standardowe długości kolejki w scenariuszu Data Center. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 97 Docelowa kolejki 15 30 50 100 długość AQM: Nazwa parametru Wartość ARED:thresh 5 ARED:maxthresh 25 PI:qref 15 REM:pbo 15 DPB:qref 15 ARED:thresh 15 ARED:maxthresh 45 PI:qref 30 REM:pbo 30 DPB:qref 30 ARED:thresh 25 ARED:maxthresh 75 PI:qref 50 REM:pbo 50 DPB:qref 50 ARED:thresh 75 ARED:maxthresh 125 PI:qref 100 REM:pbo 100 DPB:qref 100 Tabela 6.3: Parametryzacja docelowej długości kolejki dla mechanizmów AQMs wykorzystywanych w symulacjach. Umiejętność utrzymania docelowej długości kolejki oraz stabilizacji opóźnień Rysunki 6.10 i 6.11 prezentują wartości ɛ q osiągane w symulacjach. Warto zauważyć, że algorytm DPB był w stanie utrzymać średnią długość kolejki na poziomie porównywalnym z wartością skonfigurowaną (wartość ɛ g typowo nie przekracza 10%). Algorytm REM oferuje podobną charakterystykę pracy w przypadku scenariusza Access Link, choć godnym uwagi jest fakt, że w przypadku algorytmu DPB, Q mean < Q 0, czego nie można powiedzieć o algorytmie REM. Mechanizm DPB nie tylko pozwala na osiągnięcie zadanych wartości, ale dodatkowo oferuje bardzo wysoki stopień stabilizacji opóźnienia (tzn. zmniejszenia wahań opóźnienia). Efekt ten można zaobserwować na wykresach 6.12 oraz 6.13. Interesujące jest zachowanie mechanizmu PI, który został stworzony

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 98 (a) (b) (c) Rysunek 6.14: Poziom wykorzystania przepustowości łącza oferowany przez różne mechanizmy AQM w scenariuszu Access Link. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d) z myślą o stabilizacji kolejki a zachowuje się wyraźnie gorzej od mechanizmu ARED, od którego można spodziewać się oscylacji w przedziale [min th ; max th ]. Wykorzystanie przepustowości łącza Wykresy 6.15 oraz 6.14 pokazują poziomy utylizacji przepustowości fizycznego łącza oferowane przez różne mechanizmy AQM. W przypadku scenariusza Access Link, współczynnik wykorzystania

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 99 (a) (b) (c) Rysunek 6.15: Poziom wykorzystania przepustowości łącza oferowany przez różne mechanizmy AQM w scenariuszu Data Center. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów. (d)

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 100 przepustowości łącza zależny jest od poziomu przeciążenia sieci i tylko w niewielkim stopniu od docelowej długości kolejki. W szczególności, algorytm DPB wyprzedza pozostałe mechanizmy w przypadku braku przeciążenia i docelowych długościach kolejki Q 0 30. Jeśli porówna się uzyskane wyniki z wynikami dotyczącymi stabilizacji, to można stwierdzić, że algorytm DPB oferuje ponadprzeciętne wykorzystanie łącza w stosunku do poziomu stabilizacji długości kolejki. Warto zauważyć, ze DPB zachowuje się bardzo podobnie niezależnie od stopnia przeciążenia, czego nie można powiedzieć o innych mechanizmach. W przypadku scenariusza Data Center, im większa jest wartość Q 0, tym lepiej badane mechanizmy radzą sobie z wykorzystaniem przepustowości łącza. Jednak w przypadku minimalizacji opóźnień (wykresy 6.15a i 6.15b), w przypadku mocno przeciążonej sieci pojawiają się negatywne efekty wpływające na działanie opisywanych mechanizmów. DPB wyprzedza inne mechanizmy, bądź też osiąga porównywalne wyniki, niezależnie od poziomu przeciążenia sieci. Dodatkowo, w przeciwieństwie do pozostałych algorytmów, zachowuje się stabilnie we wszystkich scenariuszach, podczas gdy pozostałe algorytmy nawet jeśli wykazują dobre działanie w jednym scenariuszu, nie sprawdzają się w przypadku innego. Przykładowo algorytmy REM i PI działają bardzo dobrze w przypadku sieci nieprzeciążonej, ale ich wyniki są wyraźnie gorsze w przypadku środowiska przeciążonego, w którym to ARED (oraz DPB) radzą sobie bez większych problemów. Poziom strat pakietów Poziomy strat pakietów zostały przedstawione na wykresach 6.16 oraz 6.17. Przyjmują podobne wartości we wszystkich symulacjach jednego scenariusza. W przypadku scenariusza Data Center, DPB odrzuca czasami nieco więcej pakietów niż pozostałe mechanizmy AQM, ale nie ma to wpływu ani na wykorzystanie łącza ani na stabilność pracy algorytmu. Dodatkowo różnica w liczbie odrzuconych pakietów nie jest duża. W przypadku scenariusza Access Link działanie DPB jest zupełnie odwrotne: poziom strat powodowanych przez DPB jest znacząco niższy niż w przypadku pozostałych mechanizmów, szczególnie w przypadku średniego i dużego przeciążenia sieci.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 101 (a) (b) (c) (d) Rysunek 6.16: Średni poziom strat pakietów powodowanych przez różne mechanizmy AQM w scenariuszu Access Link. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 102 (a) (b) (c) (d) Rysunek 6.17: Średni poziom strat pakietów powodowanych przez różne mechanizmy AQM w scenariuszu Data Center. Docelowe długości kolejki zostały ustawione na: (a) 15 pakietów, (b) 30 pakietów, (c) 50 pakietów, (d) 100 pakietów.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 103 Rysunek 6.18: Przebieg czasowy długości kolejki zarządzanej przez mechanizm ARED w scenariuszu Data Center; Q 0 = 100, 200 równoczesnych połączeń TCP. 6.2.5 Stabilizacja kolejki Przykładowe przebiegi czasowe długości kolejek zarządzanych przez algorytmy ARED, PI, REM oraz DPB zostały zaprezentowane odpowiednio na wykresach 6.18, 6.19, 6.20 i 6.21. Długość kolejki była mierzona w trakcie jednego przebiegu symulacji, dla każdego z algorytmów, w scenariuszu Data Center. Wartość docelowej długości kolejki Q 0 wynosiła 100 pakietów, wykorzystano 200 równoległych przepływów TCP. Wykresy 6.19, 6.20 ukazują niestabilność w przypadku algorytmów REM jak i PI. Dodatkowo, algorytm PI potrzebuje bardzo dużo czasu w celu zaadaptowania do warunków pracy sieci. ARED dosyć dobrze radzi sobie ze stabilizacją długości kolejki, ale nie jest w stanie utrzymać jej na skonfigurowanym poziomie Q 0 = 100. Również algorytm REM nie utrzymuje dobrze zadanej średniej kolejki widać, że wartość średnia jest wyraźnie poniżej 100. W zaprezentowanym scenariuszu DPB nie ma sobie równych zarówno pod względem umiejętności dążenia do Q 0 jak i stabilizacji długości kolejki na tym poziomie.

ROZDZIAŁ 6. ZASTOSOWANIE PODEJŚCIA DETERMINISTYCZNEGO 104 Rysunek 6.19: Przebieg czasowy długości kolejki zarządzanej przez mechanizm PI scenariuszu Data Center; Q 0 = 100, 200 równoczesnych połączeń TCP. Rysunek 6.20: Przebieg czasowy długości kolejki zarządzanej przez mechanizm REM w scenariuszu Data Center; Q 0 = 100, 200 równoczesnych połączeń TCP.