navngivningskonventionen for algoritmer til overbelastningskontrol (CCAs) kan have sin oprindelse i et papir fra 1996 af Kevin Fall og Sally Floyd.

følgende er en mulig klassificering i henhold til følgende egenskaber:

1. typen og mængden af feedback modtaget fra netværket
2. inkrementel implementerbarhed på det nuværende Internet
3. aspektet af ydeevne Det sigter mod at forbedre: produktnetværk med høj båndbredde-forsinkelse (B); tabte links (L); retfærdighed (F); fordel ved korte strømme (S); links med variabel hastighed (V); konvergenshastighed (C)
4. det retfærdighedskriterium, det bruger

nogle velkendte mekanismer til forebyggelse af overbelastning klassificeres efter denne ordning som følger:

TCP Tahoe og renoedit

TCP Tahoe og reno algoritmer blev retrospektivt opkaldt efter versionerne eller smagene af 4.3 BSD-operativsystemet, hvor hver først dukkede op (som selv blev navngivet af TCP Tahoe og renoedit efter Lake Tahoe og den nærliggende by Reno, Nevada). Tahoe-algoritmen dukkede først op i 4.3 BSD-Tahoe (som blev lavet til at understøtte CCI-strømmen 6/32 “Tahoe” minicomputer) og blev senere stillet til rådighed for ikke-at&t-licenstagere som en del af 4.3 BSD-Netværksudgivelse 1; Dette sikrede dens brede distribution og implementering. Forbedringer blev foretaget i 4.3 BSD-Reno og derefter frigivet til offentligheden som Netværksudgivelse 2 og senere 4.4 BSD-Lite.

mens begge overvejer retransmission timeout (RTO) og duplikerer ACKs som pakketabshændelser, adskiller Tahoe og Renos opførsel sig primært i, hvordan de reagerer på duplikat ACKs:

• Tahoe: hvis der modtages tre duplikat ACKs (dvs.fire ACKs, der anerkender den samme pakke, som ikke er piggybacked på data og ikke ændrer modtagerens annoncerede vindue), udfører Tahoe En hurtig genudsendelse, indstiller den langsomme startgrænse til halvdelen af det aktuelle overbelastningsvindue, reducerer antallet af vinduet overbelastning til 1 MSS, og nulstilles til langsom start tilstand.
• Reno: hvis der modtages tre duplikat ACK ‘ er, udfører Reno en hurtig videresendelse og springer over den langsomme startfase ved i stedet at halvere overbelastningsvinduet (i stedet for at indstille det til 1 MSS som Tahoe), indstille den langsomme startgrænse svarende til det nye overbelastningsvindue og gå ind i en fase kaldet hurtig gendannelse.

i både Tahoe og Reno, hvis en ACK times out (RTO timeout), bruges langsom start, og begge algoritmer reducerer overbelastningsvinduet til 1 MSS.

TCP VegasEdit

indtil midten af 1990 ‘erne var alle TCP’ s indstillede timeouts og målte returforsinkelser kun baseret på den sidst transmitterede pakke i sendebufferen. Forskere fra University of Nevada introducerede TCP Vegas (opkaldt efter Las Vegas, den største by i Nevada), hvor timeouts blev indstillet, og returforsinkelser blev målt for hver pakke i sendebufferen. Derudover bruger TCP Vegas additive stigninger i overbelastningsvinduet. I en sammenligningsundersøgelse af forskellige TCP-CCAs syntes TCP Vegas at være den glateste efterfulgt af TCP CUBIC.TCP Vegas blev ikke udbredt uden for Petersons laboratorium, men blev valgt som standard overbelastningskontrolmetode til DD-V24 SP2.

TCP ny RenoEdit

TCP ny Reno, defineret af RFC 6582 (som forældes tidligere definitioner i RFC 3782 og RFC 2582), forbedrer retransmission under hurtiggendannelsesfasen af TCP Reno. Under hurtig genopretning, for at holde sendevinduet fuldt, for hver duplikat ACK, der returneres, sendes en ny usendt pakke fra slutningen af overbelastningsvinduet. For hver ACK, der gør delvise fremskridt i sekvensrummet, antager afsenderen, at ACK peger på et nyt hul, og den næste pakke ud over det Ackede sekvensnummer sendes.

