Wydajność transmisji TCP w sieciach WAN

Wydajność transmisji TCP w sieciach WAN Mariusz Krukowski mariusz.krukowski@gtsce.com GTS CE Network Architecture and Development PLNOG, Warszawa 2012

Problemy z transmisją TCP Typowe źródła problemów z transmisją TCP Zatłoczona sieć Zbyt mała wydajność urządzeń sieciowych Uszkodzone łącza, porty, etc. Jednak czasem problemy pojawiają się, nawet gdy Sieć jest bardzo daleka od stanu wysycenia Pomiar dokonywany sprzętowym miernikiem (strumieniem pakietów) nie wykazuje żadnych strat, a parametry serwisu są zgodne z SLA A mimo to, transmisja TCP nie osiąga oczekiwanej wydajności. Dotyczy zwykle transmisji do lub od wszystkich hostów, ale czasem tylko konkretnych lokalizacji.

Agenda Podstawy TCP Sub-rate link Token Bucket Shaper Token Bucket Policer Wpływ dodatkowego ruchu

Podstawy TCP Prezentacja ta dotyczy transmisji danych (bulk transmission) Datagramy z danymi (segmenty) wysłane przez nadawcę, są potwierdzane przez odbiorcę pakietami ACK. Pakiety ACK informują nadawcę, jak duży spójny blok danych zgromadził odbiorca od rozpoczęcia transmisji. Nadawca wysyła większą grupę segmentów, posługując się procedurą przesuwanego okna nadawania (TCP Sliding Window). Blok danych znajdujący się w obrębie okna jest natychmiast wysyłany. Gdy przybywają pakiety ACK, początek okna jest przesuwany na koniec bloku danych, potwierdzonych przez odbiorcę jako otrzymane. Okno nasuwa się przy tym nad kolejną porcję danych; zostają one niezwłocznie wysłane. Rozmiar okna nadawania, czyli ilość danych wysłana do odbiorcy i jeszcze nie potwierdzona, przyjmuje mniejszą z dwóch wartości: wyliczanego przez nadawcę Congestion Window (CWND) oraz Receiver Window (RWND), sygnalizowanego w pakietach ACK przez odbiorcę (uwaga na Window Scaling!) CWND jest obliczany przy pomocy Congestion Avoidance Algorithm, poprzez analizę bieżących warunków transmisji: strat pakietów, RTT, etc.

Podstawy TCP c.d. CWND jest zwiększane przez nadawcę, gdy oszacowane warunki transmisji są dobre, i zmniejszane gdy są złe. Celem jest osiągnięcie optymalnej transmisji, dopasowanej do aktualnej sytuacji w sieci. Problem w tym, że wynik takiego oszacowania jest często daleki od doskonałości...... I rozmiar Congestion Window często nie jest doszacowany. W efekcie, nadawca traci czas niepotrzebnie zawieszając transmisję i obniżając średnią przepływność. Gwoli sprawiedliwości, szacowanie jest trudne: Nadawca nie zna prawdziwej sytuacji w sieci, wnioskowanie jest pośrednie I często musi je przeprowadzać niezależnie dla setek lub tysięcy sesji TCP jednocześnie, zapewniając ich równe traktowanie! Dlatego istnieją liczne Congestion Avoidance Algorithms, udoskonalane od lat. Niestety, wiele z nich bazuje na założeniach już nieaktualnych w dzisiejszym sieciach, lub przeciwnie nie są dostosowane do nowych sytuacji...

Warunki testów Celem przeprowadzonych testów było odtworzenie problemów pojawiających się w rzeczywistej sieci. Zostały one przeprowadzone w kontrolowanym środowisku (w laboratorium), by wyizolować źródło problemu i uczynić go powtarzalnym. Wnioski potwierdzono następnie w rzeczywistej sieci. Wyniki przedstawione w tej prezentacji zostały uzyskane w środowisku testowym, które zostało ograniczone do elementów niezbędnych do uchwycenia natury problemu. W trakcie testów, w laboratorium generowany był wyłącznie ruch związany z przeprowadzanym eksperymentem (zwykle 1 sesja TCP).

