namnkonventionen för congestion control algorithms (CCAs) kan ha sitt ursprung i ett papper från 1996 av Kevin Fall och Sally Floyd.

Följande är en möjlig klassificering enligt följande egenskaper:

1. typen och mängden feedback som mottas från nätverket
2. inkrementell distribuerbarhet på det aktuella Internet
3. aspekten av prestanda Det syftar till att förbättra: hög bandbredd-fördröjning produktnätverk (B); lossy länkar( L); rättvisa (F); fördel för korta flöden; länkar med variabel hastighet (V); konvergenshastighet (C)
4. rättvisa kriteriet det använder

vissa välkända mekanismer för undvikande av överbelastning klassificeras enligt detta schema enligt följande:

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 bandbredd	Max-min
röd	förlust	Router	minskad fördröjning
ECN	Enkelbitssignal	avsändare, mottagare, Router	minskad förlust

TCP Tahoe och renoedit

tcp Tahoe-och Reno-algoritmerna namngavs retroaktivt efter versionerna eller smakerna i 4.3 BSD-operativsystemet där var och en först uppträdde (som själva namngavs efter Lake Tahoe och Reno-algoritmerna) närliggande staden Reno, Nevada). Tahoe-algoritmen uppträdde först i 4.3 BSD-Tahoe (som gjordes för att stödja CCI Power 6/32 ”Tahoe” minicomputer) och gjordes senare tillgänglig för icke-AT&t licenstagare som en del av 4.3 BSD Networking Release 1; Detta säkerställde dess breda distribution och implementering. Förbättringar gjordes i 4.3 BSD-Reno och släpptes därefter för allmänheten som Networking Release 2 och senare 4.4 BSD-Lite.

medan båda anser återutsändning timeout (RTO) och duplicera ACKs som paketförlusthändelser, beteendet hos Tahoe och Reno skiljer sig främst i hur de reagerar på Duplicera ACKs:

• Tahoe: om tre dubbletter ACKs tas emot (dvs fyra ACKs erkänner samma paket, som inte piggybacked på data och ändrar inte mottagarens annonserade fönster), Tahoe utför en snabb återutsändning, ställer in den långsamma startgränsen till hälften av det aktuella överbelastningsfönstret, minskar congestion fönster till 1 mss, och återställs till långsam start tillstånd.
• Reno: om tre dubbla ACKs tas emot, kommer Reno att utföra en snabb återsändning och hoppa över den långsamma startfasen genom att istället halvera överbelastningsfönstret (istället för att ställa in det till 1 MSS som Tahoe), ställa in den långsamma startgränsen lika med det nya överbelastningsfönstret och gå in i en fas som kallas snabb återhämtning.

i både Tahoe och Reno, om en ACK timeout (RTO timeout), långsam start används, och båda algoritmerna minskar trängselfönstret till 1 MSS.

TCP VegasEdit

fram till mitten av 1990-talet baserades alla TCP: s inställda timeouts och uppmätta rundtursfördröjningar endast på det sista överförda paketet i sändningsbufferten. University of Arizona forskare Larry Peterson och Lawrence Brakmo introducerade TCP Vegas (uppkallad efter Las Vegas, den största staden i Nevada) där timeouts sattes och rundtursförseningar mättes för varje paket i sändningsbufferten. Dessutom använder TCP Vegas additiva ökningar i överbelastningsfönstret. I en jämförelsestudie av olika TCP cca, TCP Vegas verkade vara den smidigaste följt av TCP CUBIC.

TCP Vegas användes inte i stor utsträckning utanför Petersons laboratorium men valdes som standard överbelastningskontrollmetod för DD-WRT-firmware v24 SP2.

TCP New RenoEdit

TCP New Reno, definierad av RFC 6582 (som föråldrar tidigare definitioner i RFC 3782 och RFC 2582), förbättrar återutsändning under snabbåterställningsfasen av TCP Reno. Under snabb återhämtning, för att hålla sändningsfönstret fullt, för varje dubblett ACK som returneras, skickas ett nytt osänt paket från slutet av överbelastningsfönstret. För varje ACK som gör partiella framsteg i sekvensutrymmet antar avsändaren att ACK pekar på ett nytt hål och nästa paket utöver det ACKed sekvensnumret skickas.

