a torlódás-ellenőrzési algoritmusok elnevezési konvenciója (cca) Kevin Fall és Sally Floyd 1996-os tanulmányából származhat.

a következő lehetséges osztályozás a következő tulajdonságok szerint:

1. a hálózattól kapott visszajelzések típusa és mennyisége
2. növekményes telepíthetőség a jelenlegi Interneten
3. a teljesítmény szempontja, amelyet javítani kíván: nagy sávszélességű késleltetett termékhálózatok (B); veszteséges linkek (L); méltányosság (F); előny a rövid áramlásokkal szemben; változó sebességű linkek (V); konvergencia sebessége (C)
4. az általa alkalmazott méltányossági kritérium

néhány jól ismert torlódás-elkerülési mechanizmust ez a séma a következőképpen osztályoz:

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 sávszélesség	Max-min
piros	veszteség	Router	csökkentett késleltetés
ECN	egybites jel	küldő, Vevő, Router	csökkentett veszteség

TCP Tahoe and renoedit

a TCP Tahoe és Reno algoritmusokat visszamenőlegesen nevezték el a 4.3 BSD operációs rendszer verzióiról vagy ízeiről, amelyekben először megjelentek (amelyek maguk is a Tahoe-tóról és a közeli Tahoe-ról nevezték el) Reno városa, Nevada). A Tahoe algoritmus először a 4.3 BSD-Tahoe-ban jelent meg (amely a CCI Power 6/32 “Tahoe” miniszámítógép támogatására készült), majd később elérhetővé vált a nem AT&t licencek számára a 4.3 BSD Networking Release 1 részeként; ez biztosította annak széles körű terjesztését és megvalósítását. A fejlesztések a 4.3 BSD-Reno-ban történtek, majd később a Networking Release 2, majd a 4.4 BSD-Lite néven jelentek meg a nyilvánosság számára.

míg mindkettő az újraküldési időtúllépést (RTO) és a duplikált ACK-kat csomagvesztési eseményeknek tekinti, a Tahoe és a Reno viselkedése elsősorban abban különbözik, hogy hogyan reagálnak a duplikált ACK-kra:

• Tahoe: ha három duplikált ACK-t fogadnak (azaz négy ACK-t, amelyek ugyanazt a csomagot nyugtázzák, amelyek nem kapcsolódnak az adatokhoz, és nem változtatják meg a vevő hirdetett ablakát), Tahoe gyors újraküldést hajt végre, a lassú indítási küszöböt az aktuális torlódási ablak felére állítja, csökkenti a torlódást ablak 1 ms-ra, és visszaáll a lassú indítási állapotra.
• Reno: ha három duplikált ACK érkezik, a Reno gyors újraküldést hajt végre, és kihagyja a lassú indítási fázist azáltal, hogy a torlódási ablakot felére csökkenti (ahelyett, hogy 1 MSS-re állítaná, mint Tahoe), a lassú indítási küszöböt az új torlódási ablaknak megfelelően állítja be, és belép a gyors helyreállítás nevű fázisba.

Tahoe-ban és Reno-ban is, ha ACK időkorlátot (RTO timeout) használnak, lassú indítást használnak, és mindkét algoritmus 1 ms-ra csökkenti a torlódási ablakot.

TCP VegasEdit

az 1990-es évek közepéig a TCP összes beállított időkorlátja és mért oda-vissza késése csak az utolsó továbbított csomagon alapult az átviteli pufferben. Az Arizonai Egyetem kutatói, Larry Peterson és Lawrence Brakmo bevezették a TCP Vegast (Nevada legnagyobb városáról, Las Vegasról nevezték el), amelyben időtúllépéseket állapítottak meg és az oda-vissza késéseket mérték az átviteli pufferben lévő minden csomag esetében. Ezenkívül a TCP Vegas additív növekedést használ a torlódási ablakban. A különböző TCP cca-k összehasonlító vizsgálatában a TCP Vegas tűnt a legsimábbnak, amelyet a TCP CUBIC követett.

