Adam Domański. Instytut Informatyki Politechnika Śląska

Transkrypt

1 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania na transmisję danych w sieci Internet Influence of the TCP mechanisms and queue management on Internet transmission Adam Domański Instytut Informatyki Politechnika Śląska Gliwice 2017

2 2

3 SPIS TREŚCI 1. SŁOWNIK POJEĆ 7 2. WSTEP ALGORYTMY STEROWANIA PRZECIAŻENIEM Protokół TCP a standardy sieciowe Model warstwowy TCP/IP Zegary TCP Sterowanie przepływem oraz przeciążeniami Wydajność TCP Algorytmy sterowania przeciążeniami w TCP Algorytm Reno Algorytm New Reno Skalowanie okna Znaczniki czasowe TCP Potwierdzenia selektywne Potwierdzenia generowane w przód Podwojone SACK TCP Westwood TCP Vegas BI-TCP F-RTO Wyraźne powiadamianie o przeciążeniach ECN Podsumowanie ZARZADZANIA KOLEJKA ROUTERA Algorytmy kolejkowania Metody odrzucania pakietu Pasywne oraz aktywne zarządzanie kolejkami

4 4 Spis treści 5. OCENA MECHANIZMÓW TCP Mechanizmy oceny algorytmów sterowania przeciążeniem Przebieg eksperymentów Uzyskane rezultaty OCENA MECHANIZMÓW KOLEJKOWANIA Przebieg eksperymentów Uzyskane rezultaty IMPLEMENTACJA ORAZ OCENA MECHANIZMÓW AQM Symulacja mechanizmów aktywnego zarządzania kolejką Badania z pętlą otwartą Badania z pętlą zamkniętą Sprawiedliwa obsługa wielu strumieni danych w węźle Router AQM w Linuksie Mechanizm implementacji AQM Przebieg eksperymentów Uzyskane rezultaty APROKSYMACJA FLUID FLOW Model NewReno Model Vegas Podsumowanie PODSUMOWANIE 229 BIBLIOGRAFIA 232 INDEKS 240 STRESZCZENIE 242

5 CONTENTS 1. NOTION 7 2. INTRODUCTION CONGESTION CONTROL ALGORITHM TCP protocol and network standards TCP model TCP timers Congestion and flow control TCP performance TCP and congestion control algorithms Reno algorithm New Reno algorithm Window scaling Timestamps Selective acknowledgements Forward acknowledgements Duplicated SACK TCP Westwood TCP Vegas BI-TCP F-RTO Explicit Congestion Notification ECN Summary QUEUE MANAGEMENT Queuing algorithms Dropping packets strategies Passive and active queue management

6 6 Contents 5. TCP MECHANISMS EVALUATION TCP congestion control evaluation mechanisms Experiments Obtained results QUEUING MECHANISMS EVALUATION Experiments Obtained results AQM MECHANISMS IMPLEMENTATION AND EVALUATION The active queue mechanisms simulation Open loop researches Closed loop researches Fair service of multiple data streams in a node AQM router in Linux AQM mechanism implementation Experiments Obtained results FLUID FLOW APPROXIMATION NewReno model Vegas model Summary CONCLUSIONS 229 BIBLIOGRAFHY 232 INDEX 240 ABSTRACT 244

7 Rozdział 1 SŁOWNIK POJEĆ IETF LRD fgn QoS TCP UDP IP Internet Engineering Task Force nieformalne, międzynarodowe stowarzyszenie osób zainteresowanych ustanawianiem standardów technicznych i organizacyjnych w Internecie. Long Range Dependence pojęcie powiązane z procesami samopodobnymi. Statystyczna zależność wykorzystywana w analitycznych i symulacyjnych metodach modelowaniu ruchu sieciowego do tworzenia źródeł transmisji danych. Fractional Gaussian Noise jeden ze sposobów tworzenia ciągów charakteryzujących się samopodobną charakterystyką wykorzystywanych do tworzenia samopodobnych źródeł ruchu sieciowego. Quality of Service w rozumieniu sieci komputerowych transmisja danych spełniająca wymogi użytkownika dotyczące prędkości, opóźnień oraz błędów transmisji. Dla sieci Internet zaproponowano dwie motedy zapewniania QoS: usług zróżnicowanych (DiffServ) oraz usług zintegrowanych (IntServ). Transmission Control Protocol połączeniowy, niezawodny, strumieniowy protokół komunikacyjny wykorzystywany w Internecie na poziomie warstwy transportowej. User Datagram Protocol bezpołączeniowy protokół komunikacyjny wykorzystywany w Internecie na poziomie warstwy transportowej. Nie gwarantuje dostarczenia datagramu. Jako protokół bezpołączeniowy nie wnosi narzutu na nawiązywanie połączenia i śledzenie sesji. Internet Protocol protokół komunikacyjny warstwy sieciowej (warstwy Internetu dla modelu TCP/IP).Zawiera zbiór reguł i metod postępowania, pozwalających urządzeniom nawiązać łączności i wymieniać dane w Internecie.

8 8 Słownik pojęć RTT BDP AIMD AIAD SACK FACK D-SACK Round Trip Time czas przejścia pakietu w obie strony (pakietu z danymi oraz jego potwierdzenia). Bandwidth-Delay Product iloczyn przepustowości i czasu przejścia pakietu w obie strony RTT. Wykorzystywany do oszacowania optymalnej prędkości wysyłanych danych w zależności od szacowanej przepustowości danego połączenia i aktualnych warunków (obciążenia) w sieci. Additive Increase Multiplicative Decrease przyrostowe, addytywne zwiększanie okna przeciążenia i jego wielokrotne zmniejszanie (jako reakcja na upłynięcie czasu retransmisji) stosowane w algorytmach Reno i New Reno, określane jest jako mechanizm addytywnego zwiększania i wielokrotnego zmniejszania okna przeciążenia. Additive Increase, Adaptive Decrease przyrostowe, addytywne zwiększanie okna przeciążenia i jego addytywne zmniejszanie (jako reakcja na upłynięcie czasu retransmisji) stosowane w pierwszych algorytmach sterowania przeciążeniami w sieci Internet. Selective Acknoledgement blok SACK używany jest przez odbiorcę, aby poinformować nadawcę o odebranych blokach danych, dla których nie wszystkie segmenty zostały stracone. Nadawca zna więc dokładny stan buforów odbiorcy i retransmituje tylko brakujące segmenty. Forward acknowledgements zadaniem algorytmu FACK (potwierdzenia generowane w przód) jest poprawienie sterowania przeciążeniem w fazie odzyskiwania. Mechanizm potwierdzeń generowanych w przód może być wykorzystywany tylko dla połączeń korzystających z algorytmu SACK, ponieważ dodatkowe informacje przesyłane w blokach SACK pozwalają mu na dokładne określenie liczby danych będących w drodze. Duplicated SACK algorytm D-SACK (zduplikowane potwierdzenia SACK) jest rozszerzeniem algorytmu selektywnych potwierdzeń, umożliwiający poinformowanie nadawcy o fakcie odebrania zduplikowanych segmentów. Zduplikowane potwierdzenia oznaczają najczęściej, że połączenie replikuje pakiety, gubi pakiety ACK lub przestawia kolejność pakietów. Przesłanie nadawcy tej informacji daje mu

9 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania... 9 możliwość odpowiedniej reakcji na sytuacje (zmniejszenie lub nie okna przeciążenia, lub progu powolnego startu). ECN CE AQM RED TBF FQ CBQ Explicit Congestion Notification algorytm ten jest modyfikacją działania aktywnego zarządzania kolejką RED. Różnica polega na tym, że zamiast z określonym prawdopodobieństwem gubić pakiet, mechanizm oznacza go flagą przeciążenia (CE - ang. Congestion Experience). Pakiet taki dociera do odbiorcy, a odbiorca ustawia flagę przeciążenia w pakiecie potwierdzenia wysyłanym do nadawcy. Congestion Experience flaga przeciążenia wykorzystywana przez mechanizm ECN. Active Queue Management aktywne zarządzanie pakietami. Mechanizm ten umozżliwia wcześniejsze, prewencyjne odrzucanie pakietów. Mechanizm polega na monitorowaniu stanu łącza, a co z tym się wiąże liczby pakietów w kolejce. Na tej podstawie mechanizm podejmuje decyzję o ewentualnym usunięciu nadchodzącego pakietu. Random Early Detection nazywana również: Random Early Discard lub Random Early Drop. Rodzaj algorytmu kolejkowania realizujący regułę AQM, wcześniejszego zachowawczego wyrzucania pakietów z kolejki. Token Bucket Filter modyfikacja algorytmu tzw. cieknącego wiadra (ang. leaky bucket). Mechanizmem kształtowania ruchu. Kolejka TBF jest dużym buforem (FIFO), z którego pakiety pobierane są ze stałą częstotliwością, tzn. w jednostce czasu przesyłana jest określona, zadana liczba bajtów. Pakiety przepełniające wiaderko (przekraczające maksymalny rozmiar bufora) są usuwane. Fairness Queueing algorytm sprawiedliwego kolejkowania. Celem nadrzędnym mechanizmu jest zapewnienie sprawiedliwego podziału dostępnej przepustowości między wszystkie strumienie. Dwa najbardziej znane odmiany tego algorytmu to SFQ oraz WFQ. Classful Based Queueing jeden z najbardziej elastycznych algorytmów zawartych w linuksowej implementacji kolejkowania. Elastyczność mechanizmu wynika bezpośrednio z jego klasowości (możliwości tworzenia klas wewnętrznych) i dużej konfigurowalności. Algo-

10 10 Słownik pojęć rytm ten może kształtować zarówno ruch przychodzący, jak i wychodzący. Struktura klas tworzona z wykorzystaniem CBQ ma postać odwróconego drzewa (rysunek 4.2). Na szczycie znajduje się klasa główna (ang. root). Każda z pozostałych klas może być węzłem (ang. node) lub liściem (ang. leaf). Węzły posiadają zarówno rodzica, jak i potomstwo, a liście posiadają wyłącznie rodzica. Klasy mające wspólnego rodzica określane są jako rodzeństwo (ang. siblings). Rodzeństwo domyślnie wzajemnie pożycza sobie przepustowość.

11 Rozdział 2 WSTEP Sieć Internet powstała kilkadziesiąt lat temu. W założeniach miała ona służyć celom wojskowym, do zapewniania niezawodnej komunikacji na odległość niezależnie od awarii niektórych jej składników. Przy jej projektowaniu najważniejsza była niezawodność. Na początku istnienia Internetu, przy ówczesnych prędkościach transmisji, nikt nie był w stanie przewidzieć, że kiedyś będzie możliwy przesył dźwięku, obrazu oraz innych treści multimedialnych. Konsekwencje wynikające z projektu, który cechowała niezawodność i niski koszt połączenia, okazały się barierą, w momencie kiedy sieć Internet stała się dostępna niemal w każdym domu i w każdym miejscu na kuli ziemskiej. Naukowcy opracowujący w połowie lat 70 zeszłego wieku podstawy rodziny protokołów TCP/IP nie przewidzieli, jakie wyzwania dla tych protokołów przyniosą technologie i rozwiązania powstałe kilkanaście, czy nawet kilkadziesiąt lat później. Najpoważniejszą aktualnie barierą okazał się być protokół internetowy IP (oparty na bezpołączeniowym modelu datagramowym). Model ten nie jest dobrym rozwiązaniem, kiedy przesyłamy dane wrażliwe na przepustowość, opóźnienie czy też gubienie pakietów. Rozwiązaniem jest tutaj zwiększanie przepustowości łączy internetowych lub stosowanie sieci typu połączeniowego (np. ATM, MPLS). Te rozwiązania niestety wiążą się z wielkim nakładem finansowym i są trudne w realizacji, ponieważ wymagałyby globalnych zmian w sieci. W obliczu wymogu dostosowania sieci do dzisiejszych potrzeb jej użytkowników stworzono wiele mechanizmów sieciowych, których zadaniem jest zapewnienie możliwie najlepszych parametrów połączeń w sieci. Wraz z upływem lat liczba użytkowników Internetu szybko wzrastała, co zaowocowało szybkim wzrostem natężenia ruchu i zaczęło powodować częste zatory na wielu trasach z powodu braku wystarczających zasobów. Z braku możliwości łatwego i taniego zwiększania zasobów wprowadzono mechanizmy zarządzania zasobami sieciowymi. Najważniejsze elementy zarządzania strumieniami ruchu sieciowego to: zarządzanie pakietami nadchodzącymi do węzła transmisyjnego, zarządzanie odrzucaniem pakietów w kolejce oraz zarządzane prędkością wysyłania pakietów przez nadajnik na poziomie protokołu transportowego.

12 12 Wstęp W miejsce standardowego podejścia do obsługi różnych strumieni według reguły best efford (kolejka FIFO), zaczęto wprowadzać algorytmy kolejkowania, umożliwiające podział łącza między równolegle odbywające się transmisje. Algorytmy te szeregują pakiety i wysyłają, zachowując pewną dyscyplinę kolejkowania (np. algorytmy WFQ, WRR, DRR, CBQ i inne). Prócz algorytmów kolejkowania należało poradzić sobie z pojawiającymi się przeciążeniami, które objawiały się brakiem miejsca w buforach wyjściowych routerów, co w konsekwencji doprowadzało do odrzucania (gubienia) pakietów, a w następstwie retransmisji danych. Tradycyjne podejście zakładało odrzucanie nadchodzących pakietów z kolejki dopiero po przepełnieniu bufora. Wprowadzenie mechanizmów aktywnego zarządzania wprowadziło nowy sposób podejścia do tego zagadnienia. Zgodnie z regułami AQM możliwe jest wcześniejsze, prewencyjne odrzucanie pakietów. Mechanizm polega na monitorowaniu stanu łącza, a co z tym się wiąże ilości danych w kolejce. Na tej podstawie podejmuje się decyzję o ewentualnym usunięciu nadchodzącego pakietu. Dodatkowo mechanizmy AQM wykorzystują pewne cechy protokołu TCP (mechanizm okna przeciążeniowego). Sposób działania jest prosty, a przez to bardzo skuteczny. Ponieważ wielkość okna przeciążenia zależna jest od ilości uzyskanych zwrotnych potwierdzeń, rośnie ona aż do momentu, gdy pewna porcja danych nie zostanie zaakceptowana. Mechanizm aktywnego zarządzania wykorzystuje tę własność. Odrzucenie z pewnym prawdopodobieństwem nadchodzącego pakietu jest jednocześnie informacją dla nadawcy sugerującą zmniejszenie prędkości nadawania. Prawdopodobieństwo odrzucenia pakietu rośnie wraz z zapełnieniem bufora. Na poziomie warstwy transportowej modelu warstwowego sieci Internet istnieją dwa protokoły - UDP i TCP. Jednak to protokół TCP, nieporównywalnie bardziej złożony niż UDP, wyposażony m. in. w mechanizmy sterowania przepływem danych i pewnego dostarczania przesyłki do adresata, stanowi większość internetowego ruchu. W protokół ten zostały właśnie wbudowane mechanizmy sterowania przepływem pakietów pozwalających na unikanie przeciążeń w sieci. Wraz z rozwojem Internetu mechanizmy te rozbudowywano o kolejne, coraz sprawniej przesyłające dane mechanizmy. Mechanizmów takich, dostosowanych do różnorodnych warunków sieciowych, jest kilkadziesiąt, z czego kilkanaście znalazło już swoje stałe miejsce w systemach operacyjnych komputerów. Sterowanie prędkością generowania pakietów, działającego równie skutecznie w każdych dostępnych warunkach, nie jest zadaniem trywialnym. Taka cecha protokołu transportowego jest niezwykle istotna w dobie heterogenicznych sieci składających się z różnorakich mediów transmisyjnych.

13 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Niniejsza książka jest próbą oceny wyżej wymienionych mechanizmów oraz ich wpływu na sprawność transmisji danych w globalnej sieci. W następnych rozdziałach książki zostaną pokazane badania wyżej wymienionych mechanizmów. Zostanie również pokazana współpraca protokołów sterowania obciążeniem sieci oraz algorytmów aktywnego zarządzania pakietami w węzłach sieciowych. Książka przeznaczona jest dla inżynierów i studentów kierunków informatyka i pokrewnych oraz szerokiej rzeszy użytkowników komputerów, dla których interesująca jest problematyka efektywności transmisji w sieci Internet. W rozdziale 3 przedstawiono aktualny stan implementacji algorytmów sterowania przeciążeniami w sieci oraz przedstawiono mechanizmy protokołu TCP, mające wpływ na efektywność transmisji. W rozdziale 4 zaprezentowano mechanizmy kolejkowania oraz aktywnego zarządzania pakietami w węźle transmisyjnym. Rozdział 5 pokazuje zachowanie mechanizmów sterowania przeciążeniem w różnych, symulowanych warunkach sieciowych. W celu monitorowania zachowania tych mechanizmów (algorytmów) stworzono specjalną modyfikację jądra systemu Linux. Na podstawie tych modyfikacji zestawiono środowisko badawcze oraz przygotowano zestaw eksperymentów. W obliczu wymogu dostosowania sieci do dzisiejszych potrzeb jej użytkowników powstało wiele mechanizmów sieciowych, których zadaniem jest zapewnienie możliwie najlepszych parametrów połączeń kosztem tych połączeń, które takich parametrów nie potrzebują. Z tymi parametrami wiąże się pojęcie jakości usług. Ocenę tych mechanizmów na podstawie badań rozwiązań zaimplementowanych w systemie Linux przedstawiono w rozdziale 6. W rozdziale 7 przedstawiono oraz dokonano oceny mechanizmów aktywnego zarządzania pakietami w routerze. Ocenę tych mechanizmów zrealizowano na dwa sposoby: przez analizę zachowania routera w rzeczywistej sieci oraz przeprowadzając badania symulacyjne. Na potrzebę tych pierwszych wykorzystano rzeczywisty router sieciowy zrealizowany na komputerze z systemem Linux. Ponieważ w systemie zaimplementowano jedynie najprostszy mechanizm AQM: RED, realizacja badań wymagała zaimplementowania dodatkowych mechanizmów aktywnego zarządzania pakietami w systemie. Badania symulacyjne zrealizowano opierając się na języku Python i module tego języka SimPy. W rozdziale 8 przedstawiono ocenę dynamiki protokołu TCP na podstawie modelu Fluid Flow. Model ten ignoruje wpływ zależności czasowych protokołu TCP, ale pozwala na uzyskanie średnich wartości kluczowych zmiennych sieciowych. W rozdziale pokazano wpływ mechanizmów AQM na sterowanie oknem przeciążeniowym mechanizmów protokołu TCP. Rozdział 9 zawiera podsumowanie eksperymentów i uzyskanych rezultatów.

14 Rozdział 3 ALGORYTMY STEROWANIA PRZECIAŻENIEM Protokół TCP rozwijany od 1974 roku przez kilka dekad uległ wielu zmianom. Modyfikacje protokołu TCP najczęściej powodowane były pojawiającymi się problemami w transmisji informacji. Jednym z kierunków rozwoju protokołu TCP były modyfikacje związane ze sterowaniem przeciążeniami w sieci. Implementacja tych rozwiązań powoduje ograniczanie prędkości nadawania nadajników TCP w celu dostosowania prędkości transmisji do istniejących warunków sieciowych. Ten rozdział w większości skupia się na przedstawieniu tych mechanizmów oraz ocenie, jak mogą one wpłynąć na efektywność transmisji danych w sieci Internet Protokół TCP a standardy sieciowe Standaryzacją protokołów oraz różnego rodzaju mechanizmów internetowych zajmuje się organizacja IETF (ang. Internet Engineering Task Force). Wszystkie wyłaniające się nowe standardy na początku są publikowane w plikach RFC (ang. Request For Comment) jako propozycje standardu. Po dyskusji i ewentualnej aprobacie propozycje stają się standardami. Kolejne modyfikacje już powstałych rozwiązań pojawiają się jako kolejne pliki RFC. Spośród kilku tysięcy dokumentów RFC, kilkadziesiąt z nich dotyczy protokołu TCP i związanych z nim algorytmów. Część z tych publikacji to tylko propozycje, które nigdy nie wyjdą poza fazę eksperymentalnych implementacji. Niektóre mają charakter informacyjny, konkretyzujący implementację jakiegoś rozwiązania. Jeszcze inne są rozważaniami na temat koniecznych modyfikacji w celu zapewnienia większej wydajności protokołu TCP w specyficznych warunkach sieciowych (łącza radiowe, satelitarne czy kanały transmisyjne o dużych opóźnieniach). Początki TCP/IP sięgają roku 1974, w którym to w pracy zatytułowanej A Protocol for Packet Networking Interconnection dr Vinton G. Cerf i dr Robert Kahn ujęli kilka elementów projektowych TCP [2]. Zaś pierwsza specyfikacja RFC, powstała w tym samym roku, zawarta jest w dokumencie o numerze 675 [3]. Następnie pojawiało się jeszcze kilka kolejnych edycji rozszerzających i poprawiających specyfikacje. Zostały one podsumowane w RFC 793 [1], który

15 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania to jest uznawany za dokument definiujący podstawy działania TCP. Podstawy te mimo wielu modyfikacji protokołu TCP nie ulegały większym zmianom. Kolejne zmiany w protokole polegały raczej na dołożeniu pewnych kolejnych mechanizmów niż na całkowitej rekonstrukcji standardu. Tabela 3.1 przedstawia pliki RFC opisujące najpopularniejsze mechanizmy protokołu TCP. Opis tych mechanizmów zostanie przedstawiony w dalszej części niniejszego rozdziału. Tabela 3.1. Dokumenty RFC opisujące protokół TCP RFC 793, 1122 Podstawy TCP 1323 Rozszerzenia zwiększające wydajność TCP 1072, 2018 Potwierdzenia selektywne (SACK) 2140 Ctrl block sharing 2001, 2581 Procedury sterowania przeciążeniami 2582, 3782 TCP New Reno 2861 Walidacja okna przeciążeniowego 2883 D-SACK 2988 Obliczanie czasu retransmisji (RTO) 3042 Ograniczone przesyłanie 2481, 3168 ECN Zwiększenie rozmiaru okna początkowego 2488 TCP w łączach satelitarnych 2525 Znane problemy implementacyjne TCP 2757 TCP w sieciach WAN o niskiej przepustowości 2884 Wydajność ECN 3.2. Model warstwowy TCP/IP Model TCP/IP składa się, w odróżnieniu od siedmiowarstwowego ISO/OSI, z czterech warstw i został opracowany pod koniec lat 70. Jego poszczególne warstwy można scharakteryzować następująco: warstwa łącza danych: zadaniem tej warstwy jest przesył pakietów IP poprzez kanał komunikacyjny. Główne problemy rozwiązywane w tej war-

16 16 Algorytmy sterowania przeciążeniem stwie to dostosowanie pakietu do właściwości warstwy liniowej (struktura ramki czy adresacja), warstwa Internetu: zadaniem tej warstwy, w której skład wchodzi protokół IP (a wraz z nim ICMP i IGMP), jest przekazywanie pakietów między nadawcą i odbiorcą, uwzględniając wyznaczanie trasy pakietu między węzłami, warstwa transportowa: podobnie jak w modelu ISO/OSI, warstwa ta zapewnia kanał komunikacyjny między końcowymi węzłami wymiany danych. W ramach niej zdefiniowane są dwa protokoły transportowe - TCP (niezawodny, gwarantujący bezbłędne dostarczenie strumienia danych, zorientowany na połączenie) i UDP (zawodny, bez gwarancji dostarczenia pakietu - datagramu, niezorientowany na połączenie), warstwa aplikacji: zawiera w sobie konkretne usługi internetowe: HTTP, DNS, FTP, Telnet, SSH itd. Rys Nagłówek TCP [1] Fig TCP Header [1] Głównym zadaniem protokołu TCP jest zapewnieniu niezawodności transmisji. Bezbłędność transmisji uzyskuje się wykorzystując numery sekwencyjne do zliczania wysyłanych pakietów i stosowania mechanizmu pozytywnych potwierdzeń

17 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania w celu wykrycia zagubienia lub duplikowania pakietu. Na rysunku 3.1 przedstawiono format nagłówka segmentu protokołu TCP. Za numerację segmentów oraz numerację potwierdzeń odpowiadają dwa kolejne pola tego nagłówka: sequence number oraz acknowledgment number. Mechanizm pozytywnych potwierdzeń jest wykorzystywany również do dostosowania prędkości nadajnika i możliwości przesyłowej sieci. W celu optymalizacji prędkości nadajnika stosuje się mechanizmy okien, tzw okna odbiornika i okna przeciążeniowego. Pierwsze okno ma na celu dostosować prędkość przesyłu do możliwości odbiornika, a drugie do możliwości sieci. Mechanizmy te zostaną opisane szczegółowo w sekcji 3.4. Prędkość nadawania TCP jest silnie uzależnione od pewnych założonych czasów czekania nadajnika. Najważniejszy z nich to czas czekania nadajnika na potwierdzenie. Od niego zależą fluktuacje w wysyłaniu pakietów. Ten oraz inne istniejące zegary TCP opisuje rozdział następny Zegary TCP Podczas przesyłu danych protokół TCP wykorzystuje kilka zegarów: stoper retransmisji (ang. retransmission timer), stoper uporczywy (ang. persistence timer), stoper żywotności (ang. keepalive timer), stoper spokoju po zakończeniu połączenia. Ich zadaniem jest pilnowanie ograniczeń czasowych dla różnych zdarzeń związanych z transmisją danych. Stoper retransmisji odpowiada za ograniczanie czasu oczekiwania na potwierdzenie wysyłanych danych. W sytuacji gdy potwierdzenie nie nadejdzie w wyznaczonym czasie, uruchamiana jest procedura retransmisji pakietu, który uznaje się za zgubiony. Czas oczekiwania na potwierdzenie zmienia się w trakcie pracy protokołu i jest zależny od warunków panujących w sieci oraz parametrów konkretnego połączenia. Wyznaczany jest on na podstawie czasu przejścia pakietu w obie strony (RTT). Stoper uporczywy wykorzystywany jest do uniknięcia sytuacji zawieszenia transmisji. Sytuacja taka może wystąpić w sytuacji, gdy odbiorca prześle do nadajnika informację o całkowitym zapełnieniu bufora odbiorczego (okno odbiorcze równe zero) i stracie pakietu informującego o zwolnieniu się u odbiorcy miejsca

18 18 Algorytmy sterowania przeciążeniem w buforze (okno odbiorcze > 0). W takiej sytuacji nadawca oczekuje na zwolnienie bufora odbiorczego po stronie odbiorcy, podczas gdy odbiorca oczekuje na kolejne dane od nadawcy, nieświadomy straty pakietu z informacją o możliwości przejęcia nowych danych. Zadaniem stopera uporczywego jest odliczanie po stronie nadawcy czasu, po którym uruchamiana jest procedura wymuszenia przez nadawcę uzyskania informacji o rozmiarze okna poprzez wysłanie jednobajtowego segmentu TCP. Odbiorca w przypadku dalszej niemożności przyjmowania danych sygnalizuje ten fakt ogłoszeniem okna o zerowym rozmiarze lub wysyła zgłoszenie niezerowego rozmiaru okna odbiorczego. Stoper żywotności zaczyna odliczanie po każdorazowym skończeniu danego etapu transmisji lub przesłaniu wszystkich danych. Jeżeli w trakcie połączenia nie następuje wymiana żadnych pakietów przez określony czas (domyślnie 7200 sekund), to stoper sygnalizuje możliwość zerwania połączenia. TCP wysyła wtedy pakiety sondujące drugą maszynę. Jeśli potwierdzenie tych pakietów nie nadejdzie w określonym czasie (domyślnie 75 sekund), wysyłana jest pewna liczba (domyślnie 9-10) kolejnych pakietów sondujących w stałych odstępach (75 sekund). Gdy sondowanie zostaje bez odpowiedzi lub też odpowiedzią jest pakiet resetujący połączenie (gdy jedna z maszyn została ponownie uruchomiona), sondująca maszyna uznaje to połączenie za zerwane. Stoper spokoju po zakończeniu połaczenia zapewnia odstęp pomiędzy pakietami dopływającymi do zakończonego połączenia a pakietami zwiastującymi nowe połączenie. Określa on czas, przez jaki nie można wykorzystać portu, który właśnie był używany (przez zakończone właśnie połączenie) Sterowanie przepływem oraz przeciażeniami Protokół TCP steruje liczbą wprowadzanych do sieci danych tak, by zapobiec przepełnieniu bufora po stronie odbiorczej (okno odbiornika) oraz buforów węzłów pośredniczących (okno przeciążenia). W fazie nawiązywania połączenia odbiorca przydziela bufor o pewnym rozmiarze, do którego kopiowane są dane odebrane przez kartę sieciową. Działająca asynchronicznie aplikacja sięga następnie do tego samego bufora, by odczytać dane otrzymane od nadawcy. W komunikacji uczestniczą komputery o różnych parametrach, może zatem dojść do sytuacji, gdy aplikacja działająca po stronie odbiornika nie nadąży z opróżnianiem bufora, do którego trafiają dane od szybkiego nadawcy. Aby zapobiec takim przypadkom, protokół TCP wykorzystuje mechanizm tzw. okna odbiornika. Okno odbiornika

19 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania definiuje liczbę bajtów, jaką może wysłać nadajnik bez uzyskania potwierdzenia od odbiornika (ang. Receiver Window). Po wysłaniu określonej przez okno liczby segmentów nadajnik wstrzymuje transmisję. Okno odbiornika ustalane jest przez odbiornik na podstawie aktualnie dostępnego miejsca w buforze odbiorczym i przesyłane do nadajnika w pakietach potwierdzeń (ACK). Gdy ogłoszony przez odbiorcę rozmiar jest na tyle mały, że nadawca nie może wysłać przynajmniej jednego segmentu TCP, transmisja jest wstrzymywana do czasu zwolnienia bufora odbiorczego przez aplikację i poinformowania o tym fakcie nadawcy odpowiednim segmentem ACK. Nadawca musi dbać o to, aby ilość wysłanych i niepotwierdzonych jeszcze danych nie przepełniła bufora odbiorcy, którego rozmiar ogłasza on w kolejnych pakietach ACK. Rozmiar bufora odbiorcy przechowywany jest po stronie nadawcy w zmiennej rcv_wnd. Kolejne zmienne (snd.una i snd.nxt) wykorzystywane są do przechowywania informacji o ilości danych wysłanych i jeszcze niepotwierdzonych. Zmienna snd.una to pierwszy numer sekwencyjny bajtów wysłanych, lecz jeszcze niepotwierdzonych (lewa strona okna). snd.nxt to numer sekwencyjny bajtów, które mogą być wysłane (prawa strona okna). Przy odbieraniu kolejnych potwierdzeń lewa strona okna przesuwa się, a przy wysyłaniu nowych danych przesuwana jest prawa strona. Różnica tych dwóch zmiennych to właśnie okno, które ze względu na przesuwanie się jego granic nazywamy oknem przesuwnym. Koncepcję przesuwnego okna przedstawia rysunek Bajty potwierdzone Bajty niepotwierdzone Bajty, które mogą być wysłane Bajty, które nie mogą być wysłane Snd.una Lewa strona przesuwnego okna Snd.nxt Prawa strona przesuwnego okna Rys Mechanizm przesuwnego okna [1] Fig Sliding window mechanism [1] Opisany powyżej mechanizm sterowania przepływem zapobiega utracie danych związanych z przepełnieniem bufora odbiorczego po stronie odbiorcy. Ogra-

20 20 Algorytmy sterowania przeciążeniem niczanie zapełnienia buforów w routerach pośredniczących odbywa się poprzez mechanizm okna przeciążenia (ang. Congestion Window). Nadawca nie dostaje tutaj bezpośredniej informacji o stanie buforów urządzeń pośredniczących. Przepełnienie tychże jest wnioskowane na podstawie potwierdzeń przychodzących od strony odbiornika. Dla mechanizmu sterowania obciążeniem sieci wprowadzona została zmienna snd_cwnd. Jej wartość odwzorowuje ograniczenie na rozmiar buforów urządzeń pośredniczących i sterowana jest przez szereg algorytmów zapobiegania przeciążeniom opisanych w rozdziale 7. Zadaniem protokołów sterowania przeciążeniem jest najlepsze (z punktu widzenia wydajności transmisji) dobranie tej wartości. Nadajnik może wysłać jednorazowo w sieć taką liczbę danych, aby liczba niepotwierdzonych danych nie przekroczyła wartości wyznaczonej przez mniejszą z dwóch okien (okna odbiorcy i okna przeciążenia) Wydajność TCP Jednym z czynników wpływających na wydajność protokołu TCP jest algorytm sterowania przeciążeniami. Jego zadaniem jest dobranie prędkości wysyłanych danych do szacowanej przepustowości danego połączenia i aktualnych warunków (obciążenia) w sieci. Wydajność TCP zależy od przepustowości połączenia oraz opóźnień na danej ścieżce. Parametr łączący te dwie wartości nazwano BDP (ang. Bandwidth-Delay Product). Parametr ten jest iloczynem przepustowości i czasu przejścia pakietu w obie strony (RTT - Round Trip Time) i określa, ile danych potrzeba, aby całkowicie wykorzystać dostępną przepustowość kanału transmisyjnego. Wpływa on na wymagania co do wielkości bufora nadawcy (ile danych trzeba zbuforować, zanim nadejdzie potwierdzenie) i odbiorcy (ile danych bez wysyłania potwierdzenia można otrzymać). BDP definiowany jest jako [4]: BDP [bit] = B[ bit ] RT T [s] (3.1) s gdzie: BDP produkt przepustowości i opóźnienia dla danego łącza (Bandwidth Delay Product), B maksymalna przepustowość łącza, RT T czas przejścia pakietu w obie strony (Round Trip Time). Dla połączenia Ethernet 10Mbps, czas RT T wynosi ok. 500µs. BDP dla takiego połączenia wynosi 5000 bitów, co daje 625 bajtów. BDP dla Ethernetu

21 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Gpbs wynosi ok bajtów. Dla szerokopasmowych łączy satelitarnych oraz światłowodowych linii optycznych wartość ta przekracza 1 Mbit (ponad 125 kb). Dla międzykontynentalnego połączenia WAN o przepustowości 2.5 Gbit/s sięga 60 MB Algorytmy sterowania przeciażeniami w TCP W rozdziale tym czas opisać niektóre odmiany algorytmów TCP. Większość powstałych modyfikacji miała na celu poprawienie efektywności transmisji. Ze względu na mnogość rozwiązań przedstawione zostaną te modyfikacja protokołu TCP, które zostały zaimplementowane w jądrze Linuksa. W rozdziale 5.1 zostaną przedstawione badania tych mechanizmów z wykorzystaniem implementacji protokołu TCP dla tego systemu operacyjnego. Implementacja stosu TCP/IP w Linuksie jest bardzo elastyczna. Prawie wszystkie jego parametry mogą być ustawiane w trakcie pracy systemu i nie wymagają rekompilacji jądra czy restartu systemu. Każda sesja TCP może być sterowana inną odmianą algorytmu TCP. Włączanie algorytmów odbywa się poprzez interfejs jądra sysctl lub poprzez wirtualny system plików proc Algorytm Reno Pojawienie się protokółu TCP pozwoliło na szybki rozwój Internetu. Jednakże brak algorytmów zapobiegania przeciążeniom w jego początkowych implementacjach, doprowadził w 1986 roku do kompletnej blokady sieci [5]. W odpowiedzi na tę sytuację Van Jacobson w roku 1988 opracował główne zasady sterowania przeciążeniem w TCP, a pierwsza praktyczna implementacja tych zasad została nazwana TCP Tahoe. Od tego czasu opracowano wiele innych rozwiązań problemu unikania przeciążenia w sieciach pracujących z protokołem TCP. Najpopularniejszym z nich jest algorytm TCP Reno. Protokół ten jest udoskonaleniem mechanizmów zaimplementowanych w TCP Tahoe. Dodatkowo wprowadzono do niego mechanizm szybkiego odtwarzania utraconych pakietów (Fast Recovery).

22 22 Algorytmy sterowania przeciążeniem Algorytm Reno składa się zatem z następujących mechanizmów (opisanych w [6]): powolny start (Slow Start), unikanie przeciążenia (Congestion Avoidance), szybka retransmisja (Fast Retransmit), szybkie odtwarzanie (Fast Recovery). Powolny start i unikanie przeciażenia Zadaniem powyższych algorytmów jest sterowanie liczbą danych wprowadzanych do sieci. Mechanizm ten opiera się na kontroli danych będących w drodze pomiędzy nadawcą i odbiorcą. Ograniczanie liczby danych wysyłanych przez nadajnik opiera się na mechanizmie dwóch okien: CWND (ang. Congestion Window) okno przeciążenia, RWND (ang. Receiver s advertised window) okno odbiorcy. Górnym limitem liczby danych przesyłanych od nadawcy do odbiorcy jest okno o aktualnie mniejszej wartości (min(cw N D, RW N D)). Okno przeciążenia (CWND) jest swoistym ograniczeniem, które narzuca sobie sam nadajnik. Uniemożliwia ono nadawcy wprowadzać pakiety do sieci przed potwierdzeniem (ACK) danych już wysłanych. Okno odbiornika (RWND) opisuje możliwość odbiorcy do przyjmowania nowych danych (zależy ona od zajętości buforów po stronie odbiornika). Nowe pakiety mogą zostać wysłane tylko wtedy, gdy szacowana liczba danych w drodze jest mniejsza od minimum z dwóch powyższych zmiennych. Algorytm powolnego startu stosowany jest w fazie początkowej połączenia TCP. Zakładamy, że następuje wtedy transmisja danych przez nieznaną sieć. Na początku wartość CW ND = 1 i przy założeniu, że jednostką CWND jest liczba segmentów, pozwala to na wysłanie w sieć jednego segmentu. Następnie mechanizm oczekuje na jego potwierdzenie. Oryginalna specyfikacja mówi, że początkowa wartość CWND nie może być większa niż 2 segmenty i choć proponowano zwiększenie tej wartości [7], to stos TCP/IP w Linuksie ustawia tę wartość tak, jak mówi ogólna specyfikacja. Zakłada się, że podczas fazy powolnego startu wartość CWND zwiększana