eftersom timeout återställs när det finns framsteg i sändningsbufferten kan New Reno fylla stora hål eller flera hål i sekvensutrymmet – ungefär som TCP-säck. Eftersom New Reno kan skicka nya paket i slutet av trängselfönstret under snabb återhämtning bibehålls hög genomströmning under hålfyllningsprocessen, även när det finns flera hål, av flera paket vardera. När TCP går in i snabb återhämtning registrerar den det högsta utestående icke-erkända paketets sekvensnummer. När detta sekvensnummer bekräftas återgår TCP till tillståndet för undvikande av överbelastning.

ett problem uppstår med ny Reno när det inte finns några paketförluster utan istället ordnas paket med mer än 3 paketsekvensnummer. I det här fallet går New Reno felaktigt in i snabb återhämtning. När det omordnade paketet levereras sker ack-sekvensnummerförlopp och därifrån fram till slutet av snabb återhämtning producerar alla sekvensnummerförlopp en duplikat och onödig återutsändning som omedelbart ACKed.

ny Reno presterar såväl som säck vid låga paketfelfrekvenser och överträffar väsentligen Reno vid höga felfrekvenser.

TCP HyblaEdit

tcp Hybla syftar till att eliminera påföljder för TCP-anslutningar som innehåller markbundna eller satellitradiolänkar med hög latens. Hybla förbättringar baseras på analytisk utvärdering av överbelastningsfönsterdynamiken.

TCP BICEdit

Binary Increase Congestion control (BIC) är en TCP-implementering med en optimerad CCA för höghastighetsnätverk med hög latens, känd som long fat-nätverk. BIC används som standard i Linux-kärnor 2.6.8 till 2.6.18.

TCP CUBICEdit

CUBIC är ett mindre aggressivt och mer systematiskt derivat av BIC, där fönstret är en kubisk funktion av tiden sedan den senaste överbelastningshändelsen, med böjningspunkten inställd på fönstret före händelsen. CUBIC används som standard i Linux-kärnor mellan versionerna 2.6.19 och 3.2.

Agile-SD TCPEdit

Agile-SD är en Linux-baserad CCA som är utformad för den verkliga Linux-kärnan. Det är en algoritm på mottagarsidan som använder ett förlustbaserat tillvägagångssätt med en ny mekanism, kallad agilityfaktor (AF). för att öka bandbreddsutnyttjandet över höghastighets-och kortdistansnät (låg-BDP-nätverk) som lokala nätverk eller fiberoptiska nätverk, särskilt när den applicerade buffertstorleken är liten. Det har utvärderats genom att jämföra dess prestanda till Compound-TCP (standard CCA i MS Windows) och CUBIC (standard för Linux) med NS-2 simulator. Det förbättrar den totala prestandan upp till 55% på sikt av genomsnittlig genomströmning.

TCP Westwood+redigera

Westwood+ är en avsändarmodifiering av TCP Reno som optimerar prestandan för TCP-trängselkontroll över både trådbundna och trådlösa nätverk. TCP Westwood + är baserad på end-to-end bandbredd uppskattning för att ställa in trängselfönstret och långsam start tröskel efter en trängsel episod, det vill säga efter tre dubbla bekräftelser eller en timeout. Bandbredden beräknas genom att medelvärdet av returbekräftelsepaket. Till skillnad från TCP Reno, som blindt halverar överbelastningsfönstret efter tre dubbla ACKs, sätter TCP Westwood+ adaptivt en tröskel för långsam start och ett överbelastningsfönster som tar hänsyn till en uppskattning av bandbredd som är tillgänglig vid den tidpunkt då trängsel upplevs. Jämfört med Reno och New Reno ökar Westwood+ avsevärt genomströmningen över trådlösa länkar och förbättrar rättvisan i Trådbundna nätverk.

Compound TCPEdit

Compound TCP är en Microsoft-implementering av TCP som upprätthåller två olika överbelastningsfönster samtidigt, med målet att uppnå bra prestanda på LFNs samtidigt som det inte försämrar rättvisa. Det har använts i stor utsträckning i Windows-versioner sedan Microsoft Windows Vista och Windows Server 2008 och har portats till äldre Microsoft Windows-versioner samt Linux.

TCP Proportional Rate ReductionEdit