fordi timeout nulstilles, når der er fremskridt i sendebufferen, kan Ny Reno fylde store huller eller flere huller i sekvensrummet – ligesom TCP SACK. Fordi Ny Reno kan sende nye pakker i slutningen af overbelastningsvinduet under hurtig genopretning, opretholdes høj gennemstrømning under hulfyldningsprocessen, selv når der er flere huller, af flere pakker hver. Når TCP går ind i hurtig gendannelse, registrerer den det højeste udestående ikke-anerkendte pakkesekvensnummer. Når dette sekvensnummer anerkendes, vender TCP tilbage til tilstanden til at undgå overbelastning.

der opstår et problem med ny Reno, når der ikke er pakketab, men i stedet omarrangeres pakker med mere end 3 pakkesekvensnumre. I dette tilfælde går ny Reno fejlagtigt ind i hurtig genopretning. Når den omordnede pakke leveres, ACK sekvens-nummer fremskridt sker, og derfra indtil slutningen af hurtig genopretning, alle sekvens-nummer fremskridt producerer en duplikat og unødvendig retransmission, der straks ACKed.

ny Reno udfører såvel som SACK ved lave pakkefejl og overgår væsentligt Reno ved høje fejlfrekvenser.

TCP HyblaEdit

TCP Hybla sigter mod at eliminere sanktioner til TCP-forbindelser, der indeholder en jordbaseret eller satellitradiolink med høj latens. Hybla-forbedringer er baseret på analytisk evaluering af overbelastningsvinduets dynamik.

TCP BICEdit

Binary Increase Congestion control (BIC) er en TCP-implementering med en optimeret CCA til højhastighedsnetværk med høj latenstid, kendt som lange fedtnetværk. BIC bruges som standard i linukskerner 2.6.8 til 2.6.18.

TCP CUBICEdit

CUBIC er et mindre aggressivt og mere systematisk derivat af BIC, hvor vinduet er en kubisk funktion af tiden siden den sidste overbelastningsbegivenhed, med bøjningspunktet indstillet til vinduet før begivenheden. Kubik bruges som standard i linukskerner mellem version 2.6.19 og 3.2.

Agile-SD TCPEdit

Agile-SD er en CCA, der er designet til den virkelige kerne. Det er en modtager-side algoritme, der anvender en tabsbaseret tilgang ved hjælp af en ny mekanisme, kaldet agility factor (af). at øge båndbreddeudnyttelsen over højhastigheds-og kortdistancenetværk (lav-BDP-netværk) såsom lokalnetværk eller fiberoptisk netværk, især når den anvendte bufferstørrelse er lille. Det er blevet evalueret ved at sammenligne dets ydeevne med Compound-TCP (standard CCA i MS-vinduer) og CUBIC (standard for Linuks) ved hjælp af NS-2 simulator. Det forbedrer den samlede ydelse op til 55% på sigt af gennemsnitlig gennemstrømning.

TCP congestion control over både kablede og trådløse netværk er en kun afsender-ændring af TCP Reno, der optimerer ydelsen af TCP congestion control over både kablede og trådløse netværk. TCP er baseret på end-to-end båndbredde estimering for at indstille overbelastningsvinduet og langsomt startgrænse efter en overbelastningsepisode, det vil sige efter tre duplikatkvitteringer eller en timeout. Båndbredden estimeres ved gennemsnit af hastigheden for returnering af kvitteringspakker. I modsætning til TCP Reno, som blindt halverer overbelastningsvinduet efter tre duplikat ACK ‘ er, indstiller TCP adaptivt en langsom startgrænse og et overbelastningsvindue, der tager højde for et skøn over båndbredde, der er tilgængelig på det tidspunkt, hvor overbelastning opleves. Sammenlignet med Reno og ny Reno øger vi betydeligt gennemstrømningen over trådløse links og forbedrer retfærdigheden i kablede netværk.

Compound TCPEdit

Hovedartikel: Compound TCP

Compound TCP er en Microsoft-implementering af TCP, der opretholder to forskellige overbelastningsvinduer samtidigt med målet om at opnå god ydelse på LFNs uden at forringe retfærdigheden. Det har været meget udbredt i vinduer versioner siden Microsoft Vinduer Vista og vinduer Server 2008 og er blevet porteret til ældre Microsoft vinduer versioner samt .

TCP Proportional Rate ReductionEdit

TCP Proportional Rate Reduction (PRR) er en algoritme designet til at forbedre nøjagtigheden af data, der sendes under gendannelse. Algoritmen sikrer, at vinduesstørrelsen efter gendannelse er så tæt som muligt på den langsomme startgrænse. I test udført af Google resulterede PRR i en reduktion på 3-10% i gennemsnitlig latenstid, og gendannelsestidsudgange blev reduceret med 5%. PRR er tilgængelig i Linuks kerner siden version 3.2.