Warunki testów c.d. Testy transmisji TCP przeprowadzono z użyciem hostów na platformach PC, z portami 10/100/1000BaseT Congestion Avoidance Algorithm: CUBIC Włączone SACK i Window Scaling Wyłączony TCP offloading MTU 1500B (maksymalny rozmiar pakietu IPv4 użyty w testach) Sesja TCP generowana programem iperf Emulacja opóźnień WAN: qdisc (po stronie nadawcy i odbiorcy) Urządzenia sieciowe Użyto standardowych mechanizmów do ograniczania ruchu Upewniono się, że mechanizmy te funkcjonują zgodnie ze standardami, a problemy nie są wynikiem implementacji specyficznej dla konkretnego producenta

Sub-rate link Standardy Ethernet definiują porty o ściśle określonych przepustowościach: 10Mbps, 100Mbps, 1Gbps, 10Gbps, 40Gbps, 100Gbps W wielu przypadkach, szczególnie transmisji WAN, ten zestaw przepustowości jest zbyt mało elastyczny Pojawia się koncepcja łącza sub-rate: wyposażonego w porty ethernet, ale oferującego mniejszą przepustowość (np. system transmisyjny zakończony portami GE, ale korzystający z transportu po STM-1, czyli oferujący przepustowość około 150 Mbps) Technologia popularna szczególnie dla zaoferowania ostatniej mili Łącza EoSDH, EoRadio (p-t-p i p-t-mp), VDSL, i inne. Problem 1: bardzo często część systemu związana z obsługą ethernetu jest traktowana przez producenta po macoszemu : brak podstawowej diagnostyki, tanie układy z małym buforem, brak OAM, etc. Problem 2: urządzenia korzystające z łącza sub-rate, same nie dowiedzą się jaka jest oferowana przepustowość

Rzeczywiste serwisy Nadawca, a często i odbiorca, podłączeni do LAN szybkimi portami, np. GE (1Gbps) Na ścieżce między nimi jest łącze sub-rate (na rysunku jest to last-mile do odbiorcy, ale może pojawić się też w innym miejscu), również wyposażone w szybkie porty ethernet Urządzenia podłączone do sub-rate link często nie są informowane o zmniejszonej przepustowości

Symulacja w laboratorium Nadawca i odbiorca podłączeni portami GE (1Gbps) Pomiędzy nimi sub-rate link, symulowany na FE (100Mbps) Urządzenie przesyłające ruch od nadawcy do odbiorcy, ma wyjściowy bufor na porcie FE zmniejszony do 8KB Test pojedynczą sesją TCP, o czasie trwania 30 sekund

Wyniki 100% Średnia przepływność (Osiągnięty procent przepustowości sub-rate) 90% 80% 70% 60% 50% 40% RTT 0,4 ms RTT 10,5 ms RTT 20,5 ms 30% 20% 10% 0% W trakcie każdego testu, transmisja TCP trwała 30 sekund Obserwowany jest spadek przepływności sesji TCP, wraz ze wzrostem RTT

Wyniki c.d. 5000 Liczba zgubionych pakietów (czas trwania sesji TCP: 30sec) 4500 4000 3500 3000 2500 2000 RTT 0,4 ms RTT 10,5 ms RTT 20,5 ms 1500 1000 500 0 Częstość gubienia pakietów spada wraz ze wzrostem RTT, ale też transmitowana jest mniejsza ilość danych w jednostce czasu

RTT 0,4ms

RTT 0,4ms Regularne retransmisje, spowodowane gubieniem pakietów (buffer tail-drop)

RTT 10,5ms

RTT 10,5ms RTT