tcp Proportional Rate Reduction (PRR) är en algoritm som är utformad för att förbättra noggrannheten hos data som skickas under återställning. Algoritmen säkerställer att fönsterstorleken efter återhämtning är så nära tröskeln för långsam start som möjligt. I tester utförda av Google resulterade PRR i en 3-10% minskning av genomsnittlig latens och återhämtningstiden minskade med 5%. PRR finns i Linux-kärnor sedan version 3.2.

TCP BBREdit

Flaskhalsbandbredd och Rundtursutbredningstid (BBR) är en CCA som utvecklats på Google 2016. Medan de flesta CCA är förlustbaserade, eftersom de är beroende av paketförlust för att upptäcka trängsel och lägre överföringshastigheter, är BBR, som TCP Vegas, modellbaserad. Algoritmen använder den maximala bandbredden och rundturstiden då nätverket levererade den senaste flygningen av utgående datapaket för att bygga en modell av nätverket. Varje kumulativ eller selektiv bekräftelse av paketleverans ger ett hastighetsprov som registrerar mängden data som levereras under tidsintervallet mellan överföringen av ett datapaket och bekräftelsen av det paketet. Som nätverksgränssnitt styrenheter utvecklas från megabit per sekund till gigabit per sekund prestanda, latensen i samband med bufferbloat istället för paketförlust blir en mer tillförlitlig markör för maximal genomströmning, vilket gör modellbaserade cca som ger högre genomströmning och lägre latens, såsom BBR, en mer tillförlitlig alternativ till mer populära förlustbaserade algoritmer som TCP CUBIC.

BBR har varit tillgängligt för Linux TCP sedan Linux 4.9. Det är också tillgängligt för QUIC.

BBR version 1 (BBRv1) är effektiv och snabb, men dess rättvisa mot icke-BBR-strömmar är omtvistad. Vid implementering på YouTube gav BBRv1 i genomsnitt 4% högre nätverkskapacitet och upp till 14% i vissa länder. Medan Googles presentation visar BBRv1 samexistera väl med CUBIC, forskare som Geoff Huston och Hock, Bless och Zitterbart finner det orättvist att andra strömmar och inte skalbar. Hock et al fann också ”några allvarliga inneboende problem som ökade köförseningar, orättvisa och massiv paketförlust” i BBR-implementeringen av Linux 4.9.

Soheil Abbasloo et al. (författare till C2TCP) visar att BBRv1 inte fungerar bra i dynamiska miljöer som mobilnät. De har också visat att BBR har en orättvisa fråga. Till exempel, när ett kubiskt flöde (som är standard TCP-implementeringen i Linux, Android och MacOS) samexisterar med ett BBR-flöde i nätverket, kan BBR-flödet dominera det kubiska flödet och få hela länkbandbredden från det (se figur 18 in ).

Version 2 försöker hantera frågan om orättvisa när man arbetar tillsammans med förlustbaserad trängselhantering som CUBIC. I BBRv2 utökas modellen som används av BBRv1 för att inkludera information om paketförlust och information från Explicit Congestion Notification (ECN). Medan BBRv2 ibland kan ha lägre genomströmning än BBRv1 anses det generellt ha bättre goodput.

C2TCPEdit

cellulär kontrollerad fördröjning TCP (C2TCP) motiverades av bristen på en flexibel end-to-end TCP-strategi som kan uppfylla olika QoS-krav för olika applikationer utan att kräva några ändringar i nätverksenheterna. C2TCP syftar till att uppfylla kraven på extremt låg latens och hög bandbredd för applikationer som virtuell verklighet, videokonferenser, onlinespel, fordonskommunikationssystem etc. i en mycket dynamisk miljö som nuvarande LTE och framtida 5G-mobilnät. C2TCP fungerar som ett tillägg ovanpå förlustbaserad TCP (t .ex. Reno, NewReno, CUBIC, BIC,…) och gör den genomsnittliga fördröjningen av paket avgränsas till de önskade fördröjningar som av ansökningarna.

forskare vid NYU visade att C2TCP överträffar fördröjnings – / Jitterprestanda för olika toppmoderna TCP-system. Till exempel visade de att jämfört med BBR, CUBIC och Westwood i genomsnitt minskar C2TCP den genomsnittliga fördröjningen av paket med cirka 250%, 900% respektive 700% på olika mobilnätmiljöer.

C2TCP krävs endast för att installeras på serversidan.

Elastic-TCPEdit

