Ponieważ fale radiowe jako medium transportowe charakteryzują się stosunkowo dużą zawodnością, dużo zasobów pochłania obsługa mechanizmów niezawodności transmisji wbudowanych w protokół TCP. W efekcie trzeba iść na kompromis pomiędzy szybkością transmisji a niezawodnością. Prowadzono szereg badań nad tym tematem, m.in. nad ulepszeniem TCP czy dodaniem dodatkowych protokołów w warstwie transportowej.
TCP jest popularnym protokołem transportowym wykorzystywanym przez wiele aplikacji sieciowych. Wraz z pojawieniem się mobilnych urządzeń wyposażonych w obsługę sieci bezprzewodowych protokół TCP nabrał jeszcze większego znaczenia. Jednak nie jest on idealnym protokołem transportowym. Główny problem z TCP to założenie, że utrata pakietów następuje w wyniku przeciążenia łączy. Nadawca TCP wykrywa utratę pakietów, gdy nastąpi przekroczenie zakładanego czasu lub gdy przyjdzie zduplikowane potwierdzenie (ACK).
TCP nie może ponownie przesłać utraconych danych przed upłynięciem określonego czasu, chyba że:
- połączenie ma dużą liczbę pakietów do retransmisji,
- nadawca otrzymuje wystarczająco dużo potwierdzeń ACK od odbiorcy.
Jednak w sieciach bezprzewodowych często występuje sytuacja, w której pakiety nie mogą być odzyskane przez szybko retransmisję, ponieważ ograniczony rozmiar okna nie generuje odpowiedniej liczby zduplikowanych potwierdzeń wskazujących na pakiety poza kolejką.
Jedną z popularnych metod poprawy wydajności sieci bezprzewodowych jest mechanizm Forward Error Correction (FEC) działający na poziomie warstwy fizycznej. Ta metoda ma wiele wad i nie rozwiązuje problemu w całości. Kompleksowe rozwiązanie problemu można zdefiniować w trzech kategoriach: warstwy łącza danych, podzielenia połączenia oraz proxy.
Protokół Airmail stojący za mechanizmem FEC sprawia, że warstwa łącza danych zapewnia niezawodny transport, ponieważ stacja bazowa przesyła całe okno. Zaletą takiego podejścia jest brak konieczności oczekiwania na potwierdzenie odebrania każdego pakietu. Niestety jest też poważny, choć często ignorowany problem – sytuacja, w której współczynników błędów jest wysoki. Wtedy komunikujące się strony nie mają pojęcia o występujących błędach aż do momentu, kiedy zostanie przesłane całe okno.
Kolejna koncepcja zakłada podzielenie połączenia – komunikacja od nadawcy do odbiorcy zostaje oddzielona od strumienia płynącego w drugą stronę, od odbiorcy do nadawcy. Jednak to podejście nie sprawdza się z powodu niezgodności z TCP.
Ostatnie podejście zakłada umieszczenie pomiędzy nadawcą i odbiorcą serwera proxy. Protokół Snoop, działający w warstwie łącza danych wykorzystuje to podejście. Jednak główną wadą tego protokołu jest uwzględnianie tylko skumulowanych potwierdzeń, co sprawia, że często wynik obliczeń daje błędne informacje o utracie pakietów.
Miarą wydajności połączenia TCP jest przepustowość. Maksymalną przepustowość osiąga się, gdy okno TCP jest równe opóźnieniu na danym łączu. W takiej sytuacji przepustowość dostępnego łącza jest wykorzystywana maksymalnie. Aby osiągnąć wysoką przepustowość, należy:
- wypróbować mechanizmy zmniejszającej liczbę utraconych pakietów.
- wypróbować mechanizmy szybkiej retransmisji, gdy jednak dojdzie do utraty pakietów.
Problemy specyficzne dla połączeń bezprzewodowych
W sieciach bezprzewodowych głównymi przyczynami utraty pakietów jest kiepskiej jakości sygnał radiowy lub brak łączności. Zmienna i przypadkowa charakterystyka tego medium utrudnia określenie statystycznych opóźnień czy prawdopodobieństwa utraty pakietu.
Warstwa łącza danych
Protokoły warstwy łącza danych działają niezależnie od protokołów wyższych warstw. Implementacje TCP mają bardzo długie czasy retransmisji, będące wielokrotnością 500 ms, podczas gdy w warstwie łącza danych czasy retransmisji są wielokrotnością 200 ms. Protokoły warstwy łącza danych nie próbują dostarczać pakietów w kolejności nadawania, więc mogą one docierać do odbiorcy nieuporządkowane. Obecnie nie ma jednego standardu, który regulowałby tę sytuację. Większość protokołów warstwy łącza danych wykorzystuje mechanizmy „zatrzymaj i czekaj”, „cofnij się o N”, selektywnego powtarzania lub korekcji FEC w celu zapewnienie niezawodności transmisji.
Szereg różnych badań pokazało, że stosowanie korekcji błędów na poziomie warstwy łącza danych zwiększą ogólną wydajność. Jednak retransmisja w tej warstwie nie zawsze zwiększa wydajność, ponieważ w przypadku lokalnych retransmisja spada wydajność TCP. Dlatego rozwiązania w tej warstwie powinny skupiać się na dostarczaniu pakietów we właściwej kolejności.
TULIP (Transport Unaware Link Improvement Protocol)
Rozwiązaniem problemu jest stworzenie warstwy łącza danych, która będzie w stanie retransmitować utracone pakiety, zanim protokół TCP stwierdzi utratę pakietu (np. z powodu upływu zadanego czasu). Przy takim podejściu należy ukryć fakt utraty pakietów w sieci bezprzewodowej, wykorzystując lokalną retransmisję i korekcję FEC w sieci bezprzewodowej. Taka warstwa łącza danych powinna w jak największym stopniu wykorzystywać długie okresy upływu czasu (timeout) protokołu TCP. Protokół TULIP wykorzystuje mechanizm selektywnej retransmisji w połączeniu z przeplotem pakietów.
TULIP jest w stanie zapewnić lokalne odzyskiwanie wszystkich utraconych pakietów, co zapobiega niepotrzebnym i opóźnionym retransmisjom, czego konsekwencją jest redukcja okna TCP. Co istotne, nie wymaga modyfikacji oprogramowania obsługującego warstwę transportową.
Jest to wydajny protokół warstwy łącza danych, wykorzystujący zalety potwierdzeń warstwy łącza danych z płynącymi w drugą stronę potwierdzeniami odbioru (ACK) warstwy transportowej. Takie podejście bez żadnych modyfikacji warstwy transportowej zwiększa przepustowość nawet trzykrotnie w stosunku do TCP.
TULIP działa niezależnie od informacji przekazywanych w nagłówku TCP, np. o stanie połączenia, i może współpracować z różnymi wersjami TCP. TULIP przenosi potwierdzenia TCP wewnątrz potwierdzeń warstwy transportowej, co redukuje wykorzystanie dostępnego pasma.
TULIP działa pomiędzy warstwą adresów MAC, a warstwami TCP/IP. TULIP nie wykorzystuje informacji o stanach połączeń TCP i nie podejmuje decyzji na bazie sesji TCP, ale opiera się jedynie na celu komunikacji. Dlatego TULIP znacznie redukuje swój narzut, gdy aktywnych jest wiele sesji TCP dla danego hosta.
Jednorazowo TULIP przekazuje jeden pakiet do warstwy łącza danych. Protokół ten wykorzystuje dwa dodatkowe komunikaty: TRANS i WAIT. TULIP potrzebuje dostępu do warstwy łącza danych, żeby móc sprawdzić, czy rozpoczęła się już transmisja pakietu, który został do niego przekazany. Warstwa transportowa informuje o tym, używając komunikatu TRANS. Po otrzymaniu komunikatu TRANS protokół TULIP uruchamia licznik i oczekuje przez określony czas t1, zanim zacznie nadawać kolejny pakiet, ponieważ obie komunikujące się strony mogą nadawać dane o różnej długości. Jeśli pakiety są dłuższe, warstwa łącza danych przekazuje do protokołu TULIP informację, że powinien oczekiwać dłużej, niż przez czas t1. Ta procedura przeplotu pakietów pozwala na synchronizację dwóch komunikujących się stron podczas dwustronnego przesyłania danych.
Podstawowym zadaniem protokołu TULIP jest przyspieszenie komunikacji na poziomie warstwy adresów MAC, co pozwala skrócić opóźnienia, jakimi charakteryzuje się dane łącze. TULIP zawiera funkcje akceleracji MAC i wykorzystuje trzystopniową wymianę komunikatów w celu nawiązania połączenia. Podczas nawiązywania połączenia nadawca przesyła komunikat RTS (Request To Send) do odbiorcy, który odpowiada komunikatem CTS (Clear To Send), który trwa dłużej niż RTS. CTS jest to sygnał do wszystkich pozostałych węzłów, żeby wstrzymały się z transmisją tak długo, aż pakiet dotrze do odbiorcy, co pozwala uniknąć kolizji.
Akceleracja MAC działa w następujący sposób:
- Po uzgodnieniu połączenia (RTS i CTS) nadawca przesyła pakiet TULIP zawierający dane. Odbiorca natychmiast przesyła do nadawcy potwierdzenie odbioru (TULIP ACK).
- Jeśli odbiorca chce przesłać z powrotem pakiet z danymi (o rozmiarze 40 bajtów lub mniejszym), pakiet ten zostaje umieszczony wewnątrz pakietu TULIP ACK i odesłany do nadawcy. Dla przesłania tego pakietu nie ma potrzeby uzgadniania połączenia (RTS i CTS).
- Jeśli pakiet jest większy niż 40 bajtów, wtedy dopiero konieczne jest uzgodnienie połączenia.
TULIP wykorzystuje funkcję skumulowanych potwierdzeń. Jeśli pakiet przesyłany od nadawcy do odbiorcy nie dotrze do celu, odbiorca ponownie przesyła komunikat ACK z bitem wektora wskazującym, że dany pakiet nie został odebrany. Jednocześnie odbiorca nie przestaje odbierać kolejnych pakietów od nadawcy, umieszczając je w buforze. Następnie przygotowuje listę pakietów, które wymagają retransmisji i przesyła te informacje w jednym pakiecie ACK. Jeśli odbiorca otrzyma brakujący pakiet i wszystkie pakiety są we właściwej kolejności, zostają przekazane do protokołu wyższej warstwy.
Wydajność
Właściwości kanału radiowego są całkowicie inne niż w przypadku kabla. Kanał radiowy charakteryzuje się wysokim współczynnikiem błędów bitów (Bit-Error Rate, BER). Poza tym kanały radiowe mogą powodować skokowy przyrost liczby błędów, jeśli przez dłuższy czas sygnał radiowy jest słaby. Są różne strategie rozwiązania tego problemu:
- Kompleksowe działania na całej trasie połączenia (End-to-end).
- Podzielenie połączenie.
- Optymalizacja na poziomie warstwy łącza danych.
W przypadku połączeń end-to-end należy się liczyć ze wszystkimi rodzajami utraty danych. Optymalny schemat end-to-end powinien zakładać następującą strategię:
- Kategorie błędów zależą od typu sieci. Analizując komunikację z punktu widzenia nadawcy, ta metoda może być użyta, jeśli można zrezygnować z precyzyjnego wykrywania błędów w zamian za minimalne zmiany w węzłach pośredniczących.
- Ta metoda jest lepsza w przypadku stosowania selektywnych potwierdzeń (ACK), ponieważ pozwala nadawcy TCP szybciej retransmitować pakiety w przypadku, gdy w danym oknie zostało utraconych wiele pakietów.
Przepustowość
Współczynnik błędów bitów waha się pomiędzy 0-15 bitów na milion. Natomiast okno odbiorcy ma rozmiar 42 KB.
Protokół TULIP tworzy u nadawcy listę retransmisji w momencie odebrania pierwszego pakietu ACK, dzięki czemu wie, których pakietów brakuje, ponieważ te informacje otrzymuje od odbiorcy. Retransmituje pakiety, gdy otrzyma takie potwierdzenie od odbiorcy. Natomiast kolejne błędy występujące w miarę przesuwania się okna są naprawiane przed pierwszym błędem. Inne protokoły polegają na licznikach i skumulowanych potwierdzeniach, co prowadzi do powstawania opóźnień retransmisji serii utraconych pakietów. Dlatego TULIP znacznie redukuje opóźnienia występujące pomiędzy punktami końcowymi.