23 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania jest o jeden wraz z każdym odebranym potwierdzeniem ACK. W praktyce więc wzrost ten w stosunku do RTT ma charakter wykładniczy. Taki wzrost okna przeciążenia szybko spowodowałby przeciążenie w sieci. Dlatego też wzrost wykładniczy kończy się wraz z przekroczeniem progu powolnego startu - sstresh. Zmienna ta ustawiana jest, w momentach wykrycia przeciążenia (czyli straty pakietu lub upłynięcia czasu retransmisji), na wartość równą połowie aktualnej wartości CWND, lecz nie mniejszą niż dwa segmenty TCP [8]: ssthresh = max( F lightsize, 2 MSS) (3.2) 2 gdzie: ssthresh próg powolnego startu, F lightsize liczba danych wysłanych, ale jeszcze niepotwierdzonych, MSS maksymalny rozmiar segmentu TCP. Po przekroczeniu progu powolnego startu mechanizm przechodzi w fazę unikania przeciążenia. Dokument RFC [8] pozostawia wybór dla przypadku, gdy CW N D = ssthresh. W implementacji Linuksowej (jądro ) w sytuacji tej wybierany jest algorytm powolnego startu. Algorytm unikania przeciążeń wykazuje liniowy wzrost (w stosunku do RTT) wartości CWND. W tym algorytmie 1 wartość CWND zwiększana jest o wartość dla każdego odebranego potwierdzenia. Ilustracja tego mechanizmu została przedstawiona na rysunku CW ND 3.3. Szybka retransmisja Algorytm ten korzysta z mechanizmu zduplikowanego potwierdzenia. Odbiorca wysyła do nadajnika zduplikowane ACK (potwierdzające ostatnio poprawnie odebraną sekwencję) dla każdego odebranego segmentu, jeżeli jego numer sekwencji był inny niż spodziewany. Otrzymanie pakietu z zaburzonym numerem sekwencji oznacza zaistnienie jednej z trzech możliwych sytuacji [8]: strata pakietu w sieci, zmiana kolejności przesyłanych pakietów, zreplikowanie pakietu w jednym z routerów. Na potrzeby mechanizmu szybkiej retransmisji założono, że nadawca retransmituje pakiet po otrzymaniu trzech zduplikowanych potwierdzeń. W standardowej

24 24 Algorytmy sterowania przeciążeniem Rys Algorytmy powolnego startu i unikania przeciążeń [9] Fig Slow start and congestion avoidance algorithms [9] sytuacji nadajnik zaczyna retransmisję po zakończeniu odliczania przez zegar retransmisji. Mechanizm wcześniejszego rozpoczęcia retransmisji skutkuje zwiększeniem efektywności transmisji TCP przy pojedynczych stratach. W sytuacji wielokrotnych strat retransmisja zacznie się po zakończeniu odliczania. W algorytmie Tahoe rozpoczęcie szybkiej retransmisji powodowało zmniejszenie o połowę progu ssthresh i ustawienie okna CWND na wartość dwóch segmentów. W przypadku algorytmu Reno przechodzi on w fazę szybkiego odtwarzania. Szybkie odtwarzanie Algorytm szybkiego odtwarzania przejmuje kontrolę nad przesyłem danych po fazie szybkiej retransmisji (ponowne przesłanie segmentu uznanego za zagubiony). Algorytm zakłada (na podstawie przychodzących potwierdzeń), że przesył danych nie został wstrzymany i można nadal transmitować dane, tyle że z mniejszym natężeniem. Wraz z odebraniem trzeciego zduplikowanego ACK mecha-

25 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania nizm zmniejsza o połowę próg powolnego startu (TCP Tahoe). Natomiast okno przeciążenia ustawiane jest na ssthresh (po zmniejszeniu) i zwiększane o trzy segmenty (co odzwierciedla trzy odebrane zduplikowane potwierdzenia). Jednocześnie algorytm nie przechodzi w fazę powolnego startu. Obniżenie CWND powoduje, że liczba pakietów w drodze jest większa od zmniejszonego właśnie okna przeciążenia. Aby umożliwić wysyłanie kolejnych pakietów i utrzymać natężenie ruchu na pewnym poziomie, zakłada się, że każde kolejne zduplikowane potwierdzenie (które z punktu widzenia nadawcy informuje o dojściu kolejnego pakietu do odbiorcy) zwiększa wartość CWND o jeden. Algorytm szybkiego odtwarzania kończy się w momencie odebrania skumulowanego ACK potwierdzającego całe retransmitowane dane (łącznie z tymi, które powodowały generowanie zduplikowanych potwierdzeń). Wtedy oknu przeciążenia (którego wartość była sztucznie zawyżana dla utrzymania przepływu) przywracana jest wartość ssthresh i dalsza transmisja sterowana jest algorytmem unikania przeciążenia. Fazę szybkiego odtwarzania kończy również otrzymanie potwierdzenia (ACK), którego numer sekwencyjny mniejszy jest niż największy wysłany przed fazą szybkiej retransmisji. Sytuacja ta oznacza kolejną stratę w bieżącym oknie. Nadajnik przechodzi wtedy w fazę oczekiwania na zakończenie odliczania przez zegar retransmisji Algorytm New Reno Algorytm Reno nie radził sobie dobrze z problemem wielokrotnych strat. W każdej fazie szybkiej retransmisji i następującej po niej fazie szybkiego odzyskiwania retransmitowany jest tylko jeden najwcześniej stracony pakiet. Wielokrotne straty zmniejszają okno przeciążenia tak bardzo, że liczba zduplikowanych potwierdzeń wysyłanych przez odbiorcę jest niewystarczająca do podtrzymania przesyłu danych. W rezultacie konieczne staje się oczekiwanie na zdarzenie upłynięcia czasu zegara retransmisji i wstrzymanie transmisji do tego czasu. W algorytmie NewReno poprawiony został mechanizm szybkiego odzyskiwania [10]. Po retransmisji utraconego pakietu i odebraniu częściowego potwierdzenia (sytuacja ta oznacza kolejny stracony segment w bieżącym oknie) algorytm ten nie jest przerywany, lecz kontynuuje odzyskiwanie, retransmitując kolejny segment uznany za utracony. Jednocześnie przy pierwszym częściowym ACK zerowany jest zegar retransmisji i zmniejszana jest wartość okna przeciążenia o liczbę danych właśnie potwierdzonych (plus jeden segment dla kontynuowania nadawania). Takie podejście powoduje skończenie fazy szybkiej transmisji z liczbą pakie-

26 26 Algorytmy sterowania przeciążeniem tów w drodze mniej więcej na poziomie ssthresh. Algorytm kończy się, gdy potwierdzony zostanie segment o najwyższym numerze sekwencyjnym, który został wysłany, zanim mechanizm wszedł w fazę szybkiej retransmisji lub gdy upłynie czas zegara retransmisji. Przyrostowe, addytywne zwiększanie okna przeciążenia i jego wielokrotne zmniejszanie (jako reakcja na upłynięcie czasu retransmisji) stosowane w algorytmach Reno i New Reno określane jest jako mechanizm addytywnego zwiększania i wielokrotnego zmniejszania okna przeciążenia (ang. AIMD -Additive Increase Multiplicative Decrease) Skalowanie okna Pole na rozmiar okna odbiorczego (czyli ilości pozostałego miejsca w buforach odbiorczych) w nagłówku TCP zajmuje 16 bitów. Największe możliwe okno ma więc rozmiar 2 16, czyli 65 kb (kilobajtów). Jak wynika z szacunków rozmiaru bufora dla łączy o dużym BDP (patrz rozdział 3.5), tak mała wartość możliwego do ogłoszenia rozmiaru bufora odbiorczego jest wąskim gardłem dla takich połączeń. W [4] zaproponowano mechanizm nazwany skalowaniem okna (ang. Window Scaling). Ze względu na zapewnienie kompatybilności z poprzednią implementacją TCP rozmiar okna nadal przechowywany jest w 16-bitowym polu. Jednakże, gdy tylko pozwalają na to obie strony połączenia, rozmiar okna jest skalowany za pomocą wartości przenoszonej w dodatkowym polu (leżącym w części opcjonalnej segmentu) Skala Okna (ang. Window Scale). Pole to ma rozmiar trzech bajtów. Pierwszy bajt to rodzaj opcji (tu Skala Okna), drugi długość pola opcji, a trzeci (nazwany Shif t.cnt) jest wartością, o jaką okno ma być przeskalowane. Przeskalowanie odbywa się poprzez binarne przesunięcie w lewo o liczbę bitów wskazaną przez Shif t.cnt. Opcja skalowania okna może być wysłana tylko w fazie nawiązywania połączenia TCP (dla segmentów z ustawioną flagą SYN lub SYN+ACK). Segment SYN+ACK może zawierać opcję skalowania okna tylko wtedy, gdy maszyna inicjująca połączenie segmentem z ustawioną flagą SYN również zawiera tę opcję. W przeciwnym przypadku opcja ta jest ignorowana. Przekroczenie przez Shif t.cnt maksymalnej dozwolonej wartości (wynoszącej 14) jest traktowane jako błąd, a do obliczeń stosuje się wartość 14. Opcja Skalowania Okna umożliwia rozgłaszanie okna o rozmiarze 2 30 bitów. Maksymalna wartość wynika nie tyle z mechanizmu skalowania okna co innych ograniczeń wymaganych do poprawnego działania algorytmu TCP.

27 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Znaczniki czasowe TCP Znaczniki czasowe TCP (ang. TCP Timestamps) [4] również umiejscowione są w części opcjonalnej segmentu TCP. Opcja ta zawiera dwa 4-bajtowe znaczniki: czas wysłania pakietu i czas odpowiedzi (potwierdzenia) pakietu. Pole T Sval (ang. Timestamp Value) wypełniane jest bieżącą wartością czasu przez nadawcę podczas wysyłania pakietu. Wartość ta jest umieszczana przez odbiorcę w segmencie potwierdzającym (ACK) w polu T Secr. Nadajnik odczytuje pole T Secr (ang. Timestamp Echo Reply), o ile odebrany segment jest potwierdzający (z ustawioną flagą ACK) i odejmuje się ją od bieżącego czasu, otrzymując dokładny pomiar wartości RTT dla wysłanego wcześniej pakietu. Tak uzyskana wartość może zostać wykorzystana do ustawiania stopera retransmisji lub do zabezpieczenia przed skutkami zawinięcia się numeru sekwencyjnego w ramach jednego połączenia (mechanizm PAWS (ang. Protect Against Wrapped Sequence Numbers)). Dla prędkości Internetu (ARPANETU) z początku jego istnienia, na poziomie 56 kbps, czy nawet dla Ethernetu 10 Mbps, zawinięcie numeru seryjnego nie było problemem, gdyż czas ciągłej transmisji z pełną prędkością, po którym następuje zawinięcie, wynosi odpowiednio ok. 3.6 dnia i ok. 30 minut. Jednak dla przepustowości rzędu 100 Mbps czy 1 Gbps ten czas to odpowiednio 170 s i 17 s. Czasy te niestety są już porównywalne z maksymalnym czasem życia segmentu wynoszącym 120 sekund [1]. Zawinięcie się licznika skutkuje błędnym działaniem mechanizmu potwierdzania segmentów. Odbiornik nie jest w stanie rozróżnić starych, opóźnionych segmentów (z numerem sekwencyjnym z poprzedniego obiegu licznika) i segmentów nowych (z takim samym numerem sekwencji, lecz z kolejnego obiegu licznika). Wykorzystanie pola znacznika czasowego T Sval w mechanizmie PAWS pozwala wykryć segmenty ze znacznikiem starszym niż odebrany ostatnio w tym połączeniu, uznać takie za błędne i odrzucić Potwierdzenia selektywne Typowe implementacje TCP ze skumulowanymi potwierdzeniami wykazują słabą wydajność w przypadku występowania wielokrotnych strat w ramach jednego segmentu. Wszystkie poprzednio przedstawione mechanizmy nie poradzą sobie z tą sytuacją. Odbiornik musi odczekać czas RT T, zanim dostarczy kolejne pakiety ACK z informacją o zgubionych segmentach. Ewentualnie otrzyma niepotrzebnie zretransmitowane pakiety. Zazwyczaj sytuacja taka kończy się za-

28 28 Algorytmy sterowania przeciążeniem trzymaniem transmisji danych od nadawcy i oczekiwaniem na upłynięcie stopera retransmisji. Przyczyną takiego stanu rzeczy jest fakt, że zwyczajne potwierdzenie ACK nie daje precyzyjnej informacji, które segmenty zostały utracone, a które dotarły do odbiorcy. Rozwiązaniem tego problemu miał być mechanizm SACK (ang. Selective Acknoledgement) opisany początkowo w [11], a nastepnie uproszczony w [12]. Potwierdzenia selektywne zaimplementowane są w stosie TCP/IP wszystkich znanych i liczących się sieciowych systemach operacyjnych. Blok SACK używany jest przez odbiorcę, aby poinformować nadawcę o odebranych blokach danych, dla których nie wszystkie segmenty zostały stracone. Nadawca zna więc dokładny stan buforów odbiorcy i retransmituje tylko brakujące segmenty. SACK wykorzystuje dwa nowe pola mieszczące się w obszarze opcji nagłówka TCP: zezwolenie na SACK w ustanawianym połączeniu, informacja o odebranych i zbuforowanych nieciągłych blokach po stronie odbiorcy. Pierwsza z tych opcji może zostać użyta tylko w segmentach rozpoczynających połączenie TCP (z ustawioną flagą SYN). Druga informacja przenosi informację o N nieciągłych wysłanych blokach i ma postać przedstawioną w tabeli 3.2. Tabela 3.2. Sposób przesyłu informacji o nieciągłych odebranych blokach [11] Lewa granica 1-go bloku Prawa granica 1-go bloku... Lewa granica N-go bloku Prawa granica N-go bloku Granice bloków są 32-bitowymi liczbami. Zakładając maksymalnie 40- bajtowe pole opcji nagłówka TCP, jeden pakiet może przesłać informację o czterech nieciągłych blokach. W przypadku stosowania opcji znaczników czasowych (o długości 10 bajtów) mamy możliwość przesłania informacji tylko o trzech nieciągłych blokach. Blok SACK nie zmienia znaczenia normalnego potwierdzenia ACK i jest dołączany do każdego segmentu ACK, który potwierdza segment odebrany przez odbiorcę o nie najwyższym numerze sekwencyjnym.

29 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Potwierdzenia generowane w przód Zadaniem algorytmu FACK (ang. Forward acknowledgements) jest poprawienie sterowania przeciążeniem w fazie odzyskiwania. Mechanizm potwierdzeń generowanych w przód może być wykorzystywany tylko dla połączeń korzystających z algorytmu SACK, ponieważ dodatkowe informacje przesyłane w blokach SACK pozwalają mu na dokładne określenie liczby danych będących w drodze. Mechanizm śledzi dwa parametry transmisji: największy potwierdzony przez odbiorcę numer sekwencyjny (snd.fack), liczba retransmitowanych danych jeszcze niepotwierdzonych. Na ich podstawie szacowana jest liczba danych wysłanych, lecz jeszcze niepotwierdzonych (AWND). Gdy żadne dane nie są transmitowane, to: AW ND = snd.nxt snd.fack (3.3) gdzie: snd.nxt to kolejny numer sekwencyjny danych do wysłania (wskazuje miejsce w buforze nadawcy), a snd.f ack jest największym potwierdzonym przez odbiorcę numerem sekwencyjnym. Podczas fazy odzyskiwania do wartości AWND doliczana jest też liczba segmentów retransmitowanych - retran d ata. AW ND = snd.nxt snd.fack + retran d ata (3.4) Każdy retransmitowany segment zwiększa wartość retran d ata, a każdy segment ACK potwierdzający retransmitowane dane ją zmniejsza. Zasadą działania mechanizmu Potwierdzeń generowanych w przód jest to, że dane są wprowadzane do sieci, tylko gdy AW ND jest mniejsze niż CW ND. Dla tego mechanizmu wprowadzono również dodatkowy warunek powodujący rozpoczęcie fazy retransmisji. O ile dla TCP Reno jest nim odebranie trzech zduplikowanych potwierdzeń lub ewentualne upłynięcie czasu retransmisji, o tyle FACK rozpoczyna tę fazę, gdy dziura pomiędzy odebranymi pakietami w buforze odbiorcy przekracza trzy segmenty. Warunek ten można zapisać jako: snd.fack snd.una > 3 MSS (3.5)

30 30 Algorytmy sterowania przeciążeniem gdzie: snd.fack największy potwierdzony przez odbiorcę numer sekwencyjny, snd.una lewa granica okna nadawczego (numer sekwencyjny danych wysłanych, ale jeszcze nie potwierdzonych przez odbiorcę zwykłym potwierdzeniem ACK) Podwojone SACK Algorytm D-SACK (ang. Duplicated SACK) jest rozszerzeniem algorytmu selektywnych potwierdzeń, rozszerzenie to pozwala na poinformowanie nadawcy o fakcie odebrania zduplikowanych segmentów [13]. Zduplikowane potwierdzenia oznaczają najczęściej, że połączenie replikuje pakiety, gubi pakiety ACK lub przestawia kolejność pakietów. Przesłanie nadawcy tej informacji daje mu możliwość odpowiedniej reakcji na sytuacje (zmniejszenie lub nie okna przeciążenia lub progu powolnego startu). Specyfikacja definiuje, by pierwszy blok opcji SACK w pakiecie ACK użyty był do określenia sekwencji zwielokrotnionego segmentu. Rozszerzenie D-SACK wymaga, by nadawca i odbiorca mieli zaimplementowany zwykły algorytm SACK oraz rozszerzenie (D-SACK). Równocześnie nie są potrzebne tutaj przy inicjowaniu połączenia żadne mechanizmy uzgadniania korzystania z D-SACK,. Gdy jedna ze stron komunikacji nie obsługuje tego rozszerzenia, to po prostu ignoruje pierwszy blok zawierający numery sekwencyjne wcześniej już potwierdzone. Najprostszy przykład działania D-SACK (pokazujący wymianę trzech segmentów) przedstawiono w tabeli 3.3. Potwierdzenia dwóch pierwszych segmen- Tabela 3.3. Przykład działania mechanizmu D-SACK [13] Nadany segment Odebrany segment Wysłane ACK (SACK) (zgubione) (zgubione) , SACK tów zostają zgubione. Nadawca ponawia przesłanie pierwszego z nich. Odbiorca otrzymuje więc zduplikowany segment o numerach Reakcją na to jest wysyłanie skumulowanego potwierdzenia ACK o numerze 4000 (potwierdzającego poprawność odebrania dwóch ostatnich segmentów) oraz wyszczególnie-

31 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania nie w bloku SACK (D-SACK) dokładnych numerów zduplikowanego segmentu. Dzięki tej informacji nadawca wie, że ostatnia retransmisja była zbędna i ewentualna, idąca z nią w parze, redukcja natężenia transmitowanych danych nie jest konieczna TCP Westwood W algorytmie TCP Reno stosowany jest mechanizm zwany AIMD (patrz rozdział 3.6.2). Po stwierdzeniu straty pakietu mechanizm redukuje próg powolnego startu i okno przeciążenia do wartości połowy aktualnego CWND (okna przeciążenia). Mechanizm ten został przedstawiony na rysunku 3.3 (rozdział 3.6.1). Dla algorytu Westwood zastosowane zostało nieco inne podejście nazwane: AIAD (Additive increase, adaptive decrease) [14]. Algorytmy działające zgodnie z regułą AIMD sondują dostępne pasmo przez stopniowe zwiększanie natężenia wysyłanych danych (na początku wykładniczo, a później liniowo), reagując odpowiednio na zachodzące straty pakietów, poprzez znaczne zmniejszanie prędkości wysyłania danych. Wydajność takiego rozwiązania jest mała, zwłaszcza w połączeniach heterogenicznych (trasa strumienia danych składa się z mieszanych połączeń przewodowych i radiowych) [15]. Dla łączy kablowych strata pakietu oznacza z reguły przepełnienie buforów w routerach (czyli przeciążenie w sieci). W sieciach bezprzewodowych do straty pakietu dochodzi o wiele częściej z powodu błędów w warstwie fizycznej. Takie straty nie są oznaką przeciążenia i reagowanie na nie zmniejszaniem prędkości przesyłu jest niepotrzebne. Występujące w takim przypadku niedoszacowanie dostępnego pasma znacznie wpływa na mniejszą wydajność transmisji. Pojawiło się wiele prób rozwiązania tego problemu [5]. Niektóre z nich wymagają niestety modyfikacji stosu TCP/IP w urządzeniach pośredniczących, czym naruszają pewną niezależność rozwiązań. Wszystkie omawiane do tej pory modyfikacje dotyczyły tylko urządzeń końcowych. TCP Westwood jest modyfikacją implementowaną tylko po stronie nadawcy. Jest on próbą zwiększenia wydajności TCP zarówno w sieciach heterogenicznych, jak i w sieciach homogenicznych, charakteryzujących się stosunkowo dużą stopą błędu kanału fizycznego. Zachowuje on podstawowe zasady działania protokołu TCP i nie wymaga modyfikacji ani na urządzeniach pośredniczących, ani po stronie odbiorcy. Algorytm przez cały czas szacuje aktualnie wykorzystywane pasmo. W momencie stwierdzenia straty okno przeciążenia nie jest zmniejszane o połowę (jak

32 32 Algorytmy sterowania przeciążeniem dla TCP Reno), lecz ustala się je na podstawie ostatniej estymowanej (sprzed straty pakietu) przepustowości (BWE) (rysunek 3.4). Pierwsza wersja TCP Westwood szacowała pasmo na podstawie przychodzących potwierdzeń ACK od odbiorcy. Potwierdzenia informują nadawcę o liczbie potwierdzanych danych. Znając czasy przyjścia kolejnych pakietów ACK i ilość potwierdzanych danych, można wyznaczyć tzw. dyskretną próbkę pasma obliczaną jako [15]: d k b k = (3.6) t k t k 1 gdzie: b k próbka pasma, d k liczba potwierdzonych danych (w segmencie ACK), t k czas odebrania aktualnego potwierdzenia, t k 1 czas odebrania poprzedniego potwierdzenia, Zasadę ustalania rozmiaru okna i progu powolnego startu przedstawia rysunek 3.4. Kolejna wersja algorytmu nazwana Westwood+ powstała ze względu na problemy występujące w prawdziwych sieciach, związane między innymi z implementacją i kompresją ACK. W tym algorytmie zmieniono algorytm szacowania pasma. Kolejne próbki nie są zbierane w momentach przyjścia potwierdzeń, lecz w równych odstępach czasu (nie mniejszych niż 50 ms). Pasmo szacuje się zatem na podstawie poniższego wzoru: b k = d k t k (3.7) gdzie: b k próbka pasma, d k liczba potwierdzonych danych (w segmencie ACK), t k czas odebrania aktualnego potwierdzenia, Estymatę przepustowości jako filtr dolnoprzepustowy, korzystając ze stałych współczynników oblicza się ze wzoru: BW E k = 7 8 BW E k b k (3.8) gdzie: BW Ek określa k-tą estymatę przepustowości. Działanie algorytmu ustalania rozmiaru okna przeciążenia przedstawiono w postaci prostego pseudokodu (listing 3.1).

33 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Ustalanie rozmiaru okna przeciążenia i progu powolnego startu w algorytmie Westwood [15] Fig Congestion window and slow start threshold calculation in Westwood algorithm [15] Listing 3.1. Algorytm ustalania CWND dla TCP Westwood i f ( odebrano 3 zduplikowane ACK) s s t h r e s h = (BWE RTTmin ) / MSS; i f ( s s t h r e s h < 2) s s t h r e s h = 2 ; CWND = s s t h r e s h ; i f ( upłynął c z a s r e t r a n s m i s j i ) s s t h r e s h = (BWE RTTmin ) / MSS; i f ( s s t h r e s h < 2) s s t h r e s h = 2 ; CWND = 1 ; i f ( odebrano poprawne ACK) powiększ CWND z g o d n i e z d z i a ł a j ącym a k t u a l n i e algorytmem ( powolny s t a r t l u b u n i k a n i e p r z e c i ążeń )

34 34 Algorytmy sterowania przeciążeniem Algorytm osługuje zduplikowane, opóźnione i skumulowane potwierdzenia. Do liczby potwierdzonych danych (d k ) zliczanej przez algorytm dodawane jest odpowiednio: jeden segment (za zduplikowane ACK), dwa segmenty (za opóźnione ACK), jeden segment lub różnica segmentów w stosunku do ostatniego zduplikowanego (za skumulowane ACK). W stosie TCP/IP Linuxa zaimplementowano algorytm Westwood+. Pierwsza implementacja pojawiła się w wersji , a w wersjach pre1 i rc1 została na stałe włączona do jądra systemu TCP Vegas Algorytm zaproponowano w 1994 roku, czyli dużo wcześniej niż TCP New Reno. Jego autorami byli Peterson, Brakmo i O Malley z Wydziału Informatyki Uniwersytetu w Arizonie [16]. Algorytm ten prezentuje całkowicie inne podejście do oceny dostępnej przepustowości w łączu oraz wykrywania zatorów i przeciążeń w sieci. We wszystkich dotąd opisanych algorytmach informacją o przeciążeniu w sieci była strata pakietu. Algorytmy te tak sterowały nadawaniem danych, aby podczas fazy sondowania łącza (powolnego startu) jak najszybciej doprowadzić do straty (przeciążenia w sieci). Podobne zachowanie wykazywały w fazie unikania przeciążenia, przy czym zwiększanie prędkości nadawania następuje tutaj mniej agresywnie (liniowy wzrost zamiast wykładniczego). Efektem takiego zachowania źródeł TCP jest duże zapełnienie kolejek, z czym wiążą się dłuższe czasy obsługi przesyłanych pakietów [17]. Sterowanie przeciążeniem w TCP Vegas zakłada, że nie powinno dopuszczać się do strat pakietów. Założenie to wpływa na redukcję długości kolejek, a tym samym obniża czas obsługi pakietów i zwiększa ogólną przepustowość sieci. Okno przeciążenia ustalane jest w TCP Vegas na podstawie czasu RTT. Decyzja o ewentualnym zwiększeniu lub zmniejszeniu okna przeciążenia podejmowana jest na podstawie wartości minimalnej RTT (będącej odpowiednikiem czasu propagacji i przetwarzania w łączu, w momencie gdy łącze jest jak najmniej obciążone), kolejnych próbek RTT i odchyleń od wartości minimalnej oraz wartości progowych (α, β i γ). Wraz z upływem interwału RTT wyznacza się tzw. przepustowość spodziewaną: CW ND EBW = (3.9) MIN RT T

35 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Zmiany rozmiaru okna dla algorytmu TCP Reno i TCP Vegas [18] Fig Congestion window evolution for TCP Reno and TCP Vegas algorithms [18] gdzie: EBW spodziewane dostępne pasmo, CW N D okno przeciążenia, MIN RT T minimalny, zmierzony czas przejścia pakietu w obie strony (RTT). Na podstawie aktualnego czasu RTT i ilości danych przesłanych w tym czasie wyznaczana jest też aktualna przepustowość oraz różnica Dif f pomiędzy nią i przepustowością spodziewaną. Zadaniem algorytmu jest utrzymywanie wartości Dif f pomiędzy wartościami progowymi α i β. Jeśli wartość Diff mniejsza jest niż parametr α, okno przeciążenia zostaje liniowo zwiększone. Dla Dif f większego niż β okno przeciążenia ulega zmniejszeniu. Współczynniki α i β odpowiadają więc odpowiednio zbyt małej i zbyt dużej liczbie danych w sieci. Współczynnik γ używany jest podczas podejmowania decyzji o zakończeniu fazy powolnego startu i przejściu do fazy unikania przeciążeń. Sytuacja ta występuje wtedy, gdy różnica pomiędzy spodziewaną i aktualnie wykorzystywaną przepustowością jest mniejsza niż war-

36 36 Algorytmy sterowania przeciążeniem tość tego współczynnika. W stosunku do New Reno Vegas wprowadza trzy nowe techniki poprawienia wydajności protokołu TCP [19]: EBW unikanie przeciążeń, CW N D wcześniejsze wykrywanie straty pakietu i wolniejsze zmniejszanie rozmiaru okna przeciążenia, MIN RT T zmniejszenie o połowę prędkości wzrostu okna przeciążenia w fazie powolnego startu. Faza unikania przeciążeń zakłada liniowe zwiększanie i zmniejszanie rozmiaru okna przeciążenia i utrzymanie stałej długości kolejek w urządzeniach pośredniczących. Wcześniejsze wykrywanie i reagowanie na straty pakietu zapobiega wstrzymaniom przesyłania danych (w oczekiwaniu na upłynięcie czasu retransmisji). Sytuacja ta często występuje w TCP Reno. Zadaniem trzeciego mechanizmu jest zapobieganie strat pakietów i związaną z tym utratą wydajności w fazie wolnego startu, ze względu na oczekiwanie aż upłynie czas retransmisji. Różnice w zmianach okna CWND w stosunku do podstawowego algorytmu Reno przedstawiono na rysunku 3.5. Pierwsze implementacje algorytmu Vegas wprowadzono w 1999 roku do jądra Linuksa w wersji 2.2 i 2.3. Na stałe do systemu algorytm został włączony w wersji jądra W tzw. międzyczasie opracowano kilka modyfikacji algorytmu zwiększających jego wydajność. Główne różnice w stosunku do pierwotnej propozycji naukowców z Uniwersytetu w Arizonie to wykorzystanie do wykrywania strat pakietów i odzyskiwania po stracie już istniejących w jądrze rozwiązań (New Reno, FACK, SACK) oraz rezygnacja ze zmniejszania o połowę tempa przyrostu okna przeciążenia w fazie powolnego startu [20] BI-TCP Algorytm BI-TCP (ang. Binary Increase TCP) to jeden z wariantów TCP przeznaczony dla szybkich łączy z dużymi opóźnieniami. Twórcy mechanizmu stworzyli wydajny algorytm transportowy dla szybkich sieci, zachowując jednocześnie trzy podstawowe kryteria dla algorytmów sterowania przeciążeniem [21]: sprawiedliwość względem czasu RTT (dotyczy rywalizacji w jednym kanale transmisyjnym strumieni TCP o różnych czasach RTT),

37 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania przyjazność dla innych strumieni TCP (zachowanie algorytmu, gdy w łączu egzystują inne transmisje sterowane tym samym lub innymi algorytmami sterowania przeciążeniem); warunek ten oznacza, że algorytm nie może zabierać całego dostępnego pasma innym strumieniom, skalowalność (zdolność do działania z taką samą wydajnością zarówno na wolniejszych, jak i na szybszych łączach). Pierwsze algorytmy, powstałe w latach osiemdziesiątych, projektowane były dla wolnych łączy (rzędu kb/s). Dlatego nie potrafią one w pełni wykorzystać możliwości aktualnych szerokopasmowych linii osiągających przepustowość rzędu gigabitów z opóźnieniami na poziomie kilkudziesięciu milisekund lub mniej. Kryteria wymienione powyżej mogą być trudne do spełnienia, zwłaszcza jeżeli algorytm ma być uniwersalny i dopasowywać się do różnych kanałów transmisyjnych, zwłaszcza o różnych współczynnikach strat. Algorytm BI-TCP rozpatruje sterowanie przeciążeniem w sieci w kategoriach wyszukiwania binarnego, gdzie strata pakietu to informacja negatywna, wymuszającą kontynuowanie poszukiwań okna przeciążenia o lepszym rozmiarze. Wyszukiwanie CWND odbywa się pomiędzy dwiema wartościami: minimalną i maksymalną. Aktualna wartość okna, dla której sieć nie jest przeciążona, staje się wartością minimalną. Między tą wartością a wartością maksymalną dochodzi do binarnego wyszukiwania. Nowe okno przeciążenia ustawione zostaje w połowie tych dwóch progów. Jeśli w którymś z kroków nadajnik otrzyma informację o stracie pakietu, to aktualna wartość okna zostaje nowym maksimum, a minimum zostaje ustawione na wartość okna po redukcji. W przypadku gdy transmisja na poziomie CWND leżącego w połowie obu progów nie powoduje strat, to aktualny rozmiar okna staje się minimum i wyznaczane jest nowe maksimum. Algorytm BI-TCP zapewnia bardziej agresywne i szybsze sondowanie możliwości łącza na początku (gdy różnica pomiędzy aktualnym a docelowym oknem jest duża) i wolniejsze zmiany, gdy rozmiar okna przeciążenia oscyluje niedaleko od aktualnych możliwości toru transmisyjnego. W początkowej fazie działania algorytmu, aby nie dopuścić do zbyt gwałtownego wzrostu okna, wprowadzono mechanizm addytywnego (wzrost o jeden) zwiększania okna. Mechanizm przechodzi w ten tryb poszukiwania CWND, gdy rozmiar, o jaki należałoby zwiększyć okno w danym kroku wyszukiwania binarnego, jest zbyt duży (przekracza parametr S max ). Na tym etapie okno przeciążenia zwiększane jest w każdym kroku o S max. Addytywne zwiększania okna trwa tak długo, jak długo binarne wyszukiwanie wymaga wzrostu okna powyżej S max.

38 38 Algorytmy sterowania przeciążeniem Algorytm przewiduje również fazę powolnego startu. W fazie tej okno zwiększane jest wykładniczo (względem RTT). Faza ta trwa do czasu, aż wykładniczy wzrost okna przekroczy S max (w stosunku do rozmiaru okna z początku wejścia w tę fazę). Powolny start uruchamiany jest, gdy nie jest znany próg maksymalny, czyli na początku połączenia lub w późniejszych fazach połączenia, po osiągnięciu maksimum. Zalecenie implementacyjne (jak i również faktyczna implementacja w jądrze Linuxa) definiuje jeszcze próg, od którego algorytm BI-TCP przejmuje kontrolę nad wyznaczaniem rozmiaru okna przeciążenia. Gdy okno przeciążenia ma wartość mniejszą niż ten próg, do sterowania oknem przeciążenia używane są inne algorytmy. BI-TCP został włączony na stałe do jądra Linuxa w wersji Do pierwszych wersji wdarł się jednak pewien błąd matematyczny [22], który został poprawiony dopiero w wersji F-RTO Algorytm Forward RTO powstał, aby zwalczyć problem zbędnych retransmisji, czyli ponownego transmitowania pakietów, które zostały omyłkowo uznane za zgubione [23] [24] [25]. Do zbędnej retransmisji dochodzi najczęściej na łączach z tendencją do wprowadzania nagłych, dłuższych opóźnień lub przestawiających kolejność nadchodzących pakietów. Takie opóźnienia występują w szczególności w sieciach bezprzewodowych, jednakże podobny efekt występuje również przy nagłym wzroście obciążenia sieci. Błędna ocena sytuacji przez algorytm sterowania przeciążeniem doprowadza do niepotrzebnej retransmisji segmentów, zwiększając prawdopodobieństwo wystąpienia zatorów w sieci. Zatory mogą być spowodowane zbyt agresywnym, wykładniczym wzrostem natężenia wprowadzanych do sieci danych w przypadku drożności łącza i odbierania szybkich potwierdzeń w fazie powolnego startu. Próby rozwiązania tego problemu podejmowane były już wiele razy (TCP Eifel [26] czy bloki D-SACK). Oba wspomniane algorytmy miały za zadanie rozpoznać zbędne retransmisje i idące za tym zmiany parametrów okna przeciążenia i progu powolnego startu po stronie nadawcy, a następnie przywrócić natężenie przesyłania danych do poziomu sprzed wejścia w fazę retransmisji. Algorytm Eifel TCP do rozpoznania zbędnych retransmisji wykorzystuje pole znaczników czasowych (Timestamps). Kontrolowane są znaczniki czasowe na pakietach potwierdzeń i jeśli odebrane potwierdzenie zostało wysłane wcześniej

