Odmiany protokołu TCP

SAMODZIELNY ZAKŁAD SIECI KOMPUTEROWYCH Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej POLITECHNIKA ŁÓDZKA 90-924 Łódź ul. Stefanowskiego 18/22 tel./fax. (42) 6 360 300 e-mail: szsk@zsk.p.lodz.pl Paweł Czapnik Odmiany protokołu TCP praca dyplomowa magisterska Promotor: dr inŝ. Michał Morawski Dyplomant: Paweł Czapnik nr albumu 110360 Łódź, grudzień 2006 1

Spis treści Spis treści... 2 Wykaz stosowanych skrótów i pojęć... 4 Rozdział 1.... 5 Wstęp... 5 Rozdział 2.... 6 Cel i zakres pracy... 6 2.1. Cel pracy... 6 2.2. Opis rozdziałów... 6 Rozdział 3.... 7 Standardowe odmiany protokołu TCP... 7 3.1. Oryginalna specyfikacja TCP... 7 3.1.1. Funkcjonalność TCP... 7 3.1.2. Nagłówek segmentu TCP... 8 3.1.3. Zestawianie i zamykanie połączeń... 11 3.1.4. Mechanizm retransmisji... 14 3.1.5. Zarządzanie oknem... 15 3.2. TCP Tahoe... 16 3.2.1. Powolny start (ang. Slow start)... 16 3.2.2. Unikanie przeciąŝenia (ang. Congestion Avoidance)... 18 3.2.3. Szybka retransmisja (ang. Fast Retransmit)... 19 3.2.4. Estymacja czasu RTO... 21 3.2.4.1 Obliczanie RTO na podstawie algorytmu Jacobsona... 21 3.2.4.2 Algorytm Karn a... 22 3.3. TCP Reno... 23 3.3.1. Szybkie odtwarzanie w TCP Reno (ang. Fast Recovery)... 23 Rozdział 4.... 26 Nowe standardy i propozycje algorytmów kontroli przeciąŝenia... 26 4.1. NewReno... 26 4.1.1. Algorytm szybkiej retransmisji i szybkiego odtwarzania w NewReno... 26 4.1.2. Problemy w NewReno... 28 4.2. TCP SACK... 32 4.2.1. Algorytm szybkiego odtwarzania w mechanizmie SACK.... 32 4.3. Potwierdzenia generowane w przód (FACK)... 34 4.3.1. Algorytm FACK... 35 4.3.2. Procedura szybkiego odtwarzania w FACK... 36 4.4. TCP Vegas... 38 4.4.1. Mechanizm unikania przeciąŝenia... 38 4.4.2. Zmodyfikowana procedura powolnego startu... 40 4.4.3. Polityka retransmisji... 41 4.4.4. Problemy w TCP Vegas... 41 4.5. TCP Westwood... 42 4.5.1. Zasada działania mechanizmu BE (Bandwidth Estimation)... 42 4.5.2. Algorytm ustawienia wartości cwnd i ssthresh (algorytm szybszej retransmisji)... 43 4.6. Wyraźne powiadamianie o przeciąŝeniach (ECN)... 44 4.7. Rodzina algorytmów binomial... 47 4.7.1. Definicja algorytmów binomial... 47 4.7.2. Kompatybilność z TCP... 48 4.7.3. Algorytmy IIAD i SQRT... 49 2

4.7.4. Protokół kontroli przeciąŝenia w Binomial... 49 Rozdział 5.... 51 Dostosowanie protokołu TCP do róŝnych środowisk sieci... 51 5.1. Sieci HighSpeed... 51 5.1.1. HighSpeed TCP... 51 5.2. Odmiany protokołu TCP w sieciach satelitarnych... 53 5.2.1. Charakterystyka łącz satelitarnych... 53 5.2.2. Standardowe i dodatkowe mechanizmy TCP w sieciach satelitarnych... 55 5.2.2.1 Mechanizmy kontroli przeciąŝenia (ang. Congestion Control)... 55 5.2.2.2 Skalowanie okna (ang. Window scaling)... 55 5.2.2.3 Znacznik czasu (RTTM)... 56 5.2.2.4 Ochrona przed przepełnieniem numeru sekwencyjnego (PAWS)... 57 5.2.2.5 Opóźnianie potwierdzeń (DACK)... 57 5.2.2.6 Właściwe liczenie bajtów (ABC ang. Appropriate Byte Counting)... 58 5.3. Mobilność w sieciach bezprzewodowych... 60 5.3.1. Komunikacyjne sieci komórkowe (ang. Cellular Comunications)... 60 5.3.2. Charakterystyka łącz w sieciach komórkowych 2.5G i 3G... 61 5.3.3. Usprawnienie protokołu TCP w mobilnych sieciach komórkowych... 62 5.3.4. Bezprzewodowy TCP (ang. Wireless Transmission Control Protocol)... 64 5.4. Mobilne sieci ad-hoc... 66 5.4.1. SprzęŜenie zwrotne TCP (TCP-Feedback)... 67 Rozdział 6.... 68 Symulacje protokołu TCP... 68 6.1. Cel podjęcia tematu... 68 6.2. Symulacje protokołu TCP w standardowych sieciach... 68 6.2.1. Sposób działania mechanizmów kontroli przeciąŝenia... 70 6.2.2. Wpływ czasu transmisji RTT na wydajność TCP... 76 6.2.2.1 Wydajność w zaleŝności od opóźnienia propagacji... 76 6.2.2.2 Wydajność TCP w zaleŝności od opóźnienia w kolejkach... 79 6.2.3. Wpływ pojemności bufora odbiorczego na szybkość transmisji... 83 6.2.4. Wydajność w przypadku ruchu impulsowego... 85 6.2.5. Zastosowanie aktywnego zarządzania kolejkowaniem... 89 6.3. Bezstronność odmian TCP(ang. Fairness)... 91 6.3.1. Interakcje poszczególnych odmian TCP z protokołem TCP Reno... 92 6.3.2. Wspólne wystąpienie badanych odmian TCP... 96 6.3.3. Bezstronność w przypadku określonej ilości transmisji tej samej odmiany TCP... 98 6.4. Symulacje wybranych odmian TCP w sieci highspeed... 101 Podsumowanie... 108 Bibliografia... 110 Załączniki... 113 3

Wykaz stosowanych skrótów i pojęć BDP (ang. Bandwidth-Delay Product) iloczyn szerokości pasma i opóźnienia BER (ang. bit-error rate) określa stopień utraty bitów CWND (ang. Congestion Window) wartość okna przeciąŝeniowego DUPACKs powielone segmenty z ustawioną flagą ACK potwierdzenie ACK segment z ustawioną flagą ACK wysyłany przez odbiorcę danych MSS maksymalny rozmiar segmentu nadawca komputer wysyłający dane do odbiorcy odbiorca komputer odbierający dane od nadawcy RED (ang. Random Early Detection) mechanizm aktywnego zarządzania kolejkami polegający na wczesnym losowym odrzucaniu pakietów z kolejki RTO (ang. Retransmission Timeout) maksymalny czas oczekiwania na potwierdzenie danych RTT (ang. Round Trip Time) czas pętli zwrotnej, inaczej czas podróŝy pakietów w obie strony RWND (ang. Recive Window) wartość okna ogłoszeniowego (ogłaszane przez odbiorcę) SACK (ang. Selective Acknowledgement) opcja selektywnego potwierdzenia ssthresh (ang. slow start threshold) wartość progowa powolnego startu TCP (ang. Transport Control Protocol) protokół kontroli transmisji 4

