Jakie są możliwe wady ustawienia (bardzo) dużego initcwnd dla połączeń o dużej przepustowości?

Eksperymentowałem z parametrami TCP w Linuksie (z jądrem 3.5). Zasadniczo dotyczące tego połączenia:

Serwer: Gigabitowe łącze wysyłające w centrum danych, rzeczywista przepustowość (ze względu na współdzielenie łącza wysyłającego) wynosi około 70 MB / s podczas testowania z innego centrum danych.

Klient: Gigabitowa lokalna sieć LAN podłączona do światłowodu 200 Mb. Pobieranie pliku testowego faktycznie osiąga 20 MB / s.

Opóźnienie: około 50ms w obie strony.

Serwer zdalny służy jako serwer plików dla plików w zakresie od 10 do 100 MB. Zauważyłem, że użycie initcwnd 10 ma duży wpływ na czas przesyłania tych plików przez powolny start TCP, który zajmuje 3,5 sekundy, aby załadować 10 Mb (prędkość maksymalna osiągnięta: 3,3 MB / s), ponieważ uruchamia się powoli, a następnie przyspiesza, jednak jest zakończone przed osiągnięciem maksymalnej prędkości. Moim celem jest dostrojenie się do minimalnych czasów ładowania tych plików (więc nie najwyższa nieprzetworzona przepustowość lub najniższe opóźnienie w obie strony, jestem gotów poświęcić oba, jeśli skróci to rzeczywisty czas potrzebny do załadowania pliku)

Próbowałem więc prostego obliczenia, aby określić, jaki powinien być idealny initcwnd, ignorując wszelkie inne połączenia i możliwy wpływ na innych. Produkt z opóźnieniem przepustowości wynosi 200 Mbit / s * 50 ms = 10 Mbit lub 1,310,720 bajtów. Biorąc pod uwagę, że initcwnd jest ustawiony w jednostkach MSS i przy założeniu, że MSS ma około 1400 bajtów, będzie to wymagało ustawienia: 1.310.720 / 1400 = 936

Ta wartość jest bardzo daleka od domyślnej (10 * MSS w Linuksie, 64kb w Windows), więc nie jest dobrym pomysłem ustawienie jej w ten sposób. Jakie są oczekiwane wady takiej konfiguracji? Na przykład:

• Czy wpłynie to na innych użytkowników tej samej sieci?
• Czy może to powodować niedopuszczalne zatory dla innych połączeń?
• Zalewasz bufory routerów gdzieś na ścieżce?
• Zwiększyć wpływ niewielkiej utraty pakietów?

Jakie są oczekiwane wady takiej konfiguracji? Na przykład:

Will it affect other users of the same network?

Zmiana initcwnd wpłynie na:

• Użytkownicy serwera z ustawieniami się zmieniają
• JEŻELI ci użytkownicy dopasują trasę, skonfigurowane zostaną zmiany ustawień.

Could it create unacceptable congestion for other connections?

Pewnie.

Flood router-buffers somewhere on the path?

Nie bez znaczenia, ale jeśli nie są Twoimi routerami, skoncentruję się na sprawach, które są Ci bliższe.

Increase the impact of small amounts of packet-loss?

Jasne, może to zrobić.

Rezultatem jest to, że zwiększy to koszty utraty pakietów, zarówno celowe, jak i niezamierzone. Twój serwer jest łatwiejszy do DOS dla każdego, kto jest w stanie ukończyć trójdrożny uścisk dłoni (znaczne ilości danych przy niskich nakładach inwestycyjnych (ilość danych)).

Zwiększy również szanse, że wiązka tych pakietów będzie musiała zostać ponownie przesłana, ponieważ jeden z pierwszych pakietów w serii zostanie utracony.

Nie sądzę, że w pełni rozumiem, o co prosisz, więc oto próba odpowiedzi:

Po pierwsze, to, co próbujesz zrobić, ma sens tylko po stronie wysyłającej, a nie po stronie odbierającej. Tzn. Musisz zmienić serwer plików, a nie odbiornik. Zakładając, że to właśnie robisz:

Zmiana initcwnd na (np.) 10 oznacza, że ​​10 pakietów natychmiast zniknie. Jeśli wszystkie osiągną swój cel, możesz skończyć z dużo większym oknem w pierwszym RTT ze względu na powolny start (wykładniczy wzrost cwnd). Jednak po utracie pakietów cwnd zostanie zmniejszony o połowę, a ponieważ masz do dyspozycji 10 pakietów, będziesz mieć znaczną liczbę retransmisji, więc możesz mieć więcej problemów niż myślisz.

Jeśli chcesz wypróbować coś bardziej agresywnego i być „nieuprzejmym” wobec innych użytkowników Internetu, możesz zamiast tego zmienić algorytm kontroli zatorów po stronie serwera. Różne algorytmy obsługują cwnd w inny sposób. Należy pamiętać, że wpłynie to na wszystkich użytkowników, chyba że oprogramowanie po stronie serwera zmieni te połączenia (co mam duże wątpliwości). Korzyścią jest to, że algorytm będzie działał nawet po utracie pakietów, podczas gdy initcwnd nie będzie odgrywał dużej roli.

/ proc / sys / net / ipv4 / tcp_congestion_control to miejsce, w którym zmieniasz algorytm kontroli przeciążenia.

FWIW dla tak małych RTT (50ms) oraz dla średnich i dużych plików initcwnd nie powinien mieć większego wpływu na średnią prędkość. Jeśli nie nastąpi utrata pakietów, wówczas (np. Gruba rura) cwnd będzie podwajał się przy każdym RTT. Z RTT = 50 ms na grubej rurze, w pierwszej sekundzie zmieścisz 20 RTT, co oznacza, że ​​przy initcwnd = 2 skończysz z cwnd = 2 * 2 ^ 20 po 1 sekundzie, co, założę się, jest więcej niż możesz uchwyt ;-)