Zachowanie TCP przy dużym RTT Większy RTT sprawia, że nadawca odbiera pakiety ACK z większym opóźnieniem Procedura slow-start próbkuje warunki panujące na ścieżce. W jej trakcie nadawca wysyła coraz większe bursty segmentów, zwiększając CWND. Przed rozpoczęciem nadawania kolejnego bursta, musi poczekać na potwierdzenie choć jednego segmentu z poprzedniego. Gdy rośnie RTT, ACK są już tak opóźnione, że nadawca nie otrzyma ani jednego potwierdzenia dla segmentów wysyłanych w ramach obecnego bursta. W konsekwencji, wzmacniany jest efekt przepływu z oscylacjami : transmisja TCP od nadawcy do odbiorcy składa się z kolejnych burstów, nadawanych w odstępach zbliżonych do RTT Przepływność sesji TCP jest mała, bo przez większość czasu nadawca nic nie wysyła

Zachowanie TCP przy dużym RTT Nadawca stara się zwiększyć rozmiar bursta poprzez zwiększenie CWND: zarówno w fazie slow-start, jak i congestion avoidance Ze wzrostem rozmiaru bursta, rośnie wypełnienie bufora łącza sub-rate W końcu bufor przepełnia się i jest gubiony pakiet W ACK od odbiorcy, nadawca dostaje powiadomienie o utraconym segmencie. Wysyła go ponownie przy użyciu procedury fast retransmission i fast recovery. Niestety, zmniejsza też CWND. Ten proces powtarza się regularnie. W efekcie, CWND nigdy nie rośnie na tyle, by efektywnie zwiększyć przepływność sesji TCP, przez wydłużenie burstów i wypełnienie luk między nimi

Wyniki z shaping iem 120% Średnia przepływność (Porównanie bez shapingu i z shapingiem) 100% 80% 60% 40% RTT 0,4 ms RTT 10,5 ms RTT 20,5 ms 20% 0% Transfer [%] Transfer z shapingiem [%] Shaping ustawiony na PE, na porcie GE, przyjmującym ruch od nadawcy Ustawiona przepustowość: 100Mbps (w L1, burst 1514B) Po włączeniu shapingu, wyniki transferu są znacznie bliższe przepustowości 100Mbps. W przypadku CUBIC i dużych RTT, zbliżenie się do 100% zajmuje więcej niż czas trwania testu (30 sekund)

Dlaczego shaping pomaga? RTT 10,5ms + shaping Widok od strony nadawcy

RTT 10,5ms + shaping Początek sesji TCP (slow-start) Oscylacje z okresem RTT są wyraźnie widoczne CWND rośnie i wzrasta długość burstów; bufor shapera jest większy i absorbuje więcej pakietów Ale to nie wszystko... Kolejne bursty coraz bardziej pochylają się

RTT 10,5ms + shaping

RTT 10,5ms + shaping Faza ustabilizowanej transmisji (congestion avoidance) Bursty rozmywają się Transmisja przybiera formę przepływu gładkiego

Dlaczego shaping pomaga? Duży bufor shapera jest pomocny w początkowej fazie (slow-start), by uniknąć strat pakietów, przy szybko rosnących burstach Bardzo ważne jest opóźnianie pakietów przez shaper, poprzez zwiększanie odstępów między nimi A gdy kolejne pakiety od nadawcy do odbiorcy są opóźniane i dzięki temu rozkładane w czasie, to również ich potwierdzenia (ACK) są podobnie rozkładane w czase przez odbiorcę. Z kolei nadawca uzależnia nadawanie kolejnych segmentów od otrzymywanych ACK. Im bardziej rozłożone w czasie ACK, tym bardziej rozłożone w czasie segmenty wysyłane przez nadawcę (bo okno nadawania przesuwa się stopniowo). Nadawca synchronizuje się do odbiorcy (bezpośrednio), a faktycznie do shapera (pośrednio). Literatura nt. TCP nazywa ten efekt self-clocking. Powstaje silne sprzężenie zwrotne, które ostatecznie prowadzi do wygładzenia burstów i przejścia sesji TCP w stan przepływu gładkiego, z przepływnością zbliżoną do przepustowości ścieżki (tu: łącza sub-rate)