39 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania (mniejsza wartość znacznika czasowego) niż retransmisja tego segmentu, oznacza to, że odebrane ACK potwierdza poprawne odebranie oryginalnego segmentu, nie zaś jego retransmisji. Retransmisja zatem była zbędna i wszystkie związane z nią zmiany parametrów mogą być wycofane. Rezultat działania D-SACK jest identyczny, jednak w tym przypadku informacja o zbędnych retransmisjach przesyłana jest w pierwszym bloku SACK (patrz rozdział 3.6.7). Choć oba wymienione wyżej algorytmy spełniają swoją rolę, to wymagają one implementacji odpowiednich rozszerzeń TCP. Wymóg implementacji rozszerzeń TCP w latach rozwoju tych algorytmów był dużym ograniczeniem. Badania serwera WWW na początku 2000 roku pokazały, że tylko ok. 15% klientów łączących się z serwerem miało zaimplementowaną opcję znaczników czasowych [23]. W algorytmie F-RTO osiągnięto podobny efekt, jednakże implementacja algorytmu Eifel wymaga tylko modyfikacji po strony nadawcy. Ponadto agorytm nie wykorzystuje dodatkowych opcji nagłówka TCP. Algorytm skupia się przede wszystkim na rozwiązaniu problemu zmniejszenia wydajności w sytuacji zbędnych retransmisji. Dlatego modyfikacje w algorytmie obejmują tylko fazę następującą po upłynięciu czasu retransmisji (RTO). Główną zasadą kierującą F-RTO jest odpowiednia reakcja na pierwsze i drugie potwierdzenie odebrane po wystąpieniu zdarzenia upłynięcia czasu retransmisji. Gdy pierwsze potwierdzenie (ACK) potwierdza nowe dane, zamiast retransmisji starych segmentów wysyłane są dwa nowe. Następnie, gdy drugie potwierdzenie (ACK) również potwierdza nowe dane, reakcja na upłynięcie czasu retransmisji uznawana jest za błędną. Jeżeli co najmniej jedno z ACK jest potwierdzeniem zduplikowanym, dane są retransmitowane zgodnie z regułami konwencjonalnego algorytmu. Standardowe TCP retransmituje segmenty z całego okna nadawczego. Natomiast F-RTO poprzestaje na jednej (uznanej za zbędną) retransmisji. W pozostałych elementach swojej pracy algorytm F-RTO wykazuje zachowanie oraz wydajność podobną do konwencjonalnych algorytmów Wyraźne powiadamianie o przeciażeniach ECN W algorytmie wyraźnego powiadamiania o przeciążeniach (ang. Explicit Congestion Notification) zastosowano (w porównaniu do poprzednio omawianych rozwiązań) zupełnie odmienną koncepcję wykrywania przeciążenia. W większości wcześniej opisanych rozwiązaniach algorytmów sterowanie przeciążeniem (z wyjątkiem TCP Vegas) decyduje o zmniejszeniu natężenia wysyłanych danych na podstawie straty pakietu. Takie podejście jest znacznie łatwiejszym sposobem

40 40 Algorytmy sterowania przeciążeniem rozwiązywania problemu przeciążeń, ale niesie ze sobą pewne problemy z jednoznacznym zinterpretowaniem zaistniałej sytuacji. Strata pakietu może być spowodowana przeciążeniem routerów na trasie pakietów, ale jej powodem mogą być również błędy transmisji, przy czym strata pakietów powinna różnić się od reakcji na opóźnienia spowodowane przeciążeniem w sieci. Błędna reakcja na stratę pakietu prowadzi do zmniejszenia okna CWND i wykorzystania łącza w mniejszym stopniu, niż pozwala na to faktyczne wykorzystanie łącza. Do strat pakietów w momencie przeciążenia dochodzi z powodu przepełnienia bufora. Przy polityce odrzucania pakietów niemieszczących się w kolejce, w momencie przeciążenia, odrzucane są wszystkie kolejne pakiety. Rozwiązaniem tego problemu jest AQM odrzucający wcześniej pojedyncze pakiety (patrz rozdział 4). Bazując na podejściu zaimplementowanym w algorytmie RED, zaproponowano rozwiązanie wyraźnego powiadamiania o przeciążeniach ECN [27]. Algorytm ten jest modyfikacją działania aktywnego zarządzania kolejką RED (patrz rozdział 4.3). Różnica polega na tym, że zamiast z określonym prawdopodobieństwem gubić pakiet, mechanizm oznacza go flagą przeciążenia (CE ang. Congestion Experience). Pakiet taki dociera do odbiorcy, a odbiorca ustawia flagę przeciążenia w pakiecie potwierdzenia wysyłanym do nadawcy. Tym sposobem nadawca po odebraniu ACK wie o zbliżającym się przeciążeniu na łączu. Informacja ta może być wykorzystana przez algorytm TCP. Routery działają w warstwie sieciowej modelu ISO/OSI, stąd flaga powiadomienia o przeciążeniu ustawiana jest przez nie w nagłówku pakietu IP. Na użytek ECN przewidziano dwa wcześniej nieużywane bity pola typu TOS (Type Of Service) oraz 2 bity nagłówka TCP (spośród 6 bitów mających status zarezerwowanych).są one wykorzystywane przez odbiorcę do przesłania powiadomienia o przeciążeniu w kierunku nadawcy. Szósty bit pola TOS przeznaczony jest na flagę ECT (ECN-Capable Transport), sygnalizującą, że maszyny na obu końcach połączenia obsługują powiadamianie o przeciążeniach. Do tak oznaczonego pakietu routery pośredniczące mogą dołożyć informację o przeciążeniu (siódmy bit pola TOS) CE (Congestion Experienced). Odbiorca po odebraniu pakietu z flagami sygnalizującymi przeciążenie ustawia flagę ECN echo (ECE) w nagłówku TCP pakietu ACK odsyłanego do nadawcy. Po otrzymaniu takiej informacji, nadawca zachowuje się podobnie jak przy stracie pakietu, a w następnym pakiecie adresowanym do odbiorcy ustawia flagę redukcji rozmiaru okna przeciążenia CWR (ang. Congestion Window Reduced), informując odbiorcę o odebraniu ostrzeżenia ECN i podjęciu odpowiednich kroków.

41 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Podsumowanie Protokół TCP opiera swoją transmisję na mechanizmie pozytywnego okna (potwierdzanie przez odbiornik pozytywnie odebranych danych). W swojej podstawowej formie opisanej w [3] [1] protokół TCP regulował transmisję, wykorzystując dwa mechanizmy: okno odbiorcze (sekcja 3.4) oraz zegar retransmisji (sekcja 3.3). Okno odbiorcze dostosowuje prędkość transmisji do możliwości odbiornika, czyli uzależnia liczbę wysłanych danych od wolnego miejsca w buforze odbiorczym. Zegar retransmisji szacuje czas, w którym nadajnik po wysłaniu danych musi zaprzestać wysyłanie kolejnych danych i oczekiwać na potwierdzenie danych już wysłanych. Czas oczekiwania na potwierdzenie w sieci Internet może być znacząco długi. Stąd wykorzystanie zegara retransmisji jako jedynego sposobu wykrywania strat musi w konsekwencji doprowadzić do znacznego spowolnienia transmisji. Początkowo protokół TCP nie posiadał również mechanizmów sterowania przeciążeniami (sekcja 3.6). Ich implementacja nie była konieczna, ponieważ wszystkie łącza w sieci Internet w latach siedemdziesiątych miały porównywalne przepustowości. Problem przeciążeń pojawił się wraz z pojawieniem się łączy o zwiększonej przepustowości oraz węzłów komunikacyjnych łączących większą liczbę segmentów. Niedopasowanie prędkości nadawania do aktualnych możliwości sieci wypływających z aktualnego jej stanu powoduje wzrost opóźnień pakietów w poszczególnych węzłach, a w efekcie ich retransmisję dodatkowo zwiększającą problem przeciążenia sieci. Potrzeba rozwiązania problemu skutkowała pojawieniem się pierwszych rozwiązań związanych z dopasowaniem prędkości nadawania do możliwości sieci (opisanych w [4]). Wraz z upływem lat do protokołu TCP wprowadzono rozliczne modyfikacje. Większość z nich pojawiała się wraz z innowacjami w technologiach sieciowych. Przykładem może być tutaj mechanizm skalowalnego okna opisanego w sekcji. W nagłówku TCP do raportowania o stanie okna nadawczego wykorzystuje się szesnastobitowe pole znajdujące się w nagłówku segmentu. Pozwala ono na ustalenie maksymalnie 64 kb rozmiaru okna, co w przypadku współczesnych szybkich łączy może powodować duży spadek prędkości nadawania. Podobnie jest w przypadku mechanizmu tzw. znaczników czasowych. Mechanizm ten zabezpiecza przed skutkami zawinięcia się numeru sekwencyjnego w ramach jednego połączenia. Pojawienie się tego problemu jest możliwe tylko podczas bardzo szybkich transmisji. Zupełnie innym typem modyfikacji jest algorytm wykrywania zbędnych retransmisji. Do zbędnych retransmisji dochodzi najczęściej w sieciach wprowadza-

42 42 Algorytmy sterowania przeciążeniem jących nagłe dłuższe opóźnienia. Ten problem pojawił się wraz z rozpowszechnieniem się sieci bezprzewodowych. Najwięcej modyfikacji protokołu TCP jest związanych z ulepszaniem algorytmów estymacji okna przeciążeniowego. Ideą tego rozwiązania jest możliwość dostosowania przez nadajnik prędkości generowania pakietów do aktualnych możliwości sieci. Najczęściej ewolucja okna przeciążeniowego polega na stopniowym wzroście okna przeciążenia i radykalnej redukcji tego okna w przypadku wystąpienia przeciążenia. Oznaką przeciążenia dla większości zaproponowanych algorytmów jest strata pakietu. Nadajnik, który nie otrzymuje potwierdzenia wysłanych przez siebie danych, uważa, że sieć jest przeciążona i zmniejsza prędkość ich nadawania. Znacząco różni się tutaj tylko algorytm Vegas, który ustala okno przeciążeniowe na podstawie opóźnień transmisji. Najważniejszą zaletą przedstawionych w tym rozdziale algorytmów jest ich elastyczność. Ich implementacja wymaga zmian tylko po stronie nadajnika. Wyjątkiem jest tu mechanizm wyraźnego powiadamiania o przeciążeniu. Jego mała popularność jest dowodem tezy, że najlepiej w sieci Internet przyjmują się rozwiązania niewymagające globalnych modyfikacji. W dalszej części książki zostaną zaprezentowane szczegółowe badania protokołu TCP. W rozdziale 5 przedstawione zostały badania wpływu modyfikacji protokołu TCP na prędkość przesyłu, liczbę pakietów potrzebnych do wysłania założonej porcji danych oraz ich wpływu na zmiany okna przeciążenia (CWND) czy progu wolnego startu (ssthresh). Problem wpływu protokołu TCP na zachowanie kolejek AQM poruszono w rozdziale 7.

43 Rozdział 4 ZARZADZANIA KOLEJKA ROUTERA W niniejszym rozdziale przedstawiono podstawowe mechanizmy zarządzania pakietami umieszczonymi w kolejkach routera. Dokonano również wstępnej oceny ich wpływu na przesył strumieni danych przechodzących przez router. Węzeł sieciowy (router) jest to urządzenie umiejscowione pomiędzy dwoma odrębnymi segmentami sieci. Głównym zadaniem routera jest podjęcie odpowiedniej decyzji dotyczącej dalszej podróży pakietu i przekierowanie go do odpowiedniego interfejsu wyjściowego, a tym samym do odpowiedniej sieci docelowej. Przychodzące pakiety (do czasu podjęcia decyzji o przekierowaniu) umieszczane są w buforze wejściowym, gdzie czekają na podjęcie decyzji przez węzeł. Każdy router posiada pewną ustaloną wielkość bufora, świadczącą o ilości danych, które mogą być w nim składowane. Strumień nadchodzących pakietów w danym momencie czasu może cechować się różną intensywnością. Zadaniem kolejki jest dopasowanie szybkości przełączania pakietów przez router do zmienności tego strumienia. Kolejka jest buforem, w którym przechowywane są dane oczekujące na obsłużenie, jest to jedna z podstawowych abstrakcyjnych struktur danych. Mianem abstrakcyjnego typu danych określamy typ niezależny od implementacji, opisujący własności danych oraz operacje na nich wykonywane [28]. Każda kolejka posiada mechanizmy, których zadaniem jest odpowiednie umieszczenie oraz usunięcie porcji danych (w przypadku routera taką porcją jest pakiet). Nadchodzący pakiet, który nie może być bezpośrednio obsłużony, zostaje umieszczony w kolejce Algorytmy kolejkowania W zależności od sposobu umieszczania pakietów oraz w jaki sposób pobierane są one z kolejki, algorytmy obsługi kolejki (ang. queueing) możemy podzielić na: metoda FIFO (ang. First In First Out) zwana potocznie pierwszy przyszedł, pierwszy obsłużony. Jak sama nazwa wskazuje, algorytm ten obsługuje pakiety w kolejności nadejścia. Algorytm FIFO jest najbardziej naturalnym i sprawiedliwym sposobem obsługi kolejki,

44 44 Zarządzanie kolejką routera metoda LIFO (ang. Last In First Out) zwyczajowo znana pod nazwą ostatni przyszedł, pierwszy obsłużony, mechanizm obługuje pakiety w odwrotnej kolejności, metoda priorytetowa specjalny rodzaj kolejki, w której o kolejności obsłużenia decyduje priorytet nadany jednostce danych znajdującej się w kolejce. W przypadku pakietów o tej samej wartości priorytetu mogą zostać obsłużone wg reguły FIFO lub LIFO, metoda sprawiedliwego kolejkowania (ang. fairness queueing) - polega na umieszczaniu pakietów pochodzących z różnych strumieni w różnych kolejkach, które są następnie obsługiwanie metodą Round Robin. Dla każdej kolejki przydzielona jest pewna wartość jednostkowa przewidziana na dokonanie obsługi (kwant czasu, pakiet danych, liczba przesłanych danych). Najbardziej znanymi i najczęściej stosowanymi mechanizmami zaliczającymi się do tej grupy są metoda ważonego sprawiedliwego kolejkowania oraz stochastycznego sprawiedliwego kolejkowania [29], metoda klasowego kolejkowania (ang. Class-Based Queueing) w algorytmie tym występuje kilka kolejek zwanych klasami. Każdej klasie przypisana jest pewna przepustowość łącza. Metoda pozwala zagwarantować założoną szerokość pasma dla ustalonych strumieni danych [30], [31]. Kolejkowanie priorytetowe to jedno z podstawowych typów kolejkowania. Składa się z kilku kolejek (czyli buforów) o różnym priorytecie. Dane trafiają do odpowiedniej kolejki w zależności od ustawień odpowiednich filtrów. Każda kolejka oznaczona zostaje priorytetem im wyższy, tym pakiety znajdujące się w tej kolejce będą miały przewagę nad innymi. Jest to bardzo prosty mechanizm niepozbawiony niestety wad. Pakiety z kolejki o najwyższym priorytecie obsługiwane są w pierwszej kolejności i dopiero, jeśli ta kolejka jest pusta następuje obsługa pakietów z kolejek niższych, także w zależności od priorytetu. Wadą takiego rozwiązania jest to, że kolejki o niższym priorytecie mogą zostać zagłodzone, jeśli tylko pakiety o wyższym priorytecie będą cały czas nadchodzić a co za tym idzie będą obsługiwane przez swoją kolejkę. W takim przypadku pakiety z kolejki o niższym priorytecie nigdy nie zostaną obsłużone. Aby temu przeciwdziałać, wiąże się zatem ten typ kolejkowania z innymi rodzajami kolejkowania, np. kolejkowaniem sprawiedliwym lub z mechanizmami kształtowania ruchu. Kolejkowanie sprawiedliwe to dwa typy kolejek: SFQ (Stochastic Fairness Queuing) oraz WFQ (Weighted Fairness Queuing). Pierwsza z nich tworzy wirtu-

45 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania alny kanał dla każdego połączenia opierając się na adresie źródłowym, adresie docelowym i protokole. Dla każdej konwersacji sieciowej tworzona jest osobna kolejka, a wszystkie kolejki obsługiwane są wg algorytmu round-robin, czyli każda z nich jest kolejno obsługiwana. Sprawiedliwość tego typu kolejki polega na tym, że pakiety z każdej kolejki opuszczają bufor w stałych ilościach z każdej z nich, jednak sprawiedliwość jest prawdziwa tylko, jeśli pakiety w każdej kolejce mają tę samą długość. Wady tej nie ma kolejka typu WFQ. Mechanizm ten dla każdego połączania przeznacza podobnie jak mechanizm SFQ osobną kolejkę FIFO, z tą różnicą że każda kolejka ma swój priorytet i wagę przyporządkowaną do danego priorytetu. Kolejki o większej wadze mają dostęp do większej przepustowości niż kolejki o niższej wadze. Istotną różnicą pomiędzy kolejkami typu SFQ i WFQ jest również algorytm opróżniania kolejki. W SFQ był nim algorytm round-robin. W kolejce WFQ wykorzystujemy algorytm bit-by-bit round-robin. Polega on na tym, że nie jest wysyłany jeden pakiet z każdej kolejki, tylko jeden bit jest przepuszczany z każdej kolejki i pakiet jest wysyłany dopiero wtedy, gdy wszystkie jego bity zostaną przepuszczone. Takie reguły algorytmu zapewniają sprawiedliwość traktowania niezależną od wielkości pakietów. Wadą rozwiązania jest brak możliwości określenia, która kolejka zajmuje jaką część przepustowości w danej chwili. Przepustowość przypadająca na kolejki uzależniona jest od liczby kolejek i ich wagi, np. mając 3 kolejki priorytetowe i pakiety w nich oczekujące, każda z kolejek dostanie sprawiedliwie po jednej trzeciej przepustowości, natomiast mając dwie kolejki o wysokiej wadze i dwie o niskiej i pakiety pojawiające się w każdej z nich, kolejki o wysokim priorytecie dostaną po jednej trzeciej całości przepustowości, natomiast obie kolejki o niskiej wadze dostaną po jednej szóstej całkowitej przepustowości. Należy stwierdzić, że mechanizm WFQ zapewnia każdej kolejce dostęp do łącza, ale bez gwarancji z góry określonej przepustowości. Kolejkowanie klasowe to rozbudowany system kolejkowania, umożliwiający tworzenie rozbudowanych klas ruchu o charakterze hierarchicznym. Klasa jest tu podstawowym pojęciem oznaczającym pewną grupę typów transmisji. Każda klasa może zawierać inną klasę bądź algorytm kolejkowania bezklasowego. Klasę, która nie posiada żadnej klasy wewnątrz siebie, nazywamy liściem. Tylko liście przechowują kolejki z pakietami. Można utworzyć drzewo kolejek, które obsługują specyficzne transmisje w zależności od reguł filtrowania, które zostaną narzucone. Kolejki-węzły przyjmują określoną przepustowość, natomiast kolejki potomne potrafią odziedziczyć tę wartość po kolejce nadrzędnej. Zatem klasa-rodzic charakteryzuje się łącznym zbiorem cech klas-potomków. Wielkości charakteryzujące klasy to:

46 46 Zarządzanie kolejką routera parametr R określony dla każdej klasy, oznacza aktualną częstość wysyłania pakietów (ang. actual rate). Parametr R każdej klasy to suma klas potomnych, AR (ang. assured rate) czyli zapewniona częstość, oznacza minimalną przepustowość, którą dana klasa będzie mogła zawsze wykorzystać, jeśli tylko będzie posiadać pakiety. W przypadku przekroczenia tej wartości klasa próbuje pożyczyć część przepustowości od klasy nadrzędnej (czyli de facto pożyczyć tokeny), priorytet P określa priorytet klasy w przypadku, kiedy kilka równorzędnych klas stara się pożyczyć żetony od klasy nadrzędnej, CR (ang. ceil rate) czyli częstość szczytowa, oznacza wartość, po przekroczeniu której klasa nie może wysyłać żadnych pakietów ani pożyczać żetonów od innych klas, stan (ang. mode) obliczony na podstawie R, AR i CR, oznacza stan, w którym znajduje się klasa: czerwony klasa osiągnęła częstość maksymalną (R > CR), żółty klasa przekroczyła swoją wartość charakteryzującą przepustowość, ale wciąż może pożyczać od klas nadrzędnych (R < CR i R > AR), zielony klasa jest w stanie, w którym może wysyłać pakiety, korzystając tylko ze swoich tokenów (R < AR), kwant Q (ang. quantum) parametr określający liczbę bajtów, jakie klasa może wysłać zanim inna klasa o tym samym priorytecie rozpocznie wysyłanie pakietów, poziom (ang. level) wartość określająca poziom klasy w hierarchicznym drzewie klas. Klasa-liść posiada poziom 0, każda inna klasa posiada wartość poziomu o jeden mniejszą niż jej rodzic, a klasa-korzeń posiada wartość poziomu o jeden mniejszą od liczby wszystkich poziomów. Ogromne możliwości konfiguracji kolejkowania klasowego powodują, że jest ono głównym podmiotem zainteresowań dostawców sprzętu sieciowego nastawionych na wdrażanie mechanizmów QoS. Przykładem kolejek klasowych są CBQ (Class Based Queuing) oraz HTB (Hierarchical Token Bucket).

47 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Algorytmy cieknącego wiadra oraz wiadra z żetonami (oraz ich liczne modyfikacje) służą do sterowania przepustowością sieci (inaczej nazywamy je algorytmami kształtującymi przepływ). Za ich pomocą można sterować szybkością wypuszczania pakietów do sieci, nie są to więc osobne kolejki, tylko pewne mechanizmy, które zostają uruchomione w momencie, gdy pakiet ma opuścić właściwą kolejkę. Poniżej omówione zostaną popularne algorytmy kolejkowania. Algorytm kolejkowania FIFO W jądrze Linuksa ten najprostszy z algorytmów kolejkowania zostal zaimplementowany w trzech odmianach: pfifo_fast, pfifo oraz bfifo. Algorytm kolejkowania pfifo_fast jest domyślnym algorytmem kolejkowania. W tej odmianie algorytmu FIFO do trzech podkolejek kierowane są pakiety o różnych priorytetach. Można sobie wyobrazić ten algorytm kolejkowania jako połączenie trzech klas, z których każda jest obsługiwana przez algorytm pfifo. Pakiety klasyfikuje się na podstawie wartości pola TOS z nagłówka pakietu IP. Wersje pfifo oraz bfifo to proste mechanizmy kolejkowania bez dodatkowych ulepszeń, przydatne głównie w celach statystycznych (domyślny algorytm kolejkowania pfifo_ fast nie udostępnia statystyki ruchu pakietów). Algorytmy te przechowują wszystkie pakiety w pojedynczej kolejce FIFO. Rozmiar tej kolejki podaje się w pakietach (dla pfifo) lub w bajtach (dla bfifo). Domyślny rozmiar kolejki jest ustawiany przy aktywacji interfejsu sieciowego (np. dla sieci Ethernet wynosi 100 pakietów) i może być odczytany przez narzędzie ifconfig. Jeśli kolejka osiągnęła maksymalny dopuszczalny rozmiar, to następne przychodzące pakiety są odrzucane. Algorytm kolejkowania PRIO (PRIOrities) Algorytm PRIO jest uogólnioną odmianą algorytmu pfifo_ fast. Modyfikacja w stosunku do wspomnianego algorytmu polega na traktowaniu podkolejek jako niezależnych klas, z których każda może być skojarzona z innym algorytmem kolejkowania. Przekłada się to na większą elastyczność, gdyż pozwala klasyfikować pakiety do podkolejek nie tylko na podstawie bitów TOS, ale także przez narzędzie tc.

48 48 Zarządzanie kolejką routera W systemie Linux domyślnie istnieją trzy podkolejki, do których są kierowane pakiety z ustawionymi następująco bitami TOS: 0 minimalne opóźnienie (najwyższy priorytet), 1 maksymalna wiarygodność, 2 minimalny koszt lub maksymalna przepustowość (najniższy priorytet). Jeśli pakiet ma ustawionych równocześnie kilka wartości pola TOS, to pakiet kierowany jest do kolejki o najwyższym możliwym priorytecie (np. minimalne opóźnienie w połączeniu z maksymalną przepustowością kieruje do podkolejki 0). System Linux przewiduje możliwość zmiany liczby podkolejek, ale taka zmiana wymusza również zmianę odwzorowania priorytetów. Podobnie jak w algorytmie kolejkowania pfifo_fast pakiety są pobierane z podkolejek o niższych priorytetach dopiero wtedy, gdy nie ma już pakietów w podkolejkach o wyższych priorytetach. Takie rozwiązanie może doprowadzić do zagłodzenia kolejek o niższych priorytetach. Najprostszym sposobem uniknięcia tej sytuacji jest kształtowanie ruchu w podkolejkach o wyższych priorytetach (np. z wykorzystaniem algorytmu TBF). Algorytm kolejkowania TBF (Token Bucket Filter) Algorytm TBF (ang. Token Bucket Filter) jest pewną modyfikacją algorytmu tzw. cieknącego wiadra (ang. leaky bucket) i jest mechanizmem kształtowania ruchu. Kolejka TBF [32] jest dużym buforem (FIFO), z którego pakiety pobierane są ze stałą częstotliwością, tzn. w jednostce czasu przesyłana jest określona, zadana liczba bajtów. Pakiety przepełniające wiaderko (przekraczające maksymalny rozmiar bufora) są usuwane. Wadą algorytmu jest brak reakcji na chwilowe wzrosty natężenia ruchu. Zadaniem mechanizmów kształtowania ruchu jest określenie liczby pakietów znajdujących się aktualnie w sieci. W przypadku przestoju na łączu byłoby możliwe chwilowe przesłanie do sieci nieco większej liczby pakietów. Algorytm cieknącego wiadra tego nie umożliwia. Rozwiązaniem eliminującym tę wadę jest algorytm cieknącego wiadra z żetonami (TBF), który został przedstawiony na rysunku 4.1. W mechanizmie TBF [33] ruch pakietów regulowany jest przez żetony (ang. tokens). Pojedynczy żeton odpowiada pojedynczemu bajtowi, tak wiec liczba żetonów odpowiada rozmiarowi pakietu w bajtach, z uwzględnieniem tego, że najmniejszy pakiet odpowiada pewnej liczbie żetonów. Nawet pakiet niezawierający

49 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tokeny Przychodzące pakiety Bufor 1 token = 1 byte Rys Algorytm cieknącego wiadra z żetonami [32] Fig Token bucket filter algorithm [32] żadnych danych ma pewien rozmiar. Na przykład w sieciach Ethernet minimalny rozmiar datagramu zawierającego pakiet TCP bez danych wynosi 64 bajty. Żetony magazynowane są w kubełku, z którego wyciekają razem z wychodzącymi pakietami. Początkowo kubełek jest w pełni wypełniony żetonami. Żetony są generowane ze stałą częstotliwością i są magazynowane w kubełku aż do jego całkowitego wypełnienia. Pakiet wychodzący jest wysyłany do sieci tylko wtedy, gdy w danej chwili dostępna jest liczba żetonów odpowiadająca jego rozmiarowi. Jeśli w danej chwili nie jest dostępna wystarczająca liczba żetonów, to pakiety są wstawiane do kolejki o ograniczonej długości. Z chwilą gdy kolejka pakietów się wypełni, nowe żetony nie są przyjmowane do kubełka, dopóki nie zostanie wysłany do sieci pierwszy pakiet z kolejki. W sytuacji braku dostępnej odpowiedniej liczby żetonów, co uniemożliwia wysyłanie pakietów, uruchamiany jest regulator czasowy (ang. watchdog timer), który wznowi transmisje pakietów po nadejściu wystarczającej liczby tokenów. Magazynowanie żetonów w kubełku może prowadzić do wystąpienia krótkotrwałych przeciążeń w sieci. W implementacji Linuksowej tego algorytmu decyzja o wypuszczeniu lub nie pakietu odbywa się co kwant czasu jądra (ang. jiffe). Kwant czasu jądra zależy od platformy sprzętowej. Od wartości tego parametru zależy maksymalna prędkość przesyłu danych, dla których system jest w stanie dokładnie ukształtować prędkość przesyłu. Jeżeli kwant czasu jądra wynosi 10 ms to odwrotność wspomnia-

50 50 Zarządzanie kolejką routera nego kwantu czasu określa, ile kwantów zmieści się w czasie 1 sekundy. Przyjmując, że średni rozmiar pakietu wynosi 1000 bajtów, otrzymujemy dokładne kształtowanie ruchu dla przepustowości nieprzekraczających 1 Mb. Można kształtować s przepustowość na wyższym poziomie, ale wtedy odbywa się to kosztem dokładności. Algorytmy sprawiedliwego kolejkowania FQ Podstawową implementacją kolejkowania sprawiedliwiego jest algorytm SFQ (ang. Stochastic Fairness Queueing). Jego zadaniem jest szeregowanie pakietów wychodzących [34]. W praktyce polega to na opóźnianiu transmisji wybranych strumieni pakietów. Celem nadrzędnym mechanizmu jest zapewnienie sprawiedliwego podziału dostępnej przepustowości między wszystkie strumienie w sposób jak najmniej obciążający procesor. Do pewnej założonej liczby kolejek za pomocą funkcji haszującej przydzielane są pakiety. Funkcja haszująca jest regularnie (co ustalony czas, przykładowo co 10 sekund) przeliczana w celu zminimalizowania prawdopodobieństwa kolizji. Funkcja haszująca [35] wyznacza numer kubełka na podstawie następujących parametrów: adres źródłowy (w postaci liczby 32-bitowej), adres docelowy (w postaci liczby 32-bitowej), numer protokołu transportowego, wartość całkowita zmieniająca się co kwant czasu. Pobieranie pakietów z kolejek opiera się na algorytmie cyklicznym round-robin. Mechanizm ten zapewnia sprawiedliwą obsługę wielu równoległych strumieni i zapobiega zdominowaniu łącza przez strumienie generujące duży ruch. Pakiety wysyłane są cyklicznie po jednym z każdej kolejki, dlatego strumienie składające się z większej liczby mniejszych pakietów są wysyłane najszybciej. Efekty działania algorytmu są najbardziej widoczne, gdy ruch wychodzący zajmuje całą dostępną przepustowość. Implementacja algorytmu ma pewne ograniczenia [35]. Do najbardziej widocznych należą: ograniczenie liczby podkolejek (1024) oraz pakietów w podkolejce (128). Pewnym ograniczeniem jest również prostota algorytmu. SFQ nie bierze pod uwagę rozmiaru pakietów, które mogą się różnić. Pewną modyfikacją stochastycznego podziału są algorytmy sprawiedliwego podziału

51 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Struktura klas w postaci odwróconego drzewa dla algorytmu CBQ [37] Fig Class structure in the form of an inverted tree for CBQ algorithm [37] (np. Weighted Fair Queueing WFQ), które rozdzielają dynamicznie strumienie pakietów do kolejek o zmiennym priorytecie, stosując jako kryterium przydziału liczbę danych przesyłanych danym strumieniem [36]. W ten sposób faworyzowane są krótsze strumienie przesyłające mniejszą liczbę danych. Algorytm CBQ Algorytm CBQ (ang. Classful Based Queueing) to jeden z najbardziej elastycznych algorytmów zawartych w linuksowej implementacji kolejkowania. Elastyczność mechanizmu wynika bezpośrednio z jego klasowości (możliwości tworzenia klas wewnętrznych) i dużej konfigurowalności. Algorytm ten może kształtować zarówno ruch przychodzący, jak i wychodzący. Struktura klas tworzona z wykorzystaniem CBQ ma postać odwróconego drzewa (rysunek 4.2). Na szczycie znajduje się klasa główna (ang. root). Każda z pozostałych klas może być węzłem (ang. node) lub liściem (ang. leaf). Węzły posiadają zarówno rodzica, jak i potomstwo, a liście posiadają wyłącznie rodzica. Klasy mające wspólnego rodzica określane są jako rodzeństwo (ang. siblings). Rodzeństwo domyślnie wzajemnie pożycza sobie przepustowość (ta opcja może zostać wyłączona). Przeważnie każda klasa ma jawnie zdefiniowany uchwyt (ang. handle). Rodzic i rodzeństwo nie znają tego uchwytu, gdyż odwołują się

52 52 Zarządzanie kolejką routera do uchwytu generowanego automatycznie przez algorytm kolejkowania. Z każdą klasą skojarzony jest algorytm kolejkowania (domyślnie pf if o_f ast). Każdy węzeł może dodatkowo posiadać filtr, który przekierowuje pakiety do odpowiednich klas wśród potomstwa [37]. Rysunek 4.2 pokazuje wzajemne relacje między klasami (wraz z algorytmami kolejkowania i filtrami) Linuksa oraz zewnętrzną siecią komputerową. Pewną ciekawostką jest mechanizm umożliwiający bezpośrednie przesyłanie pakietów do odpowiednich klas, podczas gdy pobieranie pakietów z klas wymaga już pośrednictwa rodziców. Jądro systemu komunikuje się wyłącznie z klasą główną. Pobieranie pakietów z klas może się odbywać wyłącznie poprzez rodziców, co jest warunkiem koniecznym dla działania mechanizmu kształtowania ruchu. Pobieranie pakietów z klas wykonywane jest według algorytmu WRR (Weighted Round- Robin). Algorytm WRR jest modyfikacją algorytmu round-robin, polegającą na przypisaniu różnych wag (priorytetów) każdej klasie. Klasy o wyższych priorytetach są sprawdzane w pierwszej kolejności. Wstawianie pakietów do klas może się odbywać z pominięciem ich bezpośrednich rodziców. Przekierowywanie pakietów do wybranych klas odbywa się przeważnie z wykorzystaniem filtrów. Można również klasyfikować pakiety bezpośrednio w klasach, nakładając maskę bitów na pole TOS z nagłówka pakietu IP. Ogólny algorytm klasyfikowania pakietów do poszczególnych klas wygląda następująco: sprawdź filtry bieżącej klasy. Jeżeli znajdujesz się w liściu, to skończ sprawdzanie, w przeciwnym wypadku wróć do kroku 1, nałóż maskę bitów na bity TOS. Jeżeli otrzymałeś zgodność i znajdujesz się w węźle, to skończ sprawdzanie,w przeciwnym wypadku wróć do kroku 1, wstaw pakiet do bieżącej klasy. Poza szeregowaniem pakietów algorytm CBQ zajmuje się również kształtowaniem ruchu wychodzącego. Kształtowanie ruchu polega na obliczaniu bezczynności i odpowiednim wstrzymywaniu ruchu pakietów. Odpowiednie obliczenia przeprowadza się opierając się na podanym jako jeden z parametrów algorytmu kolejkowania, średnim rozmiarze pakietów (zwykle 1000 bajtów). Na tej podstawie wyznaczany jest parametr EWMA (ang. Exponential Weighted Moving Average), który traktuje nowsze pakiety jako ważniejsze od starszych. Następnie od zmierzonego okresu bezczynności łącza sieciowego odejmowana jest bezczynność obliczona z użyciem EWMA, po czym jest ona odejmowana od zmierzonej bezczynności, dając bezczynność łącza sieciowego.

53 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Średnia bezczynność łącza sieciowego może przyjmować następujące wartości: ujemne łącze jest przeciążone (ang. overlimit), zerową łącze jest idealnie zrównoważone, dodatnie łącze jest niedociążone (ang. underlimit). W przypadku przeciążenia transmisja pakietów jest wstrzymywana tak długo, dopóki nie dojdzie do zrównoważenia łącza. Dokładność zrównoważenia obciążenia łącza zależy od pojedynczego kwantu czasu zegara platformy sprzętowej. Kwant ten jest minimalną rozdzielczością ustalania czasu oczekiwania na transmisję. W przypadku niedociążenia łącza pakiety będą wysyłane szybciej, aż do momentu zrównoważenia obciążenia łącza. Aby zapobiegać zbyt dużym chwilowym przeciążeniom w sieci w trakcie wyrównywania obciążenia, definiowana jest maksymalna bezczynność łącza, do którego jest obcinana w dół aktualnie obliczona wysoka wartość bezczynności. Algorytm kolejkowania CSZ Nazwa algorytmu CSZ to akronim trzech twórców algorytmu: Clark-Shenker- Zhang. Jest on jednym z najbardziej rozbudowanych algorytmów kolejkowania zaimplementowanym w systemie Linux [38]. W algorytmie konwersacje z różnych klas ruchu są umieszczane w osobnych kolejkach fifo+. Algorytm fifo+ jest modyfikacją algorytmu FIFO, uwzględniającą czas przyjścia pakietu. Przed wysłaniem pakietu do kolejnego routera obliczany jest i zapisywany w nagłówku IP spodziewany czas przyjścia do kolejnego routera. Czas ten jest porównywany ze spodziewanymi czasami przyjścia pozostałych pakietów z kolejki i wstawiany do kolejki w odpowiednie miejsce. Mechanizm wprowadza podział strumieni na strumienie o: gwarantowanej jakości generowane przez aplikacje żądające niezmiennych parametrów transmisji, przewidywanej jakości strumienie aplikacji niewrażliwych na zmienne parametry transmisji. Do kolejek o wyższych priorytetach wstawiane są pakiety strumieni o gwarantowanej jakości, a do kolejek o niższych priorytetach pakiety strumieni