TCP BBREdit

flaskehals båndbredde og rundtur formeringstid (BBR) er en CCA udviklet hos Google i 2016. Mens de fleste CCA ‘ er er tabsbaserede, idet de er afhængige af pakketab for at opdage overbelastning og lavere transmissionshastigheder, er BBR ligesom TCP Vegas modelbaseret. Algoritmen bruger den maksimale båndbredde og rundrejsetid, hvor netværket leverede den seneste flyvning af udgående datapakker til at opbygge en model af netværket. Hver kumulativ eller selektiv anerkendelse af pakkelevering producerer en hastighedsprøve, der registrerer mængden af data leveret over tidsintervallet mellem transmission af en datapakke og anerkendelse af den pakke. Som netværksgrænsefladecontrollere udvikler sig fra megabit per sekund til gigabit per sekund ydeevne, latensen forbundet med bufferbloat i stedet for pakketab bliver en mere pålidelig markør for den maksimale gennemstrømning, hvilket gør modelbaserede CCA ‘ er, der giver højere gennemstrømning og lavere latenstid, såsom BBR, et mere pålideligt alternativ til mere populære tabsbaserede algoritmer som TCP CUBIC.BBR har været tilgængelig for TCP siden 4.9. Det er også tilgængeligt for KVIC. BBR version 1 (BBRv1) er effektiv og hurtig, men dens retfærdighed over for ikke-BBR-strømme bestrides. Ved implementering på YouTube gav BBRv1 i gennemsnit 4% højere netværksgennemstrømning og op til 14% i nogle lande. Mens Googles præsentation viser, at BBRv1 sameksisterer godt med CUBIC, finder forskere som Geoff Huston og Hock, Bless og Sitterbart det uretfærdigt over for andre strømme og ikke skalerbart. Hock et al fandt også “nogle alvorlige iboende problemer som øgede køforsinkelser, uretfærdighed og massivt pakketab” i BBR-implementeringen af Linuk 4.9.

Soheil Abbasloo et al. (forfattere af C2TCP) viser, at BBRv1 ikke fungerer godt i dynamiske miljøer såsom mobilnetværk. De har også vist, at BBR har et uretfærdigt problem. For eksempel, når en kubisk strøm (som er standard TCP-implementering i Android og MacOS) sameksisterer med en BBR-strøm i netværket, kan BBR-strømmen dominere den kubiske strøm og få hele linkbåndbredden fra den (se figur 18 i ).

Version 2 Forsøger at håndtere spørgsmålet om uretfærdighed, når de opererer sammen med tabsbaseret overbelastningsstyring som CUBIC. I BBRv2 den model, der anvendes af BBRv1 er udvidet til at omfatte oplysninger om pakketab og oplysninger fra eksplicit Congestion Notification (ECN). Mens BBRv2 til tider kan have lavere gennemstrømning end BBRv1, anses det generelt for at have bedre goodput.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) var motiveret af manglen på en fleksibel ende-til-ende TCP-tilgang, der kan tilfredsstille forskellige krav til forskellige applikationer uden at kræve ændringer i netværksenhederne. C2TCP sigter mod at tilfredsstille ultra-lav latenstid og høje Båndbreddekrav til applikationer såsom virtual reality, videokonferencer, online spil, køretøjskommunikationssystemer osv. i et meget dynamisk miljø som nuværende LTE og fremtidige 5G-mobilnetværk. C2TCP fungerer som en tilføjelse oven på tabsbaseret TCP (f .eks…) og gør den gennemsnitlige forsinkelse af pakker afgrænset til de ønskede forsinkelser indstillet af applikationerne.

forskere ved NYU viste, at C2TCP overgår forsinkelsen / Jitterydelsen af forskellige avancerede TCP-ordninger. For eksempel viste de, at sammenlignet med BBR, C2TCP i gennemsnit reducerer den gennemsnitlige forsinkelse af pakker med henholdsvis 250%, 900% og 700% på forskellige mobilnetværksmiljøer.

C2TCP skal kun installeres på serversiden.

elastisk-TCPEdit

