Laminar TCP

Co to jest Laminar?

Laminar to nowa platforma do kontroli zatorów TCP, która oddziela harmonogram transmisji, który precyzyjnie określa, kiedy dane są wysyłane, od funkcji czystej kontroli zatorów, która określa całkowitą ilość danych wysyłanych podczas każdego RTT.

Domyślnym algorytmem planowania transmisji jest rygorystyczne wdrożenie zasady zachowania pakietów Van Jacobsona [Jacobson88]. Dane docierające do odbiorcy powodują potwierdzenia potwierdzenia, które z kolei powodują, że nadawca przesyła z powrotem do sieci równoważną ilość danych. Zmienna stanu podstawowego wynika z ilości danych i potwierdzeń w sieci. Ten stan obserwuje się za pomocą ulepszonego estymatora tcp_packets_in_flight() (inaczej total_pipe). Wartość parametru total_pipe jest oparta na elemencie „pipe” zgodnie z definicją RFC 3517, ale uwzględnia też ilość danych raportowanych przez bieżące potwierdzenie potwierdzenia oraz transmisję oczekujących, które przeszły kontrolę zatoru, ale oczekują na inne zdarzenia, takie jak TSO.

Nowa zmienna, CCwin, to główna zmienna stanu kontroli zatorów. Algorytmy kontroli zatoru dostosowują funkcję CCwin, aby regulować ogólny poziom zatoru na ścieżce. Chociaż rozwiązanie CCwin przypomina CWnd, jest ono przeciążone i wykorzystywane przez wiele algorytmów (np. do ograniczania wybuchów) o różnych, a czasem sprzecznych z nimi celach.

Za każdym razem, gdy parametr total_pipe jest inny niż CCwin, algorytm planowania transmisji nieznacznie dostosowuje liczbę segmentów wysłanych w odpowiedzi na każde potwierdzenie. Powolny start i proporcjonalna redukcja współczynnika klikalności (PRR) (zamiennik współczynnika o połowę) są wbudowane w algorytm planowania transmisji.

Główną zaletą platformy Laminar jest to, że dzięki partycjonowaniu kontroli zatorów i harmonogramu transmisji w osobne podsystemy każdy podlega znacznie prostszym ograniczeniom projektowym, co ułatwia opracowanie wielu nowych algorytmów, których nie da się zrealizować przy użyciu wcześniejszej organizacji kodu.

Platforma Laminar zmienia bazową filozofię projektową kontroli zatoru TCP i może mieć szerokie konsekwencje poza samą poprawką. Ta poprawka ma umożliwić użytkownikom eksperymentowanie z kodem i komentowanie oraz wykrywanie wszelkich przypadków, które mogły zostać pominięte. Ponadto poprawka jest niekompletna w tym sensie, że wciąż brakuje szeregu algorytmów, w szczególności: algorytmów kontroli zatoru aplikacji innych niż CUBIC i Reno, walidacja cwnd, wskaźniki miejsc docelowych itp. Bardzo dobrze byłoby, gdyby pracownicy mogli pomóc w refaktoryzacji niektórych z tych algorytmów.

Schemat Laminar i jego motywacja zostały szczegółowo opisane w internetowej wersji roboczej draft-mathis-tcpm-tcp-laminar.

Komentarze i sugestie możesz wysyłać na adres mattmathis@google.com.

Ten projekt jest częścią działań Google mających na celu przyspieszenie działania sieci poprzez ulepszenia protokołów.

Uwagi o wdrażaniu

Laminar jest zaimplementowany głównie w 3 funkcjach (tcp_input.c):

Tcp_cong_avoid() i tcp_mult_decr() kontrolują przeciążenie AIMD za pomocą zmiennej stanu CCwin. Z wyjątkiem funkcji cofania te 2 funkcje są jedynymi miejscami, w których zmienia się funkcja DW. Obie funkcje wywołują elementy obsługi specyficzne dla modułu zatoru.

Tcp_laminar_schedule() określa, ile danych należy wysłać w odpowiedzi na każde potwierdzenie. Stosuje ochronę pakietów Van Jacobsona, skorygowaną nieco w górę lub w dół w celu zbieżenia funkcji tcp_packets_in_flight() z CCwin.

Wprowadziliśmy ważne zmiany w estymatorze tcp_packets_in_flight(), aby było ono niezmienną w przypadku większości zdarzeń protokołów. Zatrzymanie aplikacji, korekty w funkcji tcp_laminar_schedule() i rzeczywiste utracone pakiety zmieniają się zgodnie z procesem tcp_packets_in_flight(). Przetwarzanie potwierdzenia, TSO i większość innych zdarzeń nie. W przypadku straty rzeczywista liczba pakietów w locie natychmiast się zmienia, ale nie jest odzwierciedlana w estymatorze tcp_packets_in_flight(), dopóki maszyna do retransmisji nie oznaczy ich jako utracone i zwiększy się wartość lost_out.

Pobierz poprawkę

Ta poprawka jest niezgodna z modelem net-next Dave'a Millera i bezproblemowo stosuje się do 3.5-rc2.
Uwaga: inne moduły kontroli zatoru, inne niż Reno i CUBIC, nie zostały zaktualizowane i nie będą kompilowane. Jeśli w Twojej konfiguracji są tworzone inne moduły kontroli zatoru, takie jak Vegas, skalowalne, Szybkie itp., najpierw musisz je wyłączyć.