Dlaczego shaping pomaga? c.d. CWND staje się bliskie pojemności ścieżki (bandwidth-delay product), czyli w tym wypadku wartości PIR RTT Z punktu widzenia sieci, burstów już nie ma, bo pakiety są wysyłane nie szybciej niż wynosi przepływność ścieżki; nie akumulują się one w buforze i nie ma ryzyka strat i retransmisji Pełne wygładzenie przepływu wymaga czasu, zależnego od przepustowości ścieżki, RTT oraz wersji stosu TCP A dlaczego był tu potrzebny shaper? Łącze sub-rate przecież też zwiększa odstęp między pakietami....bo bufor łącza sub-rate był zbyt mały. Bez (większego) buforu shapera, utracone pakiety zmniejszały CWND, a bursty nie trwały dostatecznie długo, by zainicjować przejście do stanu przepływu gładkiego. W efekcie, nie zostało osiągnięte dopasowanie tempa nadawania do przepustowości ścieżki i sesja TCP pozostała w stanie przepływu z oscylacjami

Token Bucket Shaper Czasem pojawiają się zgłoszenia o kiepskiej wydajności TCP, pomimo użycia shapera Nie widać żadnych strat pakietów w sieci (pingi, obserwacja liczników); faktycznie, obciążenie sieci wzdłuż ścieżki jest małe Śledztwo wykazuje, że za siecią, na ścieżce znajduje się łącze sub-rate Tyle, że przed łączem sub-rate jest tu shaper, i ma on ustawiony PIR na przepustowość nie większą niż sub-rate. Strumień pakietów powinien być więc wygładzony i łącze sub-rate nie powinno nic gubić. Pierwszy podejrzany: Może sieć, mimo małego obciążenia, wprowadza jitter, który zagęszcza pakiety? Ale to zły trop...

Symulacja w Laboratorium Sieć jest zredukowana do dwóch urządzeń (ta sama platforma co w oryginalnym zgłoszeniu problemu); nie ma innego ruchu który wprowadzałby jitter Wąskim gardłem jest łącze sub-rate, symulowane na łączu Fast Ethernet (FE), z buforem zmniejszonym do 8KB Przed wejściem w łącze FE, ruch od nadawcy trafia na shaper z ustawionym PIR 100 Mbps Pozostałe ustawienia shapera są domyślne To jest inna platforma, niż użyta wcześniej w przykładach łącza sub-rate. (Shaper był tam zaimplementowany inaczej)

Wyniki 120% Średnia przepływność sesji TCP (Procent PIR ustawionego dla shapera) 100% 80% 60% 40% RTT 0,4 ms RTT 10,5 ms RTT 20,5 ms 20% 0% 10Mbps MBS 32KB 20Mbps MBS 64KB 50Mbps MBS 64KB 100Mbps MBS 128KB Ta platforma sama ustawia rozmiar MBS dla shapera, zależnie od PIR Wyniki z użyciem shapera z PIR 100 Mbps, praktycznie nie różnią się od wyników osiągniętych bez shapera! Dla porównania, wyniki dla PIR mniejszych niż sub-rate; z wyjątkiem PIR 10Mbps, też wygląda to kiepsko...

PIR 100 Mbps oraz RTT 10,5 ms Nie tylko wynik jest taki sam jak dla przypadku bez shapera. Wykres też wygląda tak samo... (por. wykres dla RTT 10,5 ms w sekcji o łączach sub-rate)

PIR 100 Mbps oraz RTT 10,5 ms Tu ewidentnie widać straty na buforze oraz przepływ z oscylacjami. A gdzie jest shaping?