54 54 Zarządzanie kolejką routera o przewidywanej jakości. Do kolejki o najniższym priorytecie, działającej zgodnie z zasadą best efford, trafiają pakiety przesyłane minimalnym kosztem. Aby kolejki o wyższych priorytetach nie zagłodziły kolejek o niższych priorytetach, stosuje się kształtowanie ruchu wychodzącego z kolejek o najwyższych priorytetach za pomocą jednej z odmian algorytmu cieknącego wiadra. Algorytm HTB Algorytm kolejkowania HTB (ang. Hierarchical Token Bucket) jest to elastyczny algorytm klasowy o zastosowaniach zbieżnych z zastosowaniami algorytmu kolejkowania CBQ. W porównaniu z algorytmem CBQ jest on bardziej precyzyjny przy podziale przepustowości na klasy ruchu. HTB jest hierarchiczną, klasową wersją TBF. W algorytmie zaimplementowano zaawansowany mechanizm pożyczania pasma. Każda podklasa może pożyczać wolne pasmo od rodzica, jeżeli przekroczy próg minimalnego pasma. Pożyczanie pasma trwa do czasu osiągnięcia przez klasę pasma maksymalnego. Takie rozwiązanie umożliwia dzielenie pasma przy jednoczesnym jego gwarantowaniu Metody odrzucania pakietu Bardzo istotnym problemem analizy mechanizmów kolejkowania jest zachowanie algorytmu w momencie przepełnienia bufora. Można w takiej sytuacji zastosować trzy różne podejścia: odrzucenie końca kolejki (ang. tail drop), odrzucenie początku kolejki (ang. head drop), wypychanie (ang. pushout). W przypadku odrzucania z końca kolejki (rysunek 4.3), nadchodzące pakiety są umieszczane w kolejce aż do momentu osiągnięcia maksymalnego rozmiaru kolejki. Po jej osiągnięciu każdy kolejny przychodzący pakiet jest gubiony aż do momentu opróżnienia kolejki na tyle, że można w niej umieścić cały nadchodzący pakiet. W algorytmie odrzucania z początku kolejki (rysunek 4.4), po przekroczeniu wartości progowej nadejście nowego pakietu powoduje usunięcie pierwszego

55 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Odrzucenie pakietu z końca kolejki Fig The drop-from-tail strategy znajdującego się w kolejce pakietu, przesunięcie pozostałych pakietów w kierunku początku kolejki, a następnie umieszczenie przybyłej paczki danych na końcu kolejki. Dla algorytmu wypychania nadchodzący pakiet zostaje umieszczony na miejscu ostatniego pakietu w kolejce (rysunek 4.5) Pasywne oraz aktywne zarzadzanie kolejkami Algorytmy zarządzania kolejkami w routerach IP determinują sposób i czas usuwania pakietu z kolejki. Pasywne zarządzanie kolejką polega na monitorowaniu jej długości i odrzuceniu pakietów po całkowitym zapełnieniu bufora. Takie podejście jest reagowaniem po fakcie i nie pozwala w żaden sposób wpływać na parametry transmisji danych. Jedyną możliwością jest tutaj regulacja długości kolejki, która może wpływać na opóźnienie transmisji. Najbardziej istotnymi wadami pasywnego zarządzania kolejkami są: brak przeciwdziałania przeciążeniom występującym w sieci, problem globalnej synchronizacji, częste zrywanie połączenia w przypadku wystąpienia przeciążenia i odrzucenia dużej liczby nadchodzących pakietów. Sposobem na rozwiązanie przedstawionych powyżej problemów jest zastosowanie rekomendowanego przez IETF aktywnego zarządzenia kolejką (AQM) [39].

56 56 Zarządzanie kolejką routera Rys Odrzucenie pakietu z początku kolejki Fig The drop-from-front strategy Rys Wypychanie pakietu z kolejki Fig The push-from-tail strategy

57 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Aktywne zarządzanie polega na monitorowaniu stanu łącza, a co z tym się wiąże liczby danych w kolejce i na tej podstawie podejmowaniu decyzji dotyczących przyjęcia lub odrzucenia nadchodzących danych. Dodatkową zaletą mechanizmów AQM jest współpraca z algorytmami obliczania okna przeciążenia protokołu TCP. Ponieważ wielkość okna zależna jest od liczby uzyskanych zwrotnych potwierdzeń, rośnie ona aż do momentu, gdy pewna porcja danych nie zostanie potwierdzona przez odbiorcę. Zatem, odrzucenie pakietu przez mechanizm AQM spowoduje zmniejszenie okna przeciążenia i prędkości nadawania danych przez źródło TCP. W przypadku pasywnego zarządzania kolejkami w momencie przepełnienia bufora odrzucenie dużej liczby pakietów powoduje zatrzymanie dużej liczby nadajników TCP. Zjawisko to nazwane zostało globalną synchronizacją. W przypadku AQM pakiety odrzucane są dużo wcześniej, zanim nastąpi przepełnienie buforów. Najczęściej dochodzi do losowego wyrzucenia jednego pakietu, co powoduje natychmiastowe zatrzymanie konkretnego źródła TCP. Jego zatrzymanie powoduje zmniejszenie zajętości łącza i pozwoli innym źródłom nadawać bez przeszkód. W następstwie losowego zmniejszania prędkości nadawania poszczególnych źródeł, przepełnienie bufora może w ogóle nie wystąpić. Zalety aktywnego zarządzania kolejkami to: prewencyjne odrzucanie pakietów z pewnym prawdopodobieństwem, powodujące większą stabilność połączeń i płynność transmisji danych, przeciwdziałanie występowaniu przeciążeń, przeciwdziałanie globalnej synchronizacji, dzięki losowym utratom pojedynczego pakietu, a nie masowym stratom pakietów z powodu przepełnienia kolejki. Grupa algorytmów RED Algorytmy RED (ang. Random Early Detection lub Random Early Discard) mają za zadanie wczesną detekcję przeciążenia występującego w sieci na podstawie analizy długości kolejki. Twórcy algorytmu RED Sally Floyd i Van Jacobson w swoim artykule [40] wskazują, że przeznaczeniem tego typu mechanizmu jest kooperacja z protokołami transportowymi i jego mechanizmami zarządzania przeciążeniem. Algorytm typu RED był rozwiązaniem, które całkowicie odmieniło podejście do zasad odrzucania pakietów przebywających w kolejce. W przypadku pasyw-

58 58 Zarządzanie kolejką routera nego zarządzania kolejkami nowo napływające pakiety są odrzucane tylko w przypadku całkowitego zapełnienia bufora. W kolejce obsługiwanej zgodnie z algorytmem RED pakiety odrzucane są z pewnym wyprzedzeniem, gdy zapełnienie kolejki przekracza pewien założony poziom, ale gdy jest w niej jeszcze miejsce na przychodzące pakiety. Prace nad ideą wykorzystaną później w algorytmie RED rozpoczął już w 1989 roku E. Hashem [41], który zastąpił tradycyjne podejście, polegające na odrzucaniu pakietu z końca kolejki na rzecz losowego odrzucania. Polegało ono na wyrzuceniu dowolnie wylosowanego pakietu z kolejki w celu zwolnienia w niej miejsca na nowo przybyłą porcję danych. On również był twórcą idei wczesnego losowego odrzucania (ang. Early Random Drop), w której proponował, aby wykrywać przeciążenie przez przekroczenie przez kolejkę pewnego poziomu odrzucenia (ang. Drop Level). Przekroczenie tej granicy powodować miało wyrzucanie pakietów (a co za tym idzie wymuszenia na protokole transportowym zmniejszenia prędkości nadawania) w celu zmniejszenia zapełnienia kolejki poniżej pewnego poziomu. Do najpopularniejszych algorytmów z grupy RED należą: RED (ang. Random Elary Detection) mechanizm będący podstawą dla wszelkich kolejnych modyfikacji, podejmowanie decyzji o odrzuceniu pakietu na podstawie pewnej funkcji prawdopodobieństwa, jeżeli poziom zapełnienia kolejki jest pomiędzy dwoma wartościami progowymi Min th i Max th, ARED (ang. Adaptive Random Elary Detection) adaptowalna wersja algorytmu RED, polegająca na automatycznym dopasowaniu się parametrów mechanizmów do występującego ruchu w sieci, DSRED (ang. Double Slope Random Elary Detection) - podjęcie odpowiedniej decyzji dotyczącej nadchodzącego pakietu jest podejmowane na podstawie funkcji prawdopodobieństwa, której kształt zmienia się w dodatkowym punkcie kolejki Half th, NLRED (ang. Non Linear RED) - dla tej modyfikacji algorytmu funkcja prawdopodobieństwa odrzucania pakietu nie jest funkcją liniową, FRED (ang. Flow Random Early Detection) RED operujący na przepływach, do każdego przepływu przypisana jest odpowiednia kolejka, na podstawie jej długości oraz długości kolejki ogólnej podejmowany jest werdykt dotyczący odrzucenia pakietu,

59 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania SRED (ang. Stabilized Random Early Detection) algorytm równie operujący na przepływach. Mechanizm przechowuje listę aktywnych przepływów zwaną zombie list. Na podstawie jej zawartości oraz zawartości kolejki podejmowana jest decyzja o odrzuceniu pakietu [64], WRED (ang. Weighted Random Early Detection) w algorytmie tym występuje kilka kolejek mających różne wartości progów; pakiety umieszczane są w odpowiedniej kolejce na podstawie informacji zapisanej w pakiecie IP w polu ToS (ang.type of Service) [43]. Wielką zaleta tych algorytmów jest ich indywidualność. Oznacza ona, iż routery współpracujące ze sobą w sieci Internet nie potrzebują zaimplementowanych identycznych mechanizmów. Mogą również wykorzystywać standardową kolejkę FIFO. Poniżej zostaną szczegółowo opisane zasady działania wybranych algorytmów. Algorytm RED Działanie algorytmu RED opiera się na dwóch podstawowych mechanizmach. Pierwszy z nich to mechanizm obliczania tzw. kroczącej średniej długości kolejki, drugi to sposób obliczania prawdopodobieństwa odrzucenia pakietu. Prawdopodobieństwo odrzucenia pakietu zależy od wartości średniej kroczącej długości kolejki. Wartość średnia obliczana jest na podstawie wzoru 4.1. Zależy ona od aktualnej długości kolejki q, wartości średniej długości kolejki obliczonej w poprzednim kroku (avg i ) oraz wagi w. avg i+1 = (1 w)avg i + wq (4.1) W przypadku pustej kolejki średnią obliczamy na podstawie poniższego wzoru: avg i+1 = (1 w) f(time g_time) avg i (4.2) W przeszłości w wielu artykułach dokonywano analizy wpływu wartości parametru w na efektywność działania mechanizmu RED. Artykuły [44] i [45] rekomendowały ustawienie w na poziomie w = lub w = Artykuł [46] przedstawia efektywność mechanizmu dla w = 0.05 i w = W artykule [47] pokazano, jak dobór parametru w wpływa na ruch sieciowy. Analizy wykazały, że wzrost wartości parametru w wpływa na wzrost fluktuacji w ruchu sieciowym.

60 60 Zarządzanie kolejką routera W artykule [48] zaproponowano nieco inny sposób obliczania średniej długości kolejki zależnej od średniej obliczonej w kilku poprzednich iteracjach, a nie tylko od ostatnio obliczonej średniej. Według powyższej propozycji wzór obliczający średnią długość kolejki można przedstawić następująco: avg i+1 = a 1 avg i + a 2 avg i 1 + (1 a 1 a 2 b 1 ) q i + b 1 q i 1 (4.3) Dla zestawu parametrów [a 1, a 2, b 1 ] = [0.002, 0, 0] liczona średnia jest identyczna jak zaproponowana we wzorze 4.1. W artykule zaproponowano zestaw parametrów [a 1, a 2, b 1 ] = [0.08, , 0.001] i pokazano, że taki dobór liczenia średniej kroczącej może pozytywnie wpłynąć na transmisję danych. Prawdopodobieństwo odrzucenia pakietu zależy od wartości średniej kroczącej i jest opisane wzorem 4.4. Rysunek 4.6 przedstawia funkcję prawdopodobieństwa odrzucenia pakietu zależną od dwóch progów Min th oraz Max th. Pomiędzy nimi funkcja ta rośnie liniowo od 0 do wartości P max. Gdy avg przekroczy 1, wszystkie pakiety są odrzucane. Działanie kolejki przedstawia rysunek dla x < Min th p = ( avg Min th Max th Min th )P max dla Min th <= avg <= Max th 1 dla x > Max th Prosty opis działania algorytmu RED przedstawia listing 4.1. (4.4) Listing 4.1. Pseudokod algorytmu RED [49] I n i t i a l i z a t i o n : avq = 0 c o u n t = 1 f o r each p a c k e t a r r i v a l c a l c u l a t e t h e new a v e r a g e queue s i z e avq : i f t h e queue i s nonempty avq = (1 w) avg +w q e l s e m = f ( time q_time ) avg = (1 w) avq i f Min th <= avq < Max th i n c r e m e n t c o u n t

61 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania c a l c u l a t e p r o b a b i l i t y pa : pb = P max ( avg Min th ) / ( Max th Min th ) pa = pb(1 c o u n t pb ) with p r o b a b i l i t y pa : mark t h e a r r i v i n g p a c k e t c o u n t = 0 e l s e i f Max th <= avq mark t h e a r r i v i n g p a c k e t c o u n t = 0 e l s e c o u n t = 1 when queue becomes empty q_time = time Zapamiętywane zmienne : avq : ś r e d n i a długość k o l e j k i q_time : czas, od k t órego k o l e j k a p o z o s t a j e w bezczynnoś c i c o u n t : l i c z b a p a k i e t ów od o s t a t n i e g o o d r z u c e n i a S t a łe p a r a m e t r y : w: i n t e r w a ł c z a s u o b l i c z a n i a avq Min th : wartość minimalna progu d l a k o l e j k i Max th : wartość maksymalna progu d l a k o l e j k i P max : maksymalna wartość d l a pb P o z o s t a łe wartoś c i : pa : obecne prawdopodobieństwo o d r z u c e n i a p a k i e t u q : obecna długość k o l e j k i time : obecny c z a s f ( t ) : l i n i o w a f u n k c j a c z a s u t W artykule [44] potwierdzono następujące zalety algorytmu RED: przeciwdziałanie przeciążeniom w sieci poprzez odrzucanie pakietów proporcjonalnie do średniej długości kolejki (dla odpowiednio ustawionego parametru w), ominięcie problemu globalnej synchronizacji. W zależności od stopnia obciążenia mechanizm dokonuje gubienia porcji danych, zmniejszając okna dla poszczególnych przepływów (a nie dla wszystkich),

62 62 Zarządzanie kolejką routera Rys Funkcja prawdopodobieństwa wyrzucenia pakietu dla mechanizmu RED [49] Fig Dropping packet probability function for the RED mechanism [49] sprawiedliwość działania. Liczba traconych pakietów dla danego źródła uzależniona jest od przepustowości łącza, którą wykorzystuje, możliwość pracy w różnorodnych środowiskach mechanizm losowego odrzucania pakietów sprawia, że algorytm ten przeznaczony jest głównie dla sieci o: szerokiej przepustowości łącza, wysokiej wartości współczynnika RTT, dużej liczbie aktywnych połączeń. Dodatkową zaletą mechanizmu jest to, że nawet dla krótkich połączeń TCP lub połączeń niestosujących protokołu TCP, obciążenie sieci również jest sterowane przez wcześniejsze odrzucenie pakietów po przekroczeniu progu Min th. Największą wadą algorytmu RED jest duża trudność w doborze prawidłowych

63 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Max th Min th Rys Kolejka RED Fig RED queue [49] parametrów. Parametry te są stałe i niezmienne, a warunki panujące w sieci mogą ulegać częstym zmianom. Pewnym rozwiązaniem tego problemu jest zaproponowana modyfikacja, zwana Adaptive RED opisana w kolejnym podpunkcie. Algorytm ARED Algorytm ARED (ang. Adaptive RED) opisany w [50] jest rozszerzeniem opisanego wcześniej algorytmu RED. Celem modyfikacji było stworzenie mechanizmu automatycznie modyfikującego swoje parametry w zależności od ruchu sieciowego. Głównym celem stosowania RED jest uzyskanie niskich wartości opóźnienia pakietów oraz uzyskanie maksymalnej prędkości transmisji danych. W tradycyjnym mechanizmie dobór odpowiednich wartości parametrów mechanizmu jest niezmiernie trudny. Średnia zajętość kolejki przyjmuje wartości bliskie minimalnego progu Min th w przypadku małego obciążenia lub zbyt wysokiej wartości parametru P max. W przypadku dużego obciążenia lub zbyt małej wartości parametru P max zajętość kolejki przyjmuje wartości bliskie, a nawet przekraczające wartości Max th.

64 64 Zarządzanie kolejką routera Zadaniem mechanizmu ARED jest dostosowanie wartości P max celem uzyskania średniej długości kolejki pomiędzy wartościami Min th i Max th. Działanie algorytmu przedstawia listing 4.2. Listing 4.2. Pseudokod algorytmu ARED [50] Every i n t e r v a l s e c o n d s : i f ( avq > t a r g e t and P max <= 0, 5 ) / i n c r e a s e P max / P max = P max + α e l s e i f ( avq < t a r g e t and P max >= 0,01 ) / d e c r e a s e P max / P max = P max β Zapamiętywane zmienne : avq : ś r e d n i a długość k o l e j k i S t a łe p a r a m e t r y : i n t e r v a l : o d s t ęp czasu, co k t óry dokonywane są o b l i c z e n i a t a r g e t : wartość, do k t ó r e j dążyć bę d z i e avq α : współczynnik, o k t óry zwiększamy P max β : współczynnik, o k t óry zwiększamy P max Co pewien określony czas interval (twórcy algorytmu proponują 0,5 s) dokonywane jest sprawdzenie wartości target oraz P max. Wielkość target należy do przedziału zdefiniowanego jako: [Min th (Max th Min th ), Min th (Max th Min th )] (4.5) Jeśli średnia długość kolejki przekracza wartość target i jednocześnie P max jest mniejsze lub równe 0.5, parametr P max zwiększany jest o współczynnik α, definiowany jako mniejsza z wartości 0, 01 oraz P max /4. W przeciwnym wypadku parametr zmniejszany jest o iloczyn parametru P max oraz współczynnika β wynoszący 0.9. Celem algorytmu ARED jest nie tylko utrzymanie średniej długości kolejki pomiędzy progiem minimalnym i maksymalnym, lecz również utrzymanie zajętości kolejki dokładnie w połowie pomiędzy tymi wartościami. Wartość P max przyjmuje wartości pomiędzy 0.1 a 0.5. W zależności od przyjętych wartości P max prawdopodobieństwo odrzucenia pakietu dla zajętości kolejki wynoszącej Max th osiągnie wartości od 10% do 50%. Zmiany wartości P max przebiegają powoli i są

65 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania rzadkie. Odpowiednie dopasowanie parametru P max może zająć od około 10 do nawet 20 sekund. Dla sieci o dużej zmienności ruchu czas tych zmian może być całkowicie nieakceptowalny. Algorytm DSRED W algorytmie DSRED (ang. Double Slope RED) funkcja prawdopodobieństwa odrzucania pakietów składa się z dwóch różnych prostych [51]. Listing 4.3 przedstawia zasadę działania algorytmu. Listing 4.3. Pseudokod algorytmu DSRED [51] I n i t i a l i z a t i o n : avq = 0 f o r each p a c k e t a r r i v a l c a l c u l a t e t h e new a v e r a g e queue s i z e avq : i f Min th < avq queuing p a c k e t e l s e i f Min th <= avq < Half th c a l c u l a t e drop p r o b a b i l i t y based on s l o p e α drop p a c k e t e l s e i f Half th < avq <= Max th c a l c u l a t e drop p r o b a b i l i t y based on s l o p e β drop p a c k e t e l s e drop p a c k e t Zapamiętywane zmienne : avq : ś r e d n i a długość k o l e j k i S t a łe p a r a m e t r y : Min th : wartość minimalna progu d l a k o l e j k i Max th : wartość maksymalna progu d l a k o l e j k i Half th : wartość poś r e d n i a progu d l a k o l e j k i P o z o s t a łe wartoś c i : α o b l i c z a n y współ c z y n n i k świadczący o n a c h y l e n i u l i n i o w e j wartoś c i prawdopodobieństwa pomiędzy Min th i Half th, β o b l i c z a n y współ c z y n n i k świadczący o n a c h y l e n i u l i n i o w e j wartoś c i prawdopodobieństwa pomiędzy Half th i Max th.

66 66 Zarządzanie kolejką routera Nachylenie prostej prawdopodobieństwa odrzucania pakietów zależy od wartości średniej zajętości kolejki. W stosunku do standardowego algorytmu RED dołożono tutaj (oprócz Min th oraz Max th ) jeszcze jeden poziom Half th. I właśnie ten poziom decyduje o nachyleniu prostej. Jeżeli wartość średniej zajętości avg nie przekracza poziomu Half th, to prawdopodobieństwo utraty pakietu obliczono następująco: gdzie wpółczynnik α obliczono korzystając ze wzoru: p = α (avg Min th ) (4.6) α = 2 (1 γ) Max th Min th (4.7) Gdy zajętość kolejki przekroczy wartość Half th, to funkcja prawdopodobieństwa wygląda następująco: gdzie współczynnik β obliczono jako: p = 1 γ + β (avg Half th ) (4.8) β = 2 γ Max th Min th (4.9) gdzie: α to współczynnik nachylenia funkcji prawdopodobieństwa pierwszego segmentu bufora, β jest współczynnikiem nachylenia funkcji prawdopodobieństwa drugiego segmentu bufora, γ to współczynnik regulujący nachylenie wartości liniowej funkcji prawdopodobieństwa. Zależności prawdopodobieństwa straty pakietu w zależności od średniej długości kolejki oblicza się na podstawie wzoru: (4.10) 0 dla x < Min th α (avg Min p = th ) dla Min th <= x <= Half th 1 γ + β (avg Half th ) dla Half th <= x <= Half th 1 dla x > Max th

67 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Przebieg funkcji prawdopodobieństwa strat pakietu przedstawia rysunek 4.8. Pierwsza część wykresu pomiędzy progiem minimalnym a przejściowym jest bardziej nachylona. W przypadku mniejszego zapełnienia kolejki straty pakietów są również małe. Po przekroczeniu progu Half th funkcja prawdopodobieństwa strat jest bardziej stroma, co staje się powodem szybszego wzrostu strat pakietów dla bardziej zapełnionej kolejki. Poglądowy rysunek kolejki DSRED przedstawiono na rysunku 4.9. p 1 ϒ Min th Half th Max th avg Rys Funkcja prawdopodobieństwa wyrzucenia pakietu dla mechanizmu DSRED [51] Fig Dropping packet probability function for the DSRED mechanism [51] Algorytm NLRED Algorytmy typu NLRED (ang. Non Linear RED) to grupa algorytmów, dla których funkcja prawdopodobieństwa odrzucania pakietów nie jest funkcją liniową. Pierwsza tego typu modyfikacja [52] funkcji prawdopodobieństwa straty pakietu polegała na zamianie funkcji liniowej na funkcję kwadratową opisaną wzorem: (4.11) 0 for x < Min th p = ( avg Min th Max th Min th ) 2 P max for Min th <= x <= Max th 1 for x > Max th

68 68 Zarządzanie kolejką routera Max th Half th Min th Rys Kolejka DSRED Fig DSRED queue Zalety mechanizmu są podobne jak w przypadku algorytmu DSRED. W stosunku do normalnego REDa prawdopodobieństwo strat pakietu rośnie znacząco, gdy zapełnienie kolejki zbliża się do poziomu Max th (rysunek 4.10). Analiza wpływu kształtu funkcji prawdopodobieństwa odrzucania pakietów na takie parametry kolejki, jak średni czas oczekiwania pakietów w kolejce, straty oraz średnia długość kolejki była omawiana w wielu pracach. W artykułach [53], [54] zaproponowano funkcję opartą na krzywych wielomianowych. Funkcja prawdopodobieństwa straty pakietu wygląda dla tego rozwiązania następująco: p(avg, a 1, a 2, p max ) = gdzie: (4.12) 0 for avg < Min th ϕ 0 (avg)+ +a 1 ϕ 1 (avg)+ +a 2 ϕ 2 (avg) for Min th <= avg <= Max th 1 for avg > Max th avg Min th ϕ 0 (avg) = p max, (4.13) Max th Min th

69 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania p 1 NLRED Min th Max th avg Rys Funkcje prawdopodobieństwa odrzucania pakietu dla mechanizmów RED oraz NLRED [52] Fig Dropping packet probability function for the RED and NLRED mechanisms [52] ϕ 1 (avg) = (avg Min th )(Max th avg), (4.14) ϕ 2 (avg) = (avg Min th ) 2 (Max th avg) (4.15) Rozwiązanie to okazało się niezwykle elastyczne. Dla odpowiedniego doboru parametrów można uzyskać krzywą dającą efekty podobne do krzywej kwadratowej (rysunek 4.11). Przez odpowiedni dobór parametrów krzywej prawdopodobieństwa strat można uzyskać różne właściwości mechanizmu RED. Właściwości te przedstawia rysunek Krzywa położona najwyżej powoduje znaczne straty pakietów, skracając średni czas oczekiwania pakietów w kolejce. Funkcjonalność krzywej zaznaczonej kolorem szarym jest dokładnie odwrotna.

70 70 Zarządzanie kolejką routera p avg Rys Funkcja prawdopodobieństwa odrzucania pakietu dla NLRED P max =0.6, a 1 =- 0,00006, a 2 =-0, [53] Fig Dropping packet probability function for the NLRED P max =0.6, a 1 =-0,00006, a 2 =-0, [53] Rys Zbiór funkcji prawdopodobieństwa odrzucania pakietu dla NLRED opartego na krzywych wielomianowych [54] Fig Probability dropping packet function for the NLRED based on polynomials [54]

71 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Algorytmy CHOKE Start NewMsg= nowy nadchodzący pakiet avg = (1 w_q) * avg + w_q * q msg = wyrzuć pakiet Z kolejki newmsq->flowid == msg->flowid Tak Wyrzuć oba pakiety: Msg oraz Newmsg Nie avg <= min_th Nie Tak Akceptuj pakiet newmsg avg <= max_th Tak Zwróć pakiet msg Nie Zwróć pakiet msg Nie p_red = p_max * (avg min_th) / (max_th min_th) Tak Wyrzuć pakiet newmsg Koniec Rys Schemat blokowy algorytmu CHOKe Fig CHOKe algorithm flowchart Algorytm CHOKe w stosunku do poprzednio opisanych mechanizmów realizuje aktywne zarządzanie pakietami w odmienny sposób. Należy on do grupy algorytmów AQM, których celem jest sprawiedliwy podział łącza pomiędzy większą liczbę strumieni danych. W ogólnym zarysie faworyzuje on transmisje mało intensywne i dyskryminuje strumienie generujące większą liczbę pakietów [55]. Podobnie jak w przypadku algorytmu RED mechanizm definiuje dwa progi: Min th i Max th. Kiedy nadchodzi nowy pakiet, to tak jak dla algorytmu RED obliczana jest nowa średnia zajętość kolejki. W przypadku gdy jest ona mniejsza niż Min th, to wszystkie pakiety umieszczane są w buforze. Kiedy średnia zajętość kolejki jest większa od Min th, to mechanizm CHOKe losuje dowolny pakiet z kolejki FIFO (nazwany CHOKe victim ) i sprawdza, czy nie pochodzi on z tego samego strumienia co pakiet nadchodzący. Jeżeli tak, to oba pakiety są usuwane z kolejki (ta sytuacja nazywana jest CHOKe hit ). W przeciwnym wy-

72 72 Zarządzanie kolejką routera Start avg = 0 min_th max_th avg = (1 w_q) * avg + w_q * q avg <= min_th Tak Akcept. pakiet newmsg Nie avg <= max_th Nie Nie newmsg->flowid exists in lookup table? Tak trafienie Tak P* = min(1, p_red * 2^n) zaznacz newmsg newmsg lub msg zaznacz Wyrzuć msg lub newmsg l zaznacz newmsg Tak Yes Nie Nie cmessage msg = getpacket(cqueue queue, int randomindex) Tak newmsq->flowid == msg- >flowid? Tak, CHOKe trafienie Zaznacz oba pakiety: newmsg i msg do usunięcia, ustaw licznik trafień dla danego strumienia =1 Nie p_red = p_max * (avg min_th) / (max_th min_th) Zaznacz oba pakiety: newmsg i msg do usunięcia, inkrementuj licznik trafień dla danego strumienia Zwróć pakiet msg Czy strumień jest w tablicy trafień? Tak Nie Koniec Nie Rys Schemat blokowy algorytmu xchoke Fig xchoke algorithm flowchart padku pakiet CHOKe victim wraca do kolejki, a nadchodzący pakiet jest w niej umieszczany z prawdopodobieństwem P, obliczanym w taki sam sposób jak dla algorytmu RED (ta sytuacja została nazwana CHOKe miss ). Zasadę działania algorytmu przedstawia rysunek Algorytm xchoke pamięta zdarzenia CHOKe hit w specjalnej tablicy nazwanej lookup table [56]. Algorytm również zaczyna działać, gdy średnia zajętość kolejki jest pomiędzy Min th i Max th. Dla wszystkich nadchodzących pakietów algorytm skanuje lookup table w celu odnalezienia identyfikatora strumienia identycznego z identyfikatorem nadchodzącego pakietu. Jeżeli takie id zostanie znalezione ( table hit ), to nadchodzący pakiet jest usuwany z prawdopodobieństwem P. Nadchodzący pakiet jest porównywany z pakietem wylosowanym z kolejki ( CHOKe victim ). Jeśli oba należą do tego samego strumienia, to oba są odrzucane, a mechanizm xchoke skanuje lookup table jeszcze raz w celu znalezienia id strumienia identycznego z id wyrzuconego pakietu. W przypadku skanowania zakończonego sukcesem, mechanizm inkrementuje wartość hit co-

73 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Start NewMsg= Nowy nadchodzący pakiet msg = wyrzuć pakiet z kolejki newmsq->flowid == msg->flowid Tak counter++ Nie avg = (1 w_q) * avg + w_q * q avg <= min_th Nie counter < maxcomp Tak Nie Wyrzuć wszyskie Zamarkowane pakiety Tak Akceptuj pakiet newmsg avg <= max_th Tak Nie Zwróć pakiet msg Zwróć pakiet msg Nie p_red = p_max * (avg min_th) / (max_th min_th) Tak Wyrzuć pakiet Koniec Rys Schemat blokowy algorytmu gchoke Fig gchoke algorithm flowchart unter powiązaną ze znalezionym id. W przeciwnym wypadku tworzy odpowiedni wpis do tablicy, a hit counter ustawia na jeden (rysunek 4.14). Algorytm gchoke (ang. Geometric Choke) jest modyfikacją standardowego algorytmu CHOKe zaproponowaną w pracy [57]. Algorytm ten ma dodatkowy, konfigurowalny parametr maxcomp [1.. ). Parametr ten determinuje maksymalną liczbę trafionych porównań. Algorytm porównuje nadchodzący pakiet z losowo wybranym z kolejki ( CHOKe Victim ). Porównanie jest trafione, jeżeli oba pochodzą z tego samego strumienia. Porównywanie kończy się, jeżeli będzie nietrafione lub osiągniemy maksymalną liczbę porównań (maxcomp).wszystkie trafione pakiety, wraz z nadchodzącym, są usuwane z kolejki. Jeśli pierwsze porównanie nie zakończy się sukcesem, to pakiet CHOKe victim wraca do kolejki, a nadchodzący pakiet jest w niej umieszczany z prawdopodobieństwem P (rysunek 4.15).