Rozdział 1. Wstęp Protokół TCP (ang. Transport Control Protocol) jest niezwykle popularnym protokołem transportowym wykorzystywanym w 90-ciu procentach sieci komunikacyjnych opartych na technologii IP (Internet Protocol) [38]. Ze względu na zawodność protokołu IP, aby aplikacje i usługi internetowe mogły z niego korzystać, potrzebne są inne protokoły zapewniające jakość transmisji danych w sieciach komputerowych nazywane protokołami warstwy transportowej. Takim protokołem jest właśnie wspomniany protokół kontroli transmisji TCP (ang. Transport Control Protocol). Zaprojektowany został w celu zapewnienia niezawodnej warstwy transportowej dla wielu popularnych usług sieci opartych o stos protokołów TCP/IP. Jest strumieniowym protokołem komunikacji zapewniającym wiarygodne połączenie pomiędzy dwoma komputerami. Dzięki stosowaniu sum kontrolnych i numerów sekwencyjnych zapewnia kompletną i uporządkowaną wymianę danych dla aplikacji warstw wyŝszych. Obecnie jest wykorzystywany przez większość popularnych aplikacji internetowych takich jak: poczta elektroniczna, przesyłanie zasobów WWW, przesyłanie plików czy teŝ usługę zdalnego logowania. Jego pierwsza specyfikacja [39] zaimplementowana w 1983 roku w dystrybucji Berkeley UNIX 4.2 BSD, mimo iŝ była jednym z powodów szerokiego przyjęcia protokołu TCP, nie okazała się zbyt udaną, co doprowadziło w 1986 roku do historycznej blokady sieci spowodowanej przeciąŝeniem [26]. Przypadek ten okazał się motorem napędowym do powstania nowych algorytmów kontroli przeciąŝenia, które obecnie są standardem tego protokołu i kolejnych odmian przyczyniających się do wzrostu osiągów, jak i dostosowania go do róŝnych sieci. Jednym z najbardziej interesujących zagadnień związanych z protokołem TCP jest kontrola przeciąŝenia i przepływu. KaŜdego roku pojawiają się nowe opracowania analizujące i proponujące nowe mechanizmy i algorytmy kontroli przeciąŝenia w celu poprawienia wydajności, jak równieŝ adaptacji TCP do róŝnych środowisk sieciowych. Wraz z rosnącymi wymaganiami uŝytkowników zaleŝnych od sieci TCP/IP i obserwowanym trendem bezprzewodowego dostępu do Internetu terminali przenośnych, konieczne jest projektowanie i analizowanie kolejnych wersji protokołu TCP odpowiednich dla nowych środowisk komunikacyjnych. 5

Rozdział 2. Cel i zakres pracy 2.1. Cel pracy Celem niniejszej pracy jest przedstawienie roli i zasady działania, jak równieŝ porównanie efektywności poszczególnych odmian protokołu TCP powstałych w odpowiedzi na ciągły wzrost wymagań uŝytkowników, o czym mowa była we wstępie. Ze względu na popularność tego protokołu w sieci Internet i niewielką ilość artykułów w języku polskim warto przedstawić ten temat. Celem części praktycznej jest przeprowadzenie badań symulacyjnych w celu porównania wydajności i bezstronności poszczególnych odmian protokołu TCP w róŝnych konfiguracjach sieci. 2.2. Opis rozdziałów Rozdział 3 przedstawia główne pojęcia związane z działaniem protokołu TCP pozwalające zrozumieć dynamikę jego wydajności i podstawowe mechanizmy kontroli transmisji zawarte w oryginalnej specyfikacji. Zawiera równieŝ kolejne wersje mechanizmów kontroli przeciąŝenia implementowane w protokole TCP, włącznie ze standardem wykorzystywanym w obecnych sieciach. Rozdział 4 opisuje nowe odmiany bądź modyfikacje mechanizmów kontroli przeciąŝeń zaproponowane przez twórców i badaczy protokołu TCP. Rozdział 5 przedstawia adaptację protokołu TCP do róŝnych odmian sieci w celu poprawienia ich wydajności. Rozdział 6 zawiera opis i wyniki przeprowadzonych symulacji poszczególnych odmian protokołu TCP, jak równieŝ porównanie ich efektywności na podstawie tych badań. 6

Rozdział 3. Standardowe odmiany protokołu TCP 3.1. Oryginalna specyfikacja TCP Pierwsze wzmianki na temat TCP pochodzą z początku lat 70-tych, gdy niektóre pojęcia (router, warstwy sieciowe) związane z sieciami komputerowymi nie były jeszcze znane bądź oczywiste. Autorami pierwszej oficjalnej specyfikacji TCP byli Vinton Cerf, Yogen Dala i Carl Sunshine [13]. Dopiero w roku 1980 Jon Postel napisał dla Departamentu Obrony Stanów Zjednoczonych (DoD Departament of Defense) kolejną specyfikacje [37], która stała się standardem dla sieci ARPA (Advanced Research Project Agency). Mimo iŝ w latach tych istniało wiele innych odmian protokołów sieciowych, to protokół TCP był juŝ szeroko stosowany ze względu na prostotę i powszechną dostępność specyfikacji oraz kodu źródłowego. Dokument [39] zawiera specyfikacje protokołu TCP bazującą na dziewięciu wcześniejszych edycjach tego protokołu, która w 1983 roku została zaimplementowana w dystrybucji Berkeley UNIX 4.2 BSD. 3.1.1. Funkcjonalność TCP Głównym celem protokołu TCP jest zapewnienie niezawodnego i bezpiecznego połączenia pomiędzy dwoma procesami. W tym celu zdefiniowane są następujące usługi: Transmisja danych (ang. Basic Data Transfer) moŝliwość transmitowania danych w sposób strumieniowy w trybie pełnodupleksowym. Polega na zestawieniu połączenia pomiędzy dwoma procesami, w którym dane są wysyłane i odbierane w postaci strumienia bajtów (oktetów). Tak naprawdę abstrakcja strumienia jest widoczna dla aplikacji, bo sam protokół TCP gromadzi odpowiednią liczbę (nie więcej niŝ wartość MSS) oktetów danych w segmenty i transmituje przez sieć IP do odbiorcy. Następnie aplikacja w sposób strumieniowy pobiera z odpowiedniego bufora wydobyte z segmentów i uporządkowane bajty danych. Niezawodne przesyłanie (ang. Reliability) kaŝdy pojedynczy bajt musi zostać dostarczony do odbiorcy przez sieć nieuszkodzony, bez powielenia i w odpowiedniej kolejności. Zrealizowane to jest za pomocą numerów sekwencyjnych przypisywanych kaŝdemu segmentowi wysyłanych danych 7

i Ŝądania potwierdzenia poprawnego odebrania danych przez odbiorcę. Jeśli potwierdzenie wysłanych danych nie przyjdzie po określonym wcześniej czasie, to nadawca transmituje je ponownie. Numery sekwencyjne są wykorzystywane do wyeliminowania powtórzeń i złoŝenia segmentów w uporządkowaną całość. Kontrola przepływu (ang. Flow Control) odbiorca danych posiada przywilej do sterowania ilością wysyłanych przez nadawcę danych. Za pomocą pola Rozmiar okna odbiorcy w nagłówku TCP (Rys. 3.1), odbiorca wysyła w kaŝdym potwierdzeniu (ACK) pozwolenie na wysłanie określonej liczby bajtów, która jest odzwierciedleniem wolnego miejsca w buforze odbiorcy. Funkcjonalność ta nie zabezpiecza jednak przed przepełnieniem się buforów urządzeń pośredniczących np. routerów. Połączenia (ang. Connections) zanim dwie aplikacje zaczną przesyłać dane, konieczna jest wymiana informacji potrzebnych do powyŝszych mechanizmów zwana połączeniem. Wiele połączeń (ang. Multiplexing) umoŝliwia zestawienie równocześnie kilku połączeń TCP z jednego komputera. KaŜdy proces aplikacji identyfikuje połączenie na podstawie unikalnych numerów portu komputera. Unikalnym identyfikatorem połączenia TCP są dwie pary wartości (jedna dla kaŝdej ze stron połączenia) określające adres i numer portu komputera. Pierwszeństwo i bezpieczeństwo (ang. Precedence and Security) umoŝliwia oznaczenie przez uŝytkownika waŝnych danych, które powinny być dostarczone w pierwszej kolejności. 3.1.2. Nagłówek segmentu TCP Budowę segmentu TCP przedstawia Rys. 3.1 (nagłówek TCP został rozszerzony, co zostało opisane w podrozdziale 4.6). Składa się on z nagłówka zasadniczego o długości 20 bajtów i danych o róŝnej długości. Podstawowy nagłówek moŝe być rozszerzony o pole opcji. 8

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Port źródłowy U Przesunięcie Zarezerwowane R danych G Suma kontrolna A C K Numer sekwencyjny Numer potwierdzenia P S H R S T S Y N F I N Port docelowy Rozmiar okna odbiorcy Wskaźnik waŝności Opcje (róŝna długość) Dopełnienie Dane (róŝna długość) Rys. 3.1. Budowa nagłówka TCP Opis pól nagłówka: Port źródłowy (ang. Source Port) (16 bitów). Określa numer portu źródłowego. Port docelowy (ang. Destination Port) (16 bitów). Określa numer portu docelowego. Numer sekwencyjny (ang. Sequence Number) (32 bity). Określa numer sekwencyjny pierwszego bajta danych zawartych w tym segmencie. Wyjątek stanowi segment z flagą SYN, dla którego wartość tego pola jest ISN+1, gdzie ISN (ang. Initial Sequence Number) jest początkową wartością numeru sekwencyjnego generowaną podczas zestawiania połączenia. Generator ISN zapewnia unikalną wartość dla wszystkich instancji połączenia. Numer potwierdzenia (ang. Acknowledgment Number) (32 bity). Pole to słuŝy do potwierdzania odebranych danych przez odbiorcę. Jeśli wartość flagi ACK jest ustawiona, to wartość tego pola zawiera numer sekwencyjny bajtu, którego spodziewa się odbiorca. Przesunięcie danych (ang. Data Offset) (4 bity). Określa liczbę 32-bitowych słów zajmowanych przez nagłówek segmentu danych. W przypadku standardowego nagłówka bez opcji wartość tego pola wynosi 5. Zarezerwowane (ang. Reserved) (6 bitów). Zarezerwowane na przyszłe potrzeby. Flagi (ang. Flags) (6 bitów): URG Wskaźnik waŝności zawiera dane. 9