Początek sesji TCP, PIR 10 Mbps RTT 0,5 ms, tylko łącza GE Rozpoczęcie shapingu MBS 32 KB

Początek sesji TCP, PIR 100 Mbps RTT 0,5 ms, tylko łącza GE Rozpoczęcie shapingu MBS 128 KB

Token Bucket Shaper Token Bucket Shaper wykorzystuje algorytm token bucket Rozmiar token bucket określony jest przez MBS MBS nie ma związku z długością kolejki, wykorzystywanej przez shaper! Gdy pakiet przechodzi przez shaper, sprawdzany jest stan token bucket Jeśli token bucket ma co najmniej tyle kredytu, by starczyło dla pakietu, to pakiet jest przepuszczany natychmiast, a stan token bucket pomniejszany o taką liczbę oktetów, jaka była długość pakietu Jeśli token bucket nie ma wystarczającego kredytu, pakiet jest zatrzymywany na końcu kolejki shapera Pakiet czekający na początku kolejki jest wysyłany, gdy token bucket otrzyma wystarczający kredyt Tempo odnawiania kredytu jest określone przez PIR Idea jest taka, by ruch o krótkich burstach (np. Video) przepuszczać bez opóźnień

Token Bucket Shaper c.d. Implementacja może różnić się dla różnych platform wielkością MBS W tym wypadku okazało się, że MBS jest automatycznie dobierany tak, by shaper przepuszczał bursty o czasie trwania około 8 ms, przy czym wielkość MBS jest wyrażona w KB, a jej wartość jest zaokrąglana do potęg dwójki Niektóre platformy nie pozwalają na samodzielne ustawienie MBS, albo nakładają dolne ograniczenie na jego rozmiar W przypadku symulacji w Laboratorium z łączem sub-rate FE i shaperem 100 Mbps, była olbrzymia dysproporcja między rozmiarem bufora sub-rate (8 KB), a wielkością MBS (128 KB) Efekt: shaper nigdy nie zaczął wygładzać burstów Nawet dla PIR mniejszych niż przepustowość FE (na przykład 50 Mbps), MBS był zbyt duży, by shaping był efektywny W części prezentacji na temat łącz sub-rate, w trakcie testów użyty został shaper z MBS 1514B

Token Bucket Policer Zdefiniowany w RFC 2697 (A Single Rate Three Color Marker) oraz w RFC 2698 (A Two Rate Three Color Marker) Narzędzie wymyślone do przypisywania pakietów lub ramek do różnych CoS, oraz do kontroli czy poziom ruchu nie przekracza dozwolonego poziomu. Przed dotarciem do policera, strumień pakietów powinien zostać ukształtowany przez shaper. Policer jest znacznie prostszy i tańszy w implementacji niż shaper; w niektórych sytuacjach jest jedynym dostępnym narzędziem QoS Często jest więc wykorzystywany zamiast shapera, do przycinania ruchu do zadanej przepustowości CIR lub PIR: ruch poniżej CIR (lub PIR) jest natychmiast przepuszczany ruch powyżej CIR (lub PIR) jest natychmiast usuwany Decyzja podejmowana jest na podstawie aktualnych stanów token bucket, o rozmiarach CBS (dla CIR) lub MBS (dla PIR). Token bucket to tylko licznik, nie bufor!

Rzeczywiste serwisy Nadawca podłączony do LAN szybkim portem, np. GE Strumień pakietów wysłanych przez nadawcę, dociera do urządzenia sieciowego (NE) w niezmienionej formie (brak shapingu) NE przycina ten strumień policerem do zadanej przepustowości

Symulacja w laboratorium Konfiguracja uproszczona: sieć WAN zredukowana do jednego NE Nadawca i odbiorca podłączeni do NE łączami GE NE ogranicza policerem przepustowość dla ruchu przychodzącego od nadawcy Przepustowość kontrolowana przy pomocy PIR MBS = 96KB Test pojedynczą sesją TCP, o czasie trwania 30 sekund