a TCP Vegas-t nem széles körben telepítették Peterson laboratóriumán kívül, de a DD-WRT firmware V24 SP2 alapértelmezett torlódás-ellenőrzési módszerének választották.

TCP New RenoEdit

az RFC 6582 által meghatározott TCP New Reno (amely elavulttá teszi az RFC 3782 és RFC 2582 korábbi definícióit) javítja az újraküldést a TCP Reno gyors helyreállítási szakaszában. A gyors helyreállítás során, hogy az átviteli ablak tele legyen, minden ismétlődő ACK-hoz, amelyet visszaad, egy új, el nem küldött csomagot küld a torlódási ablak végéről. Minden olyan ACK esetében, amely részlegesen halad a szekvencia térben, a feladó feltételezi, hogy az ACK egy új lyukra mutat, és a következő csomag az ACK sorszámon túl kerül elküldésre.

mivel az időtúllépés visszaáll, amikor előrehaladás történik az átviteli pufferben, az új Reno nagy lyukakat vagy több lyukat tölthet be a szekvencia térben – hasonlóan a TCP SACKHEZ. Mivel az új Reno a gyors helyreállítás során új csomagokat küldhet a torlódási ablak végén, a lyuktöltési folyamat során nagy áteresztőképesség marad fenn, még akkor is, ha több lyuk van, több csomagból. Amikor a TCP belép a gyors helyreállításba, rögzíti a legmagasabb kiemelkedő, el nem ismert csomagsorozatot. Ha ezt a sorszámot nyugtázza, a TCP visszatér a torlódások elkerülésének állapotába.

probléma merül fel az új Reno-val, ha nincsenek csomagveszteségek, hanem ehelyett a csomagokat több mint 3 csomagsorszám rendezi át. Ebben az esetben az új Reno tévesen belép a gyors helyreállításba. Az újrarendezett csomag kézbesítésekor az ACK szekvenciaszám előrehaladása megtörténik, és onnan a gyors helyreállítás végéig az összes szekvenciaszám előrehaladása egy duplikált és szükségtelen újraküldést eredményez, amely azonnal ACKed.

az új Reno ugyanúgy teljesít, mint a SACK alacsony csomaghiba-arány mellett, és jelentősen felülmúlja a Reno-t magas hibaarány mellett.

TCP HyblaEdit

a TCP Hybla célja, hogy megszüntesse a magas késleltetésű földi vagy műholdas rádiókapcsolatokat tartalmazó TCP-kapcsolatok szankcióit. A Hybla fejlesztései a torlódási ablak dinamikájának analitikus értékelésén alapulnak.

TCP BICEdit

a bináris torlódás-szabályozás (BIC) egy TCP megvalósítás optimalizált CCA-val nagy sebességű, nagy késleltetésű hálózatokhoz, úgynevezett hosszú fat hálózatok. A BIC alapértelmezés szerint a 2.6.8-tól 2.6.18-ig terjedő Linux kernelekben használatos.

TCP CUBICEdit

A CUBIC a BIC kevésbé agresszív és szisztematikusabb deriváltja, amelyben az ablak az utolsó torlódási esemény óta eltelt idő köbös függvénye, az inflexiós pont az esemény előtti ablakra van állítva. A CUBIC-ot alapértelmezés szerint a Linux kernelekben használják a 2.6.19 és a 3.2 verziók között.

Agile-SD TCPEdit

Agile-SD egy Linux-alapú CCA, amely célja az igazi Linux kernel. Ez egy vevőoldali algoritmus, amely veszteségalapú megközelítést alkalmaz egy új mechanizmus, az úgynevezett agility factor (Af) alkalmazásával. a sávszélesség kihasználásának növelése nagy sebességű és rövid távú hálózatokon (alacsony BDP hálózatok), például helyi hálózatokon vagy száloptikai hálózatokon, különösen akkor, ha az alkalmazott puffer mérete kicsi. Teljesítményét a Compound-TCP (az alapértelmezett CCA az MS Windows rendszerben) és a CUBIC (Az alapértelmezett Linux) teljesítményével hasonlították össze az NS-2 simulator segítségével. Javítja a teljes teljesítményt akár 55% – kal az átlagos áteresztőképesség szempontjából.

