navnekonvensjonen for congestion control algorithms (CCAs) kan ha sin opprinnelse i En artikkel fra 1996 av Kevin Fall og Sally Floyd.

følgende er en mulig klassifisering i henhold til følgende egenskaper:

1. typen og mengden tilbakemelding mottatt fra nettverket
2. inkrementell distribusjon på det nåværende Internett
3. aspektet av ytelse det tar sikte på å forbedre: høy båndbredde-forsinkelse produktnettverk (B); lossy lenker (L); rettferdighet (F); fordel for korte strømmer( Er); variabel hastighet lenker( V); konvergenshastighet (C)
4. rettferdighetskriteriet den bruker

Noen kjente overbelastningsmekanismer er klassifisert av denne ordningen som følger:

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 båndbredde		RØD	Tap	Redusert forsinkelse
	ECN	Enkeltbitsignal	Sender, Mottaker, Ruter	Redusert tap

tcp tahoe og renoedit

tcp tahoe og reno algoritmer BLE I ETTERTID oppkalt etter versjoner eller smaker av 4.3 bsd operativsystem der hver Først Dukket Opp (som Selv ble oppkalt etter lake tahoe og den nærliggende byen reno (nevada). Tahoe-algoritmen dukket først opp i 4.3 BSD-Tahoe (som ble laget for å støtte CCI Power 6/32 «Tahoe» minidatamaskin), og ble senere gjort tilgjengelig for ikke-AT&t lisenstakere som en del av 4.3 Bsd Networking Release 1; dette sikret sin brede distribusjon og implementering. Forbedringer ble gjort i 4.3 BSD-Reno og senere utgitt til publikum Som Networking Release 2 og senere 4.4 BSD-Lite.Tahoe: Hvis tre dupliserte Acker mottas (dvs. fire Acker anerkjenner den samme pakken, som ikke er piggybacked på data og ikke endrer mottakerens annonserte vindu), Utfører Tahoe en rask retransmit, setter langsom startgrense til halvparten av det nåværende overbelastningsvinduet, reduserer overbelastningsvinduet til 1 mss, og tilbakestilles Til Sakte starttilstand.

Reno: Hvis tre dupliserte ACKs mottas, Vil Reno utføre en rask retransmit og hoppe over den langsomme startfasen ved i stedet å halvere overbelastningsvinduet (i stedet for å sette den til 1 MSS som Tahoe), sette den langsomme startterskelen lik det nye overbelastningsvinduet, og angi en fase kalt rask gjenoppretting.

i Både Tahoe og Reno, hvis EN ACK ganger ut (RTO timeout), brukes langsom start, og begge algoritmer reduserer overbelastningsvinduet til 1 MSS.

Tcp VegasEdit

frem til midten av 1990-tallet var ALLE tcp ‘ s fastsatte tidsavbrudd og målte rundturforsinkelser basert på bare den siste overførte pakken i overføringsbufferen. University Of Arizona forskere Larry Peterson og Lawrence Brakmo introduserte TCP Vegas (oppkalt Etter Las Vegas, Den største byen I Nevada) der tidsavbrudd ble satt og rundturforsinkelser ble målt for hver pakke i overføringsbufferen. I TILLEGG bruker TCP Vegas additive økninger i overbelastningsvinduet. I en sammenligningsstudie av ULIKE TCP CCAs, TCP Vegas syntes å være den jevneste etterfulgt AV TCP CUBIC.

TCP Vegas ble ikke distribuert utenfor Petersons laboratorium, men ble valgt som standard overbelastningskontrollmetode for dd-WRT firmware v24 SP2.

Tcp New RenoEdit

TCP New Reno, definert AV RFC 6582 (som obsolesces tidligere definisjoner I RFC 3782 OG RFC 2582), forbedrer retransmisjon under rask gjenoppretting fase AV TCP Reno. Under rask gjenoppretting, for å holde sendevinduet fullt, for hver duplikat ACK som returneres, sendes en ny usendt pakke fra slutten av overbelastningsvinduet. For HVER ACK som gjør delvis fremgang i sekvensområdet, antar avsenderen AT ACK peker på et nytt hull, og neste pakke utover Det ACKed sekvensnummeret sendes.

fordi timeout tilbakestilles når det er fremgang i overføringsbufferen, Kan Ny Reno fylle store hull eller flere hull i sekvensrommet-akkurat SOM TCP-SEKK. Fordi New Reno kan sende nye pakker på slutten av overbelastningsvinduet under rask gjenoppretting, opprettholdes høy gjennomstrømning under hullfyllingsprosessen, selv når det er flere hull, av flere pakker hver. NÅR TCP går inn i rask gjenoppretting, registrerer den det høyeste utestående ubekreftede pakkesekvensnummeret. NÅR dette sekvensnummeret er anerkjent, returnerer TCP til overbelastningstilstanden.

Det oppstår et problem Med Ny Reno når det ikke er noen pakketap, men i stedet blir pakker omordnet med mer enn 3 pakkesekvensnumre. I Dette tilfellet går New Reno feilaktig inn i rask gjenoppretting. NÅR den ombestilte pakken leveres, ACK sekvens-nummer fremgang oppstår og derfra til slutten av rask gjenoppretting, produserer alle sekvens-nummer fremgang en duplikat og unødvendig videresending som Umiddelbart ACKed.

New Reno utfører så vel SOM SEKK ved lave pakkefeil priser, og vesentlig utkonkurrerer Reno ved høye feilrater.

TCP HyblaEdit

TCP Hybla tar sikte på å eliminere straffer FOR TCP-tilkoblinger som inneholder en terrestrisk eller satellitt-radiokoblinger med høy latens. Hybla forbedringer er basert på analytisk evaluering av lunger vinduet dynamikk.

TCP BICEdit

Binary Increase Congestion control (Bic) Er En tcp-implementering med en optimalisert CCA for høyhastighetsnettverk med høy ventetid, kjent som lange fat-nettverk. BIC brukes som standard I Linux-kjerner 2.6.8 til 2.6.18.

TCP CUBICEdit

CUBIC ER et mindre aggressivt OG mer systematisk derivat AV BIC, der vinduet er en kubisk funksjon av tid siden den siste overbelastningshendelsen, med bøyningspunktet satt til vinduet før hendelsen. CUBIC brukes som standard I Linux-kjerner mellom versjoner 2.6.19 og 3.2.

Agile-SD TCPEdit

Agile-SD Er En Linux-basert CCA som er designet for den virkelige Linux-kjernen. Det er en mottaker-side algoritme som benytter en tap – basert tilnærming ved hjelp av en ny mekanisme, kalt agility factor (AF). for å øke båndbreddeutnyttelsen over høyhastighets-og kortdistansenettverk (lav-BDP-nettverk) som lokalnettverk eller fiberoptisk nettverk, spesielt når den anvendte bufferstørrelsen er liten. Det har blitt evaluert ved å sammenligne ytelsen Til Compound-TCP (standard CCA I MS Windows) og CUBIC (standard Av Linux) ved HJELP AV NS-2 simulator. Det forbedrer den totale ytelsen opp til 55% i løpet av gjennomsnittlig gjennomstrømning.

Tcp Westwood+Edit

Westwood + er en sender-modifikasjon av TCP Reno som optimaliserer ytelsen TIL tcp-overbelastningskontroll over både kablede og trådløse nettverk. Tcp Westwood + er basert på ende-til-ende båndbreddeestimering for å angi overbelastningsvinduet og terskelen for langsom start etter en overbelastningsepisode, det vil si etter tre dupliserte bekreftelser eller en tidsavbrudd. Båndbredden er estimert ved å gjennomsnittlig returnere bekreftelsespakker. I motsetning TIL TCP Reno, som blindt halverer overbelastningsvinduet etter tre dupliserte Acker, setter Tcp Westwood + adaptivt en langsom startgrense og et overbelastningsvindu som tar hensyn til et estimat av båndbredde som er tilgjengelig når overbelastning oppleves. Sammenlignet Med Reno og New Reno, Øker Westwood+ betydelig gjennomstrømning over trådløse koblinger og forbedrer rettferdighet i kablede nettverk.

Compound TCPEdit

Compound TCP er En Microsoft-implementering av TCP som opprettholder to forskjellige overbelastningsvinduer samtidig, med målet om å oppnå god ytelse på Lfner uten å svekke rettferdigheten. Det har vært mye distribuert I Windows-versjoner Siden Microsoft Windows Vista Og Windows Server 2008 og har blitt portet til eldre Microsoft Windows-versjoner samt Linux.

Tcp Proporsjonal Hastighetsreduksjonrediger

TCP Proporsjonal Hastighetsreduksjon (PRR) er en algoritme utviklet for å forbedre nøyaktigheten av data som sendes under gjenoppretting. Algoritmen sikrer at vinduets størrelse etter gjenoppretting er så nær som mulig til den langsomme startgrensen. I tester Utført Av Google resulterte PRR i en 3-10% reduksjon i gjennomsnittlig ventetid og gjenopprettingstidsavbrudd ble redusert med 5%. PRR er tilgjengelig I Linux-kjerner siden versjon 3.2.

TCP BBREdit

Flaskehals Båndbredde Og Rundtur forplantningstid (BBR) er En CCA utviklet Hos Google i 2016. MENS De fleste Cca-Er er tapsbaserte, er DE avhengige av pakketap for å oppdage overbelastning og lavere overføringshastigheter, BBR, som TCP Vegas, modellbasert. Algoritmen bruker maksimal båndbredde og rundtur tid der nettverket levert den siste flyturen av utgående datapakker for å bygge en modell av nettverket. Hver kumulativ eller selektiv bekreftelse av pakkelevering produserer en hastighetsprøve som registrerer mengden data som leveres over tidsintervallet mellom overføringen av en datapakke og bekreftelsen av den pakken. Etter hvert som nettverksgrensesnittkontrollere utvikler seg fra megabit per sekund til gigabit per sekund ytelse, blir ventetiden forbundet med bufferbloat i stedet for pakketap en mer pålitelig markør for maksimal gjennomstrømning, noe som gjør modellbaserte Cca-Er som gir høyere gjennomstrømning og lavere ventetid, for eksempel BBR, et mer pålitelig alternativ til mer populære tapsbaserte algoritmer som TCP CUBIC.BBR HAR vært tilgjengelig For Linux TCP siden Linux 4.9. Det er også tilgjengelig FOR QUIC. BBR versjon 1 (BBRv1) er effektiv og rask, men rettferdigheten til ikke-BBR-strømmer er omstridt. Når implementert På YouTube, bbrv1 ga et gjennomsnitt på 4% høyere nettverk gjennomstrømning og opp til 14% i enkelte land. Mens Googles presentasjon viser BBRv1 sameksisterende godt MED CUBIC, finner forskere Som Geoff Huston Og Hock, Bless og Zitterbart det urettferdig mot andre strømmer og ikke skalerbar. Hock et al fant også «noen alvorlige iboende problemer som økte køforsinkelser, urettferdighet og massivt pakketap» i BBR-implementeringen Av Linux 4.9.

Soheil Abbasloo et al. (forfattere AV C2TCP) viser At BBRv1 ikke fungerer bra i dynamiske miljøer som mobilnettverk. DE har også vist AT BBR har et urettferdighetsproblem. For eksempel, når EN KUBISK strømning (som er standard TCP-implementering I Linux, Android og MacOS) sameksisterer med EN BBR-strømning i nettverket, KAN BBR-strømmen dominere KUBISK strømning og få hele koblingsbåndbredden fra den (se figur 18 i).

Versjon 2 forsøker å håndtere problemet med urettferdighet når de opererer sammen med tapsbasert overbelastning, for eksempel CUBIC. I BBRv2 er modellen som Brukes Av BBRv1 utvidet til å inkludere informasjon om pakketap og informasjon Fra Eksplisitt Congestion Notification (ECN). Mens BBRv2 til tider kan ha lavere gjennomstrømning enn BBRv1, anses det generelt å ha bedre goodput.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) var motivert av mangelen på en fleksibel ende-til-ende TCP-tilnærming som kan tilfredsstille ulike QoS-krav til forskjellige applikasjoner uten å kreve endringer i nettverksenhetene. C2TCP har som mål å tilfredsstille ultra-lav latens og høy båndbredde krav til applikasjoner som virtuell virkelighet, videokonferanser, online gaming, kjøretøy kommunikasjonssystemer, etc. i et svært dynamisk miljø som nåværende LTE og fremtidige 5g-mobilnettverk. C2TCP fungerer som en add-on på toppen av tap-basert TCP (f .Eks Reno, NewReno, CUBIC, BIC,…) og gjør gjennomsnittlig forsinkelse av pakker avgrenset til de ønskede forsinkelser satt av programmene.

