Convenția de denumire pentru algoritmii de control al congestiei (CCAs) poate să fi apărut într-o lucrare din 1996 a lui Kevin Fall și Sally Floyd.

următoarea este o posibilă clasificare în funcție de următoarele proprietăți:

1. tipul și cantitatea de feedback primit de la rețea
2. implementabilitate incrementală pe Internetul actual
3. aspectul performanței își propune să îmbunătățească: rețele de produse cu întârziere de lățime de bandă mare (B); legături cu pierderi (L); corectitudine (F); avantaj față de fluxurile scurte; legături; viteza de convergență (C)
4. criteriul de corectitudine pe care îl folosește

unele mecanisme bine cunoscute de evitare a congestiei sunt clasificate de această schemă după cum urmează:

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 lățime de bandă	Max-min
roșu	pierdere	Router	întârziere redusă
ECN	semnal pe un singur bit	expeditor, receptor, Router	pierdere redusă

TCP Tahoe și renoedit

algoritmii TCP Tahoe și Reno au fost denumiți retrospectiv după versiunile sau aromele sistemului de operare 4.3 BSD în care fiecare a apărut pentru prima dată (care au fost ele însele numite după Reno, Nevada). Algoritmul Tahoe a apărut pentru prima dată în 4.3 BSD-Tahoe (care a fost creat pentru a sprijini minicomputerul CCI Power 6/32 „Tahoe”) și a fost ulterior pus la dispoziția licențiaților non-AT&t ca parte a versiunii de rețea 4.3 BSD 1; Acest lucru a asigurat distribuția și implementarea sa largă. Îmbunătățirile au fost făcute în 4.3 BSD-Reno și ulterior lansate publicului ca versiunea de rețea 2 și ulterior 4.4 BSD-Lite.

în timp ce ambele consideră timeout retransmission (RTO) și ACK-uri duplicate ca evenimente de pierdere a pachetelor, comportamentul Tahoe și Reno diferă în primul rând prin modul în care reacționează la ACK-uri duplicate:

• Tahoe: dacă sunt primite trei ACK-uri duplicate (adică patru ACK-uri care recunosc același pachet, care nu sunt piggybacked pe date și nu schimbă fereastra publicizată a receptorului), Tahoe efectuează o retransmitere rapidă, stabilește pragul de pornire lentă la jumătate din fereastra curentă de congestie, reduce congestia fereastră la 1 mss, și resetează pentru a încetini starea de pornire.
• Reno: dacă sunt primite trei ACK-uri duplicate, Reno va efectua o retransmitere rapidă și va sări peste faza de pornire lentă, reducând în schimb la jumătate fereastra de congestie (în loc să o seteze la 1 MSS ca Tahoe), setând pragul de pornire lentă egal cu noua fereastră de congestie și va intra într-o fază numită recuperare rapidă.

atât în Tahoe, cât și în Reno, dacă un ACK expiră (RTO timeout), se folosește pornirea lentă și ambii algoritmi reduc fereastra de congestie la 1 MSS.

TCP VegasEdit

până la mijlocul anilor 1990, toate timeout-urile stabilite de TCP și întârzierile măsurate dus-întors s-au bazat doar pe ultimul pachet transmis în bufferul de transmisie. Cercetătorii Universității din Arizona Larry Peterson și Lawrence Brakmo au introdus TCP Vegas (numit după Las Vegas, cel mai mare oraș din Nevada) în care au fost stabilite timeout-uri și întârzieri dus-întors au fost măsurate pentru fiecare pachet din tamponul de transmisie. În plus, TCP Vegas utilizează creșteri aditive în fereastra de congestie. Într-un studiu comparativ al diferitelor CCAs TCP, TCP Vegas părea a fi cel mai neted urmat de TCP CUBIC.TCP Vegas nu a fost implementat pe scară largă în afara laboratorului Peterson, dar a fost selectat ca metodă implicită de control al congestiei Pentru firmware-ul DD-WRT V24 SP2.

TCP New RenoEdit

TCP New Reno, definit de RFC 6582 (care învechește definițiile anterioare în RFC 3782 și RFC 2582), îmbunătățește retransmisia în timpul fazei de recuperare rapidă a TCP Reno. În timpul recuperării rapide, pentru a menține fereastra de transmisie plină, pentru fiecare ACK duplicat returnat, este trimis un nou pachet netrimis de la sfârșitul ferestrei de congestie. Pentru fiecare ACK care face progrese parțiale în spațiul secvenței, expeditorul presupune că ACK indică o nouă gaură, iar următorul pachet dincolo de numărul secvenței ACKed este trimis.