Wyniki 120% Średnia przepływność (Procent PIR) 100% 80% 60% 40% RTT 0,2 ms RTT 10,3 ms RTT 20,3 ms 20% 0% 2Mbps 10Mbps 20Mbps 50Mbps 100Mbps 200Mbps Na wykresie powyżej, przedstawione są wyniki dla różnych PIR (wartości Mbps pod osią poziomą), dla trzech różnych RTT Zgodnie z oczekiwaniami, wyniki dla RTT 20ms są gorsze niż dla RTT 10ms Przy ustalonym MBS, nie dziwi też spadek efektywności policera dla rosnącego PIR Ale skąd się bierze dołek wokół PIR 20Mbps, dla małego RTT?

PIR 20 Mbps oraz RTT 0,2 ms 40 ms 200 ms >> RTT = 0,2 ms

Dlaczego tak się dzieje? Jest to efekt działania policera i jego interakcji z dwoma timeout ami: Min RTO = 200 ms Delayed ACK Timeout = 40 ms To są wartości charakterystyczne dla Linux; dla innych systemów mogą być nieco inne, co będzie skutkowało innymi przepływnościami TCP.

Jak to wygląda w mikroskali? Policer początkowo przepuszcza wszystkie pakiety z taką przepływnością, z jaką były wysyłane przez nadawcę. Gdy kończy się kredyt w token bucket, nagle zaczyna odrzucać pakiety z końcówki bursta. Odbiorca nic o tym nie wie; dotąd dostawał serię segmentów, które normalnie potwierdzał przy pomocy ACK. Gdy kolejne segmenty przestają napływać, wydaje mu się, że ostatni burst już się skończył, więc czeka na następny. Nadawca dostawał potwierdzenia dla wysyłanych segmentów. W pewnym momencie ACK przestały docierać. Kończy wysyłanie bursta, o wielkości określonej przez bieżący CWND i teraz czeka na potwierdzenia. Ale kolejne ACK nie napłyną, bo w ogóle nie zostały wysłane. Obie strony czekają, aż nastąpi timeout. W trakcie oczekiwania, token bucket odtwarza swój kredyt: w całości (200ms) lub częściowo (40ms) Cykl się powtarza.

Timeout Jest kilka możliwości: Policer nagle odcina całą końcówkę bursta Wtedy następuje oczekiwanie, w tym wypadku min RTO = 200 ms, po którym nadawca ponownie wysyła nie potwierdzone segmenty. Policer zaczyna odrzucać końcówkę bursta, ale burst jest jeszcze na tyle długi, że token bucket w międzyczasie dostaje trochę kredytu na kolejny pakiet Wtedy odbiorca orientuje się, że czegoś zabrakło, i powiadamia nadawcę. Jeśli dotarły dwa pakiety z końcówki bursta, to generowane są Triple Duplicate ACK i nadawca ponownie wysyła brakujący segment. Tyle że policer znów nie ma kredytu i blokuje retransmitowany segment. Ostatecznie, odbiorca nic nie dostaje, a nadawca bezskutecznie czeka na potwierdzenie (w tym przypadku, aż upłynie min RTO). Jeśli wykorzystywane są opóźnione potwierdzenia (Delayed ACK), może się zdarzyć, że na końcu przepuszczonej części bursta, odbiorca dostanie jeden segment bez pary Wtedy odbiorca czeka na drugi segment do pary, a ponieważ ten nie dociera, po upływie Delayed ACK Timeout (tu: 40ms) potwierdzi ostatni otrzymany segment, dzięki czemu nadawca ponownie wysyła niepotwierdzone dotąd segmenty.

A co z innymi PIR? Dlaczego w takim razie nie ma takich problemów dla PIR znacząco mniejszego i znacząco większego od 20 Mbps? Czy wtedy timeout się nie pojawia? I tak, i nie...