Forskere ved NYU viste AT C2TCP overgår forsinkelsen / Jitterytelsen til ulike toppmoderne TCP-ordninger. For eksempel viste de at SAMMENLIGNET MED BBR, CUBIC og Westwood i gjennomsnitt, REDUSERER C2TCP gjennomsnittlig forsinkelse av pakker med henholdsvis 250%, 900% og 700% på ulike mobilnettverksmiljøer.

C2TCP er bare nødvendig å være installert på serversiden.

Elastic-TCPEdit

Elastic-TCP har blitt foreslått i februar 2019 Av Mohamed A. Alrshah et al. for å øke båndbreddeutnyttelsen over høy-BDP-nettverk for å støtte nyere applikasjoner som cloud computing, big data transfer, IoT, etc. Det Er En Linux-basert CCA som er designet for Linux-kjernen. Det er en mottaker-side algoritme som benytter En Tap-forsinkelse-basert tilnærming ved hjelp av en ny mekanisme, Kalt WINDOW-correlated Weighting Function (WWF). Den har et høyt nivå av elastisitet for å håndtere ulike nettverksegenskaper uten behov for menneskelig tuning. Det har blitt evaluert ved å sammenligne ytelsen Til Compound-TCP (standard CCA I MS Windows), CUBIC (standard Av Linux) og TCP-BBR (standard Av Linux 4.9 Av Google) ved HJELP AV NS-2 simulator og testbed. Elastisk-TCP forbedrer den totale ytelsen betydelig i løpet av gjennomsnittlig gjennomstrømning, tapsforhold og forsinkelse.