deoarece timeout – ul este resetat ori de câte ori există progrese în tamponul de transmisie, New Reno poate umple găuri mari sau mai multe găuri în spațiul secvenței-la fel ca TCP SACK. Deoarece new Reno poate trimite pachete noi la sfârșitul ferestrei de congestie în timpul recuperării rapide, debitul ridicat este menținut în timpul procesului de umplere a găurilor, chiar și atunci când există mai multe găuri, de mai multe pachete fiecare. Când TCP intră în recuperare rapidă, înregistrează cel mai mare număr de secvență de pachete nerecunoscut. Când acest număr de secvență este recunoscut, TCP revine la starea de evitare a congestiei.

o problemă apare cu noul Reno atunci când nu există pierderi de pachete, dar în schimb, pachetele sunt reordonate cu mai mult de 3 numere de secvență de pachete. În acest caz, noul Reno intră în mod eronat în recuperare rapidă. Când pachetul reordonat este livrat, apare progresul numărului de secvențe ACK și de acolo până la sfârșitul recuperării rapide, toate progresele numărului de secvențe produc o retransmisie duplicată și inutilă, care este imediat ACKed.

New Reno efectuează, precum și sac la rate de eroare de pachete mici, și substanțial surclasează Reno la rate de eroare ridicate.

TCP HyblaEdit

TCP Hybla își propune să elimine sancțiunile pentru conexiunile TCP care încorporează o legătură radio terestră sau prin satelit cu latență ridicată. Îmbunătățirile Hybla se bazează pe evaluarea analitică a dinamicii ferestrei de congestie.

TCP BICEdit

binar crește controlul congestiei (BIC) este o implementare TCP cu un CCA optimizat pentru rețele de mare viteză cu latență ridicată, cunoscut sub numele de rețele fat lungi. BIC este utilizat în mod implicit în nucleele Linux 2.6.8 până la 2.6.18.

TCP CUBICEdit

CUBIC este un derivat mai puțin agresiv și mai sistematic al BIC, în care fereastra este o funcție cubică de timp de la ultimul eveniment de congestie, cu punctul de inflexiune setat la fereastră înainte de eveniment. CUBIC este utilizat în mod implicit în nucleele Linux între versiunile 2.6.19 și 3.2.

Agile-SD TCPEdit

Agile-SD este un CCA bazat pe Linux, care este proiectat pentru kernel-ul real Linux. Este un algoritm pe partea receptorului care folosește o abordare bazată pe pierderi folosind un mecanism nou, numit factor de agilitate (AF). pentru a crește utilizarea lățimii de bandă în rețelele de mare viteză și pe distanțe scurte (rețele BDP reduse), cum ar fi rețelele locale sau rețeaua de fibră optică, mai ales atunci când dimensiunea tamponului aplicat este mică. Acesta a fost evaluat prin compararea performanței sale la Compound-TCP (implicit CCA în MS Windows) și CUBIC (implicit de Linux) folosind NS-2 simulator. Îmbunătățește performanța totală de până la 55% în ceea ce privește randamentul mediu.

TCP Westwood+Edit

Westwood+ este o modificare numai pentru expeditor a TCP Reno care optimizează performanța controlului congestiei TCP atât în rețelele cu fir, cât și în cele fără fir. TCP Westwood + se bazează pe estimarea lățimii de bandă end-to-end pentru a seta fereastra de congestie și pragul de pornire lentă după un episod de congestie, adică după trei Confirmări duplicate sau un timeout. Lățimea de bandă este estimată prin medierea ratei de returnare a pachetelor de confirmare. Spre deosebire de TCP Reno, care înjumătățește orbește fereastra de congestie după trei ACK-uri duplicate, TCP Westwood+ stabilește adaptiv un prag de pornire lentă și o fereastră de congestie care ia în considerare o estimare a lățimii de bandă disponibile în momentul în care este experimentată congestia. În comparație cu Reno și New Reno, Westwood + crește semnificativ randamentul prin legături wireless și îmbunătățește corectitudinea în rețelele cu fir.

Compound TCPEdit

Compound TCP este o implementare Microsoft a TCP care menține simultan două ferestre de congestie diferite, cu scopul de a obține performanțe bune pe LFN-uri, fără a afecta corectitudinea. Acesta a fost implementat pe scară largă în versiunile Windows de la Microsoft Windows Vista și Windows Server 2008 și a fost portat la versiunile mai vechi Microsoft Windows, precum și Linux.

TCP Proportional Rate ReductionEdit