TCP Westwood+Szerkesztés

a Westwood+ a TCP Reno csak Feladó módosítása, amely optimalizálja a TCP torlódások vezérlésének teljesítményét mind a vezetékes, mind a vezeték nélküli hálózatokon. A TCP Westwood + a végpontok közötti sávszélesség becslésén alapul, hogy beállítsa a torlódási ablakot és a lassú indítási küszöböt egy torlódási epizód után, azaz három ismétlődő nyugtázás vagy időtúllépés után. A sávszélességet a nyugtázó csomagok visszatérési sebességének átlagolásával becsüljük meg. Ellentétben a TCP Reno-val, amely vakon felezi a torlódási ablakot három duplikált ACK után, a TCP Westwood+ adaptívan állít be egy lassú indítási küszöböt és egy torlódási ablakot, amely figyelembe veszi a torlódás idején rendelkezésre álló sávszélesség becslését. A Reno-hoz és az új Reno-hoz képest a Westwood+ jelentősen növeli a vezeték nélküli kapcsolatok átviteli sebességét és javítja a Vezetékes hálózatok méltányosságát.

összetett TCPEdit

összetett TCP a TCP Microsoft megvalósítása, amely két különböző torlódási ablakot tart fenn egyszerre, azzal a céllal, hogy jó teljesítményt érjen el az LFNs-en, miközben nem rontja a méltányosságot. A Microsoft Windows Vista és a Windows Server 2008 óta széles körben alkalmazzák a Windows verziókban, és régebbi Microsoft Windows verziókra, valamint Linuxra is portolták.

TCP Proportional Rate ReductionEdit

a TCP Proportional Rate Reduction (PRR) egy algoritmus, amelynek célja a helyreállítás során küldött adatok pontosságának javítása. Az algoritmus biztosítja, hogy az ablak mérete a helyreállítás után a lehető legközelebb legyen a lassú indítási küszöbhöz. A Google által végzett tesztek során a PRR az átlagos késleltetés 3-10% – os csökkenését eredményezte, a helyreállítási időkorlátok pedig 5% – kal csökkentek. A PRR a 3.2-es verzió óta elérhető Linux kernelekben.

TCP BBREdit

szűk sávszélesség és oda-vissza terjedési idő (BBR) egy cca, amelyet a Google fejlesztett ki 2016-ban. Míg a legtöbb cca veszteségalapú, mivel a csomagvesztésre támaszkodnak a torlódások és az alacsonyabb átviteli sebesség észlelésében, a BBR, mint a TCP Vegas, modellalapú. Az algoritmus azt a maximális sávszélességet és oda-vissza időt használja, amikor a hálózat a kimenő adatcsomagok legutóbbi repülését szállította a hálózat modelljének felépítéséhez. A csomagküldés minden egyes kumulatív vagy szelektív nyugtázása egy sebességmintát hoz létre, amely rögzíti az adatcsomag továbbítása és a csomag nyugtázása közötti időintervallumban szállított adatok mennyiségét. Mivel a hálózati interfész vezérlők másodpercenként megabitről gigabit / másodperc teljesítményre fejlődnek, a csomagvesztés helyett a pufferbloat-hoz kapcsolódó késleltetés a maximális átviteli sebesség megbízhatóbb jelölőjévé válik, így a modellalapú cca-k, amelyek nagyobb átviteli sebességet és alacsonyabb késleltetést biztosítanak, mint pl BBR, megbízhatóbb alternatíva a népszerűbb veszteségalapú algoritmusokhoz, mint pl TCP köbös.

a BBR a Linux 4.9 óta elérhető a Linux TCP számára. A QUIC számára is elérhető.

a BBR 1-es verziója (BBRv1) hatékony és gyors, de a nem BBR-adatfolyamokkal szembeni igazságossága vitatott. Amikor a YouTube-on bevezették, a BBRv1 átlagosan 4% – kal nagyobb hálózati teljesítményt eredményezett, egyes országokban pedig akár 14% – kal is. Míg a Google bemutatója azt mutatja, hogy a BBRv1 jól működik együtt a CUBIC-szal, a kutatók, mint Geoff Huston és Hock, Bless és Zitterbart igazságtalannak találják a többi adatfolyamot, és nem skálázhatók. Hock és szerzőtársai a Linux 4.9 BBR implementációjában “olyan súlyos problémákat is találtak, mint a megnövekedett várakozási idő, az igazságtalanság és a hatalmas csomagvesztés”.