elastisk-TCP er blevet foreslået i februar 2019 af Mohamed A. Alrshah et al. at øge båndbreddeudnyttelsen over high-BDP-netværk til understøttelse af nylige applikationer som cloud computing, big data transfer, IoT osv. Det er en CCA, der er designet til kernen. Det er en modtager-side algoritme, der anvender en Tabsforsinkelsesbaseret tilgang ved hjælp af en ny mekanisme, kaldet Vindueskorreleret Vægtningsfunktion. Det har et højt elasticitetsniveau til at håndtere forskellige netværkskarakteristika uden behov for menneskelig tuning. Det er blevet evalueret ved at sammenligne dets ydeevne med Compound-TCP (standard CCA i MS-vinduer), CUBIC (standard for Linuk) og TCP-BBR (standard for Linuk 4.9 af Google) ved hjælp af NS-2 simulator og testbed. Elastisk-TCP forbedrer signifikant den samlede ydelse med hensyn til gennemsnitlig gennemstrømning, tabsforhold og forsinkelse.

NATCP/NACubicEdit

for nylig, Soheil Abbasloo et. al. foreslået NATCP (Netværksassisteret TCP) et kontroversielt TCP-design rettet mod Mobile Kantnetværk som MEC. Nøgleideen med NATCP er, at hvis netværkets egenskaber var kendt på forhånd, ville TCP være designet på en bedre måde. Derfor anvender NATCP de tilgængelige funktioner og egenskaber i de nuværende MEC-baserede cellulære arkitekturer for at skubbe TCP ‘ s ydeevne tæt på den optimale ydeevne. NATCP bruger en out-of-band feedback fra netværket til serverne i nærheden. Tilbagemeldingen fra netværket, som omfatter kapaciteten af cellular access link og netværkets mindste RTT, styrer serverne til at justere deres sendehastigheder. Som foreløbige resultater viser, overgår NATCP de avancerede TCP-ordninger ved mindst at opnå 2 gange højere effekt (defineret som gennemstrømning/forsinkelse). NATCP erstatter det traditionelle TCP-skema hos afsenderen.

for at håndtere bagudkompatibilitetsproblemet foreslog de en anden version kaldet NACubic. NACubic er et bagudkompatibelt design, der kræver ingen ændring i TCP på de tilsluttede noder. NACubic anvender den modtagne feedback og håndhæver et loft på overbelastningsvinduet (CND) og tempoet efter behov.

andre TCP-algoritmer til undgåelse af overbelastning af TCP

• hurtig TCP
• generaliseret hurtig TCP
• h-TCP
• datacenter TCP
• høj hastighed TCP
• HSTCP-LP
• TCP-Illinois
• TCP-lp
• TCP SACK
• skalerbar TCP

ja-TCP

• TCP-fit
• undgåelse af overbelastning med normaliseret tidsinterval (Canit)
• ikke-lineær neuralt netværk overbelastningskontrol baseret på genetisk algoritme til TCP/IP-netværk

TCP ny Reno var den mest almindeligt implementerede algoritme, SACK support er meget almindelig og er en udvidelse til Reno/ny Reno. De fleste andre er konkurrerende forslag, som stadig skal evalueres. Fra og med 2.6.8 skiftede Linuk-kernen standardimplementeringen fra Ny Reno til BIC. Standardimplementeringen blev igen ændret til CUBIC i 2.6.19-versionen. FreeBSD bruger ny Reno som standardalgoritme. Det understøtter dog en række andre valg.

Når per-strømningsproduktet af båndbredde og latenstid øges, uanset køordningen, bliver TCP ineffektiv og tilbøjelig til ustabilitet. Dette bliver stadig vigtigere, da internettet udvikler sig til at inkorporere optiske links med meget høj båndbredde.

TCP Interactive (iTCP) tillader applikationer at abonnere på TCP-begivenheder og reagere i overensstemmelse hermed, hvilket muliggør forskellige funktionelle udvidelser til TCP udefra TCP-lag. De fleste TCP-overbelastningsordninger fungerer internt. iTCP giver desuden avancerede applikationer mulighed for direkte at deltage i overbelastningskontrol, såsom at kontrollere kildegenereringshastigheden.TCP registrerer overbelastningerne fra både latens-og tabsprocentmålingerne og anvender forskellige backoff-strategier for overbelastningsvindue baseret på sandsynligheden for overbelastningerne for at maksimere goodput. Det har også et par andre forbedringer til nøjagtigt at registrere pakketabene, undgå retransmission timeout retransmission; og fremskynde/kontrollere den indgående (Hent) trafik.