TCP Proportional Rate Reduction (PRR) este un algoritm conceput pentru a îmbunătăți acuratețea datelor trimise în timpul recuperării. Algoritmul asigură că dimensiunea ferestrei după recuperare este cât mai aproape de pragul de pornire lentă. În testele efectuate de Google, PRR a dus la o reducere de 3-10% a latenței medii, iar termenele de recuperare au fost reduse cu 5%. PRR este disponibil în nucleele Linux de la versiunea 3.2.

TCP BBREdit

strangulare lățime de bandă și timp de propagare dus-întors (BBR) este un CCA dezvoltat la Google în 2016. În timp ce majoritatea CCAs sunt bazate pe pierderi, prin faptul că se bazează pe pierderea pachetelor pentru a detecta congestia și ratele mai mici de transmisie, BBR, cum ar fi TCP Vegas, este bazat pe model. Algoritmul folosește lățimea de bandă maximă și timpul dus-întors la care rețeaua a livrat cel mai recent zbor de pachete de date de ieșire pentru a construi un model al rețelei. Fiecare confirmare cumulativă sau selectivă a livrării de pachete produce un eșantion de rată care înregistrează cantitatea de date livrate în intervalul de timp dintre transmiterea unui pachet de date și confirmarea pachetului respectiv. Pe măsură ce controlerele interfeței de rețea evoluează de la megabit pe secundă la performanță gigabit pe secundă, latența asociată cu bufferbloat în loc de pierderea pachetelor devine un marker mai fiabil al debitului maxim, făcând CCAs bazate pe model care oferă un debit mai mare și o latență mai mică, cum ar fi BBR, o alternativă mai fiabilă la algoritmi mai populari bazați pe pierderi, cum ar fi TCP CUBIC.

BBR este disponibil pentru Linux TCP începând cu Linux 4.9. De asemenea, este disponibil pentru QUIC.

BBR versiunea 1 (BBRv1) este eficientă și rapidă, dar corectitudinea sa față de fluxurile non-BBR este contestată. Când a fost implementat la YouTube, BBRv1 a obținut o medie de transfer de rețea cu 4% mai mare și până la 14% în unele țări. În timp ce prezentarea Google arată BBRv1 coexistând bine cu CUBIC, cercetători precum Geoff Huston și Hock, Bless și Zitterbart consideră că este nedrept față de alte fluxuri și nu este scalabil. Hock și colab au găsit ,de asemenea,” unele probleme inerente severe, cum ar fi întârzieri crescute la coadă, nedreptate și pierderi masive de pachete ” în implementarea BBR a Linux 4.9.

Soheil Abbasloo și colab. (autorii c2tcp) arată că BBRv1 nu funcționează bine în medii dinamice, cum ar fi rețelele celulare. Ei au arătat, de asemenea, că BBR are o problemă de nedreptate. De exemplu, atunci când un flux CUBIC (care este implementarea TCP implicită în Linux, Android și MacOS) coexistă cu un flux BBR în rețea, fluxul BBR poate domina fluxul CUBIC și poate obține întreaga lățime de bandă a legăturii din acesta (vezi Figura 18 in ).

Versiunea 2 încearcă să se ocupe de problema nedreptății atunci când operează alături de managementul congestiei bazat pe pierderi, cum ar fi CUBIC. În BBRv2 modelul utilizat de BBRv1 este mărit pentru a include informații despre pierderea pachetelor și informații din Notificarea explicită a congestiei (ECN). În timp ce BBRv2 poate avea uneori un debit mai mic decât BBRv1, se consideră, în general, că are un randament mai bun.

C2TCPEDIT

cellular controlled Delay TCP (C2TCP) a fost motivat de lipsa unei abordări TCP end-to-end flexibile care să poată satisface diverse cerințe QoS ale diferitelor aplicații fără a necesita modificări ale dispozitivelor de rețea. C2TCP își propune să satisfacă cerințele de latență ultra-scăzută și lățime de bandă ridicată ale aplicațiilor precum realitatea virtuală, videoconferința, jocurile online, sistemele de comunicații auto etc. într-un mediu extrem de dinamic, cum ar fi rețelele celulare LTE actuale și viitoare 5G. C2tcp funcționează ca un add-on pe partea de sus a TCP bazate pe pierderi (de exemplu, Reno, NewReno, CUBIC, BIC,…) și face întârzierea medie a pachetelor delimitate la întârzierile dorite stabilite de aplicații.

cercetătorii de la NYU au arătat că C2TCP depășește performanța de întârziere / bruiaj a diferitelor scheme TCP de ultimă generație. De exemplu, au arătat că, în comparație cu BBR, CUBIC și Westwood în medie, C2TCP scade întârzierea medie a pachetelor cu aproximativ 250%, 900% și respectiv 700% pe diferite medii de rețea celulară.

C2TCP este necesar doar pentru a fi instalat pe server-side.

