konwencja nazewnictwa algorytmów kontroli zatorów (CCAs) mogła powstać w 1996 roku w pracy Kevina Fall ’ a i Sally Floyd.

poniżej przedstawiono jedną z możliwych klasyfikacji według następujących właściwości:

1. typ i ilość informacji zwrotnych otrzymanych z sieci
2. przyrostowa możliwość wdrożenia w bieżącym Internecie
3. aspekt wydajności, który ma na celu poprawę: sieci produktowe o wysokiej przepustowości (B); łącza stratne (L); uczciwość (F); przewaga nad krótkimi przepływami (s); łącza o zmiennej szybkości (V); szybkość konwergencji (C)
4. kryterium uczciwości, które stosuje

niektóre dobrze znane mechanizmy unikania zatorów są klasyfikowane według tego schematu w następujący sposób:

d

Variant	Feedback	Required changes	Benefits	Fairness
(New) Reno	Loss	—	—	Delay
Vegas	Delay	Sender	Less loss	Proportional
High Speed	Loss	Sender	High bandwidth
BIC	Loss	Sender	High bandwidth
CUBIC	Loss	Sender	High bandwidth
C2TCP	Loss/Delay	Sender	Ultra-low latency and high bandwidth
NATCP	Multi-bit signal	Sender	Near Optimal Performance
Elastic-TCP	Loss/Delay	Sender	High bandwidth/short & long-distance
Agile-TCP	Loss	Sender	High bandwidth/short-distance
H-TCP	Loss	Sender	High bandwidth
FAST	Delay	Sender	High bandwidth	Proportional
Compound TCP	Loss/Delay	Sender	High bandwidth	Proportional
Westwood	Loss/Delay	Sender	L
Jersey	Loss/Delay	Sender	L
BBR	Delay	Sender	BLVC, Bufferbloat
CLAMP	Multi-bit signal	Receiver, Router	V	Max-min
TFRC	Loss	Sender, Receiver	No Retransmission	Minimum delay
XCP	Multi-bit signal	Sender, Receiver, Router	BLFC	Max-min
VCP	2-bit signal	Sender, Receiver, Router	BLF	Proportional
MaxNet	Multi-bit signal	Sender, Receiver, Router	BLFSC	Max-min
JetMax	Multi-bit signal	Sender, Receiver, Router	High przepustowość	Max-min
czerwony	strata	Router	zmniejszone opóźnienie
ECN	sygnał jednobitowy	nadawca, Odbiornik, Router

TCP Tahoe i renoedit

algorytmy TCP Tahoe i Reno zostały nazwane retrospektywnie od wersji lub smaków systemu operacyjnego 4.3 BSD, w którym każdy z nich pojawił się po raz pierwszy (które zostały nazwane po Jezioro Tahoe i pobliskie Miasto Reno w stanie Nevada). Algorytm Tahoe po raz pierwszy pojawił się w 4.3 BSD-Tahoe (który został stworzony do obsługi minikomputera CCI Power 6/32 „Tahoe”), a później został udostępniony licencjobiorcom spoza AT&T jako część 4.3 BSD Networking Release 1; zapewniło to jego szeroką dystrybucję i implementację. Ulepszenia zostały wprowadzone w 4.3 BSD-Reno, a następnie udostępnione publicznie jako Networking Release 2, a później 4.4 BSD-Lite.

podczas gdy obie strony uważają retransmission timeout (RTO) i duplicate ACK za zdarzenia utraty pakietów, zachowanie Tahoe i Reno różni się przede wszystkim tym, jak reagują na duplikaty ACK:

• Tahoe: jeśli odebrane zostaną trzy duplikaty ACK (tj. cztery ACK potwierdzające ten sam pakiet, które nie są obciążone danymi i nie zmieniają reklamowanego okna odbiornika), Tahoe wykonuje szybki retransmit, ustawia próg powolnego startu na połowę bieżącego okna przeciążenia, zmniejsza wartość okno przeciążenia do 1 MSS i resetuje do stanu wolnego startu.
• Reno: jeśli zostaną odebrane trzy duplikaty ACK, Reno wykona szybki retransmit i pominie fazę powolnego startu, zmniejszając o połowę okno zatorów (zamiast ustawiać je na 1 MSS, jak Tahoe), ustawiając próg wolnego startu równy nowemu oknu zatorów i wchodząc w fazę zwaną szybkim odzyskiwaniem.