NATCP /NACubicEdit

Nylig, Soheil Abbasloo og. al. foreslått NATCP (Network-Assisted TCP) et kontroversielt tcp-design rettet Mot Mobile Edge-nettverk som MEC. Nøkkelideen TIL NATCP er at HVIS egenskapene til nettverket var kjent på forhånd, VILLE TCP blitt utformet på en bedre måte. DERFOR BRUKER NATCP de tilgjengelige funksjonene og egenskapene i dagens MEC-baserte cellulære arkitekturer for å presse ytelsen TIL TCP nær optimal ytelse. NATCP bruker en out-of-band tilbakemelding fra nettverket til serverne i nærheten. Tilbakemeldingen fra nettverket, som inkluderer kapasiteten til cellular access link og minimum rtt av nettverket, guider serverne for å justere sendingsratene. Som foreløpige resultater viser, OVERGÅR NATCP state-of-the-art TCP-ordninger ved minst å oppnå 2x høyere Effekt (definert som Gjennomstrømning/Forsinkelse). NATCP erstatter den tradisjonelle TCP-ordningen hos avsenderen.

for å håndtere bakoverkompatibilitet problemet, foreslo de en annen versjon kalt NACubic. NACubic er en bakoverkompatibel design, som krever ingen endring I TCP på de tilkoblede nodene. NACubic benytter mottatt tilbakemelding og håndhever en hette på congestion window (CWND) og pacing rate etter behov.