PIR 2 Mbps oraz RTT 0,2 ms Nadal pojawiają się takie same timeout y! A mimo to, średnia przepływność osiąga (nawet przekracza) PIR

PIR 2 Mbps oraz RTT 0,2 ms 40 ms 200 ms MBS = 96 KB To jest rozpoczęcie sesji TCP, z punktu widzenia nadawcy

PIR 2 Mbps oraz RTT 0,2 ms W takim razie, dlaczego osiągnięta została wysoka przepływność? PIR został nawet lekko przekroczony! Dlatego, że PIR jest tu na tyle mały, iż nawet wliczając długie okresy ciszy, przesłane bursty wystarczą do osiągnięcia średniej przepływności, wyznaczonej przez PIR

PIR 50 Mbps oraz RTT 0,2 ms Czyżby gładki przepływ? Nie!

PIR 50 Mbps oraz RTT 0,2 ms Początek sesji TCP wygląda dobrze...

PIR 50 Mbps oraz RTT 0,2 ms...ale dalej, policer już daje o sobie znać

PIR 50 Mbps oraz RTT 0,2 ms Tu, PIR jest na tyle duży, że token bucket jest uzupełniany na bieżąco. Nawet jeśli zabraknie tokenu dla pojedynczego pakietu, to kolejny pakiet zostanie przepuszczony. Wtedy odbiorca dostrzega brak utraconego segmentu i szybko prosi nadawcę o jego retransmisję. Jako że RTT jest mały, nadawca szybko otrzymuje ACK, o odbiorca szybko otrzymuje ponownie wysłany segment. Utrata pakietów zdarza się jednak bardzo często i CWND pozostaje w granicach: 1, 2 lub 3 segmenty. Efekt: wydajność sesji TCP jest znacząco większa niż dla PIR 20 Mbps, i rośnie ze wzrostem PIR (dla PIR 200 Mbps zbliża się do 100%). Dzieje się tak dzięki temu, że straty pakietów są częste, ale za to gubiony jest tylko jeden pakiet na raz.

PIR 20 Mbps oraz RTT 10,3 ms RTT

PIR 20 Mbps oraz RTT 10,3 ms Formuje się przepływ z oscylacjami, jaki już widzieliśmy dla dużego RTT Efekt jest nawet silniejszy, bo nie ma tu żadnego mechanizmu, który zwiększyłby odstępy między pakietami. Segmenty docierają do odbiorcy w postaci burstów, powodując odesłanie serii ACK też w postaci burstów. W efekcie, nadawca przesuwa okno nadawania gwałtownie do przodu, generując kolejny burst. Duży RTT stabilizuje sesję TCP i zapobiega timeout om Duży RTT sprawia, że CWND rośnie wolniej Tempo uzupełniania token bucket jest takie samo (z definicji równe PIR) Pojedyncze bursty są rozdzielone przerwami RTT; deficyt token bucket jest więc zawsze bardzo mały lub żaden Raz na jakiś czas, policer gubi 1-2 segmenty z końca bursta, więc odbiorca ich nie potwierdzi Po czasie RTT/2, nadawca dostaje ACK dla wcześniejszych segmentów i zaczyna wysyłanie kolejnego bursta Odbiorca dostaje pierwsze segmenty kolejnego bursta po kolejnym RTT/2; od razu zauważa brak segmentów odrzuconych przez policer i powiadamia o tym nadawcę Nadawca dostaje tę informację po kolejnym RTT/2 i dosyła brakujące segmenty Odbiorca dostaje je po kolejnym RTT/2, czyli po czasie 2*RTT od nadejścia bursta, do którego pierwotnie należały

PIR 20 Mbps oraz RTT 10,3 ms Brakujące segmenty docierają do odbiorcy po upływie 2 * RTT