zarówno w Tahoe, jak i w Reno, jeśli przekroczony jest czas ACK (RTO timeout), używany jest powolny start, a oba algorytmy zmniejszają okno przeciążenia do 1 MSS.

TCP VegasEdit

do połowy lat 90.wszystkie ustawione przez TCP timeouty i zmierzone opóźnienia w obie strony były oparte tylko na ostatnim przesyłanym pakiecie w buforze transmisji. Naukowcy z University of Arizona Larry Peterson i Lawrence Brakmo wprowadzili TCP Vegas (nazwane na cześć Las Vegas, największego miasta w Nevadzie), w którym ustalono limity czasowe i zmierzono opóźnienia w obie strony dla każdego pakietu w buforze transmisji. Ponadto TCP Vegas wykorzystuje dodatkowe wzrosty w oknie zatorów. W badaniu porównawczym różnych CCP, TCP Vegas wydaje się być najłagodniejszym, a następnie TCP CUBIC.

TCP Vegas nie był szeroko wdrażany poza laboratorium Petersona, ale został wybrany jako domyślna metoda kontroli zatorów dla DD-WRT firmware v24 SP2.

TCP New RenoEdit

TCP New Reno, zdefiniowany przez RFC 6582 (przestarzałe definicje w RFC 3782 i RFC 2582), poprawia retransmisję podczas fazy szybkiego odzyskiwania TCP Reno. Podczas szybkiego odzyskiwania, aby okno transmisji było pełne, dla każdego zwracanego duplikatu ACK wysyłany jest nowy niewysłany pakiet z końca okna przeciążenia. Dla każdego ACK, który wykonuje częściowy postęp w przestrzeni sekwencji, nadawca zakłada, że ACK wskazuje na nową dziurę, a następny pakiet poza numerem sekwencji ACK jest wysyłany.

ponieważ timeout jest resetowany za każdym razem, gdy w buforze transmisji jest postęp, nowe Reno może wypełnić duże dziury lub wiele otworów w przestrzeni sekwencji – podobnie jak TCP SACK. Ponieważ nowe Reno może wysyłać nowe pakiety na końcu okna przeciążenia podczas szybkiego odzyskiwania, wysoka przepustowość jest utrzymywana podczas procesu napełniania otworów, nawet gdy istnieje wiele otworów, z których każdy zawiera wiele pakietów. Kiedy TCP wchodzi w tryb fast recovery, zapisuje najwyższy niezauważony numer sekwencji pakietów. Gdy ten numer sekwencji zostanie potwierdzony, TCP powróci do stanu unikania zatorów.

problem występuje w przypadku New Reno, gdy nie ma strat pakietów, ale zamiast tego pakiety są uporządkowane o więcej niż 3 numery sekwencji pakietów. W tym przypadku New Reno błędnie wprowadza szybkie odzyskiwanie. Po dostarczeniu ponownie uporządkowanego pakietu następuje postęp liczby sekwencyjnej ACK i stamtąd aż do końca szybkiego odzyskiwania, cały postęp liczby sekwencyjnej tworzy duplikat i niepotrzebną retransmisję, która jest natychmiast ACKed.

New Reno działa tak samo jak SACK przy niskich błędach pakietów i znacznie przewyższa Reno przy wysokich błędach.

TCP HyblaEdit

tcp Hybla ma na celu wyeliminowanie sankcji dla połączeń TCP, które zawierają połączenia radiowe naziemne lub satelitarne o wysokim opóźnieniu. Ulepszenia Hybla opierają się na analitycznej ocenie dynamiki okna przeciążenia.

TCP BICEdit

Binary Increase Congestion control (BIC) jest implementacją TCP ze zoptymalizowanym CCA dla szybkich sieci z dużym opóźnieniem, znanych jako długie sieci fat. BIC jest domyślnie używany w jądrach Linuksa od 2.6.8 do 2.6.18.

TCP CUBICEdit

CUBIC jest mniej agresywną i bardziej systematyczną pochodną BIC, w której okno jest sześcienną funkcją czasu od ostatniego zdarzenia przecięcia, z punktem przegięcia ustawionym na okno przed zdarzeniem. CUBIC jest domyślnie używany w jądrach Linuksa pomiędzy wersjami 2.6.19 i 3.2.