74 74 Zarządzanie kolejką routera Algorytm FRED Dla algorytm FRED (ang. Flow RED) router również zarządza strumieniami znajdującymi się w kolejce. Jego zadaniem jest kontrola, czy liczba pakietów z danego przepływu nie przekracza pewnego określonego progu. Algorytm FRED zapewnia większą uczciwość obsługi dla różnych rodzajów ruchu [58]. Listing 4.4. Pseudokod przedstawiający algorytm FRED [58] f o r each a r r i v i n g p a c k e t P : i f flow i = conn ( P ) has no s t a t e t a b l e q l e n i = 0 ; s t r i k e i = 0 ; i f queue i s empty c a l c u l a t e a v e r a g e queue l e n g t h avg maxq = minth ; i f ( avg >= maxth ) maxq = 2 ; i f ( q l e n i >= maxq ( avg >= maxth && q l e n i > 2 avgcq ) ( q l e n i >= avgcq && s t r i k e i > 1 ) ) s t r i k e i ++; drop p a c k e t P ; r e t u r n ; i f ( minth <= avg < maxth ) { c o u n t = c o u n t + 1 ; i f ( q l e n i >= MAX( minq, avgcq ) ) c a l c u l a t e p r o b a b i l i t y pa : pb = maxp ( avg minth ) / ( maxth minth ) ; pa = pb / ( 1 c o u n t pb ) ; with p r o b a b i l i t y pa : drop p a c k e t P ; c o u n t = 0 ; r e t u r n ; e l s e i f ( avg < minth ) c o u n t = 1; e l s e drop t a i l mode : c o u n t = 0 ;

75 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania drop p a c k e t P ; r e t u r n ; i f ( q l e n i == 0) N a c t i v e ++; c a l c u l a t e a v e r a g e queue l e n g t h a c c e p t p a c k e t P ; f o r each d e p a r t i n g p a c k e t P : c a l c u l a t e a v e r a g e queue l e n g t h i f ( q l e n i == 0) { Nactive ; d e l e t e s t a t e t a b l e f o r flow i ; c a l c u l a t e a v e r a g e queue l e n g t h : i f ( q p a c k e t d e p a r t e d ) avg = (1 wq) avg + wq q ; e l s e m = f ( t ime q_time ) ; avg = (1 wq )m avg ; q_time = time ; i f ( N a c t i v e ) avgcq = avg / N a c t i v e ; e l s e avgcq = avg ; avgcq = MAX( avgcq, 1 ) ; i f q == 0 && p a c k e t d e p a r t e d q_time = time ; S t a łe p a r a m e t r y : w = ; minth = wartość minimalna z ( w i e l kość b u f o r a ) / 4 l u b RTT maxth = 2 minth ; maxp = ; minq minimalna w i e l kość b u f o r a d l a danego p r z e p ływu = 2 d l a małego b u f o r a = 4 d l a b u f o r a dużego

76 76 Zarządzanie kolejką routera Zmienne g l o b a l n e : q : obecna długość k o l e j k i time : a k t u a l n y c z a s avg : ś r e d n i a długość k o l e j k i c o u n t : l i c z b a p a k i e t ów od o s t a t n i e g o o d r z u c e n i a avgcq : ś r e d n i a długość k o l e j k i na p r z e p ływ maxq : maksymalna d o p u s z c z a l n a długość k o l e j k i d l a j e d n e g o p r z e p ływu Zmienne d l a p r z e p ływu : q l e n i : l i c z b a p a k i e t ów danego p r z e p ływu z n a j d u j ących s i ę w k o l e j c e s t r i k e i : l i c z b a p a k i e t ów ponad d o p u s z c z a l n y s t a n d l a p r z e p ływu Funkcje mapujące : conn ( P ) : połą c z e n i e p a k i e t u i d z p a k i e t e m p f ( time ) : l i n i o w a f u n k c j a z a l e żnoś c i c z a s o w e j Listing 4.4 pokazuje algorytm działania mechanizmu FRED. Każdy przybywający nowy pakiet zostaje sprawdzony, a sprawdzenie to polega na identyfikacji przepływu, z którego się wywodzi. Źródła pochodzenia pakietów, a więc ich przepływy, uznawane są za identyczne, jeśli mają jednakowy adres docelowy i źródłowy, numery portu oraz rodzaj użytego protokołu. Na podstawie tego sprawdzenia, jeśli w wyniku jego wykonania okaże się, że pakiet pochodzi z przepływu niewystępującego obecnie w kolejce, zostają zainicjalizowane dla niego zmienne przechowujące dane na temat liczby pakietów oraz liczby nadmiarowych porcji danych. Dodatkowo informacja o tym przepływie umieszczona zostaje w tablicy stanów zawierającej dane na temat aktywnych przepływów. Kolejnym krokiem jest sprawdzenie zajętości kolejki. Jeżeli okazuje się pusta, to obliczona zostaje jej średnia długość. Parametr maxq przechowuje informację o liczbie maksymalnie dopuszczanych pakietów w buforze przypadających na dany przepływ. Dopóki średnia długość kolejki nie przekroczy progu górnego, zmienna ta przyjmuje wartość progu dolnego, w przeciwnym razie ustawione zostaje dopuszczenie tylko dwóch pakietów w kolejce przypadające na jeden przepływ. Kolejna część pseudokodu jest odpowiedzialna za zarządzanie nadmiarowym ruchem pojawiającym się w sieci. Algorytm FRED pilnuje, aby liczba pakietów dla danego przepływu nie przekroczyła wartości maksymalnej maxq. Dla przepływów próbujących przekroczyć tę wartość zwiększany zostaje wskaźnik świadczący o próbie nadużycia (strikei).

77 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Pakiety z przepływów z wysoką wartością wskaźnika strikei wstawiane są do kolejki w liczbie nie większej niż średnia długość kolejki (avcq) przeznaczonej dla tego konkretnego przepływu. Kolejnym fragmentem algorytmu jest blok odpowiedzialny za zarządzanie kolejkami w trybie losowym. Średnia długość kolejki kształtuje się w przedziale pomiędzy górnym a dolnym progiem. Zwiększona zostaje liczba obsłużonych pakietów count, a następnie sprawdzona zostaje długość kolejki przypadająca na przepływ qleni, dla której przekroczenie powyżej maksymalnej wartości spośród minimalnej wielkości kolejki przypadającej na przepływ minq lub średniej długości kolejki na przepływ avcq powoduje odrzucenie pakietu z prawdopodobieństwem obliczanym według wzoru 4.4. Jeżeli program nie przejdzie do wcześniej wymienionych trybów (losowego lub sterowania ruchem nieadaptowalnym) oraz jeśli średnia długość kolejki mniejsza jest od progu dolnego, wtedy mechanizm umieszcza w kolejce wszystkie nadchodzące pakiety, ustawiając wartość count na 1. Jeżeli żaden z wcześniej wymienionych warunków nie zostanie spełniony, następuje przejście do trybu odrzucania porcji danych z końca kolejki. Następnie dokonywane jest sprawdzenie, czy kolejka dla nowego przepływu jest pusta, jeśli tak, to pakiet jest w niej umieszczany, a liczba aktywnych przepływów znajdujących się w kolejce N active zostaje inkrementowana. Następnie następuje obliczenie średniej długości kolejki oraz obliczona zostaje średnia długość kolejki przypadająca na jeden przepływ jako iloraz średniej długości kolejki i liczbie aktywnych przepływów. Twórcy algorytmu zwracają szczególną uwagę na fakt, że w ich rozwiązaniu bardzo często dokonywane zostaje obliczenie wartości avq (zgodnie ze wzorami 4.1 i 4.2), nie tylko dla pakietów przychodzących, ale również przy każdorazowym opuszczeniu kolejki przez porcję danych. Opuszczenie kolejki przez pakiet powoduje dodatkowo sprawdzenie, czy w kolejce znajdują się jeszcze inne pakiety należące do danego przepływu. Jeśli nie, to liczba aktywnych przepływów zostaje dekrementowana, a informacja o nim zostaje usunięta z tablicy stanów przepływów. Autorzy algorytmu wprowadzili kategoryzację ruchu i założyli, że algorytm dostosowuje działanie do następujących kategorii: ruch nieadaptowalny (ang. Non-adaptive) połączenie tego typu wykorzystuje całą przepustowość łącza wymaganą do dokonania transmisji i nie obniża prędkości transmisji podczas wystąpienia przeciążenia. Niektóre aplikacje audio i video korzystają z tego typu ruchu; ruch zdecydowany (ang. Robust) połączenie zawsze posiada jakieś dane, do nadania lub odebrania wykorzystuje do tego celu całą dostępną przepu-

78 78 Zarządzanie kolejką routera stowość. W przypadku przeciążenia dopuszczalne jest zmniejszenie prędkości transmisji, przy czym ruch wykorzystuje każdą pojawiającą się wolną przepustowość dla przyspieszania transmisji; ruch wrażliwy (ang. Fragile) połączenie stara się unikać przeciążeń dzięki swojemu dopasowaniu do pojawiających się obciążeń sieci. Zazwyczaj posiada mniej pakietów w kolejce niż ruch zdecydowany; wynika to z faktu, że wywodzi się on z ruchu terminalowego, w którym rzadziej pojawia się żądanie transmisji, co jakiś czas wysyłane są jednak małe porcje danych. Algorytm BLACK Istnieją dwie modyfikacje algorytmu BLACK [59]: bez pamięci podręcznej, z pamięcią podręczną. Wersje te znacznie się różnią, dlatego należy je rozpatrywać jako dwa zupełnie odrębne mechanizmy. Algorytm BLACK bez pamięci podręcznej Zadaniem algorytmu jest analiza stanu strumieni danych. Na podstawie tej analizy podejmowana jest decyzja o ewentualnym odrzuceniu pakietów. Po przyjściu pakietu mechanizm losuje inny dowolny pakiet z kolejki i sprawdza, czy pakiet nadchodzący i pakiet wylosowany są z tego samego i-tego przepływu. Jeśli tak, to zmienna Hit i jest zwiększana o jeden. Po m nadejściach pakietów zostaje oszacowana zmienna Hitfraction i, która jest przewidywaną liczbą pakietów z i-tego strumienia obliczaną jako Hit. Aby zmniejszyć fluktuacje zmiennej Hitfraction i oblicza się jej średnią m ważoną: Hest i = (1 α) Hest i + α Hitfraction i (4.16) gdzie α to współczynnik wagi (liczba z przedziału (0,1)). Równocześnie dochodzi do oszacowania liczby wszystkich przepływów w kolejce. Gdy losowanie opisane powyżej jest zgodne, to zwiększona zostaje o jeden zmienna Match. Po m próbach liczba aktywnych strumieni Nact to: m. Match

79 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Algorytm zachowuje się bardzo podobnie do normalnego algorytmu RED. Prawdopodobieństwo odrzucenia pakietów P jest ograniczone przez parametr P i : gdzie wartość P i obliczana jest ze wzoru: P = ( avg Min th Max th Min th )P i (4.17) gdzie: P i = H i 1 Nact 1 Nact H i = Hit i + (Hest i m) m + m a m to aktualna liczba próbek. (4.18) (4.19) Algorytm BLACK z pamięcia podręczna Dla każdego nadchodzącego pakietu mechanizm przegląda specjalną listę LRU (ang. last recently used), tj. listę przepływów w celu znalezienia tego, do którego należy nadchodzący pakiet. Jeśli taki rekord zostaje znaleziony, to ten rekord jest przesuwany na sam początek listy, a zmienna Hit jest inkrementowana. Jeżeli nie znaleziono takiego strumienia, to z prawdopodobieństwem 0.05 następuje zamiana z ostatnim rekordem w LRU (pod warunkiem że zmienna Hitf raction ostatniego rekordu jest większa niż 1/N act). Dalsze działanie algorytmu jest zgodne z algorytmem BLACK w wersji bez pamięci podręcznej. Dla rozmiaru pamięci podręcznej LRU równej 0 algorytm będzie się zachowywał jak algorytm RED, w którym zmienna P max = 1. Algorytm BRED Algorytm BRED (ang. Balanced RED) opisany w [60] swoje działanie uzależnia od strumieni przepływających przez kolejkę. Dla nadchodzącego pakietu sprawdzany jest strumień, do którego on należy. Następnie mechanizm sprawdza, czy istnieje zmienna stanu Qlen i opisująca ten przepływ. Jeżeli nie, to zmienna zostaje zainicjowana i zostaje jej nadana wartość 0. Jeżeli zmienna istnieje i ma wartość 0, to zostaje ona zinkrementowana. Po dokonaniu tej czynności mechanizm przechodzi do sprawdzenia następujących warunków:

80 80 Zarządzanie kolejką routera jeżeli Qlen i > W m lub nastąpiło przepełnienie bufora, to pakiet zostaje odrzucony (W m maksymalna liczba pakietów w buforze dla danego strumienia), jeżeli W m > Qlen i > l 2, to pakiet zostaje odrzucony z prawdopodobieństwem P 2, jeżeli l 2 > Qlen i > l 1, to pakiet zostaje odrzucony z prawdopodobieństwem P 1, dla Qlen i < l 1 pakiet zostaje wstawiony do kolejki, a zmienna Qlen i zostaje powiększona o jeden. Podczas pobierania pakietu z kolejki zmienna Qlen i zostaje pomniejszona o 1. Jeśli Qlen i = 0, to parametr Nactive zostaje pomniejszony o 1. Parametry l 1, l 2, P 1, P 2 obliczane są dla każdej zmiany w buforze według następujących wzorów: l 1 = β l 2, dla0 β < 1 (4.20) l 2 = Q 2 N (4.21) P 1 = p 2 (4.22) 10 N P 2 = (4.23) N + 10 gdzie: Q to rozmiar bufora, a N to średnia ważona liczby przepływów. Parametr Nactive obliczyć można na podstawie wzoru: N = (1 w) N + Nactive w (4.24) Autorzy algorytmu zaproponowali, aby parametr wagi w = Natomiast maksymalną liczbę pakietów dla danego strumienia W n szacuje się na podstawie wzoru: Q W m = (4.25) Nactive

81 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Algorytm GREEN Zadaniem algorytmu GREEN jest jak największe wykorzystanie łącza przy równoczesnej minimalizacji opóźnień oraz strat pakietów [61]. Dla każdego nadchodzącego pakietu szacowana jest tzw. przepustowość wejściowa x est, a następnie pakiet jest odrzucany z prawdopodobieństwem P. Prawdopodobieństwo to jest zmienne w czasie i zależy od wartości funkcji U: gdzie: x est estymator przepustowości wejściowej, c t przepustowość wyjściowa, P kwant zmiany prawdopodobieństwa, U funkcja zdefiniowana następująco: P = P + P U(x est c t ) (4.26) U(x) = Estymator x est oblicza się następująco: { +1 dla x 0 1 dla x < 0 (4.27) x est = (1 e Del B K ) T e Del K xest_old (4.28) gdzie: Del czas pomiędzy nadejściami pakietów, K stała, B rozmiar pakietu. Jeżeli parametr x est (przepustowość wejściowa) jest większy lub równy c t (przepustowość wyjściowa), to prawdopodobieństwo odrzucenia pakietu P zwiększane jest o P. W przeciwnym razie prawdopodobieństwo zmniejszane jest o P. Zmiana prawdopodobieństwa P odbywa się co T. Sprawność mechanizmu jest zależna od ustawień następujących parametrów: c t przepustowość wyjściowa, P kwant zmiany prawdopodobieństwa P, T odstęp czasu pomiędzy kolejnymi zmianami prawdopodobieństwa P, k stała wykorzystywana do obliczania x est.

82 82 Zarządzanie kolejką routera Algorytm REM Algorytm REM (ang. Random Exponential Marking) dopasowuje wymagania źródeł do warunków panujących w sieci [28]. W tym celu została zdefiniowana zmienna kosztu: p l (t + 1) = max(0, p l (t) + γ (α (b l (t) b ) + x l (t) c l (t))) (4.29) gdzie: 0 < γ << 1, 0 < α, b l (t) aktualne zapełnienie bufora, b pożądane zapełnienie bufora (do którego algorytm dąży), x l (t) przepustowość wejściowa, c l (t) przepustowość wyjściowa. Wyrażenie x l (t) c l (t) to niedopasowanie przepustowości, a wyrażenie b l (t) b opisuje niedopasowanie zajętości bufora. Wartość tych dwóch wyrażeń przeskalowana o współczynniki α i γ wpływa na wzrost lub spadek wartości kosztu p l. Ze względu na trudność z pomiarem przepustowości wzór ten został przekształcony do postaci: p l (t + 1) = max(0, p l (t) + γ (b l (t + 1) (1 α) b i (t) α b )) (4.30) w której wyrażenie x l (t) c l (t) zastąpiono wyrażeniem b l (t + 1) b i (t) (zamiast szacowania przepustowości algorytm szacuje zmiany zajętości bufora). Tak obliczony koszt zostaje wykorzystany do obliczenia prawdopodobieństwa wyrzucenia pakietu: P i = 1 θ p l(t) (4.31) Ze względu na łatwość implementacji sprzętowej parametr θ przyjmuje wartość wielokrotności liczby 2. Sprawność mechanizmu jest zależna od doboru następujących parametrów: α, γ współczynniki służące do obliczania kosztu, b pożądana zajętość bufora, θ parametr służący do obliczania prawdopodobieństwa odrzucenia pakietu P i.

83 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Algorytm BLUE Algorytmu BLUE [62] prawdopodobieństwo odrzucenia pakietu P m uzależnia od dwóch zdarzeń: jeżeli kolejka jest pełna, to pakiet jest odrzucany, a parametr P m jest zwiększany o wartość d1, o ile od ostatniej aktualizacji upłynął kwant czasu f reeze_time, jeżeli kolejka jest pusta, to parametr P m zostaje zmniejszony o wartość d2, o ile od ostatniej aktualizacji upłynął kwant czasu freeze_time. Uproszczony algorytm działania mechanizmu BLUE został przedstawiony na listingu 4.5. Listing 4.5. Pseudokod algorytmu BLUE [62] A f t e r d r o p p i n g p a c k e t and i f b u f f e r i s f u l l : i f ( ( now l a s t _ u p d a t e ) > f r e e z e _ t i m e ) { pm = pm + d1 ; l a s t _ u p d a t e = now ; } I f b u f f e r i s empty : i f ( ( now l a s t _ u p d a t e ) > f r e e z e _ t i m e ) { pm = pm d2 ; l a s t _ u p d a t e = now ; } f o r each p a c k e t a r r i v a l : d r o p _ p a c k e t w ith p r o b a b i l i t y P m Sprawność mechanizmu jest zależna od doboru następujących parametrów: d1, d2 współczynniki zwiększające lub zmniejszające prawdopodobieństwo P m, f reeze_time kwant czasu, od którego upłynięcia uzależniona jest zmiana P m. Algorytm SFB Algorytm SFB (Stochastic Fair Blue) [63] dzieli kolejkę na L poziomów i N kubełków na każdym poziomie. Każdy kubełek ma własne prawdopodobieństwo

84 84 Zarządzanie kolejką routera odrzucania pakietów P m definiowane tak jak dla algorytmu BLUE (podrozdział 4.3). Każdy nadchodzący pakiet na podstawie identyfikatora przepływu jest wkładany do jednego kubełka na każdym poziomie. Klasyfikacja odbywa się za pomocą funkcji haszujących (postać tych funkcji nie jest jawnie zdefiniowana przez twórców algorytmu). Po klasyfikacji w L kubełkach algorytm szuka minimum wśród nich. To minimum staje się prawdopodobieństwem odrzucenia pakietu. Uproszczony algorytm działania został przedstawiony w listingu 4.6. Listing 4.6. Pseudokod algorytmu SFB [63] B[ l ] [ n ] : L x N a r r a y of b i n s enque ( ) c a l c u l a t e h a s h e s h0, h1... hl 1 u p d a t e b i n s a t each l e v e l f o r i = 0 t o L 1: i f (B[ i ] [ h i ]. q l e n > b i n S i z e ) B[ i ] [ h i ]. pm += d e l t a ; Drop p a c k e t ; e l s e i f (B[ i ] [ h i ]. q l e n == 0 ) : B[ i ] [ h i ]. pm = d e l t a ; pmin = min (B [ 0 ] [ h0 ]. pm... B[ L ] [ h l ]. pn ) i f ( pmin == 1 ) : r a t e l i m i t ( ) ; e l s e : Drop p a c k e t with p r o b a b i l i t y pmin Na rysunku 4.16 przedstawiona została sytuacja przydzielania dwóch przepływów do kubełków.strumień UDP nie dostosowuje prędkości do przeciążeń tak jak strumień TCP. Można więc założyć, że w każdym kubełku dojdzie do przekroczenia wartości binsize i wzrostu prawdopodobieństwa odrzucenia pakietów do 1. Taki sposób ograniczenia strumieni UDP pozwoli strumieniom samoograniczającym (TCP) na korzystanie z łącza. Parametry algorytmu (oprócz tych wykorzystywanych przez algorytm BLUE) to: L liczba poziomów, N liczba kubełków na każdym poziomie.

85 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania h0 h1 hl-2 hl-1 P=0.3 Strumień UDP Pmin=1.0 P=1.0 P=1.0 P=0.2 Strumień TCP Pmin=0.2 P=1.0 P=0.2 N-1 P=1.0 Rys Przykładowy przydział strumieni [63] Fig An example streams allocation [63] Algorytm SRED Mechanizm SRED (ang. Stabilized RED) [64] stosuje do sterowania strumieniami specjalną listę zwaną zombie list. W liście tej przechowywany jest: identyfikator przepływu, liczba trafień (Count) oraz parametr time_stamp. Lista zombie nie zawiera informacji o wszystkich możliwych przepływach. Aby skrócić czas przeszukiwania tej listy, przechowuje ona informację tylko o ostatnich M przepływach. Na początku lista zombie jest pusta. Wraz z nadchodzącymi pakietami lista ta jest zapełniania. Parametr Count ustawiany jest na 0, a time_stamp przechowuje czas nadejścia konkretnego pakietu. Sytuacja ta trwa aż do całkowitego zapełnienia listy. Gdy lista jest już całkowicie pełna, algorytm zmienia zasadę działania. Nadejście pakietu powoduje wylosowanie z listy zombie dowolnego pakietu. Jeśli oba pakiety (wylosowany i nadchodzący) należą do tego samego strumienia, to nastąpiło trafienie i zmienna Count zwiększana jest o jeden. W prze-

86 86 Zarządzanie kolejką routera ciwnym wypadku (nie było trafienia) dochodzi, z prawdopodobieństwem p, do zamiany w liście zombie przybyłego pakietu z wylosowanym. Jeżeli doszło do wymiany, to zmienna Count (skojarzoną z świeżo włożonym pakietem) ustawiona zostaje na 0. Po tych czynnościach mechanizm sprawdza, czy przybyły pakiet ostatecznie znajduje się na liście. Jeżeli tak, to zostaje obliczony tzw. estymator trafień: P (t) = (1 α) P (t 1) + α Hit(t) (4.32) gdzie: α waga z przedziału (0,1), Hit funkcja zdefiniowana jako: Hit(t) = { 0, jeśli nie było trafienia 1, jeśli było trafienie (4.33) Do obliczenia prawdopodobieństwa odrzucenia pakietu z kolejki korzystamy ze wzoru: 1 P zap = P sred (q) min(1, (256 P (t)) ) (4.34) 2 gdzie: P max dla 1Q q < Q 3 1 P sred (q) = 4 P max dla 1Q q < 1Q dla 0 q < 1Q 3 (4.35) gdzie: Q rozmiar bufora, q aktualny rozmiar kolejki, P max maksymalne prawdopodobieństwo odrzucenia pakietu, p prawdopodobieństwo wymiany pakietów na liście zombie (autorzy zaproponowali prawdopodobieństwo 0.25), M rozmiar zombie list (autorzy algorytmu zaproponowali 1000).

87 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Kontroler PI λ D µ Regulator proporcjonalno-całkująco-różniczkujący (ang. proportionalintegral-derivative controller) zwany skrótowo PID jest często stosowany w przemysłowych układach regulacji [65]. Jego zadaniem jest utrzymanie wartości wyjściowej sygnału na pewnym założonym poziomie. Zadaniem regulatora jest obliczenie wartości uchybu, czyli różnicy pomiędzy wartością pożądaną a aktualnie zmierzoną wartością jakiegoś procesu. Proces obliczeń składa się z trzech oddzielnych etapów i dlatego mówi się o trzech członach regulatora: proporcjonalnym, całkującym i różniczkującym. Każdy z członów ma inne zadania do spełnienia. Część proporcjonalna kompensuje uchyb aktualny, całkująca kompensuje akumulację uchybów z przeszłości, a różniczkująca kompensuje przewidywane uchyby w przyszłości. Algorytm realizowany przez regulator, przedstawiony w postaci dyskretnej, określa wzór [66]: G(s) = K p + K i 1 s + K ds (4.36) Ideę wykorzystania regulatora jako mechanizmu aktywnego zarządzania kolejkami zaproponowano w [67]. W artykule porównano działanie standardowego algorytmu RED z kontrolerem PI (bez modułu różniczkującego). Idea wykorzystania regulatora PID jako mechanizmu AQM jest prosta: na początku zostaje ustalony pożądany rozmiar kolejki, a obliczony uchyb wpływa na prawdopodobieństwo odrzucenia pakietu. Kolejnym etapem rozwoju prac nad kontrolerami PID było wykorzystanie do tych celów rachunku różniczkowo-całkowego niecałkowitych rzędów. Jak wykazały badania, w wielu dziedzinach nauk wykorzystanie takiego rachunku może dać o wiele lepsze efekty. Zainteresowanie tym rachunkiem zaczęło wzrastać od lat 50. dwudziestego wieku, kiedy zauważono, że wiele zjawisk fizycznych można dokładniej opisać korzystając z tego rachunku. Na przykład, dla procesu rozchodzenia się ciepła w pręcie, dla rachunku z wykorzystaniem operatora Laplace a mamy pierwiastek z operatora s, co można zinterpretować jako pochodną rzędu 0.5 [68]. W [69] z użyciem rachunku opisano odkształcanie się ramienia robota, a w [70] przedstawiono modelowanie ruchu sieciowego. Duże zainteresowanie rachunkiem jest związane z regulatorami PID [65], [66]. Wykorzystanie kontrolera PI λ do celów regulacji ruchu sieciowego z wykorzystaniem analizy Fluid Flow przedstawia praca [71].

88 88 Zarządzanie kolejką routera Pewne uogólnienie kontrolera wykorzystujące ułamkowy rachunek różniczkowy zostało nazwane kontrolerem niecałkowitych rzędów PI λ D µ. Jego działanie w dziedzinie czasu można przedstawić za pomocą wzoru [72]: U(t) = K p e(t) + K i D λ e(t) + K d D µ e(t) (4.37) gdzie: D v f(t) pochodna lub całka rzędu v funkcji f(t), K p, K i, K d człony regulatora: proporcjonalny, całkujący i różniczkujący, e(t) uchyb regulatora, u(t) sygnał wyjściowy regulatora, λ funkcja rzędu sumowania, µ funkcja rzędu różnicowania, W dalszej części rozdziału przedstawiono pokrótce ogólną ideę ułamkowego rachunku różniczkowego, a następnie zaprezentowano wykorzystanie regulatorów PID do aktywnego zarządzania pakietami w kolejce. Rachunek różniczkowy i całkowy ułamkowego rzędu Rachunek różniczkowy i całkowy ułamkowego rzędu (ang. fractional calculus) jest rozszerzeniem znanych pojęć całki i różniczki. Po raz pierwszy problem ten podniósł Leibnitz w 1695 roku w liście do l Hospital a. Natomiast podstawy rachunku różniczkowego i ułamkowego stworzone zostały pod koniec XIX wieku [73] przez takich matematyków, jak: Liouvile, Grünwald, Letnikow oraz Riemann. Riemanna i Liouville zaproponowali obliczanie całki niecałkowitego rzędu jako uogólnienie wzoru na całkowanie wielokrotne: ai n x = x 1 (x u) n 1 f(u)du (4.38) (n 1)! a Wzór 4.39 przedstawia sposób obliczania różniczko-całki ułamkowego rzędu [74]. x 0 Dxf(x) n 1 d m x = (x t) m n 1 f(t)dt (4.39) Γ(m n) dx m x 0 gdzie n to rząd całki (dla n < 0) lub różniczki (dla n > 0 ). Natomiast m jest pewnym arbitralnie wyznaczanym parametrem.

89 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Natomiast funkcja Γ jest uogólnieniem silni dla argumentów rzeczywistych i zespolonych. Dla n N Γ(n + 1) = n! (4.40) dla x R, Z Γ(x) = 0 e t t x 1 dt (4.41) Przykład obliczania różniczko-całki Riemanna-Liouville a w języku Python zaczerpnięty z biblioteki mpmath modułu sympy przedstawia listing 4.7. Funkcja oblicza całkę rzędu 0.5 dla funkcji e x w granicach (0,3) Listing 4.7. Obliczanie różniczko-całki Riemanna-Liouville a w języku Python (biblioteka SymPy) i m p o r t sympy. mpmath as c t x d e f d i f f e r i n t ( f, x, n =1, x0 = 0 ) : m = max ( i n t ( c t x. c e i l ( c t x. r e ( n ) ) ) + 1, 1) r = m n 1 g = lambda x : c t x. quad ( lambda t : ( x t ) r f ( t ), [ x0, x ] ) r e t u r n c t x. d i f f ( g, x, m) / c t x. gamma (m n ) d e f fun ( t ) : r e t u r n math. exp ( t ) p r i n t d i f f e r i n t ( fun, n = 0.5, x0 =0, x = 3. 0 ) Opis parametrów: f funkcja całkowana, n rząd całkowania, x0,x granice całkowania. Funkcja ta wykorzystuje funkcje zdefiniowane w module mpmath: quad obliczanie całki funkcji f(t) w granicach (x0,x), diff obliczanie różniczki funkcji rzędu całkowitego m,

90 90 Zarządzanie kolejką routera gamma obliczanie funkcji gamma, re wyznaczanie części rzeczywistej (dla zespolonego rzędu całkowania). Definicja różniczko-całki Grünwalda-Letnikowa opiera się na następującym wywodzie. Różniczka pierwszego rzędu definiowana jest jako [73]: df dt = lim f(t) f(t h) h 0 h (4.42) Różniczkę n-tego rzędu możemy zapisać jako: d n f dt n = lim 1 h 0 h n n r=0( 1) r( n r ) f(t rh) (4.43) Ponieważ ( ) n r = 0 dla r > n i uogólniając dwumian Newtona na liczby rzeczywiste, można zapisać różniczko-całkę Grünwalda-Letnikowa jako: d n f dt n = lim 1 h 0 h n r=0( 1) r( α r ) f(t rh) (4.44) W rzeczywistym zarządzaniu stratami pakietów reakcja AQM jest spowodowana nadejściem do systemu kolejnego pakietu. Z takiego punktu widzenia układ zarządzania stratami pakietów w kolejkach jest układem dyskretnym. Dla układów dyskretnych istnieje tylko jedna definicja różniczko-całki. Jej definicja jest wynikiem wywodu identycznego jak dla różniczko-całki Grünwalda-Letnikowa [75]. Różnica pierwszego rzędu to: Różnica drugiego rzędu to: Stąd różnica n-tego rzędu dla n N to: x k = x k x k 1 (4.45) x k = x k 2x k 1 + x k 2 (4.46) ) n n x k = r=0( 1) r( n x k r (4.47) r

91 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Korzystając z tych samych własności jak w definicji Grünwalda-Letnikowa ( ( ) n r = 0 dla r > n), można zapisać: ) k n x k = j=0( 1) j( n x k i (4.48) j gdzie n R jest ułamkowym rzędem całkowania, k N jest numerem próbki, a x k jest różnicowaną funkcją dyskretną. Natomiast współczynnik ( ) n j dla n R można obliczyć w następujący sposób: (4.49) ( ) { n 1 dla j = 0 = n(n 1)...(n j+1) j dla j > 0 j! Różnica ułamkowego rzędu to suma wszystkich próbek od x 0 (w chwili zerowej) do x k (w chwili k-tej), gdzie każda próbka przemnożona jest z odpowiednim współczynnikiem ν j zgodnym ze wzorem Ze względu na złożoność obliczeniową do obliczeń współczynników można stosować zapis rekurencyjny: Kontroler PI λ jako algorytm AQM { 1 dla j = 0 ν j = ν j 1 (1 ( 1+n )) dla j > 0 j (4.50) W zaproponowanym rozwiązaniu założono, że wartość uchybu wychodzącą z kontrolera wykorzystana zostaje do estymacji prawdopodobieństwa odrzucenia pakietów, którą można przedstawić za pomocą wzoru: p = max(0, (K p e + K i j V i ν(j)e)) (4.51) gdzie: K p wzmocnienie części proporcjonalnej, K i wzmocnienie części całkującej, e = q setpoint wartość uchybu, setpoint pożądany rozmiar kolejki, q aktualny rozmiar kolejki; ewentualnie średni ważony rozmiar kolejki.

92 92 Zarządzanie kolejką routera Rysunki 4.17, 4.18 pokazują, jak parametry kontrolera wpływają na prawdopodobieństwo straty pakietów na skutek ciągłego zapełniania bufora przez nieprzerwany strumień pakietów. W rozdziale 7.1 pokazano, jak dobór parametrów kontrolera może wpłynąć na zachowanie kolejek AQM Kp= Kp= Kp= Kp= Prawdopodobienstwo Rozmiar kolejki Rys Funkcja prawdopodobieństwa utraty pakietu (wpływ parametru K p ), λ = 0.2, K i = Fig Dropping packet probability function (K p parameter influence), λ = 0.2, K i = Podsumowanie W niniejszym rozdziale poruszono dwa niezmiernie istotne problemy związane z obsługą pakietów w routerze. Pierwszym z nich jest problem mechanizmów kolejkowania pakietów i ich traktowania w zależności od rodzajów strumieni, do których należą. Standardowe podejście best-efford stosowane przez dekady w sieciach komputerowych opierało się na identycznym traktowaniu każdego nadchodzącego pakietu. Pakiety były obsługiwane według kolejności ich nadchodzenia (kolejka FIFO). Wraz z pojawieniem się pojęcia QoS (ang. Quality of Service), popularne stały się rozwią-

93 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania λ=-1.1 λ=-1.0 λ=-0.9 λ=-0.8 Prawdopodobienstwo Rozmiar kolejki Rys Funkcja prawdopodobieństwa utraty pakietu (wpływ rzędu całkowania λ), K p = , K i = Fig Dropping packet probability function (integral order influence), K p = , K i = zania kwalifikacji pakietów i ich traktowania zależnego od rodzajów strumieni, do których dane pakiety przynależą. Takie rozwiązanie jest dość proste w implementacji, gdyż zarówno analiza ruchu, jak i klasyfikacja odbywają się w jednym miejscu, a jakiekolwiek zmiany wprowadzane są w jednym węźle sieci. Podobnie jak w przypadku protokołu TCP, prostota wdrażania tego typu rozwiązań, ograniczająca się tylko do pojedynczego węzła, stała się powodem niezwykłej popularności tych rozwiązań. Rozwiązania tego typu są najczęściej instalowane w punktach styku pomiędzy sieciami lokalnymi i rozległymi. Zalety tych rozwiązań są widoczne, zwłaszcza w sytuacji gdy łącze sieci rozległej jest znacznie wolniejsze od prędkości możliwych do uzyskania w sieci lokalnej. Rozszerzenie rozwiązań z pojedynczego routera na całą sieć pozwala na uzyskanie transmisji o żądanych parametrach (prędkość transmisji, opóźnienia i straty pakietów) pomiędzy dwoma wybranymi punktami w sieci. Jednakże implementacja mechanizmów QoS w kilku węzłach dostarcza dodatkowych problemów. Aby parametry transmisji były zachowane na całej drodze, do mechanizmów kolejkowania należy dodać metodę informowania sieci o zapotrzebowaniu na określone parametry ru-

94 94 Zarządzanie kolejką routera chu. Badania mechanizmów kolejkowania oraz ich wpływu na kształtowanie ruchu w celu uzyskania transmisji danych o założonych parametrach jakości usług przedstawiono w rozdziale 6. Drugim problemem opisanym w rozdziale jest aktywne zarządzanie pakietami. W statycznym podejściu do zarządzania pakietami są one usuwane z kolejki tylko w przypadku braku miejsca dla nadchodzących pakietów w buforach. Organizacja IETF (ang. Internet Engineering Task Force) zaproponowała zupełnie inne podejście do tego problemu. W rozdziale opisano popularne mechanizmy wcześniejszego usuwania pakietów wywodzących się z pierwszego tego typu mechanizmu nazwanego RED. Kolejne ulepszenia algorytmu polegają głównie na modyfikacjach obliczania prawdopodobieństwa odrzucania pakietów. Istotna zmiana w tego typu algorytmach polega na wbudowaniu mechanizmów sprawiedliwego podziału łącza pomiędzy większą liczbą strumieni. Najprostszym mechanizmem tego typu opisanym w tym rozdziale jest mechanizm CHOKe. Badania mechanizmów AQM, ich wpływ na straty pakietów oraz opóźnienia transmisji w routerze zostaną szczegółowo przedstawione w rozdziale 7.

95 Rozdział 5 OCENA MECHANIZMÓW TCP W niniejszym rozdziale przedstawiono badania wpływu mechanizmów TCP na transmisję danych. Zrealizowane eksperymenty polegały na przesyle założonej porcji danych za pomocą protokołu TCP pomiędzy dwoma komputerami. W czasie realizacji badań oceniano wpływ różnych modyfikacji protokołu TCP na prędkość transmisji, liczbę przesłanych pakietów z danymi oraz pakietów potwierdzeń. Dodatkowo oceniono, jak często dokonują się zmiany okna CWND czy progu ssthresh w zależności od wybranych opcji protokołu TCP. W czasie badań zmienne były również warunki występujące na łączu sieciowym. Do generowania pakietów czy dokonywania pomiarów w trakcie badań wykorzystano istniejące w systemie Linux oprogramowanie. Jedynym wyjątkiem były badania zmian okna przeciążenia (CWND) i progu wolnego startu (ssthresh). Badania te wymagały dokonania zmian w jądrze systemu operacyjnego. Zmiany te zostały opisane w następnej sekcji Mechanizmy oceny algorytmów sterowania przeciażeniem W systemie Linuks mamy dwa tryby uruchamiania oprogramowania. Normalni użytkownicy uruchamiają swoje programy w tzw. przestrzeni użytkownika (ang. User Space). Programy będące częścią systemu operacyjnego są uruchamianie w tzw. przestrzeni jądra (ang. Kernel Space) i wymagają do uruchomienia specjalnych uprawnień. Stos sieciowy w systemie Linux jest częścią oprogramowania systemowego i jako taki jest uruchamiany w przestrzeni jądra systemu. Stąd oprogramowanie monitorujące zmiany rozmiaru okna musi również działać jako kod jądra. Stworzone rozwiązanie opiera się na założeniu, że każda zmiana okna przeciążenia będzie powodowała uruchomienie procedury pozwalającej na zapamiętanie zmian. Takie rozwiązanie wymagało przeanalizowania stosu sieciowego systemu linuksowego na tyle dokładnie, aby móc wyznaczyć wszystkie miejsca w kodzie (wszystkie funkcje), w których następuje modyfikacja obserwowanych parametrów. Konieczne zatem było w pierwszej fazie wprowadzenie modyfikacji w wyżej opisanych miejscach i zrekompilowanie jądra. Tabela 5.1 przedstawia funkcje stosu sieciowego wraz z nazwami plików źródłowych, w których docho-

96 96 Ocena mechanizmów TCP dzi do zmiany śledzonych parametrów (czyli okna przeciążenia i progu powolnego startu). W funkcjach tych dokonano zmian przez wprowadzenie mechanizmów śledzących. Przykładowe miejsce, w którym dokonano zmian, przedstawia listing 5.1. Listing 5.1. Przykładowe miejsce podpięcia funkcji monitorujacej / CWND moderation, p r e v e n t i n g b u r s t s due t o t o o b i g ACKs i n d u b i o u s s i t u a t i o n s. / s t a t i c i n l i n e void tcp_moderate_cwnd ( s t r u c t t c p _ s o c k t p ) { tp >snd_cwnd = min ( tp >snd_cwnd, t c p _ p a c k e t s _ i n _ f l i g h t ( t p )+ t c p _ m a x _ b u r s t ( t p ) ) ; tp >snd_cwnd_stamp = t c p _ t i m e _ s t a m p ; / Wywoł n i e f u n k c j i m o n i t o r u j ą c e j po z m i a n i e r o z m i a r u okna p r z e s ł a n i e a k t u a l n y c h p a r a m e t r ów / cwnd_monitor ( t p ) ; } Funkcja monitorująca tworzy napis znakowy z wartościami obserwowanych parametrów, adresami i portami maszyn uczestniczących w danym połączeniu, dokładnym czasem systemowym, nazwą funkcji, w której doszło do zmiany oraz informacją o algorytmie przepływu sterującym połączeniem Przebieg eksperymentów Pojedynczy eksperyment polegał na przesyle danych za pomocą protokołu TCP pomiędzy dwoma komputerami podłączonymi poprzez HUB do łącza Ethernet 10 Mb/s. Do generowania strumienia danych wykorzystano program ttcp, pozwalający między innymi na określenie rozmiaru buforów nadawczych, liczby przesyłanych danych itp. W trakcie badań gromadzono następujące rezultaty: czas trwania pomiaru (czas przesyłu porcji danych), średnia prędkość przesyłu, liczba pakietów z danymi potrzebnych do przesłania zadanej porcji danych,

97 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela 5.1. Funkcje stosu TCP/IP wraz z nazwami plików źródłowych, w których są one zdefiniowane Funkcja stosu sieciowego Plik źródłowy tcp_init_metrics net/ipv4/tcp_input.c tcp_enter_frto_loss net/ipv4/tcp_input.c tcp_enter_loss net/ipv4/tcp_input.c tcp_moderate_cwnd net/ipv4/tcp_input.c tcp_cwnd_down net/ipv4/tcp_input.c tcp_complete_cwr net/ipv4/tcp_input.c reno_cong_avoid net/ipv4/tcp_input.c vegas_cong_avoid net/ipv4/tcp_input.c tcp_process_frto net/ipv4/tcp_input.c tcp_cwnd_application_limited net/ipv4/tcp_input.c tcp_v4_init_sock net/ipv4/tcp_ipv4.c tcp_cwnd_restart net/ipv4/tcp_output.c tcp_try_to_open net/ipv4/tcp_input.c tcp_transmit_skb net/ipv4/tcp_output.c liczba pakietów potwierdzeń (ACK), numery sekwencyjne pakietów danych wraz z czasem ich wysłania, numery sekwencyjne pakietów ACK wraz z czasem ich wysłania, zmiany wartości okna przeciążenia (CWND) wraz z czasem wystąpienia zmiany, zmiany wartości progu powolnego startu (ssthresh) wraz z czasem wystąpienia zmiany. Podczas etapu badawczego przebadany został wpływ mechanizmu TCP na przesył danych torem transmisyjnym o danych parametrach. Elastyczność stosu sieciowego Linuksa umożliwia włączanie i wyłączanie danej opcji w trakcie pracy systemu, bez konieczności restartu i ponownego załadowania jądra do pamięci. Możliwa jest zatem sytuacja, w której nawiązanych jest wiele sesji (połączeń) TCP i każde z nich sterowane jest przez inny algorytm przepływu. Parametry te mogą być ustawiane poprzez interfejs sysctl bądź też wirtualny system plików

98 98 Ocena mechanizmów TCP Tabela 5.2. Funkcje stosu TCP/IP wraz z nazwami plików źródłowych, w których są one zdefiniowane Aktywne opcje/algorytmy Komentarz 1 - TCP NewReno 2 tcp_window_scaling Aktywna tylko opcja skalowania okna TCP 3 tcp_timestamps Aktywna tylko opcja znaczników czasowych 4 tcp_sack Aktywny algorytm SACK 5 tcp_sack, tcp_fack Aktywny algorytm FACK 6 tcp_sack, tcp_fack, tcp_dsack Aktywny D-SACK 7 tcp_westwood Aktywny algorytm TCP Westwood 8 tcp_vegas Aktywny algorytm TCP Vegas 9 tcp_bic Aktywny algorytm BI-TCP 10 tcp_frto Aktywny algorytm F-RTO /proc. W każdym etapie badań analizowano 10 różnych modyfikacji (patrz tabela 5.2) stosu sieciowego TCP/IP. Eksperyment dla każdego przypadku wykonywany był wielokrotnie, a prezentowane rezultaty są wartościami średnimi Uzyskane rezultaty Przedstawione w tej sekcji książki badania podzielone zostały na kilka etapów. Każdy etap badań jest próbą odzwierciedlania odmiennej sytuacji, jaka może wystąpić w rzeczywistej sieci. Celem badań jest ocena działania algorytmów sterowania przepływem danych TCP w zależności od warunków występujących w łączu sieciowym. W czasie badań analizowano takie sytuacje, jak: transmisja pojedynczego strumienia TCP, rywalizacja kilku strumieni TCP na łączu, rywalizację strumieni TCP i UDP, transmisję na łączu o założonej stopie bitowej błędu czy transmisję kanałem transmisyjnym o bardzo małym paśmie przepustowości. Pojedynczy strumień TCP Celem eksperymentu było sprawdzenie, jak zachowują się różne odmiany algorytmu TCP w komfortowych warunkach. W ramach eksperymentu dokonano transferu 16 MB danych. Na wykresach ( ) przedstawiono rezultaty eks-

99 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania perymentu. Schemat wykresu jest następujący: wykres po lewej stronie pokazuje, jak w trakcie transmisji ewoluuje okno przeciążenia (CWND) oraz próg wolnego startu (ssthresh). Na wykresie (chcąc zachować jego czytelność) pokazano wyłącznie fazę, w której okno podlega największym zmianom. Wykres po prawej stronie pokazuje, jak wysyłane są kolejne numery sekwencyjne oraz jak nadchodzą potwierdzenia tych numerów w czasie. Analizując wykres 5.1, dotyczący zmienności okna i progu, wyraźnie widać, że ewolucja okna przebiega bez przeszkód. Można zauważyć również, że w tym czasie raz ustalony próg nie zmienia się w czasie całej transmisji. Brak przeciążeń i strat powoduje regularność w wysyłaniu nadejść (prawa część wykresu). Wynikiem tej regularności jest uzyskanie na wykresie prostej. Ponieważ w trakcie transmisji dochodzi do zawinięcia (przekroczenia maksymalnej wartości licznika ACK), odliczanie zaczyna się znowu od zera, co można zaobserwować na wykresie. Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New Reno stream

100 100 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO + skalowanie okna Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New Reno stream + window scaling Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO+znaczniki czasowe Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New Reno stream + time stamps

101 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK stream Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK + FACK Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK stream + FACK

102 102 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK + FACK + D-SACK Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK stream + FACK + D-SACK Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Westwood Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Westwood stream

103 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Vegas stream Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP BI-TCP Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP BI-TCP stream

104 104 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP F-RTO Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP F-RTO stream Jak można zauważyć na wykresach ( ) praktycznie we wszystkich algorytmach, w warunkach braku strat oraz przeciążeń na łączu, do ustabilizowania rozmiaru okna CWND dochodzi w ułamku pierwszej sekundy. Mimo iż wyraźnie widać nieco inną charakterystykę ustalania okna dla różnych algorytmów, to ich wpływ na wydajność transmisji nie wydaje się istotny. Pakiety wysyłane są równomiernie. Bez przeszkód nadchodzą również potwierdzenia pakietów. Wyjątkiem jest tu algorytm TCP Vegas (rysunek 5.8), który zgodnie z założeniami stara się utrzymać stałą liczbę wysłanych danych, balansując rozmiarem okna przeciążenia między wartością 3 i 5, co można też zauważyć w liczbie wywołań funkcji korygującej rozmiar okna (tabela 5.3), która jest do 240 razy większa niż w innych przypadkach. Okazuje się, że w takich warunkach (tylko jeden strumień TCP i brak strat na łączu) podejście proponowane przez algorytm TCP Vegas jest wyjątkowo wydajne. Przesłanie testowych danych zajmuje o 20% mniej czasu (zmierzona średnia prędkość przesyłania danych jest o 20% większa niż w pozostałych przypadkach i wynosi 1107 kb/s). Pojedynczy strumień TCP + dodatkowy obciażaj acy strumień TCP Celem następnego eksperymentu była ocena mechanizmów protokołu TCP transmitującego dane w towarzystwie drugiego coraz bardziej agresywnego łą-

105 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela 5.3. Wyniki eksperymentu dla pojedynczego strumienia TCP Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 17,91 915, , , ,88 916, , , ,04 908, , ,8 920, ,07 906, , , ,04 908, , , ,94 913, , ,8 1107, , ,11 904, , ,99 910, , cza. Dla badań wykorzystano program wget, umożliwiający narzucenie prędkości transmisji danych. Prędkość transmisji drugiego strumienia danych zmieniała się kolejno: 100 kb/s, 500 kb/s, 900 kb/s. Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream (additional stream TCP speed of 100 kb/s)

106 106 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze skalowaniem okna (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream with scaling window (additional stream TCP speed of 100 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze znacznikami czasowymi (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO with time stamps stream (additional stream TCP speed of 100 kb/s)

107 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK stream (additional stream TCP speed of 100 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP TCP SACK, FACK stream (additional stream TCP speed of 100 kb/s)

108 108 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK, D-SACK (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP TCP SACK, FACK, D-SACK stream (additional stream TCP speed of 100 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Westwood (dodatkowy strumień TCP o pędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Westwood stream (additional stream TCP speed of 100 kb/s)

109 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas (dodatkowy strumień TCP o prękości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Vegas stream (additional stream TCP speed of 100 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia BI-TCP (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single BI-TCP stream (additional stream TCP speed of 100 kb/s)

110 110 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP F-RTO (dodatkowy strumień TCP o prędkości 100 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP F-RTO stream (additional stream TCP speed of 100 kb/s) Tabela 5.4. Wyniki eksperymentu dla pojedynczego strumienia TCP (dodatkowy strumień TCP o prędkości 100 kb/s 10% możliwości łącza) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 20,97 781, , ,86 785, ,38 766, , , ,18 773, ,67 23, ,31 769, , , ,84 786, , , ,02 779, , , ,49 993, , , ,24 771, , ,46 763, , ,33 Wykresy pokazują zachowanie mechanizmów sterowania przeciążeniem nadającego strumienia TCP, w sytuacji gdy łącze jest również wykorzystywane przez drugi strumień TCP o prędkości 100 kb/s. Algorytm TCP Vegas najszybciej przesłał testowe dane (tabela 5.4). Na tym etapie badań nie widać jeszcze opisanej w literaturze słabej wydajności tego algorytmu w sytuacjach rywali-

111 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela 5.5. Wyniki eksperymentu dla pojedynczego strumienia TCP (dodatkowy strumień TCP o prędkości 500 kb/s) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 39,11 418, , , ,5 489, ,61 413, , , ,67 423, , , ,18 418, , , ,8 422, ,2 417, , ,76 532, , , , ,17 418, , ,09 419, , zacji z innymi strumieniami TCP kontrolowanymi przez inne, bardziej agresywne algorytmy sterowania przeciążeniem. Przypuszczalnie związane jest to ze sposobem, w jaki wykorzystywane do generowania ruchu narzędzie wget zachowuje narzucony limit przesyłanych (ściąganych) danych. Co pewien czas wstrzymuje on odbieranie danych tak, by w przeliczeniu na jednostkę czasu utrzymać założony limit. Najprawdopodobniej w chwilach przerw między przesyłaniem kolejnych danych, badany strumień, sterowanymi przez algorytm TCP Vegas, bez przeszkód wysyła swoje pakiety. W następnym etapie dochodzi do zwiększenia prędkości transmisji drugiego strumienia do 500 kb/s ( 50% dostępnego pasma). Ponownie algorytm TCP Vegas uzyskuje najlepszy wynik, choć wyraźnie widać, że dostępne pasmo w łączu 10 Mbps dzieli się mniej więcej na połowę na dwa strumienie TCP. Algorytm New Reno z włączoną opcją skalowania okna (przypadek 2) uzyskuje również dość dobre wyniki na tle reszty algorytmów czas przesyłu jest o 15-17% krótszy (patrz tabela 5.5). Trzecim etapem badań było zwiększenie prędkości strumienia obciążającego do poziomu 900 kb/s ( 90% możliwości łącza). Badanie to pokazało słabą efektywność algorytmu TCP Vegas w rywalizacji z innym strumieniem w łączu. Rywalizacja dwóch podobnych w działaniu algorytmów sterujących oknem w połączeniu TCP doprowadzała do mniej więcej równego podziału dostępnej przepustowości łącza. Uzyskane wyniki są praktycznie identyczne z poprzednimi (do-

112 112 Ocena mechanizmów TCP datkowy strumień o natężeniu 500 kb/s) (porównaj tabele 5.5 oraz 5.6). Wyniki w przypadku algorytmu TCP Vegas potwierdziły tezy prezentowane w innych pracach (np. [5]). W rywalizacji z bardziej agresywnymi algorytmami wykazuje on wyjątkowo niską wydajność, uzyskując zaledwie 36% wydajności pozostałych algorytmów. Opcja skalowania okna, podobnie jak w poprzednim eksperymencie, uzyskała o 11% lepszy wynik od pozostałych. Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream (additional stream TCP speed of 900 kb/s)

113 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze skalowaniem okna (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO with scaling window stream (additional stream TCP speed of 900 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze znacznikami czasowymi (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO with time stamps stream (additional stream TCP speed of 900 kb/s)

114 114 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK stream (additional stream TCP speed of 900 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK stream (additional stream TCP speed of 900 kb/s)

115 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK, D-SACK (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK, D-SACK stream (additional stream TCP speed of 900 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Westwood (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Westwood stream (additional stream TCP speed of 900 kb/s)

116 116 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Vegas stream (additional stream TCP speed of 900 kb/s) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia BI-TCP (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single BI-TCP stream (additional stream TCP speed of 900 kb/s)

117 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP F-RTO (dodatkowy strumień TCP o prędkości 900 kb/s) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP F-RTO stream (additional stream TCP speed of 900 kb/s) Pojedynczy strumień TCP na łaczu z prawdopodobieństwem strat 0.05) Celem badań przedstawionych w niniejszej sekcji było pokazanie zachowania protokołów sterowania przeciążeniem w warunkach występowania błędów transmisji. Pokazały one prawdziwą siłę algorytmów selektywnie potwierdzających odebrane dane. W warunkach ciągłych strat na łączu algorytmy te uzyskują w najlepszym wypadku poprawę wydajności o 31% (przypadek 6 SACK, FACK, D- SACK) w stosunku do zwykłego TCP NewReno (patrz tabela 5.7). Poprawę wydajności widać już podczas badań przy włączonej opcji SACK. Po uaktywnieniu algorytmu FACK (bardziej agresywnej odmiany SACK) wydajność ta jeszcze rośnie. Dodatkowe uaktywnienie opcji D-SACK pozwala uzyskać najlepsze rezultaty. W przypadku tej opcji można zaobserwować ogromny wzrost liczby wywołań funkcji kontrolującej rozmiar okna przeciążenia. Liczba modyfikacji okna w praktyce równa jest liczbie przesłanych pakietów danych. Efekt ten jest spowodowany występującymi na łączu stratami i koniecznością ciągłej modyfikacji rozmiaru okna (patrz tabela 5.7 oraz rysunki od 5.31 do 5.40).

118 118 Ocena mechanizmów TCP Tabela 5.6. Wyniki eksperymentu dla pojedynczego strumienia TCP (dodatkowy strumień TCP o prędkości 900 kb/s) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 38,67 423, , , ,64 472, , , ,92 420, , , , , , ,09 419, , , ,79 422, , ,07 419, ,45 152, , , ,23 417, , , ,2 417, , ,67 153,67 Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream (the link with the probability of losses 0.05)

119 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze skalowaniem okna (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream with window scaling (the link with the probability of losses 0.05) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze znacznikami czasowymi (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO stream with time stamps (the link with the probability of losses 0.05)

120 120 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK (the link with the probability of losses 0.05) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK (the link with the probability of losses 0.05)

121 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK, D-SACK (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK, D-SACK (the link with the probability of losses 0.05) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Westwood (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Westwood (the link with the probability of losses 0.05)

122 122 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Vegas (the link with the probability of losses 0.05) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia BI-TCP (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single BI-TCP (the link with the probability of losses 0.05)

123 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP F-RTO (łącze z prawdopodobieństwem strat 0.05) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP F-RTO (the link with the probability of losses 0.05) Tabela 5.7. Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu z prawdopodobieństwem strat 0.05 Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 32,77 500, , , ,87 531, , , , ,33 559, , ,88 633, , ,51 697, , ,64 726, , , ,45 556, , , , ,87 515, , ,08 589, , , , ,41 508, , ,33

124 124 Ocena mechanizmów TCP Pojedynczy strumień TCP na łaczu z prawdopodobieństwem strat dodatkowe obciażenie ruchem UDP Tabela 5.8 pokazuje wyniki uzyskane podczas eksperymentu dodatkowego obciążenia kanału ruchem UDP o prędkości 100 kb/s. Tak samo jak w przypadku badań bez dodatkowego strumienia, ale dla stratnego kanału algorytmy selektywnego potwierdzania uzyskują najlepsze wyniki. Dodatkowym efektem, dostrzegalnym również w poprzednim badaniu, jest wzrost liczby wysłanych pakietów potwierdzeń (z poziomu 5000 do poziomu 9000 pakietów). Wzrost ten spowodowany jest zarówno stratami na łączu i związaną z tym koniecznością sygnalizowania straty powtórzonym ACK, jak i z dostosowywaniem się algorytmów do przesyłu stratnym łączem i potwierdzaniem każdego bloku danych. Sytuacja na łączu nie pozwala na wykorzystywanie skumulowanych ACK. Badania wykazały również słabnącą w takich warunkach efektywność mechanizmu TCP Vegas. W następnych etapach eksperymentu prędkość towarzyszącego ruchu UDP była Tabela 5.8. Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu z prawdopodobieństwem strat 0.05 (dodatkowe obciążenie ruchem UDP o prędkości 100 kb/s) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 31,85 514, , , ,97 497, , , , ,5 490, , , , ,48 619, , , , ,19 650, , , , ,98 687, , ,28 544, , , , ,59 463, , , , ,05 511, , , , ,18 528, ,67 stopniowo zwiększana. Etapy te potwierdziły tendencje zachowań mechanizmów TCP uwidocznionych w poprzednich etapach badań dla łącza z błędami. Tabela 5.9 przedstawia pierwszą fazę zwiększania prędkości wysyłania danych przez dodatkowy ruch UDP (500 kb/s). Algorytmy SACK, FACK i D-SACK

125 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania uzyskują tutaj również najlepsze rezultaty, lecz ich przewaga w stosunku do reszty mechanizmów maleje. Obciążenie generowane ruchem UDP uniemożliwia większe wykorzystanie pasma przez badany ruch TCP. Na tym etapie ograniczeniem dla prędkości transmisji staje się dostępne pasmo, a nie wydajność danego algorytmu TCP. W przypadku dodatkowego ruchu UDP o prędkości transmisji 900 kb/s (tabela 5.10), ruch ten jest ruchem bardzo agresywnym, gdyż natężenie wprowadzanych przez niego danych nie jest sterowane żadnym algorytmem przeciążenia i jest ograniczone tylko przez narzucony limit przepustowości. W znaczący sposób wpływa to na wykorzystanie pasma przez inne algorytmy. Dla ruchu TCP zostaje tylko ok. 10% dostępnej przepustowości łącza. Tabela 5.9. Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu z prawdopodobieństwem strat 0.05 (dodatkowe obciążenie ruchem UDP o prędkości 500 kb/s 50% możliwości łącza) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 47,23 346, , , , ,39 353, , , ,97 334, , , ,03 372, , , ,68 393, ,2 379, , , , ,5 362, , , , ,24 314, , ,44 345, , , ,36 332, , ,67 Pojedynczy strumień TCP na łaczu szeregowym 9600 kbps (RS-232) W ramach eksperymentu przeprowadzono transfer 32 kb danych testowych łączem szeregowym (RS-232). Uzyskane rezultaty przedstawia tabela Przy tak wolnym łączu i wysyłaniu tak małej liczby danych algorytmy TCP nie różnią się wydajnością. Również sposób, w jaki kontrolują okno przeciążenia, jest praktycznie identyczny. Przy wysyłaniu zaledwie 23 pakietów, bezstratnym łą-

126 126 Ocena mechanizmów TCP Tabela Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu z prawdopodobieństwem strat 0.05 (dodatkowe obciążenie ruchem UDP o prędkości 900 kb/s 90% możliwości łącza) Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 152,81 107, , , , ,74 49, , , ,16 106, , , ,56 117, , , ,58 119, , , , ,34 122, , , ,05 118, , , , ,51 74, , ,68 108, , , , ,44 109, ,33 czem, zaawansowane algorytmy zarządzania przeciążeniem nie znajdują specjalnego zastosowania. Dla wszystkich testowanych opcji ewolucja okna jest identyczna z przypadkiem standardowego TCP NewReno (wykres 5.41). Znacząco od reszty odróżnia się mechanizm TCP Vegas (wykres 5.42). Zgodnie z założeniami utrzymuje on rozmiar okna przeciążenia na jednym poziomie i stara sią nie przeciążać łącza, wysyłając zazwyczaj tylko jeden pakiet na każde odebrane potwierdzenie.

127 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO (łącze RS-232) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO (the RS-232 link) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas (łącze RS-232) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Vegas (the RS-232 link)

128 128 Ocena mechanizmów TCP Tabela Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu o przepustowości 9600 kb/s Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji 1 34,13 0, , ,13 0, ,42 0, ,14 0, ,13 0, ,14 0, , ,13 0, , ,14 0, ,16 0, ,14 0, ,67 Pojedynczy strumień TCP na łaczu z wymuszona stopa błędów trwajac a tylko przez pewien czas transmisji Celem badań przedstawionych poniżej było sprawdzenie reakcji protokołu TCP na pojawiające się przez pewien czas błędy transmisji. Eksperyment przeprowadzono w 4 fazach, zmieniając prawdopodobieństwo przekłamania bitu (0.5 i 0.8) oraz czas trwania transmisji z takim poziomem błędów (1 sekunda oraz 5 sekund). Symulowana przerwa na łączu uzyskana była przez wprowadzenie na łącze straty pakietów na poziomie 50% w obu kierunkach połączenia (zarówno pakiety danych, jak i potwierdzeń) po paru sekundach trwania połączenia. W tabeli 5.12 umieszczono rezultaty eksperymentu, dla którego przez pięć sekund utrzymywana jest bitowa stopa błędu na poziomie 0.5 (co drugi bit może być przekłamany). Eksperyment sprawdza, jak szybko badane algorytmy radzą sobie z odzyskaniem wydajności po trwającej dłuższy czas dużej stracie pakietów. Uzyskane rezultaty wykazują, że prędkość reakcji mechanizmów TCP jest praktycznie identyczna. Każdy z algorytmów w ułamku sekundy potrafi powrócić do wysyłania danych z pełną wydajnością (rysunki ). Identycznie dobry wynik uzyskano dla algorytmu TCP Vegas.

129 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zarówno zwiększenie prawdopodobieństwa strat pakietów do wartości 0.8, jak i zwiększenie czasu trwania do 5 sekund nie ma praktycznie żadnego wpływu na uzyskane wyniki. Po stwierdzeniu strat każdy z algorytmów redukuje jak najszybciej rozmiar okna przeciążenia (CWND). Równocześnie dochodzi do redukcji progu powolnego startu (ssthresh). Po ustaniu strat algorytmy TCP błyskawicznie powracają do maksymalnych możliwości transmisyjnych łącza. Tabela 5.12 pokazuje wyniki dla eksperymentu utrzymywania przez pięć sekund bitowej stopy błędu na poziomie 0.5 (co drugi bit może być przekłamany). Wyniki dla pozostałych eksperymentów nie zostaną zaprezontowane, ponieważ nie różnią się one w istotny sposób od tych przedstawionych w tabeli. Tabela Wyniki eksperymentu dla pojedynczego strumienia TCP na łączu z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund Alg czas prędkość l. pakietów l. pak. ACK l.wywołań [s] [kb/s] danych funkcji , , , ,04 606, , , ,91 658, , , ,31 647, , ,33 505, ,8 660, , ,17 651, , ,96 656, , ,59 759, , , , ,9 658, , ,78 661, Podsumowanie W rozdziale zostały przedstawione różne mutacje algorytmu TCP. Zaprezentowane badania miały na celu pokazanie zachowania tych mechanizmów w różnych sytuacjach, które mogą wystąpić w trakcie przesyłu danych w rzeczywistej sieci. Analizując powyższe badania, widać wyjątkowo dobrą wydajność protokołu TCP Vegas w sytuacji, gdy nie musi on rywalizować o pasmo z innymi algorytmami TCP. W rywalizacji z bardziej agresywnymi algorytmami, TCP Vegas wykazuje niską wydajność. Wyższa wydajność tego algorytmu uzyskana została kosztem mniejszej agresywności w działaniu. Wydaje się (bo badanie takie nie

130 130 Ocena mechanizmów TCP zostało przeprowadzone), że algorytm ten zachowałby swoją dobrą wydajność podczas działania w warunkach rywalizacji z innymi strumieniami TCP, lecz sterowanymi również algorytmem TCP Vegas. Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO (the link with the stimulated probability of losses 0.05 lasted 5 seconds) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze skalowaniem okna (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO with window scaling (the link with the stimulated probability of losses 0.05 lasted 5 seconds)

131 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP New RENO ze znacznikami czasowymi (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP New RENO with time stamps (the link with the stimulated probability of losses 0.05 lasted 5 seconds) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK (the link with the stimulated probability of losses 0.05 lasted 5 seconds)

132 132 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK (the link with the stimulated probability of losses 0.05 lasted 5 seconds) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP SACK, FACK, D-SACK (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP SACK, FACK, D-SACK (the link with the stimulated probability of losses 0.05 lasted 5 seconds)

133 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Westwood (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP Westwood (the link with the stimulated probability of losses 0.05 lasted 5 seconds) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP Vegas (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP vegas (the link with the stimulated probability of losses 0.05 lasted 5 seconds)

134 134 Ocena mechanizmów TCP Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia BI-TCP (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single BI-TCP (the link with the stimulated probability of losses 0.05 lasted 5 seconds) Rys CWND oraz sstresh (okno lewe), numery sekwencyjne i ACK (okno prawe) dla pojedynczego strumienia TCP F-RTO (łącze z wymuszoną stopą błędów (0.5) trwającą przez okres 5 sekund) Fig CWND and sstresh (left), sequence numbers and ACK (right) for single TCP F-RTO (the link with the stimulated probability of losses 0.05 lasted 5 seconds)

135 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Niemożność zachowania sprawiedliwości (ang. fairness jeden z parametrów oceny algorytmów sterowania przeciążeniem) pomiędzy strumieniem TCP z zaimplementowanym algorytmem TCP Vegas oraz innymi, bardziej zachłannymi algorytmami wyraźnie widoczna jest w ruterach, których kolejki pasywnie zarządzają odrzucaniem pakietów. Sytuacja jest w pewnym stopniu lepsza, gdy kolejka aktywnie zarządza stratami (np. algorytm RED)[76]. Zagadnienia wpływu algorytmów kolejkowania na mechanizmy sterowania przeciążeniem zostały poruszone w innych częściach książki. Przeprowadzone badania wykazały również bardzo dobrą efektywność algorytmów selektywnego potwierdzania odebranych bloków. Algorytmy te doskonale spełniają swoje zadanie w przypadkach występowania strat pakietów na łączu.

136 Rozdział 6 OCENA MECHANIZMÓW KOLEJKOWANIA Niniejszy rozdział poświęcony został badaniom mechanizmów kolejkowania pakietów. Mechanizmy te determinują sposób przechowywania do routera pakietów oraz sposób wyboru pakietu z kolejki. Zostały one omówione w sekcji 4.1. W praktyce mechanizmy te implementowane są w dedykowanym sprzęcie sieciowym i w rzeczywistej sieci w takiej formie są one wykorzystywane. Cena takiego sprzętu sprawia jednak, że nie jest on w zasięgu przeciętnego użytkownika. W czasie badań wykorzystano router programowy oparty na komputerze klasy PC oraz systemie operacyjnym Linux. Rozwiązanie to jest o wiele tańszą, a równocześnie bardzo elastyczną alternatywą. W rozdziale przedstawiono sposób konfiguracji routera z systemem operacyjnym Linux pozwalającym na elastyczne kolejkowanie nadchodzących pakietów. Przedstawiono również rezultaty potwierdzające skuteczność takiego rozwiązania Przebieg eksperymentów Stanowisko badawcze składało się z czterech komputerów PC i jednego przełącznika. Schemat stanowiska badawczego przedstawia rysunek 6.1. Na rysunku wyraźnie zaznaczono nazwy komputerów, ich adresy IP oraz nazwy interfejsów sieciowych. Nazwy te były wykorzystywane w przykładowych konfiguracjach mechanizmów kolejkowych. Oprócz standardowych interfejsów sieciowych podczas konfiguracji routera wykorzystywano wirtualny interfejs imq0. Jest to specyficzny pośredni interfejs kolejkowania. Wykorzystanie tego interfejsu upraszcza konfigurację routera. W przypadku kształtowania ruchu przychodzącego z pewnego interfejsu, a wysyłanego poprzez dwa lub więcej interfejsów do różnych podsieci, wystarczy przekierować ruch przychodzący na interfejs imq i tam dokonywać założonego kształtowania ruchu. Ze względu na charakter badań, który obejmuje m.in. takie parametry, jak opóźnienie, ograniczono możliwą prędkość transmisji do 10 Mbit/s na interfejsie eth0. Ograniczenie to realizowano poprzez ustawienie takiego trybu pracy na przełączniku. W czasie realizacji badań wykorzystano następujące narzędzia:

137 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Przełącznik Serwer Komputer A eth0 Komputer B eth eth Router Rys Sieć wykorzystana w trakcie badań Fig Network used during the research iptables+patch imq program do administracji tablicami filtrowania i routingu systemu Linux z obsługą interfejsu pośredniego kolejkowania IMQ, tc (iproute) program do wyświetlania i administrowania ustawieniami sterowania ruchem, tcpdump narzędzie do nasłuchu i przechwytywania ruchu w sieci, lftp menedżer wymiany plików protokołem FTP, HTTP, HTTPS, iperf narzędzie do testowania parametrów połączenia, pracujące w architekturze klient/serwer. W trakcie badań dokonano analizy najbardziej popularnych mechanizmów kolejkowania pakietów zaimplementowanych w systemie operacyjnym Linux Uzyskane rezultaty Przed wykonaniem eksperymentów dokonano pomiaru prędkości przesyłu danych pomiędzy komputerem A i serwerem oraz komputerem B i serwerem. Wyniki pomiarów przedstawia tabela 6.1 oraz wykres 6.2. Należy zwrócić uwagę, że komputer B ze względu na swoją konfigurację jest wyraźnie wolniejszy.

138 138 Ocena mechanizmów kolejkowania Tabela 6.1. Uzykane prędkości transmisji danych Kierunek transmisji Prędkość [MB/s] komputer A serwer komputer B serwer Predkosc [B/s] :00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 00:50 00:55 01:00 Czas [s] Rys Prędkość transmisji; komputer B serwer Fig Transmission speed; computer B server Kolejka pfifo_fast Kolejka pfifo_fast jest domyślną kolejką stosowaną w systemie Linux na wyjściu każdego interfejsu sieciowego. Jest to standardowa kolejka FIFO z priorytetowym obsługiwaniem pakietów oznaczonych polem TOS (niskie opóźnienie). Kolejka ta nie wymaga żadnej dodatkowej konfiguracji. Dla uzyskania odpowiedniej wartości TOS dla danych przepływających pomiędzy komputerem A i serwerem wykonano na komputerze A i serwerze następujące polecenia (patrz listing 6.1): Listing 6.1. Ustawienie wartości TOS komputer A: # i p t a b l e s t mangle A OUTPUT d p t c p d p o r t 5001 j DSCP s e t dscp 0x4

139 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Komputer B Komputer A Predkosc transmisji [B/s] :00 49:05 49:10 49:15 49:20 49:25 49:30 49:35 49:40 Czas [s] Rys Rywalizacja strumieni komputer A - serwer oraz komputer B - serwer; kolejka pfifo_fast Fig Streams contest computer A - server and computer B - server; pfifo_fast queue serwer: # i p t a b l e s t mangle A OUTPUT d p t c p s p o r t 5001 j DSCP s e t dscp 0x4 Dodatkowo dla ograniczenia prędkości przesyłu i zwiększenia opóźnień wprowadzono przełącznik w tryb 10 Mb/s. Eksperyment polegał na transmisji pomiędzy komputerem B i serwerem oraz uruchomieniu w pewnym momencie transmisji pomiędzy komputerem A i serwerem. Pakiety z połączenia pomiędzy komputerem A i serwerem mają wartość pola TOS 0x10 (niskie opóźnienie). Uzyskane rezultaty zostały przedstawione na rysunku 6.3. W momencie rozpoczęcia transmisji pomiędzy komputerem A a serwerem dochodzi do całkowitego zajęcia pasma przepustowości przez ten strumień. Efekt ten dodatkowo uwidacznia analiza fluktuacji (zmienności opóźnienia) dla tego strumienia (rysunek 6.4). Różnica pomiędzy fluktuacją na linii obciążonej i nieobciążonej jest niewielka. Pomijając krańcowe wahania, opóźnienie utrzymuje się na tym samym niskim i stabilnym poziomie.

140 140 Ocena mechanizmów kolejkowania Opoznienie [ms] Opoznienie [ms] Czas [s] Czas [s] Rys Opóźnienia strumienia komputer A serwer, linia nieobciążona (wykres prawy), w trakcie transmisji razem ze strumieniem komputer B serwer (wykres lewy); kolejka pfifo_fast Fig Stream computer A server delays, unloaded link (right), during computer B server transmission; pfifo_fast queue Kolejka SFQ Algorytm SFQ został szczegółowo opisany w rozdziale 4.1. Dyscyplina stochastycznego równomiernego kolejkowania jest dyscypliną należącą do klasy sprawiedliwego podziału łącza (ang. Fairness Queueing FQ). Jej działanie powoduje przydzielanie każdemu strumieniowi osobnej kolejki. Po przydzieleniu przepływu do kolejki jest on wysyłany do sieci na zasadzie round-robin. Użycie tej dyscypliny kolejkowania teoretycznie powinno pomóc w sytuacji, gdy pasmo jest zawłaszczane przez niektóre strumienie. W trakcie badań, podobnie jak w poprzednim eksperymencie, stłumiono odpowiednio prędkość na interfejsie eth0 serwera do 10 Mbit/s (poprzez ustawienie przełącznika sieciowego). Następnie uaktywniono dyscypliny kolejkowania SFQ na interfejsach komunikacyjnych routera (patrz listing 6.2). Listing 6.2. Konfiguracja kolejek SFQ dla interfejsów sieciowego i pośredniego kolejkowania # t c q d i s c add dev e t h 0 r o o t s f q p e r t u r b 5 quantum 1500 # t c q d i s c add dev imq0 r o o t s f q p e r t u r b 5 quantum 1500 # i p t a b l e s t mangle A PREROUTING i e t h 0 j IMQ t o d e v 0 Pierwsza i druga linia konfiguracji uaktywnia kolejki SFQ na interfejsie eth0 i imq0 routera. Trzecia przekierowuje ruch, który przybywa do routera z inter-

141 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania fejsu eth0 na interfejs imq0. Parametry kolejki SFQ określają kolejno, co jaki czas zmienia się klucz mieszający tablicy oraz ile bajtów może być w jednym cyklu pobrane z każdej kolejki (zwykle jest to największa możliwa wielkość pakietu dla sieci Ethernet 1500 bajtów). Zmiana klucza ma na celu uniknięcie sytuacji, w której dwa strumienie byłyby umieszczone w jednej kolejce. Badanie mechanizmu kolejkowania SFQ miało pokazać, jak wygląda podział pasma przepustowości pomiędzy rywalizującymi przepływami. Jak pokazuje rysunek 6.5, sytuacja komputera B jest o wiele lepsza. Jednakże różnica pomiędzy wysyłaniem i odbieraniem danych jest tu dosyć istotna, gdyż router ma znacznie mniejszą możliwość wpływania na ruch przychodzący. Pomimo takiego ograniczenia kolejka SFQ daje odczuwalną poprawę sytuacji w przypadku odbioru danych Komputer B Komputer A Komputer B Komputer A Predkosc transmisji [B/s] Przepustowosc [B/s] :00 00:05 00:10 00:15 00:20 00:25 00: :00 00:05 00:10 00:15 00:20 00:25 Czas [s] Czas [s] Rys Rywalizacja strumieni komputer A serwer oraz komputer B serwer, kolejka SFQ; wysyłanie danych (wykres lewy), odbieranie danych (wykres prawy) Fig Streams contest computer A server and computer B server; SFQ queue, sending data (left), receiving data (right) Kolejka TBF Filtr TBF jest implementacją algorytmu cieknącego wiadra z żetonami. Mechanizm (opisany w rozdziale 4.1) umożliwia kształtowanie ruchu, zgodnie z charakterystyką podaną w jego parametrach konfiguracyjnych. Filtr ten umożliwia dostosowanie i ograniczanie pasma do przepustowości łącza oraz ewentualnej jakości usług.

142 142 Ocena mechanizmów kolejkowania Ciąg poleceń realizujących włączenie kolejki przedstawia listing 6.3. Ponieważ mechanizm TBF posiada możliwość ustawienia prędkości przesyłu danych, w eksperymencie przywrócono na linii między routerem a przełącznikiem prędkość 100 Mbit/s. Listing 6.3. Konfiguracja filtrów TBF dla interfejsów sieciowego i pośredniego kolejkowania # t c q d i s c add dev e t h 0 r o o t t b f r a t e 10 Mbit l a t e n c y 50ms b u r s t 15k # t c q d i s c add dev imq0 r o o t t b f r a t e 10 Mbit l a t e n c y 50ms b u r s t 15k # i p t a b l e s t mangle A PREROUTING i e t h 0 j IMQ t o d e v 0 Parametry filtru TBF określają prędkość, z jaką generowane są żetony, długość kolejki, obliczaną na podstawie maksymalnego czasu obsługi pakietu (latency) i pojemności kubełka na żetony (burst). Niewłaściwy dobór parametrów (szczególnie zbyt niskiego parametru burst w stosunku do prędkości generowania żetonów) może doprowadzić do uniemożliwienia osiągnięcia pełnej żądanej przepustowości. Na rysunku 6.6 przedstawiono charakterystyki dla dwóch długości kolejek, odpowiadających maksymalnemu czasowi obsługi 10 oraz 150 milisekund. Charakterystyki silnie zależą od pojemności kubełka na żetony (burst). Dla transmisji z prędkością 10 Mbit/s musi on wynosić przynajmniej 14 kb. Rysunek 6.7 prezentuje zależność opóźnienia od pojemności kubełka na żetony. Zamieszczone wykresy przedstawiają minimalne oraz maksymalne opóźnienia dla różnych wartości parametrów latency i burst. Dla małych rozmiarów kubełka na żetony oraz maksymalnego rozmiaru kolejki zaobserwowano bardzo dużą fluktuację opóźnienia, która stopniowo maleje wraz ze wzrostem tych parametrów. Zachowanie to świadczy, jak ważny jest w przypadku tej kolejki poprawny dobór parametrów. Niepoprawna konfiguracja mechanizmu może spowodować bardzo nieefektywne działanie. Kolejka priorytetowa PRIO Kolejka priorytetowa jest nietypową kolejką klasową. Domyślnie nie zawiera ona żadnych kolejek. Umożliwia jedynie klasyfikowanie ruchu i przydzielanie mu priorytetu. Przydział algorytmu kolejkowania definiowanej klasie jest dowolny.

143 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania ms 150 ms Predkosc [B/s] Burst [B] Rys Zależność prędkości od parametrów burst oraz latency; kolejka TBF Fig Transmission speed depending on burst and latency parameters; TBF queue Listing 6.4. Konfiguracja kolejki PRIO i przydzielenie filtrów TBF dla wysokiego i średniego priorytetu oraz kolejki SFQ dla niskiego, dla interfejsów eth0 i imq0 # t c q d i s c add dev e t h 0 r o o t h a n d l e 1 : p r i o # t c q d i s c add dev e t h 0 p a r e n t 1 : 1 h a n d l e 1 0 : t b f r a t e 10 Mbit l a t e n c y 10ms b u r s t # t c q d i s c add dev e t h 0 p a r e n t 1 : 2 h a n d l e 2 0 : t b f r a t e 500 k b i t l a t e n c y 50ms b u r s t 5140 # t c q d i s c add dev e t h 0 p a r e n t 1 : 3 h a n d l e 3 0 : s f q # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p t o s 0x8 0 x f f f l o w i d 1 : 3 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p t o s 0x10 0 x f f f l o w i d 1 : 1 # t c q d i s c add dev imq0 r o o t h a n d l e 1 : p r i o # t c q d i s c add dev imq0 p a r e n t 1 : 1

144 144 Ocena mechanizmów kolejkowania Opoznienie [ms] Opoznienie [ms] Burst [B] Burst [B] Opoznienie [ms] Burst [B] Rys Maksymalne oraz minimalne opóźnienie dla kolejki TBF, w zależności od parametru burst; czas obsługi pakietu 10 ms (wykres lewy góra), czas obsługi pakietu 50 ms (wykres prawy góra), czas obsługi pakietu 150 ms (wykres dolny) Fig Maximal and minimal delay for TBF queue, depending on burst parameter; packet service time 10 ms (left top), packet service time 50 ms (right top),packet service time 150 ms (bottom) h a n d l e 1 0 : t b f r a t e 10 Mbit l a t e n c y 10ms b u r s t # t c q d i s c add dev imq0 p a r e n t 1 : 2 h a n d l e 2 0 : t b f r a t e 100 k b i t l a t e n c y 50ms b u r s t 5140 # t c q d i s c add dev imq0 p a r e n t 1 : 3 h a n d l e 3 0 : s f q # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p t o s 0x8 0 x f f f l o w i d 1 : 3 # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p t o s 0x10 0 x f f f l o w i d 1 : 1 # i p t a b l e s t mangle F # i p t a b l e s t mangle A PREROUTING i e t h 0 j IMQ t o d e v 0

145 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Korzeń 1:0 1:1 1:2 1:3 Tbf Tbf Tbf Rys Hierarchia klas dla kolejki PRIO Fig Queues hierarchy for PRIO queue Predkosc transmisji [Mbit/s] Opoznienie [ms] Czas [s] Czas [s] Rys Prędkość transmisji (wykres lewy), opóźnienie (wykres prawy), transmisja pomiędzy komputerem B a serwerem dla pojedynczego strumienia, kolejka PRIO Fig Transmission speed (left), delay (right), transmission between computer B and server for one stream, PRIO queue

146 146 Ocena mechanizmów kolejkowania Komputer B Komputer A Ruch wrazliwy Predkosc transmisji [B/s] :00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 Czas [s] Rys Prędkość transmisji dla jednoczesnego przesyłu danych do serwera przez komputer A oraz komputer B i dodatkowym ruchu w klasie uprzywilejowanej, kolejka PRIO Fig Transmission speed for simultaneous transmission to server by computer A and computer B and additional traffic in privileged class, PRIO queue Opoznienie [ms] Czas [s] Rys Opóźnienie pakietów dla ruchu priorytetowego, przeciążone łącze, kolejka PRIO Fig Packets delay for privileged traffic transmission, the overloaded link, PRIO queue

147 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zbiór poleceń konfigurujących router zamieszczono w listingu 6.4. Utworzoną w ten sposób hierarchię klas przedstawia rysunek 6.8. Pierwsze polecenia z listingu jest odpowiedzialne za utworzenie głównej klasy (1:0) oraz trzech podklas (1:1, 1:2 i 1:3). Do każdej podklasy przypisano kolejkę oraz dodano reguły klasyfikujące ruch. Dopisanie tych reguł nie jest konieczne, ponieważ kolejka PRIO ma domyślnie ustalone reguły klasyfikowania. Podczas konfiguracji skorzystano z istniejącej możliwości i dodano ruch wymagający niskiego opóźnienia (wartość pola TOS 0x10) do klasy 1:1, natomiast ruch oznaczony polem TOS maksymalna przepustowość (pole TOS 0x8) przypisano do klasy 1:3. Na komputerze A wprowadzono reguły ustawiające pole TOS na 0x10 dla ruchu wychodzącego z tego komputera (patrz listing 6.5). Listing 6.5. Ustalenie pola TOS dla komputera A # i p t a b l e s t mangle A OUTPUT d p t c p d p o r t 5001 j DSCP s e t dscp 0x10 # i p t a b l e s t mangle A OUTPUT d p udp d p o r t 5001 j DSCP s e t dscp 0x10 Rysunek 6.9 przedstawia prędkość transmisji oraz opóźnienie przy pustym, nieobciążonym połączeniu dla transmisji pomiędzy komputerem B a serwerem. Na rysunku można zaobserwować spore wahania opóźnienia w transmisji pakietów. Zjawisko to ma związek z narzutami wprowadzanymi przez mechanizm kolejki PRIO, nadzorującej i planującej wysyłanie pakietów. Na rysunku 6.10 przedstawiono prędkość transmisji, odczytaną na interfejsie łączącym router z serwerem. Około siódmej sekundy pojawia się na wykresie wrażliwy ruch (generowany przez narzędzie iperf). Oba wcześniej transmitujące przepływy zostają natychmiast stłumione, chociaż ich transmisja nie została całkowicie zawieszona. Po zakończonej transmisji przez ruch wrażliwy transmisja poprzednio stłumionych strumieni wraca do stanu poprzedniego. Pomimo silnego obciążenia połączenia opóźnienie dla pakietów nie jest duże i waha się pomiędzy 0.25 ms a nieco ponad 0.3 ms (rysunek 6.11). Opóźnienie takie jest akceptowalne, jednak w przypadku transmisji przez kilka routerów, w którym każdy narzuca takie opóźnienie, warunki wrażliwego połączenia mogą ulec szybkiemu pogorszeniu. Rysunki 6.12 oraz 6.13 pokazują sytuację, w której do tej pory uprzywilejowany strumień, poprzez przywrócenie dla niego domyślnej wartości TOS, zostaje przeniesiony do klasy średniego uprzywilejowania. Jak można zauważyć, zmiana wartości TOS z badanego ruchu, a tym samym zmiana jego klasyfikacji, spowodowała znaczne obniżenie prędkości tego ruchu oraz podniesienie wartości opóźnień.

148 148 Ocena mechanizmów kolejkowania Komputer B Komputer A Ruch sredniego uprzywilejowania Predkosc transmisji [B/s] :00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45 Czas [s] Rys Prędkość połączenia przy wysyłaniu danych do serwera przez komputer A oraz komputer B jednocześnie oraz dodatkowy ruch przeniesiony z klasy uprzywilejowanej do klasy średniego uprzywilejowania; kolejka PRIO Fig Transmission speed obtained during simultaneous data sending by computer A and computer B and additional traffic moved from privileged class to medium privileged class, PRIO queue Opoznienie [ms] Czas [s] Rys Opóźnienie pakietów dla zwykłego ruchu, przeciążone łącze; kolejka PRIO Fig Packets delay for normal traffic transmission, the overloaded link, PRIO queue

149 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Kolejka CBQ Kolejka CBQ była w pewnym okresie podstawową kolejką (zaimplementowaną w systemie Linux), pozwalającą na tworzenie skomplikowanych, hierarchicznych modeli klasyfikowania ruchu w sieci. Oprócz hierarchii klas kolejka ta pozwala na kształtowanie ruchu (podobnie jak algorytm cieknącego wiadra z żetonami). Wadą tego mechanizmu jest dość duża liczba ustawianych parametrów. Dobór konfiguracji kolejki CBQ miał na celu zaprezentowanie możliwości statycznego i dynamicznego dzielenia pasma przepustowości. Przykładową konfigurację systemu, wykorzystaną do testów, prezentują listingi 6.6 oraz 6.7. Stworzoną hierarchię klas przedstawia rysunek Listing 6.6. Konfiguracja klas kolejki CBQ i przydzielenie im dyscypliny SFQ dla ruchu wychodzącego poprzez interfejs ETH0: # t c q d i s c add dev e t h 0 r o o t h a n d l e 1 : 0 cbq bandwidth 100 Mbit a v p k t 1000 c e l l 8 # t c c l a s s add dev e t h 0 p a r e n t 1 : 0 c l a s s i d 1 : 1 cbq bandwidth 100 Mbit r a t e 5 Mbit i s o l a t e d bounded w e i g h t 0. 5 Mbit p r i o 8 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c c l a s s add dev e t h 0 p a r e n t 1 : 0 c l a s s i d 1 : 2 cbq bandwidth 100 Mbit r a t e 5 Mbit i s o l a t e d bounded weight 0. 5 Mbit p r i o 8 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c c l a s s add dev e t h 0 p a r e n t 1 : 1 c l a s s i d 1:10 cbq bandwidth 5 Mbit r a t e 4 Mbit s h a r i n g borrow weight 0. 4 Mbit p r i o 5 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c c l a s s add dev e t h 0 p a r e n t 1 : 1 c l a s s i d 1:20 cbq bandwidth 5 Mbit r a t e 1 Mbit s h a r i n g borrow weight 0. 1 Mbit p r i o 1 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c q d i s c add dev e t h 0 p a r e n t 1:10 h a n d l e 1 0 : s f q # t c q d i s c add dev e t h 0 p a r e n t 1:20 h a n d l e 2 0 : s f q # t c q d i s c add dev e t h 0 p a r e n t 1 : 2 h a n d l e 3 0 : s f q # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1 : 1 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1 : 2 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1:10

150 150 Ocena mechanizmów kolejkowania # t c f i l t e r add dev e t h 0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 3 u32 match i p t o s 0x10 0 x f f f l o w i d 1:20 5 Mb/s Korzeń 1:0 5 Mb/s 1:1 1:2 4 Mb/s 1 Mb/s SFQ 1:10 1:20 SFQ SFQ Rys Hierarchia klas dla kolejki CBQ Fig Class hierarchy for CBQ queue Listing 6.7. Konfiguracja klas kolejki CBQ i przydzielenie im dyscypliny SFQ dla ruchu wychodzącego poprzez interfejs img0: # t c q d i s c add dev imq0 r o o t h a n d l e 1 : 0 cbq bandwidth 100 Mbit a v p k t 1000 c e l l 8 # t c c l a s s add dev imq0 p a r e n t 1 : 0 c l a s s i d 1 : 1 cbq bandwidth 100 Mbit r a t e 5 Mbit i s o l a t e d bounded weight 0. 5 Mbit p r i o 8 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c c l a s s add dev imq0 p a r e n t 1 : 0 c l a s s i d 1 : 2 cbq bandwidth 100 Mbit r a t e 5 Mbit i s o l a t e d bounded w e i g h t 0. 5 Mbit p r i o 8 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c c l a s s add dev imq0 p a r e n t 1 : 1 c l a s s i d 1:10 cbq bandwidth 5 Mbit r a t e 4 Mbit s h a r i n g borrow w e i g h t 0. 4 Mbit p r i o 5 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000

151 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania # t c c l a s s add dev imq0 p a r e n t 1 : 1 c l a s s i d 1:20 cbq bandwidth 5 Mbit r a t e 1 Mbit s h a r i n g borrow weight 0. 1 Mbit p r i o 5 a l l o t 1514 c e l l 8 maxburst 20 a v p k t 1000 # t c q d i s c add dev imq0 p a r e n t 1:10 h a n d l e 1 0 : s f q # t c q d i s c add dev imq0 p a r e n t 1:20 h a n d l e 2 0 : s f q # t c q d i s c add dev imq0 p a r e n t 1 : 2 h a n d l e 3 0 : s f q # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p d s t / 2 4 f l o w i d 1 : 1 # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p d s t / 2 4 f l o w i d 1 : 2 # t c f i l t e r add dev imq0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 5 u32 match i p d s t / 2 4 f l o w i d 1:10 # t c f i l t e r add dev imq0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 3 u32 match i p t o s 0 x10 0 x f f f l o w i d 1:20 # i p t a b l e s t mangle F # i p t a b l e s t mangle A PREROUTING i e t h 0 j IMQ t o d e v Opoznienie [ms] Opoznienie [ms] Czas [s] Czas [s] Rys Opóźnienie dla badanego ruchu na linii obciążonej między komputerem A a serwerem; transmisja przekraczająca założony limit w klasie CBQ (wykres lewy), transmisja mieszcząca się w założonym limicie w klasie CBQ (wykres prawy) Fig Traffic delay on overloaded link between computer A and server; transmission exceeding the established limit in CBQ class (left), transmission keeping the established limit in CBQ class (right) Podział pasma odbywa się statycznie na poziomie klas 1:1 i 1:2 (rysunek 6.14). Oznacza to, że dla każdej z obu klas przyporządkowano po 5 Mbit/s z całkowitej przepustowości i nie mogą one uzyskać więcej w chwili bezczynności swego rodzeństwa. Nie mogą też użyczyć tego pasma w chwili swojej bezczynności.

152 152 Ocena mechanizmów kolejkowania Klasa 1:2 Klasa 1:10 Klasa 1: Klasa 1:2 Klasa 1:10 Klasa 1: Predkosc transmisji [B/s] Predkosc transmisji [B/s] :40 51:45 51:50 51:55 52:00 52:05 52:10 52:15 52:20 52:25 52:30 52: :05 24:10 24:15 24:20 24:25 24:30 24:35 24:40 Czas [s] Czas [s] Rys Prędkość połączeń należących do klas kolejki CBQ; klasa 1:20 z podwyższonym priotytetem (wykres lewy), klasa 1:20 z normalnym priorytetem (wykres prawy) Fig Transmission speed of streams belonging to class of CBQ queue; class 1:20 with increased priority (left), class 1:20 with normal priority (right) Odpowiada za to opcja isolated bounded w linii konfiguracji klasy CBQ. Inaczej jest w przypadku klas 1:10 i 1:20. Pasmo przepustowości dla tych klas jest przyznawane dynamicznie, czyli w przypadku, gdy jedna klasa nie obsługuje żadnego ruchu, druga może zająć całe dostępne pasmo od swojego rodzica. Dodatkowo ruch klasy 1:20 obsługiwany jest z wyższym priorytetem. Badanie przeprowadzono generując ruch dla każdej zdefiniowanej klasy osobno. Do klasy 1:2 zaklasyfikowany został ruch z komputera B do serwera, do klasy 1:10 ruch z komputera A do serwera, a do klasy 1:20 ruch oznaczony polem TOS 0x10 (minimalne opóźnienie). Działanie statycznego i dynamicznego podziału łącza wykazano rozsynchronizowując poszczególne transmisje. Początkowo transmisję rozpoczyna komputer B (ruch należący do klasy 1:2), następnie uruchamia transmisję komputer A (klasa 1:10). Na końcu zaczyna transmisję ruch z narzędzia iperf, zaklasyfikowany do klasy 1:20. W pierwszej kolejności kończy nadawanie ruch z klasy 1:10, a na końcu ruch z klasy 1:20 i 1:2. Ustawienie pola TOS 0x10 wykonano za pomocą identycznych poleceń z przypadkiem kolejki PRIO (patrz listing 6.5). Rysunek 6.15 pokazuje opóźnienie dla badanego strumienia, należącego do klasy 1:20 w przypadku, gdy natężenie jego ruchu przekracza znacznie dopuszczalną wartość 1 Mbit/s oraz gdy strumień transmituje z założoną prędkością. Ruch przekraczający limit prędkości dla swojej klasy doznaje opóźnień większych o rząd wielkości od ruchu dopasowanego do parametrów konfiguracji. Późniejszy spadek opóźnień (dla przeciążonego strumienia) jest efektem zakończenia transmisji danych przez strumień, należący do rodzeństwa klasy ruchu badanego. Przekroczenie prędkości powoduje również wzrost odsetek gubionych pakietów

153 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania na poziomie 85% w chwili, gdy wszystkie strumienie wykorzystują łącze i 50% po zakończeniu transmisji przez jedną z klas. Rysunek 6.16 przedstawia prędkość poszczególnych strumieni danych w kolejnych odcinkach czasu. Transmisję rozpoczyna strumień klasyfikowany jako 1:2. Po pewnym czasie pojawia się strumień z klasy 1:10. Transmisja z klasy 1:10 nie wpływa w żaden sposób na klasę 1:2, ponieważ podział pasma dla tych dwóch strumieni jest statyczny. Pojawienie się strumienia klasyfikowanego jako 1:20 wpływa na klasę 1:10. Obydwie klasy podzieliły się pasmem po połowie (patrz wykres lewy). W założeniu klasa 1:20 miał przejąć jedynie 1/5 pasma dostępnego dla obydwu przepływów, jednak klasa o niższym priorytecie jest zawsze odpytywana jako pierwsza, co doprowadza do przywłaszczenia sobie przez nią większych zasobów. Dowodem na powyższe stwierdzenie (o nieplanowanym wpływie priorytetu na działanie mechanizmu) są wyniki w powtórzonym eksperymencie. Obydwu klasom (1:10 oraz 1:20) nadano taki sam priorytet. Rezultaty przedstawia prawa część omawianego rysunku. W tym przypadku ruch z klasy 1:20 zajął jedynie tyle dostępnej przepustowości, ile powinien. Kolejka HTB Główną ideą powstania kolejki HTB (ang. Hierarchical Token Bucket) było umożliwienie tworzenia klas, dodatkowo kształtujących ruch za pomocą algorytmu wiadra żetonów. Nie występuje w niej czasochłonne przeliczanie zajętości łącza, jak ma to miejsce w kolejce CBQ. Takie podejście upraszcza konfigurację mechanizmu, w czasie której nie ma konieczności podawania wielu parametrów konfiguracyjnych. Wystarczy jedynie ustalić parametry dla wiadra żetonów, stworzyć hierarchię klas oraz ewentualnie nadać priorytety dla klas strumieni. Na potrzeby opisanego w tej sekcji eksperymentu stworzono konfigurację kolejek o tej samej hierarchii klas jak dla kolejki CBQ (patrz rysunek 6.14). Konfigurację systemu przedstawiają listingi 6.8 oraz 6.9. Stworzone klasy odpowiadają funkcjonalnie konfiguracji kolejki CBQ zaproponowanej w poprzedniej sekcji. Porównując skrypty tworzące obydwie kolejki, łatwo zauważyć prostotę konfiguracji kolejek HTB w porównaniu do konfiguracji kolejki CBQ.

154 154 Ocena mechanizmów kolejkowania Listing 6.8. Konfiguracja klas kolejki HTB i przydzielenie algorytmu kolejkowania SFQ dla ruchu wychodzącego poprzez interfejs ETH0: # t c q d i s c add dev e t h 0 r o o t h a n d l e 1 : h t b # t c c l a s s add dev e t h 0 p a r e n t 1 : 0 c l a s s i d 1 : 1 h t b r a t e 5 Mbit b u r s t 15k # t c c l a s s add dev e t h 0 p a r e n t 1 : 0 c l a s s i d 1 : 2 h t b r a t e 5 Mbit b u r s t 15k # t c c l a s s add dev e t h 0 p a r e n t 1 : 1 c l a s s i d 1:10 h t b r a t e 4 Mbit c e i l 5 Mbit b u r s t 15k p r i o 5 # t c c l a s s add dev e t h 0 p a r e n t 1 : 1 c l a s s i d 1:20 h t b r a t e 1 Mbit c e i l 5 Mbit b u r s t 15k p r i o 1 # t c q d i s c add dev e t h 0 p a r e n t 1:10 h a n d l e 1 0 : s f q # t c q d i s c add dev e t h 0 p a r e n t 1:20 h a n d l e 2 0 : s f q # t c q d i s c add dev e t h 0 p a r e n t 1 : 2 h a n d l e 3 0 : s f q # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1 : 1 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1 : 2 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 5 u32 match i p s r c / 2 4 f l o w i d 1:10 # t c f i l t e r add dev e t h 0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 3 u32 match i p t o s 0x10 0 x f f f l o w i d 1:20 Listing 6.9. Konfiguracja klas kolejki HTB i przydzielenie im algorytmu kolejkowania SFQ dla ruchu wychodzącego poprzez interfejs img0: # t c q d i s c add dev imq0 r o o t h a n d l e 1 : h t b # t c c l a s s add dev imq0 p a r e n t 1 : 0 c l a s s i d 1 : 1 h t b r a t e 5 Mbit b u r s t 15k # t c c l a s s add dev imq0 p a r e n t 1 : 0 c l a s s i d 1 : 2 h t b r a t e 5 Mbit b u r s t 15k # t c c l a s s add dev imq0 p a r e n t 1 : 1 c l a s s i d 1:10 h t b r a t e 4 Mbit c e i l 5 Mbit b u r s t 15k p r i o 5 # t c c l a s s add dev imq0 p a r e n t 1 : 1 c l a s s i d 1:20 h t b r a t e 1 Mbit c e i l 5 Mbit b u r s t 15k p r i o 1 # t c q d i s c add dev imq0 p a r e n t 1:10 h a n d l e 1 0 : s f q # t c q d i s c add dev imq0 p a r e n t 1:20 h a n d l e 2 0 : s f q # t c q d i s c add dev imq0 p a r e n t 1 : 2 h a n d l e 3 0 : s f q # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5

155 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania u32 match i p d s t / 2 4 f l o w i d 1 : 1 # t c f i l t e r add dev imq0 p a r e n t 1 : 0 p r o t o c o l i p p r i o 5 u32 match i p d s t / 2 4 f l o w i d 1 : 2 # t c f i l t e r add dev imq0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 5 u32 match i p d s t / 2 4 f l o w i d 1:10 # t c f i l t e r add dev imq0 p a r e n t 1 : 1 p r o t o c o l i p p r i o 3 u32 match i p t o s 0x10 0 x f f f l o w i d 1:20 # i p t a b l e s t mangle F # i p t a b l e s t mangle A PREROUTING i e t h 0 j IMQ t o d e v Klasa 1:2 Klasa 1:10 Klasa 1: Predkosc transmisji [B/s] :45 52:50 52:55 53:00 53:05 53:10 53:15 53:20 Czas [s] Rys Prędkość połączeń poszczególnych klas kolejki HTB Fig Transmission speed of individual class for HTB queue Rysunek 6.17 przedstawia prędkości transmisji uzyskane przez strumienie należące do różnych klas ruchu. Ruch w klasach 1:10 i 1:20 nie wpływa na ruch w klasie 1:2 (jeżeli sieć posiada wystarczającą przepustowość). Pojawienie się ruchu, należącego do klasy 1:20, powoduje obniżenie prędkości ruchu z klasy 1:10. Wykres 6.18 pokazuje prędkość transmisji strumienia zaklasyfikowanego do klasy 1:20 w zależności od ustawienia pola TOS. Wzrost prędkości w drugiej części wykresu wynika z zakończenia transmisji dla klasy 1:10.

156 156 Ocena mechanizmów kolejkowania Klasa 1:20 z TOS 0x10 Klasa 1:20 z nieustawionym TOS 4 Predkosc transmisji [MB/s] Czas [s] Rys Prędkość transmisji w zależności od pola TOS Fig Transmission speed depending on TOS field Rysunek 6.19 pokazuje opóźnienia dla ruchu UDP o prędkości 10 Mbit/s i 1 Mbit/s. Podobnie jak w kolejce CBQ, również i tutaj przekroczenie dopuszczalnej prędkości ruchu powoduje występowanie dużych opóźnień. Podsumowanie Przebadane powyżej dyscypliny kolejkowania przeznaczone są do różnych celów. Najprostszą i najmniej funkcjonalną okazała się być domyślna kolejka pfifo_fast. Kolejka SFQ pozwala dzielić dostępną przepustowość połączenia pomiędzy konkurujące o nią przepływy, dzięki czemu przeciwdziała sytuacji, w której jedna transmisja może zawłaszczyć całą dostępną przepustowość łącza. W przypadku potrzeby dostosowania charakterystyki przepływu można wykorzystać filtr TBF lub użyć kombinacji poznanych mechanizmów w kolejce PRIO, która pozwala na domyślne klasyfikowanie ruchu lub definiowanie własnych reguł. Porównując kolejki HTB oraz CBQ, należy stwierdzić, że konfiguracja pierwszej z nich jest dużo prostsza. Z praktycznego punktu widzenia oferuje ona usługi kolejkowania bez potrzeby skomplikowanego doboru parametrów, których więk-

157 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Opoznienie [ms] Opoznienie [ms] Czas [s] Czas [s] Rys Opóźnienie dla ruchu UDP; prędkość transmisji 10 Mbit/s przekraczająca założony limit (wykres lewy), prędkość transmisji mieszcząca się w limicie prędkości (wykres prawy) Fig Delay for UDP traffic; transmission speed 10 Mbit/s exceeding the established limit (left), transmission speed keeping the established limit (right) szość, tak jak w przypadku CBQ, jest słabo udokumentowana i często niezrozumiała dla przeciętnego użytkownika. Wyniki badań pokazały, że w przypadku kolejki CBQ nadanie priorytetu wewnątrz klas, które mogą sobie pożyczać przepustowość, może doprowadzić do przekraczania założonych limitów prędkości przesyłu danych. Sytuacja taka nie występuje w przypadku kolejki HTB. Podczas testów wykazano, jak ważne jest dopasowywanie charakterystyki transmisji, zwłaszcza jej prędkości do parametrów kolejki, skonfigurowanej dla klasy, w której mieści się dane połączenie. Ruch przekraczający te parametry powoduje powstawanie kolejek, które drastycznie zwiększają czas potrzebny na dotarcie danych do celu. Problem dużych opóźnień można rozwiązać przez skrócenie długości kolejki, co powoduje wzrost liczby gubionych pakietów lub dostosowanie parametrów ruchu.

158 Rozdział 7 IMPLEMENTACJA ORAZ OCENA MECHANIZMÓW AQM Niniejszy rozdział przedstawia badania wybranych mechanizmów aktywnego zarządzania kolejką. Algorytmy te zostały szczegółowo omówione w rozdziale 4. Badania opisane w tym rozdziale zostały zrealizowane za pomocą symulacji oraz badań rzeczywistego routera opartego na komputerze z zainstalowanym systemem operacyjnym Linux Symulacja mechanizmów aktywnego zarzadzania kolejka W rozdziale tym zostanie przedstawiona ocena wybranych mechanizmów AQM w pakiecie symulacyjnym SimPy. Pakiet SimPy jest środowiskiem symulacyjnym zdarzeń dyskretnych opartym na standardowych mechanizmach języka Python. Pakiet symulacyjny zarządza zdarzeniami, wykorzystując pythonowskie mechanizmy generatorów [77]. Symulator jest udostępniany na podstawie licencji MIT. W trakcie badań dokonano oceny wpływu mechanizmu zarządzania kolejkami na straty pakietów, średni czas przejścia pakietów przez system oraz zajętość kolejek. Oceny dokonano dla modeli z pętlą otwartą (ang. open loop) oraz z pętlą zamkniętą biorącą pod uwagę zachowanie protokołu TCP Badania z pętla otwarta Mimo iż większość ruchu internetowego odbywa się za pomocą protokołu TCP, badania typu open loop mają również niezaprzeczalną wartość. Po pierwsze, udział ruchu UDP, który nie posiada żadnych mechanizmów sterowania transmisją, cały czas rośnie. Po drugie, badania open loop mogą w pewnym stopniu odzwierciedlać zachowanie dużej liczby źródeł TCP, a badania wprost przez symulacje dużej liczby strumieni TCP mogą być bardzo złożone obliczeniowo. Uzyskanie rzetelnych wyników w przypadku symulacji open loop może zależeć od sposobu generowania zdarzeń (generowania pakietów). Dlatego w przedstawionych w tym rozdziale symulacjach dokonano oceny wpływu samopodob-

159 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania nej charakterystyki ruchu internetowego na uzyskane wyniki. Od ponad dwóch dekad analiza ruchu internetowego została zdominowana przez analizę zależności długoterminowych, samopodobieństwa oraz tzw. rozkładu długoogonowego. Na potrzeby symulacji wykorzystano metodę generowania przybliżonych próbek dla procesów fgn (Fractional Gaussian Noise) przedstawioną w [78]. W ramach pracy wygenerowano za pomocą metody fgn próbki o założonej wartości parametru Hursta zmieniającego się od 0.5 do 0.95 (im większy parametr Hursta, tym większe zależności długoterminowe LRD, dla Hursta=0.5 brak takowych (normalne źródło Poissonowskie)) oraz założonej intensywności źródła λ = 0.5. Po każdym wygenerowaniu próbki, metodą zagregowanej wariancji, szacowano rzeczywistą wartość parametru Hursta. Przykładowe wyniki dla 10 próbek dla parametru Hursta równego 0.7 przedstawia tabela 7.1. Jak widać, uzyskane oszacowane wartości parametru Hursta różnią się od założonego. Sytuacja ta powtarzała się dla każdej wartości parametru Hursta. Tabela 7.1. Oszacowany parametr Hursta dla wygenerowanych próbek fgn dla założonego Hursta=0.7 Nr próbki Oczacowany parametr Hursta Rysunek 7.1 pokazuje, jak wyglądają te różnice w zależności od współczynnika samopodobieństwa generowanej próbki. Generator w większości próbek generuje ruch o większym współczynniku samopodobieństwa. Można zauważyć, że błąd ten maleje wraz ze wzrostem parametru Hursta. Dla małych wartości błąd ten wynosił od 3% do 5%. Dla Hursta=0.95 szacowana wartość różni się od wartości pożądanej tylko o 0.06%, co przelicza się na około 80-krotny wzrost sprawności w stosunku do najgorszej wygenerowanej próbki. Do symulacji zostały wybrane próbki o najniższym odchyleniu od wartości pożądanych parametru Hursta.

160 160 Implementacja oraz ocena mechanizmów AQM 6,00% 5,00% 4,00% Odchylenie 3,00% 2,00% 1,00% 0,00% ,00% hurst Rys Maksymalny i minimalny błąd pomiędzy założoną i oszacowaną wartością parametru Hursta Fig Maximal and minimal error between established and estimated Hurst parameter value Celem przeprowadzonych symulacji była ocena, jak aktywne zarządzanie pakietami oraz strategia wyboru pakietu do odrzucenia (z początku kolejki lub pakietu nadchodzący) wpływa na zachowanie kolejek (straty pakietów, średni czas oczekiwania pakietów w kolejkach oraz zajętość kolejek). Intensywność źródła pakietów (niezależnie od parametru Hursta) była stała i wynosiła λ = 0.5. Parametr µ geometrycznego rozkładu czasu obsługi (prawdopodobieństwo pobrania pakietu z kolejki w danej szczelinie czasowej) wynosił µ = Taki dobór parametrów pozwala na rozważania bardzo obciążonego układu.

161 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50 Fig Simulation results for FIFO queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.50 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50 Fig Simulation results for FIFO queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.50 Czas

162 162 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.70 Fig Simulation results for FIFO queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.70 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.70 Fig Simulation results for FIFO queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.70 Czas

163 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80 Fig Simulation results for FIFO queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.80 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80 Fig Simulation results for FIFO queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.80 Czas

164 164 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90 Fig Simulation results for FIFO queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.90 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki FIFO; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90 Fig Simulation results for FIFO queue; from front packet dropping, waiting times distribution (left), queue occupancy (right); Hurst=0.90 Czas

165 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rysunki od 7.2 do 7.9 pokazują zapełnienie kolejki oraz rozkład średniego czasu oczekiwania w zależności od współczynnika samopodobieństwa oraz sposobu pobierania pakietu z kolejki. Badanym algorytmem kolejkowania była metoda FIFO. Maksymalny rozmiar kolejki wynosił 300 pakietów. Wyraźnie widać, że burzowa charakterystyka ruchu powoduje duże fluktuacje zajętości kolejki. O ile dla parametru Hursta równego 0.7 są one ledwie zauważalne, o tyle dla Hursta równego 0.9 są one już znaczące. Tabela 7.2. Wyniki symulacji kolejki FIFO Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość przebywania pakietów kolejki pakietów w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop Szczegółowe rezultaty zostały przedstawione w tabeli 7.2. Jak można zauważyć, odrzucanie pakietu z końca kolejki skraca średni czas oczekiwania pakietów w kolejce. Natomiast wzrastające samopodobieństwo źródła zwiększa liczbę odrzuconych pakietów. Wzrost ten nie jest wynikiem wzrostu intensywności źródła. Badania wykazały, że niezależnie od parametru Hursta każde ze źródeł generowało dokładnie taką samą liczbę pakietów. W omawianym przypadku dla parametru λ = 0.50 liczba slotów, w których źródło generowało pakiet, było równe dokładnie połowie liczby wszystkich slotów. Wzrost liczby odrzuconych pakietów jest wynikiem statystycznych właściwości źródła, co najlepiej odzwierciedlają wykresy 7.8 oraz 7.9. Dla wzrastającej wartości parametru Hursta okresy, w których źródło generuje dużą liczbę pakietów, przeplatają się z okresami zastojów. Taka właściwość ruchu staje się powodem wzrostu strat pakietów przy zmniejszającej się średniej zajętości kolejki.

166 166 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50 Fig Simulation results for RED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.50 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50 Fig Simulation results for RED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.50 Czas

167 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80 Fig Simulation results for RED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.80 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80 Fig Simulation results for RED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.80 Czas

168 168 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90 Fig Simulation results for RED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.90 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki RED; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90 Fig Simulation results for RED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.90 Czas

169 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela 7.3. Wyniki symulacji kolejki RED Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop Bardzo podobne zależności uzyskano w trakcie symulacji dla kolejki RED (rysunki od 7.10 do 7.15). Parametry kolejki RED były następujące: w = 0.02, Min th = 100, Max th = 200, P max = 0.1, rozmiar bufora M ax_size = 300. Szczegółowe rezultaty zostały przedstawione w tabeli 7.3. Kolumna Straty- RED1 przedstawia liczbę odrzuconych pakietów w wyniku losowania dla kroczącej zajętości kolejki<max th. Kolumna Straty-RED2 pokazuje straty spowodowane przekroczeniem Max th. Kolumna Straty-bufor to straty spowodowane przekroczeniem maksymalnego rozmiaru bufora. Uzyskane rezultaty pokazują niedoskonałości algorytmu RED. Pierwszą wada algorytmu wynika z doboru parametrów symulacji (duże przeciążenie systemu). Większość pakietów odrzucana jest z powodu przekroczenia maksymalnego progu. Zajętość kolejki cały czas oscyluje wokół tej wartości. Analizując wyniki dla parametru Hursta równego 0.90, można zauważyć jeszcze jedną słabość tego algorytmu. Brak strat z powodu przekroczenia maksymalnego rozmiaru bufora przy równoczesnej dużej liczbie strat i zmniejszonej średniej zajętości kolejki pokazuje, że algorytm RED nie radzi sobie również w przypadku ruchu sieciowego o dużej fluktuacji.

170 170 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50, a1 = , a2 = , P max = Fig Simulation results for NLRED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.50, a1 = , a2 = , P max = Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80, a1 = , a2 = , P max = Fig Simulation results for NLRED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.80, a1 = , a2 = , P max = Czas

171 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, a1 = , a2 = , P max = Fig Simulation results for NLRED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.90, a1 = , a2 = , P max = Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów z początku kolejki, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, a1 = , a2 = , P max = Fig Simulation results for NLRED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.80, a1 = , a2 = , P max = Czas

172 172 Implementacja oraz ocena mechanizmów AQM Tabela 7.4. Wyniki symulacji kolejki NLRED - a1 = , a2 = , P max = Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop Artykuł [53] proponuje modyfikację obliczania prawdopodobieństwa wyrzucenia pakietu opartą na krzywych wielomianowych. W artykule wykazano, że kształt krzywej może wpływać na zachowanie mechanizmu kolejkowania. W zrealizowanych symulacjach wykorzystano dwa zestawy parametrów zaproponowanych w artykule. Pierwszy zestaw odpowiada funkcji prawdopodobieństwa minimalizującej czas oczekiwania pakietów w kolejce kosztem strat. Drugi zestaw parametrów odpowiada mechanizmowi odwrotnemu. Parametry kolejki RED były następujące: w = 0.02, Min th = 100, Max th = 200, rozmiar bufora M ax_size = 300. W czasie badań przeprowadzono symulację dla dwóch rodzajów funkcji prawdopodobieństwa utraty pakietów o następujących współczynnikach wielomianu: agresywna kontrola długości kolejki (duże straty pakietów): a1 = , a2 = , P max = 0.855, minimalizacja strat: a1 = , a2 = , P max = 0.6.

173 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50, a1 = , a2 = , P max = 0.6 Fig Simulation results for NLRED queue; drop-from-tail, waiting times distribution (left), queue occupancy (right); Hurst=0.50, a1 = , a2 = , P max = 0.6 Czas Szczegółowe wyniki zostały przedstawione w tabelach 7.4 oraz 7.5. Dla agresywnego odrzucania pakietów (tabela 7.4) wszystkie pakiety odrzucane są zanim rozmiar kolejki przekroczy Max th (rysunki od 7.16 do 7.19). Dla mechanizmu mniej agresywnego (tabela 7.5) znaczna liczba pakietów jest odrzucana z powodu przekroczenia Max th. Jednocześnie zajętość kolejki oscyluje wokół tej wartości (rysunki 7.20 oraz 7.21). Bardzo ciekawe efekty można zaobserwować porównując straty uzyskane w zrealizowanych do tej pory symulacjach (tabele 7.4 oraz 7.5). Dla źródeł o niskim samopodobieństwie (H = ) wyraźnie widać, że liczba strat (suma strat odrzuconych przez mechanizm RED i z powodu przekroczenia Max th ) jest mniejsza dla agresywnego odrzucania pakietów (pierwszy eksperyment). Dla H = 0.80 liczba odrzucanych pakietów jest podobna dla obydwu eksperymentów. Dopiero dla H = 0.90 liczba straconych pakietów jest większa dla drugiego eksperymentu. Bardzo podobne zależności uwidoczniły się przy badaniach zwykłego algorytmu RED (tabela 7.3). Eksperymenty te pokazały, że w większości przypadków agresywne odrzucanie pakietów może być bardziej opłacalne. Uzyskujemy o wiele lepsze średnie czasy oczekiwania pakietów w kolejce, a liczba strat i tak jest mniejsza.

174 174 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki NLRED; usuwanie pakietów nadchodzących, rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, a1 = , a2 = , P max = 0.6 Fig Simulation results for NLRED queue; drop-from-front, waiting times distribution (left), queue occupancy (right); Hurst=0.90, a1 = , a2 = , P max = 0.6 Czas Tabela 7.5. Wyniki symulacji kolejki NLRED - a1 = , a2 = , P max = 0.6 Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop

175 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania H=0.50 H=0.70 H=0.80 H= H=0.50 H=0.70 H=0.80 H=0.90 Prawdopodobienstwo 6 4 Prawdopodobienstwo Rozmiar kolejki Rozmiar kolejki Rys Rozkład zajętości kolejki dla algorytmu RED w zależności od parametru Hursta; standardowa średnia (wykres lewy), zmodyfikowana średnia (wykres prawy) Fig Queue length distribution for RED depending on Hurst parameter; standard average (left), modified average (right) W kolejnych eksperymentach przebadano wpływ zmodyfikowanego algorytmu obliczania średniej kroczącej długości kolejki na zachowanie kolejki. W standardowym podejściu średnia ta zależy od aktualnej zajętości kolejki oraz wartości średniej obliczonej w poprzednim kroku. W rozdziale 4.3 przedstawiono podejście proponujące obliczanie średniej ważonej na podstawie kilku poprzednich kroków (patrz wzór 4.3). W artykule [48] do obliczania średniej zaproponowano następujący zestaw wartości wagowych: [a 1, a 2, b 1 ] = [0.08, , 0.001]. W przeprowadzonych symulacjach wykorzystano niniejsze wartości. Szczegółowe rezultaty pokazuje tabela 7.6. Wpływ sposobu obliczania średniej kroczącej na zajętość kolejki przedstawia rysunek Różnice w stosunku do standardowego algorytmu RED nie są duże (różnice sięgają w zależności od parametru Hursta od 0.02% do 0.1%). Podobne zależności można wykazać dla algorytmu NLRED (tabele 7.7 i 7.8). Mimo niewielkich różnic wyraźnie widać tendencję do polepszania się wyników (w stosunku do standardowego obliczania średniej) przy wzrastającym parametrze Hursta. Wyniki te sugerują, że dla ruchu sieciowego o dużych zależnościach długoterminowych zwiększanie wpływu liczby danych historycznych (liczby momentów) w obliczaniu średniej kroczącej staje się opłacalne.

176 176 Implementacja oraz ocena mechanizmów AQM Tabela 7.6. Wyniki symulacji kolejki RED ze zmodyfikowanym sposobem obliczania średniej kroczącej zajętości kolejki Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop Tabela 7.7. Wyniki symulacji NLRED ze zmodyfikowanym obliczaniem średniej kroczącej zajętości kolejki - a1 = , a2 = , P max = Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop

177 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela 7.8. Wyniki symulacji kolejki NLRED ze zmodyfikowanym sposobem obliczania średniej kroczącej zajętości kolejki - a1 = , a2 = , P max = 0.6 Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów RED1 RED2 Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop We wszystkich poprzednio przeprowadzonych symulacjach wraz ze wzrostem parametru Hursta źródła rosła również liczba odrzucanych pakietów z równoczesnym zmniejszaniem się średniej zajętości kolejki. Czyli tak naprawdę mechanizm AQM wyrzucał zbyt dużą liczbę pakietów, niż było to konieczne. Zaproponowane modyfikacje w różnym stopniu wpływały na to zjawisko. Na przykład, mechanizm modyfikacji obliczania średniej ważonej spowodował poprawienie rezultatów przy wzrastającym współczynniku Hursta. Przedstawione poniżej rezultaty opierają się na zupełnie innym podejściu do aktywnego zarządzania pakietami za pomocą kontrolera PI. Mechanizm ten został dokładnie opisany w rozdziale 4.3.

178 178 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50, K p = , K i = , λ = 1.0 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.50, K p = , K i = , λ = 1.0 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.70, K p = , K i = , λ = 1.0 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.70, K p = , K i = , λ = 1.0 Czas

179 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80, K p = , K i = , λ = 1.0 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.80, K p = , K i = , λ = 1.0 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, K p = , K i = , λ = 1.0 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.90, K p = , K i = , λ = 1.0 Czas

180 180 Implementacja oraz ocena mechanizmów AQM Tabela 7.9. Wyniki symulacji dla kolejki P I λ - K p = , K i = , λ = 1.0 Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów PID Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50, K p = , K i = , λ = 1.2 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.50, K p = , K i = , λ = 1.2 Czas

181 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.70, K p = , K i = , λ = 1.2 Fig Simulation results for P I λ queue, the waiting times distribution (left), the queue occupancy (right), Hurst=0.70, K p = , K i = , λ = 1.2 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80, K p = , K i = , λ = 1.2 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.80, K p = , K i = , λ = 1.2 Czas

182 182 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, K p = , K i = , λ = 1.2 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.90, K p = , K i = , λ = 1.2 Czas Tabela Wyniki symulacji kolejki P I λ - K p = , K i = , λ = 1.2 Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów PID Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop

183 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.50, K p = , K i = , λ = 0.8 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.50, K p = , K i = , λ = 0.8 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.70, K p = ; K i = , λ = 0.8 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.70, K p = , K i = , λ = 0.8 Czas

184 184 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.80, K p = , K i = , λ = 0.8 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.80, K p = , K i = , λ = 0.8 Czas Zajetosc kolejki Rys Wyniki symulacji dla kolejki P I λ ; rozkład czasu oczekiwania w kolejce (wykres lewy), zajętość kolejki (wykres prawy), parametr Hursta=0.90, K p = , K i = , λ = 0.8 Fig Simulation results for P I λ queue, waiting times distribution (left), queue occupancy (right), Hurst=0.90, K p = , K i = , λ = 0.8 Czas

185 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji kolejki P I λ - K p = , K i = , λ = 0.8 Sposób Parametr Średnia Śr. czas Straty usuwania samopod. zajętość pakietów PID Bufor pakietów kolejki w kolejce Tail drop Front drop Tail drop Front drop Tail drop Front drop Tail drop Front drop W czasie symulacji tzw. set_point, czyli pożądany rozmiar, do którego dążymy w regulacji kolejki, ustawiony został na 100 pakietów. Jest to wielkość równa parametrowi Max th dla kolejki RED. Przedstawione rezultaty pokazują, jak dobór parametrów kontrolera wpływa na jego możliwości regulowania zajętości kolejki. W przedstawionych eksperymentach zaproponowano trzy zestawy parametrów kontrolera, ilustrujące zupełnie trzy różne zachowania kontrolera. Dla wszystkich trzech eksperymentów parametry K p = , K i = były identyczne. Kontrolery różnią się jedynie rzędem całkowania λ. Tabela 7.9 pokazuje wyniki dla kontrolera z całkowitym rzędem całkowania równym 1 (λ = 1). Z wszystkich trzech przypadków jest on najbardziej wyważony. Dla tego przypadku uzyskano również zachowanie niepojawiające się dla mechanizmu RED. Wraz ze wzrostem parametru Hursta rosną oczywiście straty, ale rośnie również średnia zajętość kolejki. Wykresy od 7.23 do 7.24 pokazują, jak wygląda zachowanie kolejki w zależności od samopodobieństwa źródła pakietów. Rysunek 7.24 tłumaczy to zjawisko. Po okresie zastoju w sieci kontroler pozwala na chwilowe większe zajętości kolejki. Zachowanie to wypływa z zasad obliczania prawdopodobieństwa strat. W przypadku algorytmu RED chwile, w których zajętość kolejki nie przekracza Min th, nie mają wpływu na prawdopodobieństwo strat. W przypadku modułu całkującego kontrolera okresy te powodują zmniejszenie prawdopodobieństwa. Tabela 7.10 pokazuje rezultaty dla kontrolera z rzędem całkowania λ = 1.2. Straty pakietów są podobne jak w pierwszym przypadku. Wykresy od 7.27 do

186 186 Implementacja oraz ocena mechanizmów AQM 7.30 pokazują, że kontroler ten doskonale stabilizuje kolejkę wokół pożądanego rozmiaru. Patrząc na rozkłady czasu oczekiwania, można zauważyć, że są one podobne i nie zależą od samopodobieństwa. Kontroler z rzędem całkowania λ = 0.8 okazał się całkowicie niespełniający swojej funkcji (patrz tabela 7.11). Większość pakietów została wyrzucona z powodu przekroczenia maksymalnego rozmiaru kolejki. W porównaniu do drugiego kontrolera ogólna strata pakietów jest tu niższa o 0.2%, lecz średni czas oczekiwania w kolejce wzrósł aż o 33.67% (dla Hurst = 0.50) Badania z pętla zamknięta W niniejszym rozdziale zostaną przedstawione wyniki symulacyjnych badań mechanizmów TCP oraz ich wpływu na zachowanie kolejek AQM. Na potrzeby badań, wykorzystując przedstawiony w poprzednim rozdziale mechanizm symulacyjny, stworzono dwa uproszczone modele mechanizmów TCP: NewReno oraz Vegas. Stworzony w SimPy uproszczony model protokołu TCP NewReno ma trzy podstawowe mechanizmy wbudowane w algorytm tego typu: wolnego startu, unikania przeciążenia oraz redukcji okna w przypadku straty pakietu. Stworzony model działa w taki sposób, że w danym slocie czasowym generuje pakiety w liczbie równej rozmiarowi okna przeciążenia (CWND). Pakiety umieszczane są w kolejce. Jeżeli dla wszystkich pakietów znajdzie się miejsce w buforze, okno zostaje zwiększone. W przypadku braku miejsca w kolejce (strata pakietu) rozmiar okna zostaje zmniejszony o połowę. Pobieranie pakietów z kolejki odbywa się podobnie jak w poprzednim modelu. W danym slocie czasowym pobierana jest pewna liczba pakietów, zgodnie z rozkładem Poissona i parametrem µ. Regulacja obciążenia kolejki odbywa się poprzez zmienną liczbę pobrań pakietów z kolejki w pojedynczym slocie czasowym (zgodnie z rozkładem). Rysunek 7.35 pokazuje zmiany okna TCP w zależności od szybkości opróżniania kolejki. Wykres po lewej stronie pokazuje sytuację szybszego pobierania pakietów z kolejki. Początkowa wartość parametru progowego (ang. threshold) wynosi 32. Do tego czasu okno rośnie wykładniczo. Po osiągnięciu progu CWND zaczyna rosnąć liniowo. Przy próbie wysłania 102 pakietów dochodzi do strat i okno zostaje zmniejszone o połowę do wartości 51. Od tego momentu okno przeciążeniowe powiększa się liniowo.

187 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Wykres po prawej stronie pokazuje system obciążony. Początek rozwoju okna jest identyczny. Po osiągnięciu CWND=49 dochodzi do przeciążenia i okno zmniejsza się do wartości 25. Zmniejszenie okna nie zapobiega stratom. Po dwóch kolejnych próbach nieudanego wysłania pakietów okno osiąga wartość 7 i powoli liniowo zaczyna rosnąć. Fazy liniowego wzrostu oraz zmniejszania okna o połowę powtarzają się cyklicznie, aż do końca symulacji. Drugim modelem stworzonym na potrzeby eksperymentów był model algorytmu Vegas. W odróżnienie od NewReno, który zmniejsza okno w reakcji na straty pakietów, algorytm Vegas stara się nie dopuścić do strat. Rysunek 7.37 pokazuje ewolucje okna TCP algorytmu Vegas w zależności od obciążenia systemu. Dla kolejki mało obciążonej okno narasta na początku wykładniczo, a potem liniowo aż do osiągnięcia pewnego poziomu CWND. Poziom ten jest utrzymywany aż do końca symulacji. Wraz ze wzrostem obciążenia kolejki rosną wahania okna przeciążenia. Rysunek 7.38 porównuje ewolucję okna przeciążenia dla algorytmów Vegas i NewReno, przesyłających dane tym samym łączem w tym samym czasie, w zależności od obciążenia systemu. Uzyskane wyniki są spowodowane ustawieniem parametrów (α i β) algorytmu Vegas. Zmiany okna dla algorytmu Vegas nie są tak drastyczne. Pozwala to algorytmowi Vegas osiągnąć pewną przewagę nad algorytmem NewReno. Wraz z obciążaniem systemu jego przewaga maleje. Jest to spowodowane ustawieniem parametru β, który wymusza na nim wcześniejszą (w stosunku do NewReno) reakcję i zmniejszenie CWND. Aby pokazać prawdziwość poprzedniego stwierdzenia, powtórzono symulacje, podnosząc wartości progowe α i β dla algorytmu Vegas. Rezultaty tej symulacji przedstawiono na rysunku Przez porównanie z rysunkiem 7.38 (wykresy dolne) można zauważyć, jak podniesienie tych wartości zwiększyło szanse algorytmu Vegas w rywalizacji o łącze (dla obciążonego łącza).

188 188 Implementacja oraz ocena mechanizmów AQM CWND 60 CWND Czas Rys Zmiany okna TCP (typu NewReno); kolejka nieobciążona (wykres lewy), kolejka obciążona (wykres prawy) Fig TCP window evolution (NewReno type); unloaded queue (left), overloaded queue (right) Czas RENO VEGAS RENO VEGAS CWND 30 CWND Czas Rys Ewolucja okna TCP (typu Vegas i NewReno); kolejka obciążona, podniesione wartości parametrów α i β Fig TCP window evolution (Vegas and NewReno type); unloaded queue, increased values of the α i β parameters Czas

189 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania CWND 60 CWND Czas Czas CWND Czas Rys Zmiany okna TCP Vegas; kolejka: nieobciążona (wykres lewy), średnio obciążona (wykres prawy), obciążona znacznie (wykres dolny) Fig TCP Vegas window evolution; unloaded queue (left), medium loaded queue (right), overloaded queue (bottom)

190 190 Implementacja oraz ocena mechanizmów AQM 100 RENO VEGAS RENO VEGAS CWND CWND Czas Czas 50 RENO VEGAS RENO VEGAS CWND CWND Czas Rys Zmiany okna TCP (typu Vegas i NewReno); kolejka: nieobciążona (wykres lewy), średnio obciążona (wykres prawy), obciążona znacznie (wykresy dolne) Fig TCP window evolution (Vegas and NewReno type); unloaded queue (left), medium loaded queue (right), overloaded queues (bottom) Czas

191 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji, wpływ algorytmu sterowania przeciążeniem, kolejka FIFO TCP Sposób Intensywność Średnia Śr. czas Straty usuwania pobierania zajętość pakietów pakietów pakietów kolejki w kolejce Reno Tail drop Reno Tail drop Reno Tail drop Reno Tail drop Reno Front drop Reno Front drop Reno Front drop Reno Front drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Front drop Vegas Front drop Vegas Front drop Vegas Front drop

192 192 Implementacja oraz ocena mechanizmów AQM Zajetosc kolejki Zajetosc kolejki Czas Rys Zajętość kolejki FIFO dla źródła TCP Reno (wykres lewy) i TCP Vegas (wykres prawy); kolejka obciążona Fig FIFO queue occupancy for TCP Reno (left) and TCP Vegas (right) Czas W tabeli 7.12 przedstawiono wyniki analizujące wpływ algorytmu sterowania przeciążeniem na zachowania kolejki FIFO. Wyniki uzyskano dla czterech różnych obciążeń kolejki. W przypadku pierwszych trzech opcji intensywność pobierania pakietów ustawiono tak, aby zobrazować obciążony węzeł komunikacyjny (rysunek 7.39). Strona lewa rysunku przedstawia zajętość kolejki w przypadku algorytmu NewReno. Pobieranie pakietów z kolejki jest tak wolne, że nawet maksymalna minimalizacja okna nic nie poprawia sytuacji (kolejka jest całkowicie zapełniania). W przypadku algorytmu Vegas (strona prawa wykresu) zajętość kolejki zmienia się zgodnie ze zmianami CWND (rysunek 7.37). Porównując średnie zajętości kolejek, można zauważyć przewagę algorytmu Vegas. Przewaga ta wynika z szybszej reakcji algorytmu Vegas na zapełnienie kolejki. Zależność ta zanika w przypadku algorytmu RED (tabela 7.13) oraz NLRED (tabela 7.14). Badania wykazały również, że dla ruchu sterowanego przez mechanizm TCP spada znaczenie modyfikacji w obliczaniu średniej kroczącej. Uzyskane wyniki (patrz tabele 7.15 oraz 7.16) nie różnią się znacząco od rezultatów uzyskanych dla standardowego obliczania średniej kroczącej zajętości kolejki.

193 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji, wpływ algorytmu sterowania przeciążeniem, kolejka RED TCP Sposób Intensyw. Średnia Śr. czas Straty usuwania pobierania zajętość pakietów RED1 RED2 pakietów pakietów kolejki w kolejce Reno Tail drop Reno Tail drop Reno Tail drop Reno Tail drop Reno Front drop Reno Front drop Reno Front drop Reno Front drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Front drop Vegas Front drop Vegas Front drop Vegas Front drop

194 194 Implementacja oraz ocena mechanizmów AQM Tabela Wyniki symulacji, wpływ algorytmu sterowania przeciążeniem, kolejka NLRED TCP Sposób Intensywn. Średnia Śr. czas Straty usuwania pobierania zajętość pakietów RED1 RED2 pakietów pakietów kolejki w kolejce Reno Tail drop Reno Tail drop Reno Tail drop Reno Tail drop Reno Front drop Reno Front drop Reno Front drop Reno Front drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Front drop Vegas Front drop Vegas Front drop Vegas Front drop

195 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji, wpływ algorytmu sterowania przeciążeniem, kolejka RED, ze zmodyfikowanym sposobem obliczania średniej kroczącej zajętości kolejki TCP Sposób Intensywn. Średnia Śr. czas Straty usuwania pobierania zajętość pakietów RED1 RED2 pakietów pakietów kolejki w kolejce Reno Tail drop Reno Tail drop Reno Tail drop Reno Tail drop Reno Front drop Reno Front drop Reno Front drop Reno Front drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Front drop Vegas Front drop Vegas Front drop Vegas Front drop

196 196 Implementacja oraz ocena mechanizmów AQM Tabela Wyniki symulacji, wpływ algorytmu sterowania przeciążeniem, kolejka NLRED, ze zmodyfikowanym sposobem obliczania średniej kroczącej zajątości kolejki TCP Sposób Intensywn. Średnia Śr. czas Straty usuwania pobierania zajętość pakietów RED1 RED2r pakietów pakietów kolejki w kolejce Reno Tail drop Reno Tail drop Reno Tail drop Reno Tail drop Reno Front drop Reno Front drop Reno Front drop Reno Front drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Tail drop Vegas Front drop Vegas Front drop Vegas Front drop Vegas Front drop Sprawiedliwa obsługa wielu strumieni danych w węźle W niniejszym podrozdziale przedstawiono próbę oceny algorytmów AQM i ich wpływu na strumienie o różnych intensywnościach generowania pakietów oraz zależnościach długoterminowych. W pierwszym etapie symulacji zostaną porównane dwa strumienie o takim samym parametrze intensywności źródła λ, lecz o różnym parametrze Hursta.

197 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji, wpływ parametru Hursta na sprawiedliwość obsługi, kolejka FIFO Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania Bufor Tabela Wyniki symulacji, wpływ parametru Hursta na sprawiedliwość obsługi, kolejka FIFO Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania Bufor

198 198 Implementacja oraz ocena mechanizmów AQM Tabele 7.17 i 7.18 pokazują średnie czasy obsługi oraz straty poszczególnych strumieni w kolejce FIFO. Różnice w czasach obsługi oraz stratach pakietów poszczególnych strumieni zależą od samopodobieństwa źródła. Im większe samopodobieństwo obu źródeł, tym większe różnice. Tabele 7.19 oraz 7.20 pokazują, że stosowanie algorytmu RED niweluje te różnice. Zarówno straty, jak i czas oczekiwania dla strumieni o różnym parametrze Hursta są zbliżone. Tabela Wyniki symulacji, wpływ parametru Hursta na sprawiedliwość obsługi, kolejka RED Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania RED1 RED2 Bufor Tabela Wyniki symulacji, wpływ parametru Hursta na sprawiedliwość obsługi, kolejka NLRED Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania RED1 RED2 Bufor

199 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Tabela Wyniki symulacji, wpływ parametru Hursta oraz parametru λ na sprawiedliwość obsługi, kolejka FIFO Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania Bufor Tabela Wyniki symulacji, wpływ parametru Hursta oraz parametru λ na sprawiedliwość obsługi, kolejka FIFO Parametr Nr Intesywn. Śr. czas Straty Hursta strumienia λ przebywania Bufor W ostatnim etapie badań dokonano oceny sytuacji dwóch źródeł o różnym parametrze λ. Tabele 7.21 i 7.22 pokazują, że znaczne różnice intensywności źródeł nie wpływają na uzyskane różnice w czasach obsługi. Również dla tego przypadku największe różnice uzyskano dla dwóch źródeł o parametrze Hursta=0.90.

200 200 Implementacja oraz ocena mechanizmów AQM 7.2. Router AQM w Linuksie W odróżnieniu od poprzednio przedstawianych mechanizmów sieciowych (mechanizmy QoS, wielość implementacji protokołu TCP) implementacja mechanizmów AQM w systemie Linux jest uboga. W jądro Linuksa wbudowano jedynie kilka mechanizmów aktywnego zarządzania kolejką. Porównanie różnych wersji RED wymaga zatem implementacji własnych rozwiązań Mechanizm implementacji AQM Niniejszy rozdział przedstawia mechanizmy wykorzystane w czasie implementacji opisanych powyżej mechanizmów AQM w systemie Linux. Implementacja ta pozwola na wykorzystanie komputera z dwoma kartami sieciowymi jako routera sieciowego oraz ocenę mechanizmów AQM w rzeczywistym działaniu sieci. Routowanie pakietów pomiędzy sieciami możliwe jest dzięki zastosowaniu pakietu iptables. Pakiet ten odpowiedzialny jest za kierowanie ruchem sieciowym na danej maszynie, na której został uruchomiony. Dzięki zastosowaniu odpowiednich reguł możliwe jest przekierowanie ruchu wejściowego na odpowiedni sieciowy interfejs wyjściowy. W programie został wykorzystany łańcuch odpowiedzialny za przekazywanie pakietów. Zasada działania programu jest następująca: odpowiednia reguła iptables wszystkie nadchodzące pakiety umieszcza w kolejce, kolejka przenoszona jest do części użytkownika (ang. User Space), a jej zawartość zostaje odpowiednio obsłużona, po obsłużeniu pakietu, a więc wydaniu odpowiedniego werdyktu (umieszczenie w kolejce lub usunięcie pakietu), kolejka wraca do części jądra. Po deklaracji oraz inicjalizacji zmiennych następuje kalibracja czasu. Aby uzyskać dokładny czas (podawany w milisekundach), obliczana jest liczba cykli maszynowych przypadająca na jednostkę czasu. Aby aplikacja mogła działać poprawnie w systemie, musi być uaktywniony moduł ip_queue. Moduł ten używa tzw. uchwytu netlinka do kopiowania danych z przestrzeni jądra do przestrzeni użytkownika. Jednorazowo program kopiuje całą porcję danych: zawartość pakietu oraz informację na jego temat.

201 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Następnie w nieskończonej pętli odbierane i przekazywane do części użytkownika są przybywające dane oraz sprawdzana jest ich poprawność. Każdy pojawiający się błąd powoduje wypisanie odpowiedniego komunikatu o przyczynie jego powstania oraz zakończenie działania programu. Dla poprawnie odebranych pakietów następuje wybranie odpowiedniego algorytmu i jego wywołanie. Wybór odbywa się na podstawie zmiennej wywołania programu, podawanej jako jedna z wartości listy parametrów wywołania programu. Wszystkie wywołania odpowiednich algorytmów wyglądają podobnie, z wyjątkiem algorytmu ARED, gdzie niezbędne jest utworzenie dodatkowego wątku periodycznie obliczającego niezbędny do wykonywania prawidłowych obliczeń parametru P max. Poniżej opisana zostanie zasada działania funkcji umieszczającej nadchodzące pakiety w kolejce. Pierwsza część algorytmu to sprawdzenie, czy wstawienie nowego pakietu nie spowoduje przepełnienia bufora danych, jeśli taka sytuacja miałaby mieć miejsce, to jest on odrzucany, a zmienna o tym informująca jest inkrementowana. W przeciwnym przypadku pakiet wstawiany jest do kolejki, a jednocześnie zapamiętany zostaje czas jego wstawienia. Inkrementowane zostają parametry informujące o fakcie dodania. Podobnie jak w każdym routerze, również i w tej implementacji wykorzystano bufor przesuwny. Dodanie nowego elementu powoduje przesunięcie wskaźnika na następny element bufora. Wyjątkiem jest przesunięcie dokonywane po przekroczeniu wielkości bufora. Aby nie wystąpił błąd odwołania poza zadeklarowany obszar pamięci bufora, wskaźnik ustawiany jest na początek bufora, czyli na wartość zero. Funkcja wstawiająca przybyłe pakiety do kolejki, na początek sprawdzone zostaje, czy wstawienie nowego pakietu nie spowoduje przepełnienia bufora danych, jeśli taka sytuacja miałaby mieć miejsce, porcja przybyłych danych jest odrzucana, a zmienna o tym informująca jest inkrementowana. W przeciwnym przypadku pakiet wstawiany jest do kolejki i jednocześnie zapamiętany zostaje czas jego wstawienia. Inkrementowane zostają parametry informujące o fakcie dodania. Pewnego rodzaju wyjaśnienia wymaga sposób wyznaczania wskaźnika ostatnio wstawianego elementu. Podobnie jak w każdym routerze, również i w tej implementacji został zastosowany bufor przesuwny, dodanie nowego elementu powoduje przesunięcie wskaźnika na następny element bufora. Wyjątkiem jest przesunięcie dokonywane po przekroczeniu wielkości bufora, aby nie wystąpił błąd odwołania poza zadeklarowany obszar pamięci bufora, wskaźnik ustawiany jest na początek bufora, czyli wartość zero. Funkcja zajmująca się pobieraniem pakietów znajdujących się w kolejce działa jako osobny wątek w programie. Funkcja ta oprócz standardowej obsługi pakietów zajmuje się również zbieraniem danych związanych z długością kolejki

202 202 Implementacja oraz ocena mechanizmów AQM i czasem przebywania pakietu w kolejce. Dane te posłużą potem do oceny mechanizmów, która zostanie przedstawiona w dalszej części rozdziału. Faza inicjalizacji przebiega dokładnie tak, jak we wszystkich innych funkcjach. Po jej zakończeniu rozpoczyna się główna cześć funkcji, czyli nieskończenie działająca pętla na bieżąco sprawdzającą długość kolejki. Pojawienie się pakietu w buforze powoduje przejście do konkretnych działań polegających na: pobraniu paczki danych z kolejki oraz obliczeniu, a następnie zapamiętaniu czasu przebywania pakietu w kolejce. Kolejnym fragmentem funkcji jest obsługa akceptacji pakietów umieszczanych w buforze. Po umieszczeniu pakietu uaktualniane są zmienne przechowujące dane na temat długości kolejki. Następnie, w przypadku algorytmu FRED, należy wykonać odpowiednie czynności wskazane w algorytmie dla sytuacji opuszczenia przez pakiet kolejki. Następuje sprawdzenie wszelkich parametrów działania związanych z przepływami. Dalsze działanie funkcji nie jest uzależnione od wyboru żadnego konkretnego algorytmu RED. Dla pustej kolejki zapamiętany zostaje czas opuszczenia jej przez ostatni pakiet. Następnie zmieniany jest wskaźnik do pakietu ostatnio pobranego z kolejki, sposób jego zmiany przebiega dokładnie tak samo jak dla funkcji wstawiania pakietu. Do uruchomienia opisanego programu wymagany jest system operacyjny Linux oraz program iptables (narzędzie będące filtrem pakietów) i modułu ip_queue (uaktywnianego z programu). Aby komputer mógł pracować jako router, wymaga przed uruchomieniem odpowiedniej konfiguracji. Uaktywnienia przekazywania pakietów przechodzących dokonano za pomocą zmiany w pliku ip_forward: echo 1 > /proc/sys/net/ipv4/ip_forward Następnie należy uaktywnić moduł ip_queue. Dokonać tego można poleceniem: modprobe ip_queue Należy również dokonać najważniejszego ustawienia, którego zadaniem jest przekazywanie wszystkich pakietów pojawiających się na interfejsie sieciowym do kolejki pakietów, z której pobierane będą do dalszej obsługi przez program: iptables A FORWARD -i port_wejściowy o port_wyjściowy j QUEUE Przykładowa konfiguracja zastosowana w routerze wykorzystywanym na stanowisku badawczym to: iptables A FORWARD i eth0 o eth1 j QUEUE Przedstawiona powyżej reguła dotyczy ruchu przekazywanego (łańcuch FOR- WARD), czyli ruchu wchodzącego na interfejsie eth0 i przesyłanego do interfejsu eth1. Cały ten ruch zostaje umieszczony w kolejce dla modułu ip_queue.

203 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Przebieg eksperymentów Schemat stanowiska badawczego został przedstawiony na rysunku W skład stanowiska badawczego wchodzą: komputer A (system operacyjny: Windows) stacja należąca do sieci /8, o adresie IP jest odpowiedzialna za generowanie ruchu. Ruch ten generowany był w dwojaki sposób: za pomocą programu Nsasoft Network Traffic Emulator umożliwiającego tworzenie i nadawanie pakietów TCP oraz UDP w sieci, przez intensywne wykorzystanie przepustowości łącza, komputer B (system operacyjny: Linux) komputer pełni rolę routera w procesie przekazywania pakietów pomiędzy komputerem A oraz serwerem. Posiada dwa interfejsy sieciowe: pierwszy należący do sieci /24 o adresie IP oraz drugi działający w sieci /8 z adresem IP , serwer (System operacyjny: Linux) urządzenie przekazuje pakiety do sieci Internet i stanowiące bramę domyślną dla komputera B. Zawiera dwa interfejsy sieciowe: pierwszy pracujący w sieci lokalnej /24 o adresie IP oraz drugi posiadający publiczny adres IP, łącze 1 łącze FastEthernet o przepustowości 100 Mb/s; funkcję medium transmisyjnego pełni kabel miedziany UTP kategorii 5e skrosowany. Czas RTT (czas przesyłu pakietu oraz potwierdzenia z komputera A do komputera B) wynosi 0,5 ms, łącze 2 łącze FastEthernet o przepustowości 100 Mb/s, medium transmisyjne to kabel miedziany UTP kategorii 5e prosty. Czas RTT (czas przesyłu pakietu oraz potwierdzenia z komputera B do serwera) wynosi 5,6 ms, łącze internetowe o przepustowości wynoszącej minimum 512 kb/s. Przebieg procesu pomiarowego podzielić można na trzy oddzielne segmenty: zachowanie algorytmu dla ruchu pakietów TCP (prędkość transmisji około 5000 pakietów na sekundę),

204 204 Implementacja oraz ocena mechanizmów AQM Rys Sieć wykorzystana w trakcie badań Fig Network used during the research zachowania algorytmu dla ruchu pakietów UDP (prędkość transmisji około 5000 pakietów na sekundę), zachowanie algorytmu dla ruchu mieszanego UDP i TCP w równych proporcjach, gdzie sumaryczna ilość generowanego ruchu była identyczna z poprzednimi dwoma przypadkami. Parametry kolejki wspólne dla algorytmów grupy RED były następujące: wielkość bufora routera buf_size=25 pakietów, próg dolny Min th = 5 pakietów, próg górny Min th = 15 pakietów, waga przy liczeniu średniej zajętości kolejki w = 0.002, prawdopodobieństwo P max = 0.1, γ = 0.96 (dla DSRED), target t = 0.5 (dla ARED). W trakcie badań analizowano wpływ algorytmu AQM (RED, DSRED, ARED, FRED) oraz sposobu wypychania pakietów z kolejki na długości kolejek, a także czas oczekiwania pakietów w kolejce oraz liczbę strat pakietów.

205 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Średnia długość kolejki dla algorytmu RED; TCP Fig Mean queue length for RED algorithm; TCP traffic Rys Średnia długość kolejki dla algorytmu RED; ruch UDP Fig Mean queue length for RED algorithm; UDP traffic

206 206 Implementacja oraz ocena mechanizmów AQM Rys Rozkład długości kolejki RED; ruch TCP Fig Queue length distribution for RED algorithm; TCP traffic Rys Rozkład długości kolejki RED; ruch UDP Fig Queue length distribution for RED algorithm; UDP traffic

207 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Czas oczekiwania pakietów w kolejce routera dla algorytmu RED; ruch TCP Fig Waiting times for RED algorithm; TCP traffic Rys Czas oczekiwania pakietów w kolejce routera dla algorytmu RED; ruch UDP Fig Waiting times for RED algorithm; UDP traffic

208 208 Implementacja oraz ocena mechanizmów AQM Rys Rozkład długości kolejki ARED; ruch TCP Fig Queue length distribution for ARED algorithm; TCP traffic Uzyskane rezultaty Wykresy pokazują wyniki uzyskane w przypadku, gdy regulatorem kolejki jest podstawowy mechanizm RED. Z rysunków 7.41 oraz 7.42 widać, jak zmieniała się średnia długość kolejki w czasie trwania eksperymentu. Rozmiar ten dla ruchu TCP podlega większym fluktuacjom, co wynika z mechanizmu sterowania przeciążeniami wbudowanego w protokół TCP. Na skutek strat TCP zmniejsza się prędkość nadawania pakietów, stąd skokowe zmiany w zajętości bufora. Dla protokołu UDP generator pakietów wykorzystany w eksperymencie generuje pakiety ze stałą prędkością, a zajętość kolejki utrzymuje się na pewnym stałym poziomie, wynikającym z całkowitego zapełnienia bufora (co bardzo dobrze obrazują wykresy 7.43 oraz 7.44 z rozkładami zajętości bufora). Rysunki 7.45 oraz 7.46 pokazują, że czas oczekiwania pakietów w kolejce zależy od zajętości kolejki. Na wykresach tych wyraźnie zaznacza się tendencja skracania czasu oczekiwania w kolejce dla przypadku pobierania pakietów z początku kolejki. Tendencja ta jest widoczna zwłaszcza dla protokołu UDP. Dla TCP różnice te nie są aż tak znaczące. Rysunki 7.47 oraz 7.48 pokazują rozkłady kolejek uzyskane w czasie oceny algorytmu ARED. Zadaniem algorytmu ARED jest utrzymanie zapełnienia bufora w okolicach połowy między progiem górnym a dolnym.

209 Wpływ mechanizmów protokołu TCP oraz algorytmów kolejkowania Rys Rozkład długości kolejki ARED; ruch UDP Fig Queue length distribution for ARED algorithm; TCP traffic Po porównaniu rozkładów dla RED i ARED (rysunki 7.45, 7.47) widać, że są one niezwykle podobne (z niewielką przewagą algorytmu ARED). Rysunki te potwierdzają wcześniej postawioną tezę, że dla ruchu sterowanego mechanizmami ograniczania przeciążenia maleje znaczenie rodzaju mechanizmu AQM. Większe różnice pomiędzy regulaminami kolejkowania widoczne są dla ruchu UDP (7.46, 7.48). O ile algorytm RED (rysunek 7.46) nie radzi sobie z utrzymaniem zapełnienia kolejki na założonym poziomie (pomiędzy Min th a Max th ), o tyle rozkład dla algorytmu ARED (rysunek 7.48) pokazuje, że poziom połowy pomiędzy progami górnym a dolnym jest najbardziej prawdopodobny.