Elastic-TCP har föreslagits i februari 2019 av Mohamed A. Alrshah et al. för att öka bandbreddsutnyttjandet över högbdp-nätverk för att stödja nya applikationer som cloud computing, big data transfer, IoT, etc. Det är en Linux-baserad CCA som är utformad för Linux-kärnan. Det är en algoritm på mottagarsidan som använder en Förlustfördröjningsbaserad metod med hjälp av en ny mekanism, kallad Window-correlated Weighting Function (WWF). Den har en hög elasticitet för att hantera olika nätverksegenskaper utan behov av mänsklig inställning. Det har utvärderats genom att jämföra dess prestanda med Compound-TCP (standard CCA i MS Windows), CUBIC (standard för Linux) och TCP-BBR (standard för Linux 4.9 av Google) med NS-2 simulator och testbed. Elastic-TCP förbättrar signifikant den totala prestandan på sikt av genomsnittlig genomströmning, förlustförhållande och fördröjning.

NATCP/NACubicEdit

nyligen, Soheil Abbasloo et. al. föreslagen NATCP (Network-Assisted TCP) en kontroversiell TCP-design riktad mot mobila Kantnätverk som MEC. Nyckeltanken med NATCP är att om nätverksegenskaperna var kända i förväg, skulle TCP ha utformats på ett bättre sätt. Därför använder NATCP de tillgängliga funktionerna och egenskaperna i de nuvarande MEC-baserade cellulära arkitekturerna för att driva TCP: s prestanda nära optimal prestanda. NATCP använder en out-of-band feedback från nätverket till servrarna i närheten. Återkopplingen från nätverket, som inkluderar kapaciteten för mobilåtkomstlänk och minsta RTT i nätverket, styr servrarna för att justera sina sändningshastigheter. Som preliminära resultat visar NATCP överträffar de toppmoderna TCP-scheman genom att åtminstone uppnå 2x högre effekt (definierad som genomströmning/fördröjning). NATCP ersätter det traditionella TCP-schemat vid avsändaren.

för att hantera bakåtkompatibilitetsproblem föreslog de en annan version som heter NACubic. NACubic är en bakåtkompatibel design som inte kräver någon ändring av TCP på de anslutna noderna. NACubic använder den mottagna feedbacken och upprätthåller ett tak på trängselfönstret (CWND) och stimuleringsgraden efter behov.

andra TCP överbelastning undvikande algoritmredigera

• snabb TCP
• allmänt snabb TCP
• h-TCP
• datacenter TCP
• hög hastighet TCP
• Hstcp-lp
• TCP-Illinois
• TCP-LP
• TCP säck
• skalbar TCP
• TCP veno
• Westwood
• XCP
• ja-TCP
• TCP-fit
• undvikande av överbelastning med normaliserat tidsintervall (canit)
• icke-linjär kontroll av neuralt nätverk överbelastning baserat på genetisk algoritm för TCP/IP-nätverk

tcp new Reno var den vanligaste implementerade algoritm, SÄCKSTÖD är mycket vanligt och är en förlängning till Reno/New Reno. De flesta andra är konkurrerande förslag som fortfarande behöver utvärderas. Från och med 2.6.8 bytte Linuxkärnan standardimplementeringen från New Reno till BIC. Standardimplementeringen ändrades igen till CUBIC i 2.6.19-versionen. FreeBSD använder ny Reno som standardalgoritm. Det stöder dock ett antal andra val.

När perflödesprodukten av bandbredd och latens ökar, oavsett köschemat, blir TCP ineffektivt och benäget för instabilitet. Detta blir allt viktigare eftersom Internet utvecklas för att införliva optiska länkar med mycket hög bandbredd.

tcp Interactive (iTCP) tillåter applikationer att prenumerera på TCP-händelser och svara i enlighet därmed möjliggör olika funktionella tillägg till TCP från utanför TCP-lagret. De flesta TCP-överbelastningssystem fungerar internt. iTCP gör det dessutom möjligt för avancerade applikationer att direkt delta i trängselkontroll, t.ex. för att styra källgenereringshastigheten.

Zeta-TCP upptäcker överbelastningarna från både latens-och förlusthastighetsåtgärderna och tillämpar olika överbelastningsfönsterbackoff-strategier baserat på sannolikheten för överbelastningarna för att maximera goodput. Det har också ett par andra förbättringar för att exakt upptäcka paketförlusterna, undvika återutsändning timeout återutsändning; och påskynda / kontrollera inkommande (nedladdning) trafik.