Soheil Abbasloo et al. (a c2tcp szerzői) azt mutatják, hogy a BBRv1 nem teljesít jól dinamikus környezetekben, például mobilhálózatokban. Azt is megmutatták, hogy a BBR-nek igazságtalansága van. Például, amikor egy CUBIC flow (ami az alapértelmezett TCP implementáció Linuxban, Androidban és MacOS-ban) együtt létezik egy BBR flow-val a hálózatban, a BBR flow uralhatja a CUBIC flow-t, és megkaphatja a teljes link sávszélességet (lásd a 18.ábrát).

a 2.verzió megpróbálja kezelni a tisztességtelenség kérdését, amikor veszteségalapú torlódás-menedzsment mellett működik, mint pl köbös. A BBRv2-ben a BBRv1 által használt modellt kibővítették, hogy tartalmazza a csomagvesztéssel kapcsolatos információkat és az Explicit torlódási értesítésből (ECN) származó információkat. Míg a BBRv2 időnként alacsonyabb átviteli sebességgel rendelkezik, mint a BBRv1, általában jobb goodputnak tekintik.

C2TCPEdit

a Cellular Controlled Delay TCP-t (C2TCP) a rugalmas végpontok közötti TCP-megközelítés hiánya motiválta, amely kielégíti a különböző alkalmazások különböző QoS-követelményeit anélkül, hogy bármilyen változtatást igényelne a hálózati eszközökben. A C2TCP célja az olyan alkalmazások rendkívül alacsony késleltetési és nagy sávszélességi követelményeinek kielégítése, mint a virtuális valóság, a videokonferencia, az online játékok, a járműkommunikációs rendszerek stb. olyan rendkívül dinamikus környezetben, mint a jelenlegi LTE és a jövőbeli 5G mobilhálózatok. C2TCP működik, mint egy add-on tetején veszteség alapú TCP (pl Reno, NewReno, CUBIC, BIC,…), és a csomagok átlagos késleltetését az alkalmazások által beállított kívánt késleltetésekre korlátozza.

a NYU kutatói kimutatták, hogy a C2TCP felülmúlja a különböző korszerű TCP rendszerek késleltetési/Jitter teljesítményét. Például kimutatták, hogy a BBR, a CUBIC és a Westwood átlagához képest a C2TCP körülbelül 250% – kal, 900% – kal, illetve 700% – kal csökkenti a csomagok átlagos késleltetését különböző mobilhálózati környezetekben.

a C2TCP-t csak a szerver oldalon kell telepíteni.

Elastic-TCPEdit

az Elastic-TCP-t 2019 februárjában javasolta Mohamed A. Alrshah et al. a sávszélesség kihasználásának növelése a magas BDP hálózatokon keresztül a legújabb alkalmazások, például a felhőalapú számítástechnika, a nagy adatátvitel, az IoT stb. Ez egy Linux-alapú CCA, amelyet a Linux kernelhez terveztek. Ez egy vevőoldali algoritmus, amely veszteség-késleltetés alapú megközelítést alkalmaz egy új mechanizmus alkalmazásával, az úgynevezett ablak-Korrelált súlyozási függvény (WWF). Magas szintű rugalmassággal rendelkezik a különböző hálózati jellemzők kezeléséhez emberi hangolás nélkül. Teljesítményét a Compound-TCP (az alapértelmezett CCA az MS Windows rendszerben), a CUBIC (Az alapértelmezett Linux) és a TCP-BBR (az alapértelmezett Linux 4.9 A Google által) teljesítményével hasonlították össze az NS-2 szimulátor és a testbed használatával. Az Elastic-TCP jelentősen javítja a teljes teljesítményt az átlagos áteresztőképesség, a veszteségarány és a késleltetés tekintetében.