ACK Pole z numerem potwierdzenia zawiera dane. PSH Oznacza operację wypchnięcia danych. RST Przerwanie połączenia. SYN Rozpoczęcie nowego połączenia. FIN Ostatni segment od nadawcy. Rozmiar okna odbiorcy (ang. Window) (16 bitów). Wykorzystywane przez nadawcę do kontroli przepływu. Określa liczbę bajtów, jaką nadawca moŝe zaakceptować (wolne miejsce w buforze). Suma kontrolna (ang. Checksum) (16 bitów). Zabezpiecza segment przed uszkodzeniem. Suma kontrolna liczona jest na podstawie nagłówka, danych w segmencie i 96-bitowego pseudonagłówka składającego się z adresu źródłowego i docelowego oraz długości segmentu TCP (nagłówek + dane aplikacji) [39]. Wskaźnik waŝności (ang. Urgent Pointer) (16 bitów). Pole to jest interpretowane tylko w przypadku ustawienia flagi URG. Zawiera numer sekwencyjny bajtu występującego po waŝnych danych, które są przetwarzane w pierwszej kolejności przez aplikację. Opcje (ang. Options) (zmienna długość). Występują po nagłówku standardowym i zajmują wielokrotność 8-bitowych oktetów. Mogą występować jako pojedynczy oktet określający rodzaj opcji lub dwa oktety określające rodzaj i rozmiar pola danych opcji (łącznie z tymi dwoma bajtami). Całkowity rozmiar listy opcji nie moŝe przekraczać moŝliwości pola określającego długość nagłówka (64 bajty). Rodzaje opcji, jakie musi implementować protokół TCP przedstawia Rys. 3.2. Rodzaj (w bitach) Długość (w oktetach) Zawartość 00000000 - Koniec listy 00000001 - Brak operacji 00000010 4 MSS Rys. 3.2. Podstawowe opcje nagłówka standardu TCP [39] Opcja MSS: Maksymalny rozmiar segmentu (MSS - ang. Maximum Segment Size) (16 bitów) określa maksymalny rozmiar przesyłanych danych zawartych w jednym segmencie (ilość bajtów danych bez nagłówka). Opcja MSS ustawiana jest podczas 10

zestawiania połączenia przez stronę rozpoczynającą połączenie (tylko w segmencie SYN) w celu wynegocjowania maksymalnej ilości danych, która będzie mogła być wysłana w jednym segmencie. Dopełnienie (ang. Paddding) (zmienna długość). Wykorzystywane w celu dopełnienia długości nagłówka do wielokrotności 32-bitowych słów. Pole to jest wypełniane zerami. 3.1.3. Zestawianie i zamykanie połączeń Ze względu na to, Ŝe funkcjonalność TCP opiera się na połączeniach, protokół ten musi implementować dwie procedury zestawiającą i zamykającą połączenie pomiędzy dwoma punktami końcowymi. Procedura trójstronnego uzgodnienia (ang. three-way handshake) słuŝy do zestawiania połączenia. W normalnym przypadku jak na Rys. 3.3, procedura ta jest inicjalizowana przez jednego z uŝytkowników TCP. Mogą równieŝ wystąpić przypadki równoczesnego zainicjowania tej procedury przez dwa komputery chcące nawiązać połączenie w tym samym czasie (Rys. 3.4). Sekwencja zdarzeń dla trójstronnego uzgodnienia inicjowanego przez komputer A na przykładzie Rys. 3.3: 1. Nadawca A wysyła segment z ustawionym znacznikiem SYN z przykładowym startowym numerem sekwencyjnym SeqNo = 100 (jest to unikalna wartość 32-bitowa wygenerowana dla tego połączenia po stronie nadawcy). 2. Odbiorca B wysyła segment z ustawionymi znacznikami SYN i ACK oraz przykładowym numerem sekwencyjnym SeqNo =200 (jest to unikalna wartość 32-bitowa wygenerowana dla tego połączenia po stronie odbiorcy) oznacza, Ŝe odbiorca będzie uŝywał numerów sekwencyjnych zaczynając od 200. Numer potwierdzenia AckNo =101 oznacza, Ŝe odbiorca otrzymał poprawne dane do numeru sekwencyjnego 100 i oczekuje na dane z numerem 101. Startowe numery sekwencyjne TCP A i TCP B nie są w Ŝaden sposób związane. 3. Nadawca A wysyła pusty segment z ustawionym znacznikiem ACK i numerem sekwencyjnym AckNo = 201 potwierdzając w ten sposób odebranie danych od TCP B z numerem sekwencyjnym równym 200. W tym momencie połączenie jest poprawnie zestawione i komputery A i B mogą wymieniać między sobą dane. 11

TCP A TCP B SYN, SeqNo=100 SYN, ACK, SeqNo = 200 AckNo = 101 ACK, AckNo = 201 Rys. 3.3. Przykład trójstronnego zestawienia połączenia Równoczesne zainicjowanie procedury zestawienia połączenia przez obydwa końce TCP przedstawia Rys. 3.4. TCP A TCP B TCP A TCP B SYN, SeqNo=100 SYN, SeqNo=300 SYN, ACK, SeqNo = 300 AckNo = 101 SYN, ACK, SeqNo = 100 AckNo = 301 SYN, ACK, SeqNo = 101 AckNo = 301 Rys. 3.4. Równoczesne inicjalizowanie połączenia przez A i B Innym moŝliwym przypadkiem jest wystąpienie powielonych segmentów SYN. Reakcją na tego typu segmenty jest wysłanie segmentu z ustawionym bitem flagi RST oznaczającym przerwanie połączenia. Odbiorca po otrzymaniu segmentu RST przechodzi do stanu nasłuchiwania (ang. Listen), jeśli wcześniej nie był w stanie połączenia (ang. non-synchronized state), w przeciwnym wypadku połączenie zostaje przerwane. 12