andre algoritmerrediger

• Rask TCP
• Generalisert RASK TCP
• Datasenter TCP
• Høy Hastighet TCP
• HSTCP-Lp
• TCP-Lp
• TCP-Lp
• TCP-LP
• Tcp SEKK
• Skalerbar TCP

i tcp-fit

• congestion unngåelse med normalisert intervall av tid (Canit)
• Ikke-lineær neural nettverk overbelastning kontroll basert på GENETISK ALGORITME FOR TCP/ip-nettverk

tcp new reno var DEN MEST vanlig implementert algoritme, SACK støtte er svært vanlig og er en utvidelse Til Reno/New Reno. De fleste andre er konkurrerende forslag som fortsatt trenger evaluering. Fra og med 2.6.8 Byttet Linux-kjernen standardimplementeringen Fra Ny Reno TIL BIC. Standardimplementeringen ble igjen endret TIL KUBIKK i 2.6.19-versjonen. FreeBSD bruker Ny Reno som standard algoritme. Den støtter imidlertid en rekke andre valg.

NÅR per-flow-produktet av båndbredde og ventetid øker, uavhengig av køordningen, blir TCP ineffektiv og utsatt for ustabilitet. Dette blir stadig viktigere Som Internett utvikler seg til å innlemme svært høy båndbredde optiske koblinger.

tcp Interactive (iTCP) gjør det mulig for programmer å abonnere PÅ tcp-hendelser og reagere deretter, slik at ulike funksjonelle utvidelser til TCP fra utenfor TCP-laget kan aktiveres. DE FLESTE tcp-overbelastningsordninger fungerer internt. iTCP gjør i tillegg avanserte programmer til å direkte delta i lunger kontroll som å kontrollere kilden generasjon rate.

Zeta-TCP oppdager trengsler fra både latens og tap rate tiltak, og bruker ulike lunger vindu backoff strategier basert på sannsynligheten for lunger for å maksimere goodput. Det har også et par andre forbedringer for å nøyaktig oppdage pakketapene, unngå retransmission timeout retransmission; og akselerere / kontrollere innkommende (nedlastings) trafikk.