NATCP/NACubicEdit

nemrég, Soheil Abbasloo et. al. javasolt NATCP (Network-Assisted TCP) ellentmondásos TCP tervezés, amely a mobil Edge hálózatokat, például a MEC-t célozza meg. A NATCP legfontosabb gondolata az, hogy ha a hálózat jellemzői előzetesen ismertek lennének, a TCP-t jobb módon tervezték volna meg. Ezért a NATCP a jelenlegi MEC-alapú celluláris architektúrákban elérhető funkciókat és tulajdonságokat alkalmazza, hogy a TCP teljesítményét az optimális teljesítményhez közelítse. A NATCP sávon kívüli visszajelzést használ a hálózatról a közelben található szerverekre. A hálózat visszajelzése, amely magában foglalja a mobil hozzáférési kapcsolat kapacitását és a hálózat minimális RTT-jét, irányítja a szervereket a küldési arányok beállításához. Az előzetes eredmények azt mutatják, hogy a NATCP felülmúlja a legkorszerűbb TCP sémákat legalább 2x nagyobb teljesítmény elérésével (áteresztőképesség/késleltetés). A NATCP helyettesíti a hagyományos TCP sémát a feladónál.

A visszamenőleges kompatibilitási probléma kezelésére egy másik verziót javasoltak NACubic. A NACubic egy visszafelé kompatibilis kialakítás, amely nem igényli a TCP módosítását a csatlakoztatott csomópontokon. A NACubic a kapott visszajelzéseket alkalmazza, és szükség szerint korlátozza a torlódási ablakot (cwnd) és az ingerelési arányt.

Egyéb TCP torlódás elkerülő algoritmusokszerkesztés

• gyors TCP
• Általános gyors TCP
• H-TCP
• adatközpont TCP
• nagy sebességű TCP
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• TCP SACK
• skálázható TCP
• TCP veno
• Westwood
• XCP
• igen-TCP
• TCP-fit
• torlódások elkerülése normalizált időintervallummal (Canit)
• nemlineáris neurális hálózati torlódások ellenőrzése a TCP/IP hálózatok genetikai algoritmusán alapul

a TCP New Reno volt a leggyakrabban megvalósított az algoritmus, a SACK támogatás nagyon gyakori, és a Reno/New Reno kiterjesztése. A legtöbb más versengő pályázat, amelyet még értékelni kell. A 2.6.8-tól kezdve a Linux kernel az alapértelmezett megvalósítást az új Reno-ról BIC-re váltotta. Az alapértelmezett megvalósítás ismét KÖBÖSRE változott a 2.6.19-es verzióban. A FreeBSD az új Reno-t használja alapértelmezett algoritmusként. Ez azonban számos más választást támogat.

amikor a sávszélesség és a késleltetés per-flow szorzata növekszik, függetlenül a sorban állási sémától, a TCP hatástalanná válik, és hajlamos az instabilitásra. Ez egyre fontosabbá válik, mivel az Internet fejlődik a nagyon nagy sávszélességű optikai kapcsolatok beépítésére.

a TCP Interactive (iTCP) lehetővé teszi az alkalmazások számára, hogy feliratkozzanak a TCP eseményekre, és ennek megfelelően reagáljanak, lehetővé téve a TCP különböző funkcionális kiterjesztéseit a TCP rétegen kívülről. A legtöbb TCP torlódási séma belsőleg működik. az iTCP emellett lehetővé teszi a fejlett alkalmazások számára, hogy közvetlenül részt vegyenek a torlódások ellenőrzésében, például a forrásgenerálási sebesség szabályozásában.

a Zeta-TCP felismeri a torlódásokat mind a késleltetési, mind a veszteségi Arány méréséből, és különböző torlódási ablak-visszalépési stratégiákat alkalmaz a torlódások valószínűsége alapján a goodput maximalizálása érdekében. Van még néhány további fejlesztés a csomagveszteségek pontos észlelésére, elkerülve az újraküldés időtúllépését; és felgyorsítja/vezérli a bejövő (letöltési) forgalmat.