Agile-SD TCPEdit

Agile-SD jest CCA opartym na Linuksie, który jest przeznaczony dla prawdziwego jądra Linuksa. Jest to algorytm po stronie odbiornika, który wykorzystuje podejście oparte na stratach, wykorzystując nowatorski mechanizm, zwany współczynnikiem zwinności (Af). aby zwiększyć wykorzystanie przepustowości w sieciach szybkich i krótkich (sieci o niskiej przepustowości), takich jak sieci lokalne lub sieć światłowodowa, zwłaszcza gdy zastosowany rozmiar bufora jest mały. Został oceniony przez porównanie jego wydajności do Compound-TCP (domyślnego CCA w MS Windows) i CUBIC (domyślnego Linuksa) przy użyciu NS-2 simulator. Poprawia całkowitą wydajność do 55% W odniesieniu do średniej przepustowości.

TCP Westwood+Edit

Westwood+ jest modyfikacją TCP Reno, która optymalizuje wydajność kontroli zatorów TCP zarówno w sieciach przewodowych, jak i bezprzewodowych. TCP Westwood+ opiera się na estymacji przepustowości typu end-to-end w celu ustawienia okna przeciążenia i progu spowolnienia po odcinku przeciążenia, czyli po trzech duplikatach potwierdzeń lub przekroczeniu limitu czasu. Przepustowość jest szacowana przez uśrednianie szybkości zwracania pakietów potwierdzających. W przeciwieństwie do TCP Reno, który ślepo zmniejsza o połowę okno przeciążenia po trzech zduplikowanych ACK, TCP Westwood+ adaptacyjnie ustawia próg powolnego startu i okno przeciążenia, które bierze pod uwagę szacunkową przepustowość dostępną w momencie wystąpienia przeciążenia. W porównaniu z Reno i New Reno, Westwood+ znacznie zwiększa przepustowość połączeń bezprzewodowych i poprawia uczciwość w sieciach przewodowych.

Compound Tcpedit

Compound TCP jest implementacją Microsoftu, która utrzymuje dwa różne okna zatorów jednocześnie, w celu osiągnięcia dobrej wydajności na LFNs, nie naruszając przy tym uczciwości. Został szeroko wdrożony w wersjach Windows od Microsoft Windows Vista i Windows Server 2008 i został przeniesiony do starszych wersji Microsoft Windows, a także Linux.

TCP Proportional Rate ReductionEdit

tcp Proportional Rate Reduction (PRR) jest algorytmem zaprojektowanym w celu poprawy dokładności danych wysyłanych podczas odzyskiwania. Algorytm zapewnia, że rozmiar okna po odzyskaniu jest jak najbardziej zbliżony do progu wolnego startu. W testach przeprowadzonych przez Google, PRR spowodowało zmniejszenie średniego opóźnienia o 3-10%, a czas odzyskiwania został skrócony o 5%. PRR jest dostępny w jądrach Linuksa od wersji 3.2.

TCP BBREdit

Bottleneck Bandwidth and Round-trip propagation time (BBR) jest CCA opracowanym w Google w 2016 roku. Podczas gdy większość cca opiera się na stratach, ponieważ polegają na utracie pakietów w celu wykrycia zatorów i niższych szybkości transmisji, BBR, podobnie jak TCP Vegas, opiera się na modelu. Algorytm wykorzystuje maksymalną przepustowość i czas podróży w obie strony, w którym sieć dostarczyła najnowszy lot wychodzących pakietów danych, aby zbudować model sieci. Każde skumulowane lub selektywne potwierdzenie dostarczania pakietów tworzy próbkę szybkości, która rejestruje ilość dostarczonych danych w przedziale czasowym między transmisją pakietu danych a potwierdzeniem tego pakietu. Ponieważ Kontrolery interfejsów sieciowych ewoluują z wydajności megabitów na sekundę do gigabitów na sekundę, opóźnienie związane z bufferblat zamiast utraty pakietów staje się bardziej niezawodnym znacznikiem maksymalnej przepustowości, dzięki czemu oparte na modelach cca, które zapewniają wyższą przepustowość i niższe opóźnienia, takie jak BBR, są bardziej niezawodną alternatywą dla bardziej popularnych algorytmów opartych na stratach, takich jak TCP CUBIC.