Elastic-TCPEdit

Elastic-TCP a fost propus în februarie 2019 de Mohamed A. Alrshah și colab. pentru a crește utilizarea lățimii de bandă în rețelele BDP ridicate pentru a sprijini aplicații recente, cum ar fi cloud computing, transfer de date mari, IoT etc. Este un CCA bazat pe Linux, care este proiectat pentru kernel-ul Linux. Este un algoritm pe partea receptorului care folosește o abordare bazată pe pierdere-întârziere folosind un mecanism nou, numit funcția de ponderare corelată cu fereastra (WWF). Are un nivel ridicat de elasticitate pentru a face față diferitelor caracteristici ale rețelei fără a fi nevoie de reglare umană. Acesta a fost evaluat prin compararea performanțelor sale cu Compound-TCP (implicit CCA în MS Windows), CUBIC (implicit de Linux) și TCP-BBR (implicit de Linux 4.9 de Google) folosind NS-2 simulator și testbed. Elastic-TCP îmbunătățește semnificativ performanța totală în ceea ce privește debitul mediu, raportul de pierderi și întârzierea.

NATCP/NACubicEdit

recent, Soheil Abbasloo et. al. propus NATCP (TCP asistat de rețea) un proiect TCP controversat care vizează rețelele de margine mobilă, cum ar fi MEC. Ideea cheie a NATCP este că, dacă caracteristicile rețelei ar fi cunoscute în prealabil, TCP ar fi fost proiectat într-un mod mai bun. Prin urmare, NATCP utilizează caracteristicile și proprietățile disponibile în arhitecturile celulare actuale bazate pe MEC pentru a împinge performanța TCP aproape de performanța optimă. NATCP utilizează un feedback out-of-band de la rețea la serverele situate în apropiere. Feedback-ul din rețea, care include capacitatea linkului de acces celular și RTT-ul minim al rețelei, ghidează serverele să își ajusteze ratele de trimitere. După cum arată rezultatele preliminare, NATCP depășește schemele TCP de ultimă generație, obținând cel puțin o putere de 2x mai mare (definită ca debit/întârziere). NATCP înlocuiește schema TCP tradițională la expeditor.

pentru a rezolva problema compatibilității înapoi, au propus o altă versiune numită NACubic. NACubic este un design compatibil înapoi, care nu necesită nicio modificare a TCP pe nodurile conectate. NACubic utilizează feedback-ul primit și impune un plafon pentru fereastra de congestie (CWND) și rata de stimulare, după cum este necesar.

alte TCP evitarea congestiei algoritmsedit

• fast TCP
• generalizate rapid TCP
• H-TCP
• Data Center TCP
• mare viteză TCP
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• TCP sac
• scalabil TCP
• TCP veno
• Westwood
• XCP
• da-TCP
• TCP-fit
• evitarea congestiei cu interval de timp normalizat (Canit)
• controlul congestiei rețelei neuronale neliniare bazat pe algoritmul genetic pentru rețelele TCP/IP

TCP New Reno a fost cel mai frecvent implementat algoritm, suport sac este foarte frecvente și este o extensie a Reno/New Reno. Majoritatea celorlalte sunt propuneri concurente care încă mai au nevoie de evaluare. Începând cu 2.6.8 kernel-ul Linux a schimbat implementarea implicită de la New Reno la BIC. Implementarea implicită a fost din nou schimbată în cub în versiunea 2.6.19. FreeBSD folosește noul Reno ca algoritm implicit. Cu toate acestea, acceptă o serie de alte opțiuni.

când produsul per flux al lățimii de bandă și latenței crește, indiferent de schema de așteptare, TCP devine ineficient și predispus la instabilitate. Acest lucru devine din ce în ce mai important pe măsură ce Internetul evoluează pentru a încorpora legături optice cu lățime de bandă foarte mare.TCP Interactive (iTCP) permite aplicațiilor să se aboneze la evenimente TCP și să răspundă în consecință, permițând diferite extensii funcționale la TCP din afara stratului TCP. Majoritatea schemelor de congestie TCP funcționează intern. în plus, iTCP permite aplicațiilor avansate să participe direct la controlul congestiei, cum ar fi controlul ratei de generare a sursei.

Zeta-TCP detectează congestiile atât din măsurile de latență, cât și din rata pierderii și aplică diferite strategii de backoff a ferestrei de congestie bazate pe probabilitatea congestiilor pentru a maximiza goodput-ul. De asemenea, are câteva alte îmbunătățiri pentru a detecta cu exactitate pierderile de pachete, evitând retransmisia timeout retransmisie; și accelera/controla traficul de intrare (descărcare).