Półotwarte połączenia (ang. Half-Open Connections) występują w przypadku, gdy jedna ze stron połączenia TCP zostanie przerwana lub zakończona bez powiadomienia drugiej strony. Po wykryciu takiej sytuacji połączenie jest przerywane. Procedura zamknięcia połączenia jest wywoływana w momencie, gdy nie ma więcej danych do wysłania. MoŜliwe są trzy przypadki wywołania tej procedury: 1. Wywołanie przez lokalnego uŝytkownika 2. Zainicjalizowanie przez zdalnego uŝytkownika za pomocą flagi FIN. 3. Wywołanie równocześnie przez obie strony połączenia. Proces zamknięcia połączenia przebiega w czterech etapach (Rys. 3.5): 1. UŜytkownik TCP A wysyła segment z flagą FIN oznaczający chęć zakończenia połączenia. Przechodzi do stanu FIN-WAIT-1, w którym moŝe jedynie odbierać dane. 2. UŜytkownik TCP B wysyła potwierdzenie odebrania FIN, ale nie musi od razu wysyłać segmentu FIN, gdyŝ moŝe nie być gotowy na zakończenie transmisji danych. Po wysłaniu samego potwierdzenia ACK moŝe nadal wysyłać dane. 3. Gdy uŝytkownik B jest gotowy do zamknięcia połączenia wysyła segment FIN i przechodzi do stanu LAST-ACK. 4. UŜytkownik A potwierdza odebranie segmentu FIN i w ten sposób połączenie jest zakończone po obu stronach. TCP A TCP B FIN, ACK SeqNo = 100 AckNo = 300 ACK, SeqNo = 300 AckNo = 101 FIN, ACK SeqNo = 300 AckNo = 101 ACK, SeqNo = 101 AckNo = 301 Rys. 3.5. Zakończenie połączenia TCP 13

3.1.4. Mechanizm retransmisji Mechanizm retransmisji zapewnia niezawodność przesyłania danych. PoniewaŜ segmenty mogą zostać zgubione, konieczna jest ich retransmisja. Jeśli potwierdzenie danego segmentu nie przyjdzie po limicie czasu retransmisji RTO (ang. Retransmission Timeout) dla tego segmentu, to nadawca musi ponownie wysłać dane. Zegar retransmisji (ang. retransmission timer) jest implementowany dla kaŝdego połączenia i jest ostatecznym mechanizmem do wykrywania strat w transmisji segmentów. Jeśli osiągnie wartość zero to segment jest wysyłany ponownie. Uruchamiany jest z nową wartością RTO gdy: 1. Segment jest wysyłany a zegar nie jest uruchomiony. 2. Przychodzi potwierdzenie umoŝliwiające wysłanie nowych danych. 3. Segment jest transmitowany ponownie. Zatrzymanie zegara jest tylko w momencie otrzymania potwierdzenia dla wszystkich wysłanych segmentów. Ustawienie odpowiedniej wartości RTO jest kluczowe dla dobrej wydajności protokołu TCP. Problem pojawia się w sieciach o zmiennym opóźnieniu. Ustawienie zbyt małej wartości moŝe przyczynić się do niepotrzebnych retransmisji, zaś duŝe wartości czasu RTO przyczyniają się do zwiększenia opóźnień. Specyfikacja [39] z powodu duŝej zmienności opóźnień w sieci zaleca dynamiczne ustalanie wartości RTO. Czas pętli zwrotnej RTT (ang. Round Trip Time) jest to czas, jaki upłynął od momentu wysłania segmentu do otrzymania potwierdzenia obejmującego ten segment. Nie musi to być potwierdzenie dotyczące numeru tego segmentu, moŝe to być potwierdzenie otrzymania segmentu o numerze wyŝszym obejmujące równieŝ niepotwierdzone do tej pory segmenty o niŝszych numerach. Po obliczeniu próbki czasu RTT strona nadająca utrzymuje dla kaŝdego połączenia TCP oszacowaną wartość RTT (SRTT ang. Smoothed Round Trip Time) obliczoną przy wykorzystaniu filtru dolnoprzepustowego (3.1): SRTTt + 1 = α SRTTt + (1 α) RTT (3.1) gdzie: α jest stałym współczynnikiem wygładzenia zalecanym 0.8 [39], co oznacza, Ŝe większą wagę ma oszacowana wartość SRTT z poprzedniego okresu niŝ ostatnio 14