BBR jest dostępny dla Linuksa TCP od Linuksa 4.9. Jest również dostępny dla QUIC.

BBR Wersja 1 (BBRv1) jest wydajna i szybka, ale jej uczciwość wobec strumieni innych niż BBR jest kwestionowana. Po wdrożeniu w YouTube, BBRv1 przyniósł średnio o 4% wyższą przepustowość sieci i do 14% w niektórych krajach. Podczas gdy prezentacja Google pokazuje, że BBRv1 dobrze współgra z CUBIC, badacze tacy jak Geoff Huston i Hock, Bless i Zitterbart uważają, że jest to nieuczciwe w stosunku do innych strumieni i nie jest skalowalne. Hock i inni odkryli również „niektóre poważne problemy, takie jak zwiększone opóźnienia w kolejkach, niesprawiedliwość i ogromna utrata pakietów” w implementacji BBR Linuksa 4.9.

Soheil Abbasloo et al. (autorzy C2TCP) pokazują, że BBRv1 nie działa dobrze w dynamicznych środowiskach, takich jak sieci komórkowe. Wykazali również, że BBR ma problem z nieuczciwością. Na przykład, gdy przepływ sześcienny (który jest domyślną implementacją TCP w Linuksie, Androidzie i MacOS) współistnieje z przepływem BBR w sieci, przepływ BBR może zdominować przepływ sześcienny i uzyskać z niego całą przepustowość łącza (patrz rysunek 18 w ).

Wersja 2 próbuje poradzić sobie z problemem nieuczciwości podczas działania wraz z zarządzaniem zatorami opartym na stratach, takim jak CUBIC. W BBRv2 model używany przez BBRv1 został rozszerzony o informacje o utracie pakietów i informacje z Explicit Congestion Notification (ECN). Podczas gdy BBRv2 może czasami mieć niższą przepustowość niż BBRv1, ogólnie uważa się, że ma lepszą przepustowość.

C2TCPEdit

Cellular Controlled Delay TCP (C2tcp) był motywowany brakiem elastycznego podejścia end-to-end TCP, które może spełnić różne wymagania QoS różnych aplikacji bez konieczności jakichkolwiek zmian w urządzeniach sieciowych. C2TCP ma na celu spełnienie ultra-niskich opóźnień i wysokich wymagań dotyczących przepustowości aplikacji, takich jak wirtualna rzeczywistość, wideokonferencje, gry online, systemy komunikacji samochodowej itp. w bardzo dynamicznym środowisku, takim jak obecne sieci LTE i przyszłe Sieci komórkowe 5G. C2TCP działa jako dodatek do TCP opartego na stratach (np. Reno, NewReno, CUBIC, BIC, …) i sprawia, że średnie opóźnienie pakietów jest ograniczone do żądanych opóźnień ustawionych przez aplikacje.

naukowcy z NYU wykazali, że C2TCP przewyższa wydajność opóźnienia / jittera różnych najnowocześniejszych schematów TCP. Na przykład, wykazali, że w porównaniu do BBR, CUBIC i Westwood średnio, C2TCP zmniejsza średnie opóźnienie pakietów o około 250%, 900% i 700% odpowiednio w różnych środowiskach sieci komórkowych.

c2tcp jest wymagane tylko do zainstalowania po stronie serwera.

Elastic-TCP

Elastic-TCP został zaproponowany w lutym 2019 roku przez Mohameda A. Alrshaha i wsp. zwiększenie wykorzystania przepustowości w sieciach o wysokiej przepustowości w celu obsługi najnowszych aplikacji, takich jak przetwarzanie w chmurze, transfer dużych ilości danych, Internet przedmiotów itp. Jest to oparty na Linuksie CCA, który jest przeznaczony dla jądra Linuksa. Jest to algorytm po stronie odbiornika, który wykorzystuje podejście oparte na stratach i opóźnieniach, wykorzystując nowatorski mechanizm, zwany Window-correlated weighing Function (WWF). Ma wysoki poziom elastyczności, aby poradzić sobie z różnymi charakterystykami sieci bez potrzeby strojenia człowieka. Został oceniony przez porównanie jego wydajności do Compound-TCP (domyślne CCA w MS Windows), CUBIC (domyślne Linux) i TCP-BBR (domyślne Linux 4.9 przez Google) przy użyciu NS-2 simulator i testbed. Elastyczny-TCP znacznie poprawia całkowitą wydajność pod względem średniej przepustowości, współczynnika strat i opóźnienia.