Jeszcze ciekawostka... Ponownie PIR 20 Mbps i RTT 0,2 ms To efekt dodanego shapingu (PIR 20 Mbps i MBS 1514B) Ale ten shaping działał tu po policerze! Wygładzenie przepływu jest wynikiem silnego sprzężenia zwrotnego Efekt wygładzenia przepływu wystąpi również dla dużego RTT

Wpływ innego strumienia danych Przykład dla usług IP lub Carrier Ethernet CE obsługuje więcej niż jeden serwis Użyte jest łącze sub-rate W tym wypadku, CE portrafi robić shaping tylko zbiorczo, dla wszystkich serwisów (1-level QoS lub 2-level QoS) CE kontroluje przepustowość poszczególnych serwisów przy pomocy policerów (przed zbiorczym shapingiem) Nie ma shapingu dla poszczególnych serwisów

Symulacja w Laboratorium Shaper na CE ma skonfigurowany PIR 40 Mbps i MBS 2048B Policer uruchomiony jest tylko dla serwisu z TCP, i ma skonfigurowany PIR 20 Mbps oraz MBS 64KB Streaming jest opcjonalnie włączany w drugim serwisie; jest to strumień pakietów IP (1500B), równomiernie wysyłanych z przepływnością 20 Mbps

Wyniki dla RTT 0,5 ms 1. Sama transmisja TCP; streaming wyłączony Średnia przepływność TCP w teście 30 sekundowym: 5 Mbps Wynik nie zaskakuje to jest efekt działania policera, prowadzący do timeout ów 2. Działają obie usługi: TCP i streaming Średnia przepływność TCP w teście 30 sekundowym: 18,8 Mbps Dlaczego przepływność wzrosła, gdy wzrosło obciążenie łącza?...bo dodatkowy ruch ustabilizował sesję TCP Pakiety streamingu wciskają się pomiędzy pakiety sesji TCP i opóźniają je, zwiększając odstępy czasowe między segmentami Opóźnione segmenty opóźniają też ACK, umożliwiając nadawcy dopasowanie tempa nadawania do dostępnej przepustowości To wystarcza, by sesja TCP przeszła w stan przepływu gładkiego

Sesja TCP, gdy aktywny jest streaming

Podsumowanie TCP jest protokołem o skomplikowanych interakcjach, a jego zachowanie czasem przeczy intuicji Jak widzieliśmy w ostatnim przykładzie, wyłączenie innego ruchu na łączu, i testowanie jednego z serwisów sesją TCP (powszechna praktyka oczyszczenia łącza ) może czasem pogorszyć sytuację; podobnie, zwiększenie przepustowości łącza (aczkolwiek ten przykład jest raczej wyjątkowy) Na wydajność sesji TCP wpływa bardzo wiele czynników: stan WAN, ale też narzędzia QoS, stan LAN, urządzenia końcowe, etc. Problemy z transmisją przez WAN mogą wynikać z problemów w LAN lub na hostach, ale ujawniają się przy wzroście RTT lub w wyniku użycia narzędzi QoS. Mimo to, częsta jest praktyka testowania jakości (łącza, ścieżki, Internetu), poprzez zestawienie jednej sesji TCP do konkretnej lokalizacji, używając przypadkowych komputerów, i przyjmowania wyniku jako wyznacznika jakości usługi. Jest to powód, dla którego w trakcie zaprezentowanych testów także zestawiano zwykle jedną sesję TCP. Wyniki zmienią się w obecność innych sesji TCP lub innego ruchu. Niekoniecznie na gorsze... Problem wydajności leży w samym TCP: najpierw zbyt agresywnie zapycha ruchem ścieżkę, a później za bardzo się wycofuje. Ale takie są założenie projektowe TCP.

Warto poczytać... RFC 6349 Framework for TCP Throughput Testing RFC 5681 TCP Congestion Control Dokument MEF: Understanding Carrier Ethernet Throughput

Pytania?