zmierzona wartość RTT. Taka wartość α zabezpiecza przed gwałtownymi odchyleniami szacowanej wartości SRTT. Wartość RTO jest obliczana ze wzoru: [ UBound, max[ LBound, ( SRTT ) ] RTO = min β (3.2) gdzie: UBound górna granica RTO (zalecana 1 min), LBound dolna granica RTO (zalecana 1 s), β - współczynnik odchylenia opóźnienia (zalecany 2). 3.1.5. Zarządzanie oknem Kontrola przepływu (ang. flow control) zabezpieczająca odbiorcę przed zbyt duŝą ilością danych otrzymywanych od nadawcy, opiera się na rozmiarze okna odbiorcy wysyłanym w kaŝdym segmencie potwierdzającym odebranie danych. Rozmiar ten oznacza zakres numerów sekwencyjnych, jaki moŝe przyjąć bufor zadeklarowany przez odbiorcę na początku połączenia. Po kaŝdym odebraniu danych odbiorca dynamicznie aktualizuje rozmiar okna w zaleŝności od wolnego miejsca w buforze danych. Procedura zarządzania oknem ma duŝy wpływ na wydajność połączenia. Ogłoszenie małego rozmiaru okna ogranicza transmisje danych do wysyłania duŝej ilości segmentów o małym rozmiarze, włączając w to opóźnienia związane z czasem RTT. [39] wprowadza kilka moŝliwości implementacyjnych w tej procedurze: 1. Opóźnianie modyfikacji rozmiaru okna przez odbiorcę do momentu, gdy wolne miejsce w buforze nie przekroczy pewnego progu (moŝe to być od 20 do 40 procent całego zadeklarowanego miejsca). 2. Czekanie przez nadawcę na dostatecznie duŝy rozmiar okna. Wyjątkiem jest tylko sygnalizowanie wypchnięcia danych (ustawiony znacznik push), gdzie dane muszą zostać wysłane nawet, jeśli ich rozmiar jest niewielki. 3. Ze względu na to, Ŝe potwierdzenia ACK nie powinny być opóźniane i powielane, odbiorca moŝe wysłać potwierdzenie odebrania segmentu, ale bez odświeŝania wartości rozmiaru okna, a następnie wysłać inne potwierdzenie, gdy zwolni się większa ilość wolnego miejsca w buforze. 15

4. Próba łączenia małych przydziałów okna w większe od momentu, gdy mechanizm zarządzania prowadzi do duŝej ilości małych przydziałów. 3.2. TCP Tahoe Starsze odmiany działały tak, Ŝe rozpoczynały połączenie wysyłając pakiety do sieci na tyle, na ile pozwalał im na to rozmiar okna zadeklarowany przez odbiorcę. Wszystko było dobrze, jeśli komunikujące się urządzenia znajdowały się w jednej sieci bez znacznych opóźnień bądź urządzeń pośredniczących, które w wyniku kolejkowania mogą gubić pakiety. Powodem takiego pogorszenia wydajności sieci jest brak mechanizmów kontroli punktów pośrednich, niebiorących udziału w wymianie informacji transportowych [26]. Odpowiedzią było zaimplementowanie w 1988 roku w wersji UNIX 4.3 BSD podstawowych mechanizmów kontroli przeciąŝenia (ang. Congestion Control), zwanych jako TCP Tahoe [43]. Początkowa wersja tych mechanizmów, określana mianem Old Tahoe, zawierała tylko dwa mechanizmy: powolnego startu i unikania przeciąŝeń. 3.2.1. Powolny start (ang. Slow start) Wprowadza on nowe okno dla nadawcy, zwane oknem przeciąŝeniowym (CWND ang. Congestion Window). Podczas zestawiania nowego połączenia z komputerem znajdującym się w innej sieci, wartość okna cwnd jest ustawiana na 1 segment, którego rozmiar jest zadeklarowany przez drugą stronę połączenia bądź domyślnie jest ustawiany na 536 lub 512 bajtów. Następnie w trakcie wysyłania danych rozmiar okna jest zwiększany o jeden segment po kaŝdym otrzymanym potwierdzeniu ACK. Nadawca moŝe transmitować pakiety bez oczekiwania na ich potwierdzenie pod warunkiem, Ŝe liczba niepotwierdzonych segmentów nie przekracza wartości okna przeciąŝeniowego cwnd i wartości okna ogłoszeniowego rwnd. Pierwsza z nich bazuje na ocenie stanu sieci przez nadawcę, druga zaś jest związana z dostępnym buforem odbiorcy. Mechanizm ten działa tak, Ŝe nadawca zaczyna od wysłania jednego segmentu i czeka na jego potwierdzenie. Kiedy otrzyma potwierdzenie odebrania wysłanego wcześniej segmentu, zwiększa wartość cwnd o jeden i następnie moŝe wysłać jednocześnie dwa segmenty bez konieczności oczekiwania na potwierdzenie. Jak widać na Rys. 3.6, prowadzi to do wykładniczego wzrostu rozmiaru okna względem czasu RTT i algorytm ten nie jest wcale powolny. NaleŜy równieŝ zauwaŝyć, Ŝe wartość cwnd moŝe ulec podwojeniu po 16

czasie RTT, ale nie musi, co jest wynikiem potwierdzania dwóch poprawnych segmentów za pomocą jednego potwierdzenia ACK (Rys. 3.7). Nadawca Odbiorca cwnd = 1 1 segment cwnd = 2 2 segmeny cwnd = 4 4 segmenty cwnd = 8 Rys. 3.6. Procedura powolnego startu w przypadku potwierdzania wszystkich pakietów Nadawca Odbiorca cwnd = 1 1 segment cwnd = 2 2 segmeny cwnd = 3 3 segmenty cwnd = 5 Rys. 3.7. Procedura powolnego startu w przypadku wysyłania potwierdzenia co drugi segment 17

3.2.2. Unikanie przeciąŝenia (ang. Congestion Avoidance) Mechanizm ten jest implementowany łącznie z powolnym startem w celu zatrzymania wykładniczego wzrostu okna i badania przepustowości sieci od pewnego momentu w sposób liniowy. Algorytm ten zakłada, Ŝe prawdopodobieństwo zgubienia pakietu z powodu jego uszkodzenia jest mniejsze niŝ 1%, co znaczy, Ŝe większość zagubionych pakietów sygnalizuje przeciąŝenie w sieci. Następstwem zaginięcia pakietu moŝe być: 1. Wyczerpanie się czasu oczekiwania na potwierdzenie RTO. 2. Powielające się odpowiedzi ACK Ŝądające zagubionego segmentu. Implementacja tego mechanizmu wymaga dodania zmiennej ssthresh przechowującej próg dla powolnego startu (ang. slow start threshold). Do zwolnienia transmisji danych przez nadawcę algorytm ten jest w fazie powolnego startu do momentu osiągnięcia odpowiedniej wartości okna cwnd. Zasada działania algorytmu: 1. Zainicjowanie wartości cwnd na 1 segment i wartości ssthresh na 65535 bajtów. 2. Nadawca nie wysyła nigdy więcej segmentów bez potwierdzenia niŝ wartość okna przeciąŝeniowego cwnd i okna ogłoszeniowego rwnd. 3. Jeśli wystąpi zator w sieci zasygnalizowany przez wyczerpanie się czasu RTO lub powielające się potwierdzenia ACK, to do zmiennej ssthresh zapisana jest połowa wartości aktualnego rozmiaru okna cwnd wyraŝona w bajtach (ale nie mniej niŝ 2 segmenty), a wartość cwnd jest 1 i wykonuje się algorytm powolnego startu. 4. Jeśli wartość rozmiaru okna przekroczy próg ssthresh, wykonuje się algorytm unikania przeciąŝenia, w którym cwnd zwiększane jest o 1/cwnd po kaŝdym otrzymanym potwierdzeniu ACK. Wzrost okna w czasie RTT moŝe być w tym przypadku, co najwyŝej o jeden segment, czyli ma charakter z grubsza liniowy względem czasu RTT (Rys. 3.8). 18

16 15 14 13 12 Unikanie przeciąŝenia 11 Wartość okna przeciąŝeniowego [segmenty] 10 9 8 7 6 5 Powolny start Próg powolnego startu (ssthresh) 4 3 2 1 0 0 1 2 3 4 5 6 7 8 9 10 Czas [RTT] Rys. 3.8. Procedura unikania przeciąŝenia 3.2.3. Szybka retransmisja (ang. Fast Retransmit) Podobnie jak poprzedni mechanizm unikania przeciąŝenia, algorytm szybkiej retransmisji wykorzystujący powielane potwierdzenia (Rys. 3.9) jako sygnał do retransmisji nie był zaimplementowany w starszej wersji zwanej Old Tahoe. Działa w ten sposób, Ŝe zakłada moŝliwość wystąpienia, co najwyŝej dwóch zduplikowanych ACK, co moŝe być przyczyną zmiany kolejności dostarczenia segmentów. Jeśli natomiast występują 3 zduplikowane potwierdzenia ACK po kolei lub więcej, to jest to silny sygnał, Ŝe pakiet zaginął i ponownie transmituje zgubiony segment bez czekania na upłynięcie czasu RTO. W dodatku TCP podczas retransmisji zgubionego pakietu przechodzi do fazy powolnego 19

startu (cwnd = 1), zmieniając wartość progową ssthresh na połowę wartości okna przeciąŝeniowego cwnd z chwili wystąpienia retransmisji. Algorytm ten pod Ŝadnym względem nie wypiera mechanizmu zegara retransmisji, który aktywny jest dla małych rozmiarów okna przeciąŝeniowego, gdy niewystarczająca liczba segmentów nie moŝe spowodować szybkiej retransmisji. Taką sytuację przedstawia przykładowy Rys. 3.10. Nadawca Odbiorca cwnd = 2 SeqNo=4 SeqNo=5 AckNo=5 AckNo=6 cwnd = 4 cwnd = 1 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 3 powielone potwierdzenia Rys. 3.9. Procedura szybkiej retransmisji po odebraniu zduplikowanych odpowiedzi 20

cwnd = 3 Nadawca AckNo=6 SeqNo=6 SeqNo=7 SeqNo=8 Odbiorca RTO DAckNo=6 DAckNo=6 2 powielone potwierdzenia cwnd = 1 SeqNo=6 Rys. 3.10. Retransmisja spowodowana upłynięciem czasu RTO 3.2.4. Estymacja czasu RTO 3.2.4.1 Obliczanie RTO na podstawie algorytmu Jacobsona Algorytm Jacobsona [36], wykorzystywany przez tę wersję protokołu TCP do szacowania czasu retransmisji RTO, róŝni się od pierwszej specyfikacji tym, Ŝe większą wagę ma wartość odchylenia czasu RTT od wcześniejszej przechowywanej niŝ sama wartość średnia czasu RTT. W oryginale RTO obliczane było na podstawie tylko szacowanej wartości SRTT przechowywanej dla połączenia i aktualnie zmierzonej. Do implementacji tego algorytmu przechowywane są dwie zmienne na podstawie, których liczona jest wartość czasu RTO: SRTT wygładzona średnia wartość RTT i RTTVar średnie odchylenie od wartości RTT. 21

Sam algorytm przebiega następująco: 1. Początkowo, gdy nie ma jeszcze szacowanej wartości RTT: RTO = 3s (3.3) 2. Po pierwszym obliczeniu RTT: SRTT = RTT (3.4) RTTVar = RTT / 2 (3.5) 3. Po kolejnym obliczeniu RTT: SRTT ( α ) SRTT + αrtt = 1 (3.6) ( β ) RTTVar + SRTT RTT RTTVar = 1 β (3.7) gdzie: α = 1/8, β = 1/4 są współczynnikami estymacji. 4. Wartość RTO jest obliczana na podstawie powyŝszych obliczeń: RTO = SRTT + 4RTTVar (3.8) 3.2.4.2 Algorytm Karn a Do wyznaczania próbki RTT wykorzystywany jest algorytm Karn a [29] opisujący problem niejednoznaczności transmisji (Rys. 3.11). Określa sposób wyznaczenia czasu RTT w przypadku, gdy segment jest transmitowany ponownie. Podczas normalnej transmisji (bez retransmitowania segmentów) wartość próbki RTT musi być mierzona, co najmniej raz podczas kaŝdego interwału RTT. Wyjątkiem jest retransmisja jednego z segmentów transmitowanego okna, która moŝe zakłócić poprawne zmierzenie wartości RTT dla tego okna. Nadawca po odebraniu potwierdzenia dla retransmitowanego pakietu nie moŝe określić, który segment (wysłany czy retransmitowany) spowodował wygenerowanie tego potwierdzenia. W takim przypadku wartość zegara retransmisji RTO nie moŝe być zmieniona na podstawie ostatniej próbki RTT. Dodatkowo, jeśli wyczerpie się czas RTO następna jego wartość jest ustalana na podstawie wyraŝenia: RTO n+ 1 = min( 2RTOn,60)s (3.9) Algorytm ten powoduje gwałtowny wzrost wartości RTO (ang. exponential backoff), w którym wartość zegara retransmisji RTO przyjmuje maksymalną wartość określoną w oryginalnej specyfikacji. 22

SeqNo = 100 RTT? SeqNo = 100 RTT? AckNo = 101 Rys. 3.11. Niejednoznaczność transmisji Rysunek przedstawia problem związany z wyznaczeniem czasu RTT dla pakietu, który został ponownie wysłany przez nadawcę podczas retransmisji. Odbiorca pakietu ACK nie ma pewności, czy został on wygenerowany na skutek poprawnego odebrania segmentu retransmitowanego, czy teŝ oryginalnego segmentu, który dotarł poza kolejnością. W takim przypadku wartość RTO obliczana jest na podstawie algorytmu Karn a. 3.3. TCP Reno Wersję protokołu TCP Reno po raz pierwszy zaimplementowano w 1990 roku w dystrybucji Unix a 4.3 BSD Reno. RóŜni się przede wszystkim tym, Ŝe dodaje mechanizm szybkiego odtwarzania utraconych pakietów (ang. Fast Recovery) po wystąpieniu szybkiej retransmisji opisanej w przypadku protokołu TCP Tahoe ( 3.2.3). 3.3.1. Szybkie odtwarzanie w TCP Reno (ang. Fast Recovery) Mechanizm szybkiego odtwarzania utraconych pakietów [4] działa w ten sposób, Ŝe jeśli zaginięcie pakietu jest sygnalizowane przez zegar retransmisji, to jest to oznaka przeciąŝenia sieci i konieczne jest wywołanie algorytmu powolnego startu z rozmiarem okna ustawionym na jeden segment. Jeśli natomiast występuje szybka retransmisja po utracie pakietu, to jest prawdopodobne, Ŝe zaginął tylko jeden segment i wystarczy wykonanie procedury szybkiego odtwarzania. W takim przypadku wartość progu ssthresh jest uaktualniana do wartości połowy okna przeciąŝeniowego, ale nie mniej niŝ dwa rozmiary MSS. Retransmitowany jest utracony segment a wartość okna cwnd jest 23

ustawiana na (ssthresh + 3MSS) ze względu na fakt, Ŝe trzy pakiety zostały poprawnie dostarczone (Rys. 3.12). W celu rejestrowania ilości utraconych pakietów wartość okna jest zwiększana o jeden segment po kaŝdym dodatkowym zduplikowanym potwierdzeniu. Procedura szybkiego odtwarzania kończy się, gdy nadawca otrzyma potwierdzenie odebrania segmentu, który ją spowodował. Po wyjściu wartość okna cwnd jest ustawiana zgodnie z ssthresh i wykonywana jest faza unikania przeciąŝenia. Nadawca Odbiorca AckNo=6 cwnd = 4 SeqNo=6 cwnd = 2+3 ssthresh = 2 cwnd = 2 SeqNo=7 SeqNo=8 SeqNo=9 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 AckNo=10 SeqNo=10 SeqNo=11 3 powielone potwierdzenia faza szybkiego odtwarzania Rys. 3.12. Procedura szybkiego odtwarzania w TCP Reno Wadą tak zaimplementowanego mechanizmu szybkiego odtwarzania jest to, Ŝe kończy on swoje działanie po otrzymaniu częściowego potwierdzenia, a nie czeka na potwierdzenie wszystkich wysłanych segmentów, co przedstawia Rys. 3.13. Problem pojawia się, gdy uszkodzeniu ulegnie większa ilość segmentów z jednego okna danych. W takim przypadku retransmitowany jest tylko pierwszy uszkodzony segment i wartość cwnd jest redukowana o połowę, a następnie po częściowym potwierdzeniu (potwierdzenie pewnej liczby segmentów wraz z tym, który wywołał szybkie odtwarzanie) algorytm ten 24

przerywa pracę. Po kilkakrotnym wywołaniu się procedury szybkiego odtwarzania, wartość okna cwnd moŝe okazać się zbyt mała, aby spowodować szybką retransmisje i konieczne jest czekanie na upłynięcie czasu retransmisji. Następstwem jest ponowne wywołanie wolnego startu, który znacznie obniŝa wydajność protokołu TCP. Nadawca Odbiorca cwnd = 6 AckNo=6 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 SeqNo=10 SeqNo=11 cwnd = 3+3 cwnd = 7 cwnd = 3 DAckNo=6 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 AckNo=7 3 powielone potwierdzenia faza szybkiego odtwarzania oczekiwanie na czas RTO cwnd = 1 SeqNo=7 powolny start Rys. 3.13. Problem w procedurze szybkiego odtwarzania dla większej ilości zgubionych segmentów 25

Rozdział 4. Nowe standardy i propozycje algorytmów kontroli przeciąŝenia 4.1. NewReno Modyfikacja algorytmu szybkiego odtwarzania opisana w [19] nazwana NewReno, ma na celu wyeliminowanie negatywnych cech wpływających na szybkość transmisji. RóŜni się on przede wszystkim tym, Ŝe moŝliwe jest retransmitowanie więcej niŝ jeden uszkodzonych segmentów w ramach pojedynczego okna danych. Dzięki temu nie ma niepotrzebnych opóźnień związanych z zegarem retransmisji i redukcji rozmiaru okna przeciąŝeniowego. Wersja ta jest zalecana w przypadku nieuŝywania mechanizmu selektywnego potwierdzenia opisanego w podrozdziale 4.2. 4.1.1. Algorytm szybkiej retransmisji i szybkiego odtwarzania w NewReno Zaczyna się po odebraniu 3 zduplikowanych potwierdzeń ACK a kończy się po upłynięciu czasu retransmisji RTO lub po otrzymaniu potwierdzenia wszystkich danych łącznie z tymi, które były juŝ wysłane przed rozpoczęciem procedury szybkiego odtwarzania. 1. Po odebraniu 3 powielonych segmentów ACK, jeśli nadawca nie jest w trybie szybkiego odtwarzania, ustawia wartość ssthresh zgodnie z: ssthresh = max( FlightSize / 2,2 MSS) (4.1) gdzie: FlightSize oznacza liczbę wysłanych danych ale nie potwierdzonych, a MSS jest rozmiarem maksymalnego segmentu jaki moŝe być wysłany przez sieć. Dodatkowo w zmiennej recover zapisywany jest najwyŝszy numer sekwencyjny, jaki został wysłany. 2. Uszkodzony segment jest transmitowany ponownie a wartość okna przeciąŝeniowego jest sztucznie zwiększana (ang. inflates) o ilość segmentów, które opuściły sieć i są buforowane po stronie odbiorcy. cwnd = ssthresh + 3MSS (4.2) 26

Nadawca Odbiorca AckNo=6 cwnd = 6 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 SeqNo=10 SeqNo=11 recover = 11 cwnd = 3+3 cwnd = 6 +1 cwnd = 7 DAckNo=6 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 SeqNo=12 AckNo=7 SeqNo=7 SeqNo=13 3 powielone potwierdzenia Segmenty retransmitowane AckNo < recover faza szybkiego odtwarzania cwnd = 3 AckNo=14 SeqNo=14 SeqNo=15 SeqNo=16 AckNo > recover faza unikania przeciąŝenia Rys. 4.1. Przykład działania zmodyfikowanej procedury szybkiego odtwarzania w NewReno 3. Dla kaŝdego dodatkowego zduplikowanego segmentu ACK wartość okna cwnd jest równieŝ zwiększana o jeden segment. 4. Transmitowane są nowe segmenty, jeśli pozwala na to rozmiar okna cwnd i rwnd (ogłaszane przez odbiorcę). 27

5. Po otrzymaniu segmentu ACK dla nowych danych moŝe on oznaczać dwa przypadki: a. Potwierdzenie ACK dotyczy wszystkich wysłanych danych, włącznie z numerem sekwencyjnym zapisanym w zmiennej recover. Wartość okna jest redukowana do wartości ssthresh (z punktu 1) i procedura szybkiej retransmisji kończy się. b. Potwierdzenie ACK dotyczy części danych. W takim przypadku rozmiar okna jest redukowany o wartość odpowiadającą nowej ilości potwierdzonych danych i dodatkowo zwiększany o jeden segment. Jeśli nowa wartość okna na to pozwala, wysyłany jest pierwszy niepotwierdzony segment danych i ponownie wykonuje się procedura szybkiego odtwarzania zaczynając od punktu 3. Dodatkowo, jeśli jest to pierwsze częściowe potwierdzenie, resetowany jest zegar retransmisji. 4.1.2. Problemy w NewReno W związku z powyŝszym algorytmem szybkiego odtwarzania utraconych segmentów powstało kilka moŝliwości odpowiedzi na częściowe potwierdzenie [19]. Pierwszym nasuwającym się problemem jest to, kiedy resetować zegar retransmisji w przypadku częściowego potwierdzania danych. Ponowne uruchamianie zegara tylko po pierwszym potwierdzeniu części danych moŝe doprowadzić do fazy powolnego startu w przypadku duŝej utraty segmentów w ramach jednego okna danych. Ta wersja została nazwana niecierpliwym wariantem NewReno (ang. Impatient variant of NewReno). Problem ten przedstawiony jest na Rys. 4.2, na którym przedstawiona jest moŝliwość wyczerpania się czasu retransmisji zanim zakończy się procedura szybkiego odtwarzania. 28

Nadawca Odbiorca AckNo=6 cwnd = 6 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 SeqNo=10 SeqNo=11 cwnd = 3+3 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 3 powielone potwierdzenia segmenty retransmitowane recover = 11 cwnd = 6 AckNo=7 SeqNo=7 AckNo=8 resetetowanie zegara faza szybkiego odtwarzania RTO cwnd = 6 SeqNo=8 cwnd = 1 SeqNo=8 koniec czasu RTO faza powolnego startu Rys. 4.2. Przykład wyczerpania się czasu retransmisji podczas procedury szybkiego odtwarzania w wariancie NewReno z resetowaniem zegara tylko po pierwszym częściowym potwierdzeniu. Innym moŝliwym wariantem jest resetowanie zegara po kaŝdym częściowym potwierdzeniu. Ze względu na to, Ŝe w kaŝdym interwale RTT moŝe być retransmitowany co najwyŝej jeden segment, taki wariant NewReno został określony jako wolny ale stały (ang. Slow-but-Steady). 29

Drugim problemem jest ilość wysyłanych pakietów po częściowym potwierdzeniu. W przypadku wysyłania więcej niŝ jednego segmentu po częściowym potwierdzeniu, moŝna znacznie zmniejszyć czas procedury odtwarzania, ale kosztem niepotrzebnej retransmisji. Rys. 4.3 przedstawia zbędne retransmisje dwóch segmentów. Ze względu na fakt, Ŝe zgubione segmenty nie są kolejno po sobie, w przypadku retransmitowania dwóch segmentów po kaŝdym częściowym potwierdzeniu, jeden z nich jest niepotrzebny. Nadawca Odbiorca AckNo=6 cwnd = 6 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 SeqNo=10 SeqNo=11 cwnd = 3+3 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 SeqNo=7 3 powielone potwierdzenia niepotrzebnie retransmitowane segmenty recover = 11 cwnd = 5 AckNo=8 SeqNo=8 faza szybkiego odtwarzania SeqNo=9 AckNo=12 cwnd = 3 SeqNo=12 faza unikania przeciąŝenia Rys. 4.3. Przykład nadmiernej retransmisji w procedurze szybkiego odtwarzania w wariancie NewReno z dwoma segmentami wysyłanymi po kaŝdym częściowym potwierdzeniu 30

Problem związany z nadmiernym wywołaniem szybkiej retransmisji nie jest tak powaŝny jak w przypadku TCP Reno, gdyŝ powyŝszy algorytm szybkiego odtwarzania nie jest przerywany po kaŝdej retransmisji pojedynczego segmentu. Ponowne wywołanie się szybkiej retransmisji moŝe nastąpić tylko w przypadku wyczerpania się czasu retransmisji RTO. Problem ten jest rozwiązany w modyfikacji zwanej bugfix [19], która uŝywa nowej zmiennej send_high do przechowywania najwyŝszego numeru sekwencyjnego wysłanego do momentu wyczerpania się czasu RTO. Po odebraniu 3 zduplikowanych potwierdzeń, które nie obejmują danych włącznie z numerem sekwencyjnym zawartym w send_high, nie jest wykonywana Ŝadna czynność (Rys. 4.4). Nadawca Odbiorca SeqNo=7 SeqNo=8 SeqNo=9 RTO send_high = 9 cwnd = 1 AckNo=6 SeqNo=6 koniec czasu RTO faza powolnego startu po wyczerpaniu się czasu RTO cwnd = 2 DAckNo=6 DAckNo=6 DAckNo=6 AckNo=7 SeqNo=7 SeqNo=8 3 powielone potwierdzenia (zignorowane) send_high > DAckNo Rys. 4.4. Mechanizm unikania nadmiernej retransmisji w wariancie bugfix protokołu TCP NewReno 31

4.2. TCP SACK Modyfikacja selektywne potwierdzanie (SACK ang. Selective ACK) wykorzystuje te same mechanizmy kontroli przeciąŝenia co TCP Reno, jeśli chodzi o regulację okna cwnd. Główną róŝnicą jest sposób zachowania się algorytmu w przypadku utraty większej ilości pakietów naleŝących do jednego okna danych. Dzięki implementacji dodatkowych opcji w nagłówku TCP [32], odbiorca ma moŝliwość poinformowania nadawcy o tym, które segmenty zostały poprawnie odebrane, a których brakuje. Wykorzystując te informacje nadawca moŝe retransmitować jedynie brakujące segmenty bez konieczności oczekiwania na upłynięcie czasu retransmisji. Standard [32] definiuje dwie opcje uŝywane przez mechanizm SACK: 1. Opcja SACK-permitted wysyłana jest tylko raz w segmencie SYN podczas zestawiania połączenia i słuŝy do poinformowania odbiorcy o moŝliwości uŝywania opcji SACK. Ma stałą długość wynoszącą 2 bajty. 2. Opcja SACK wysyłana jest przez odbiorcę danych w przypadku odebrania bloku danych (w postaci segmentu) poza kolejnością. Zawiera listę poprawnie odebranych bloków danych oczekujących w kolejce odbiorcy, z których kaŝdy reprezentuje ciąg sąsiadujących danych w przestrzeni sekwencyjnej i jest odizolowany od innych. KaŜdy blok jest definiowany przez dwie 32-bitowe liczby całkowite i zawiera maksymalną liczbę przylegających danych. Lewa krawędź bloku (ang. Left Edge) zawiera pierwszy numer sekwencyjny danych, a prawa krawędź bloku (ang. Right Edge) określa numer sekwencyjny zaraz po ostatnim z bloku i jest to dana, którą nadawca musi retransmitować. Opcja zawierająca n bloków zajmuje 8n+2 bajtów, więc 40 bajtów przeznaczonych na wszystkie opcje w nagłówku TCP pozwala na określenie maksymalnie 4 bloków danych. W przypadku połączenia opcji np. ze znacznikiem czasu (ang. Timestamp) mechanizmu RTTM ilość moŝliwych bloków ogranicza się do 3. 4.2.1. Algorytm szybkiego odtwarzania w mechanizmie SACK Mechanizm SACK (podobnie jak TCP Reno) po odebraniu trzech zduplikowanych pakietów przechodzi do trybu szybkiego odtwarzania utraconych pakietów (Rys. 4.5). Nadawca retransmituje brakujący segment i zmniejsza wartość okna przeciąŝeniowego o połowę. Istotną róŝnicą jest to, Ŝe przechowywana jest dodatkowa zmienna pipe, której wartość odpowiada liczbie pakietów spoza sekwencji przekazywanej przez sieć [17]. 32

Nadawca AckNo=6 Odbiorca cwnd = 8 SeqNo=6 SeqNo=7 SeqNo=8 SeqNo=9 SeqNo=10 SeqNo=11 SeqNo=12 SeqNo=13 cwnd = 4 highdata = 13 pipe = 8-3 pipe = 5-3 pipe = 2 + 2 pipe = 4-2 pipe = 2 + 2 DAckNo=6 DAckNo=6 DAckNo=6 DAckNo=6 DAckNo=6 DAckNo=6 SeqNo=6 SeqNo=7 SAckNo=12 SeqNo=12 SeqNo=13 3 powielone potwierdzenia częściowe potwierdzenie cwnd - pipe = 2 recover faza szybkiego odtwarzania cwnd - pipe = 2 recover SAckNo=14 SeqNo=14 SAckNo > highdata recover SeqNo=15 SeqNo=16 faza unikania przeciąŝenia Rys. 4.5. Przykład działania procedury szybkiego odtwarzania w protokole TCP SACK 33

Nadawca wysyła nowe lub retransmituje pakiety tylko w przypadku, gdy wartość pipe jest mniejsza od cwnd. Wartość pipe jest zwiększana o jeden po wysłaniu nowego lub retransmitowanego pakietu, a zmniejszana o jeden po odebraniu zduplikowanego pakietu z opcją SACK informującą o odebraniu nowych danych [17]. Są to potwierdzenia wygenerowane po odebraniu nowych segmentów, ale niepotwierdzające większej ilości łącznie zatwierdzonych danych przechowywanych w zmiennej highack [9]. W przypadku odebrania częściowego potwierdzenia (potwierdzenie zawierające numer sekwencyjny większy niŝ przechowywany w zmiennej highack), wartość pipe jest zmniejszana o dwa rozmiary segmentów ze względu na fakt, Ŝe dwa segmenty opuściły sieć (oryginalny i retransmitowany). Wszystkie odebrane bloki danych poza sekwencją są przechowywane przez nadawcę w odpowiedniej strukturze, która w przypadku retransmisji pozwala mu określić następny z listy brakujących segmentów [9]. Jeśli nie ma brakujących segmentów bądź okno odbiorcy jest odpowiednio duŝe, wysyłane są nowe segmenty danych. Procedura szybkiego odtwarzania kończy się, gdy nadawca otrzyma skumulowane potwierdzenie dla numeru sekwencyjnego przechowywanego w zmiennej highdata, która przechowuje maksymalny numer segmentu wysłany przed przejściem do tej procedury [9]. W przypadku, gdy retransmitowany pakiet zaginie, jest to wykrywane przez procedury związane z upłynięciem czasu retransmisji i segment taki jest retransmitowany ponownie, po czym wykonywana jest procedura powolnego startu. 4.3. Potwierdzenia generowane w przód (FACK) Mechanizm potwierdzeń generowanych w przód (FACK ang. Forward Acknowledgment) bazuje na podstawowych algorytmach kontroli przeciąŝenia [33], wykorzystując równieŝ do swojej pracy dodatkową opcję SACK opisywaną w poprzednim paragrafie. Podobnie jak mechanizm selektywnych potwierdzeń zapewnia efektywniejsze działanie procedury odtwarzania pakietów w przypadku wielokrotnych ich strat w jednym oknie danych. Głównym celem jest wykorzystanie informacji z opcji TCP SACK do bardziej precyzyjnej kontroli wtłaczania danych do sieci podczas wykonywania się fazy szybkiej retransmisji i odtwarzania. Sama nazwa zaś, wynika z tego, Ŝe algorytm rejestruje najwyŝszą wartość numeru sekwencyjnego poprawnie odebranych danych. 34

4.3.1. Algorytm FACK W przeciwieństwie do TCP Reno i SACK, które próbowały oszacować ilość zaległych danych na podstawie otrzymanych powielonych potwierdzeń ACK, mechanizm ten wykorzystuje dodatkowe informacje dostarczone przez opcje SACK do wyraźnego obliczenia całkowitej ilości zaległych danych. Dodatkowo wprowadza dwie zmienne opisujące stan transmisji. Pierwsza z nich, snd.fack odzwierciedla poprawnie odebrany segment o najwyŝszym numerze sekwencyjnym. Jej wartość uaktualniana jest na podstawie numeru potwierdzenia snd.una (Rys. 4.6) w nagłówku TCP (w przypadku normalnego potwierdzenia) oraz informacji zawartych w opcji SACK (w przypadku potwierdzenia z opcją SACK). Druga zmienna, retran_data odzwierciedla ilość zaległych retransmitowanych danych w sieci i jest obliczana podczas procedury szybkiego odtwarzania. Za kaŝdym razem, gdy segment jest retransmitowany, jej wartość jest zwiększana o rozmiar tego segmentu (MSS), a zmniejszana po stwierdzeniu, Ŝe dany segment opuścił sieć. Dzięki tym wartościom nadawca moŝe oszacować ilość zaległych danych pozostających w sieci awnd w następujący sposób: awnd = snd. nxt snd. fack + retran _ data (4.3) gdzie: snd.nxt wysłany segment danych o najwyŝszym numerze sekwencyjnym. snd.una snd.nxt dane wysłane dane wysłane ale niepotwierdzone dane niewysłane Rys. 4.6. Widok sekwencji nadawcy Wartość snd.una na Rys. 4.6 określa najmniejszy numer sekwencyjny segmentu wysłanego ale niepotwierdzonego. 35

4.3.2. Procedura szybkiego odtwarzania w FACK Wywołanie szybkiej retransmisji w TCP Reno odbywa się na podstawie odebrania zduplikowanych potwierdzeń, co powoduje niepotrzebne opóźnienia w przypadku zaginięcia kilku segmentów. W wersji FACK dodatkowym mechanizmem przyspieszającym jest stan kolejki retransmisji po stronie nadawcy danych. Jeśli róŝnica pomiędzy segmentem spoza sekwencji snd.fack a numerem sekwencyjnym snd.una potwierdzonego segmentu naleŝącego do ciągłej struktury jest większa niŝ 3, nie ma konieczności oczekiwania na zduplikowane potwierdzenia: if ((snd.fack snd.una) > (3MSS) (dupacks == 3)) { /* szybka retransmisja */ } W przypadku zaginięcia tylko jednego segmentu obydwa warunki będą spełnione po takim samym czasie, jaki potrzebny jest do wywołania szybkiego odtwarzania w wersji TCP Reno. Zysk w postaci krótszego oczekiwania na retransmisję widoczny jest dopiero w przypadku wielokrotnych zaginięć. W fazie szybkiego odtwarzania wartość snd.fack odświeŝana jest na podstawie informacji zawartych w blokach SACK i rozpoczyna się zliczanie zaległych retransmitowanych danych. Wszystko to słuŝy do właściwego szacowania ilości danych pozostających w sieci a niepotwierdzonych jeszcze przez odbiorcę, o czym mowa była podczas opisywania algorytmu FACK. Wartość zaległych danych (awnd) jest tak dobierana, aby mieściła się w jednym segmencie okna cwnd. Sama wartość okna cwnd podczas trwania szybkiego odtwarzania nie zmienia się. Zakończenie procedury odtwarzania następuje w momencie, gdy wartość numeru potwierdzenia (snd.una) wyrówna się bądź przekroczy najwyŝszy numerem sekwencyjny (snd.nxt) wysłanego segmentu w okresie poprzedzającym wykrycie pierwszego braku w transmitowanych segmentach. Jest to równowaŝne z potwierdzeniem przez odbiorcę wszystkich zaległych danych. Po wyjściu z tej procedury wykonywany jest liniowy wzrost okna cwnd zgodnie z procedurą unikania przeciąŝenia. Dodatkowo przerwanie jest wymuszone przez zegar retransmisji po wykryciu ponownego zaginięcia retransmitowanego pakietu. 36