NATCP/NACUBICEDIT

Ostatnio, Soheil Abbasloo et. al. zaproponowano NATCP (Network-Assisted TCP) kontrowersyjny projekt TCP skierowany do mobilnych sieci brzegowych, takich jak MEC. Kluczową ideą NATCP jest to, że gdyby cechy sieci były znane wcześniej, TCP zostałby zaprojektowany w lepszy sposób. Dlatego NATCP wykorzystuje dostępne funkcje i właściwości w obecnych architekturach komórkowych opartych na MEC, aby zwiększyć wydajność TCP do optymalnej wydajności. NATCP wykorzystuje pozapasmową informację zwrotną z sieci do serwerów znajdujących się w pobliżu. Informacje zwrotne z sieci, które obejmują pojemność komórkowego łącza dostępowego i minimalny RTT sieci, prowadzą serwery do dostosowania szybkości wysyłania. Jak pokazują wstępne wyniki, NATCP przewyższa najnowocześniejsze Schematy TCP, osiągając co najmniej 2x większą moc (zdefiniowaną jako przepustowość / opóźnienie). NATCP zastępuje tradycyjny schemat TCP u nadawcy.

aby rozwiązać problem ze zgodnością wsteczną, zaproponowano inną wersję o nazwie NACubic. NACubic jest konstrukcją wstecznie kompatybilną, nie wymagającą żadnych zmian w TCP na podłączonych węzłach. NACubic wykorzystuje otrzymane informacje zwrotne i wymusza ograniczenie okna przeciążenia (CWND) i tempo stymulacji zgodnie z wymaganiami.

inne algorytmy unikania zatorów TCP

• szybki TCP
• uogólniony szybki TCP
• H-TCP
• centrum danych TCP
• szybki TCP
• HSTCP-LP
• TCP-LP
• skalowalne TCP
• TCP veno
• Westwood
• XCP
• tak-TCP
• TCP-fit
• unikanie przeciążeń ze znormalizowanym interwałem czasu (Canit)
• nieliniowa Kontrola przeciążeń sieci neuronowych oparta na algorytmie genetycznym dla sieci TCP / IP

tcp New Reno było najczęściej wdrażanym algorytm, obsługa SACK jest bardzo powszechna i jest rozszerzeniem Reno / New Reno. Większość innych to konkurencyjne propozycje, które nadal wymagają oceny. Począwszy od wersji 2.6.8 jądro Linuksa zmieniło domyślną implementację Z New Reno na BIC. Domyślna implementacja została ponownie zmieniona na CUBIC w wersji 2.6.19. FreeBSD używa nowego Reno jako domyślnego algorytmu. Obsługuje jednak wiele innych opcji.

gdy iloczyn przepustowości i opóźnienia na przepływie wzrasta, niezależnie od schematu kolejkowania, TCP staje się nieefektywne i podatne na niestabilność. Staje się to coraz ważniejsze, ponieważ Internet ewoluuje, aby włączyć łącza optyczne o bardzo dużej przepustowości.

tcp Interactive (iTCP) pozwala aplikacjom subskrybować zdarzenia TCP i odpowiednio reagować, umożliwiając różne funkcjonalne rozszerzenia TCP spoza warstwy TCP. Większość systemów zatorów TCP działa wewnętrznie. iTCP dodatkowo umożliwia zaawansowanym aplikacjom bezpośredni udział w kontroli zatorów, takich jak kontrola szybkości generowania źródeł.

Zeta-TCP wykrywa zatory zarówno na podstawie miar opóźnienia, jak i wskaźnika strat, i stosuje różne strategie wycofywania okien zatorów w oparciu o prawdopodobieństwo zatorów, aby zmaksymalizować wydajność. Ma również kilka innych ulepszeń, aby dokładnie wykrywać straty pakietów, unikając retransmisji limit czasu retransmisji; i przyspieszyć / kontrolować ruch przychodzący (pobieranie).