CCA: n (CCP) nimeämiskäytäntö saattaa olla peräisin Kevin Fallin ja Sally Floydin vuonna 1996 julkaisemasta tutkielmasta.

seuraava on yksi mahdollinen luokittelu seuraavien ominaisuuksien perusteella:

1. verkosta saadun palautteen tyyppi ja määrä
2. lisääntyvä käyttöönotto nykyisellä Internetissä
3. se suorituskyvyn osa-alue, jota sillä pyritään parantamaan: korkean kaistanleveyden viiveet tuoteverkot (B); häviölliset linkit (L); oikeudenmukaisuus (F); lyhyiden virtojen etu( S); vaihtuvakorkoiset linkit (V); lähentymisnopeus (C)
4. sen käyttämä oikeudenmukaisuuskriteeri

eräät tunnetut ylikuormituksen välttämismekanismit luokitellaan tässä järjestelmässä seuraavasti:

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 kaistanleveys	Max-min
RED	reititin	pienennetty viive
ECN	Yksibittinen signaali	Lähettäjä, Vastaanottaja, reititin	pienennetty häviö

TCP Tahoe ja renoedit

TCP Tahoe-ja Reno-algoritmit nimettiin jälkikäteen niiden 4.3 BSD-käyttöjärjestelmän versioiden tai makujen mukaan, joissa kukin esiintyi ensimmäisen kerran (jotka itse nimettiin Tahoe-järven ja läheisen Renon kaupunki, Nevada). Tahoe-algoritmi esiintyi ensimmäisen kerran 4.3 BSD-Tahoessa (joka tehtiin tukemaan CCI Power 6/32 ”Tahoe”-minitietokonetta), ja myöhemmin se annettiin ei-AT: n&t-lisenssinhaltijoiden saataville osana 4.3 BSD Networking Release 1: tä; tämä varmisti sen laajan jakelun ja toteutuksen. Parannuksia tehtiin 4.3 BSD-Renossa ja julkaistiin myöhemmin yleisölle nimellä Networking Release 2 ja myöhemmin 4.4 BSD-Lite.

vaikka molemmat pitävät edelleenlähetyksen aikakatkaisua (RTO) ja kaksoiskappaleita pakettihäviötapahtumina, Tahoen ja Renon käyttäytyminen eroaa pääasiassa siitä, miten ne reagoivat kaksoiskappaleisiin:

• Tahoe: jos vastaanotetaan kolme kaksoiskappaletta (eli neljä saman paketin tunnustavaa ACK: ta, joita ei ole piggybackattu dataan eivätkä ne muuta vastaanottajan mainostettua ikkunaa), Tahoe suorittaa nopean edelleenlähetyksen, asettaa hitaan aloituskynnyksen puoleen nykyisestä ruuhkautumisikkunasta, vähentää ruuhkautumista ikkuna 1 ms: ään ja nollautuu hitaaseen aloitustilaan.
• Reno: jos vastaanotamme kolme päällekkäistä ACK: ta, Reno suorittaa nopean edelleenlähetyksen ja ohittaa hitaan käynnistysvaiheen puolittamalla ruuhkautumisikkunan (sen sijaan, että se asetettaisiin 1 MS: ään kuten Tahoe), asettamalla hitaan käynnistyksen kynnysarvo vastaa uutta ruuhkautumisikkunaa ja siirtyy vaiheeseen nimeltä fast recovery.

sekä Tahoessa että Renossa, jos ACK times out (RTO timeout), käytetään hidasta aloitusta, ja molemmat algoritmit vähentävät ruuhkautumisikkunan 1 MS: ään.

TCP VegasEdit

1990-luvun puoliväliin asti kaikki TCP: n asettamat aikalisät ja mitatut edestakaiset viivästykset perustuivat vain viimeiseen lähetettyyn pakettiin lähetyspuskurissa. Arizonan yliopiston tutkijat Larry Peterson ja Lawrence Brakmo esittelivät TCP Vegasin (nimetty Nevadan suurimman kaupungin Las Vegasin mukaan), jossa aikalisät asetettiin ja edestakaiset viivästykset mitattiin jokaisesta lähetyspuskurissa olevasta paketista. Lisäksi TCP Vegas käyttää lisäkorotuksia ruuhkaikkunassa. Vertailututkimuksessa eri TCP CCAs, TCP Vegas näytti olevan tasaisin seuraa TCP kuutio.

TCP Vegasia ei otettu laajasti käyttöön Petersonin laboratorion ulkopuolella, mutta se valittiin DD-WRT-laiteohjelmiston V24 SP2: n oletusturvaohjausmenetelmäksi.

TCP New RenoEdit

TCP New Renoedit, määritelty RFC 6582: ssa (joka vanhentaa aiemmat määritelmät RFC 3782: ssa ja RFC 2582: ssa), parantaa uudelleenlähetystä TCP Renon nopean palautumisvaiheen aikana. Aikana nopea elpyminen, pitää lähetysikkunan täynnä, jokaista päällekkäistä ACK, joka palautetaan, Uusi lähettämätön paketti päässä ruuhkautumisikkunan lähetetään. Jokaista ACK: ta kohti, joka etenee osittain sekvenssiavaruudessa, lähettäjä olettaa, että ACK osoittaa uuteen reikään, ja seuraava paketti, joka ylittää ACK: n järjestysnumeron, lähetetään.

koska aikalisä nollataan aina, kun lähetyspuskurissa tapahtuu edistystä, Uusi Reno voi täyttää sekvenssiavaruudessa suuria reikiä tai useita reikiä – aivan kuten TCP-säkki. Koska uusi Reno voi lähettää uusia paketteja ruuhkautumisikkunan lopussa nopean palautumisen aikana, suuri läpimenokyky säilyy reikien täyttöprosessin aikana, vaikka reikiä olisi useita, useita paketteja. Kun TCP siirtyy nopeaan palautukseen, se tallentaa korkeimman jäljellä olevan pakettien järjestysnumeron. Kun tämä järjestysnumero on hyväksytty, TCP palaa ruuhkien välttämistilaan.

uuden Renon kanssa syntyy ongelma, kun pakettihäviöitä ei ole, mutta sen sijaan paketteja järjestellään uudelleen yli 3 paketin järjestysnumerolla. Tällöin Uusi Reno siirtyy virheellisesti nopeaan palautumiseen. Kun uudelleenjärjestetty paketti toimitetaan, ACK sekvenssi-numero edistystä tapahtuu ja sieltä loppuun asti nopea elpyminen, kaikki sekvenssi-numero edistystä tuottaa kaksoiskappaleen ja tarpeetonta edelleenlähetys, joka on välittömästi ACKed.

New Reno toimii yhtä hyvin kuin SACK alhaisilla pakettivirhemäärillä ja päihittää Renon huomattavasti korkeilla virhemäärillä.

TCP HyblaEdit

TCP Hybla pyrkii poistamaan rangaistukset TCP-yhteyksiltä, jotka sisältävät korkean latenssin maanpäällisiä tai satelliittiradiolinkkejä. Hybla-parannukset perustuvat ruuhkaikkunan dynamiikan analyyttiseen arviointiin.

TCP BICEdit

Binary Increase Congrangtion control (BIC) on TCP-toteutus, jossa on optimoitu cca suurnopeusverkoille, joilla on korkea latenssi, ns.long fat networks. BIC: tä käytetään oletuksena Linux-ytimissä 2.6.8-2.6.18.

TCP CUBICEdit

CUBIC on BIC: n vähemmän aggressiivinen ja systemaattisempi derivaatta, jossa ikkuna on edellisen ruuhkatapahtuman jälkeisen ajan kuutiofunktio, jonka taivutuspiste on asetettu ikkunaan ennen tapahtumaa. Kuutiota käytetään oletuksena Linux-ytimissä versioiden 2.6.19 ja 3.2 välillä.

Agile-SD TCPEdit

Agile-SD on Linux-pohjainen CCA, joka on suunniteltu oikealle Linux-ytimelle. Se on vastaanottimen puolen algoritmi, joka käyttää tappiopohjaista lähestymistapaa käyttäen uutta mekanismia, nimeltään agility factor (Af). lisätä kaistanleveyden käyttöä suurten nopeuksien ja lyhyen matkan verkoissa (low-BDP-verkoissa), kuten lähiverkoissa tai valokuituverkossa, erityisesti silloin, kun käytetty puskurikoko on pieni. Sitä on arvioitu vertaamalla sen suorituskykyä Compound-TCP: hen (oletus CCA MS Windowsissa) ja CUBIC: iin (Linuxin oletusarvo) NS-2 simulaattorilla. Se parantaa kokonaissuoritusta jopa 55% keskimääräisestä suoritustehosta.

TCP Westwood+Edit

Westwood+ on TCP Renon lähettäjä-muunnos, joka optimoi TCP: n ruuhkien hallinnan sekä langallisissa että langattomissa verkoissa. TCP Westwood+ perustuu päästä päähän-kaistanleveyden estimointiin, jolla asetetaan ruuhkautumisikkuna ja hitaan käynnistyksen kynnys ruuhkautumisjakson jälkeen eli kolmen päällekkäisen kuittauksen tai aikalisän jälkeen. Kaistanleveys arvioidaan palauttavien kuittauspakettien keskiarvon perusteella. Toisin kuin TCP Reno, joka sokeasti puolittaa ruuhkaikkunan kolmen päällekkäisen akun jälkeen, TCP Westwood+ asettaa mukautuvasti hitaan käynnistyskynnyksen ja ruuhkaikkunan, jossa otetaan huomioon arvio ruuhkautumishetkellä käytettävissä olevasta kaistanleveydestä. Renoon ja Uuteen Renoon verrattuna Westwood+ lisää merkittävästi langattomien linkkien läpimenoa ja parantaa oikeudenmukaisuutta langallisissa verkoissa.

yhdiste TCPEdit

yhdiste TCP on Microsoftin TCP-toteutus, joka ylläpitää kahta eri ruuhkaikkunaa samanaikaisesti, tavoitteenaan saavuttaa hyvä suorituskyky LFNs: llä heikentämättä kuitenkaan oikeudenmukaisuutta. Se on ollut laajalti käytössä Windows-versioissa Microsoft Windows Vistan ja Windows Server 2008: n jälkeen, ja se on siirretty vanhempiin Microsoft Windows-versioihin sekä Linuxiin.

TCP Proportional Rate ReductionEdit

TCP Proportional Rate Reduction (PRR) on algoritmi, jonka tarkoituksena on parantaa palautuksen aikana lähetettyjen tietojen tarkkuutta. Algoritmi varmistaa, että ikkunan koko palautumisen jälkeen on mahdollisimman lähellä hitaan aloituskynnystä. Googlen tekemissä testeissä PRR johti 3-10%: n keskimääräiseen viiveeseen ja palautumisaikoja vähennettiin 5%. PRR on saatavilla Linux-ytimissä versiosta 3.2 lähtien.

TCP BBREdit

pullonkaula kaistanleveys ja edestakainen etenemisaika (BBR) on Googlen vuonna 2016 kehittämä CCA. Vaikka useimmat CCAs ovat tappioperusteisia, koska ne luottavat pakettihäviöön havaitakseen ruuhkautumisen ja alhaisemmat siirtonopeudet, BBR, kuten TCP Vegas, on mallipohjainen. Algoritmi käyttää suurinta kaistanleveyttä ja edestakaista aikaa, jolla verkko toimitti viimeisimmän lähtevien datapakettien lennon, rakentaakseen verkon mallin. Kukin pakettitoimituksen kumulatiivinen tai valikoiva vahvistus tuottaa nopeusnäytteen, joka tallentaa toimitetun datan määrän datapaketin lähettämisen ja kyseisen paketin vastaanottamisen välisenä aikana. Kun verkkoliittymäohjaimet kehittyvät megabitistä sekunnissa gigabitiksi sekunnissa, puskurivuoraukseen liittyvä latenssi pakettihäviön sijaan tulee luotettavammaksi suurimman läpimenon merkiksi, jolloin mallipohjaiset CCAs: t, jotka tarjoavat suuremman läpimenon ja pienemmän latenssin, kuten BBR, ovat luotettavampi vaihtoehto suositummille tappiopohjaisille algoritmeille, kuten TCP-kuutiolle.

BBR on ollut saatavilla Linux TCP: lle Linux 4.9: stä lähtien. Se on saatavilla myös QUIC.

BBR-versio 1 (BBRv1) on tehokas ja nopea, mutta sen oikeudenmukaisuus ei-BBR-virtoihin nähden on kiistanalainen. YouTubessa toteutettuna Bbrv1 tuotti keskimäärin 4% suuremman verkon läpimenon ja joissakin maissa jopa 14%. Vaikka Googlen esitys osoittaa BBRv1 co-existing hyvin CUBIC, tutkijat kuten Geoff Huston ja Hock, Bless ja Zitterbart pitää epäreilua muihin puroihin ja ei skaalata. Hock et al myös löytänyt” joitakin vakavia luontaisia kysymyksiä, kuten lisääntynyt jonotusviiveitä, epäoikeudenmukaisuus, ja massiivinen pakettihäviö” vuonna BBR täytäntöönpano Linux 4.9.

Soheil Abbasloo et al. (c2tcp: n kirjoittajat) osoittavat, että BBRv1 ei toimi hyvin dynaamisissa ympäristöissä, kuten soluverkoissa. Ne ovat myös osoittaneet, että BBR: llä on epäreiluusongelma. Esimerkiksi, kun KUUTIOVIRTA (joka on oletuksena TCP-toteutus Linuxissa, Androidissa ja MacOS: ssa) rinnakkain BBR-virtauksen kanssa verkossa, BBR-virtaus voi hallita KUUTIOVIRTAA ja saada koko linkin kaistanleveyden siitä (katso kuva 18 in ).

Versio 2 pyrkii käsittelemään epäreiluutta toimiessaan tappioperusteisen ruuhkanhallinnan kuten Cubicin rinnalla. Bbrv2: ssa bbrv1: n käyttämää mallia täydennetään siten, että siihen sisällytetään tiedot pakettihäviöstä ja tiedot Eksplisiittisestä Ruuhkautumisilmoituksesta (ECN). Vaikka BBRv2: lla saattaa toisinaan olla pienempi suoritusteho kuin BBRv1: llä, sillä katsotaan yleensä olevan parempi suoritusteho.

c2tcpedit

Cellular Controlled Delay TCP (C2TCP) perusteltiin joustavan päästä päähän-TCP-lähestymistavan puuttumisella, joka voi täyttää eri sovellusten erilaiset QoS-vaatimukset ilman, että verkkolaitteissa joudutaan tekemään muutoksia. C2TCP pyrkii täyttämään erittäin alhaisen latenssin ja suuren kaistanleveyden vaatimukset sovelluksissa, kuten virtuaalitodellisuudessa, videoneuvotteluissa, verkkopelaamisessa, ajoneuvoviestintäjärjestelmissä jne. erittäin dynaamisessa ympäristössä, kuten nykyisissä LTE-ja tulevissa 5G-matkapuhelinverkoissa. C2TCP toimii lisäosana tappiopohjaisen TCP: n (esim .Reno, NewReno, CUBIC, BIC,…) ja tekee pakettien keskimääräisen viiveen, joka rajoittuu sovellusten asettamiin haluttuihin viiveisiin.

NYU: n tutkijat osoittivat, että C2TCP päihittää erilaisten huipputeknisten TCP-järjestelmien viive- / Värinätehon. Esimerkiksi, He osoittivat, että verrattuna BBR, CUBIC, ja Westwood keskimäärin, C2TCP vähentää keskimääräinen viive paketteja noin 250%, 900%, ja 700% vastaavasti eri matkapuhelinverkko ympäristöissä.

C2TCP vaaditaan asennettavaksi vain palvelinpuolelle.

Elastic-TCPEdit

Elastic-TCP: tä on ehdottanut helmikuussa 2019 Mohamed A. Alrshah et al. lisätä kaistanleveyden hyödyntämistä korkean BDP-verkkojen tukea viime sovelluksia, kuten pilvilaskenta, big tiedonsiirto, IoT, jne. Se on Linux-pohjainen CCA, joka on suunniteltu Linux-ytimelle. Se on vastaanottimen puolen algoritmi, joka käyttää Häviöviivepohjaista lähestymistapaa käyttäen uutta mekanismia, nimeltään Ikkunakorrelated Weighting Function (WWF). Sillä on korkea kimmoisuus käsitellä erilaisia verkon ominaisuuksia ilman ihmisen viritystä. Se on arvioitu vertaamalla sen suorituskykyä Compound-TCP (oletus CCA MS Windows), CUBIC (oletus Linux) ja TCP-BBR (oletus Linux 4.9 Google) käyttäen NS-2 simulaattori ja testbed. Elastinen-TCP parantaa merkittävästi kokonaissuorituskykyä keskimääräisen läpimenon, häviösuhteen ja viiveen kannalta.

NATCP/NACubicEdit

Recently, Soheil Abbasloo et. al. ehdotettu NATCP (Network-Assisted TCP) kiistanalainen TCP suunnittelu kohdistaminen Mobile Edge verkot, kuten MEC. NATCP: n keskeinen ajatus on, että jos verkon ominaisuudet olisi tiedetty etukäteen, TCP olisi suunniteltu paremmin. Siksi NATCP käyttää nykyisten MEC-pohjaisten soluarkkitehtuurien käytettävissä olevia ominaisuuksia ja ominaisuuksia työntääkseen TCP: n suorituskyvyn lähelle optimaalista suorituskykyä. NATCP käyttää verkon ulkopuolista palautetta lähellä sijaitseviin palvelimiin. Verkon antama palaute, joka sisältää matkapuhelinliittymän kapasiteetin ja verkon vähimmäisrtt: n, ohjaa palvelimia säätämään lähettämisnopeuksiaan. Kuten alustavat tulokset osoittavat, NATCP päihittää huipputason TCP-järjestelmät saavuttamalla vähintään 2x suuremman tehon (määritelty läpimeno/viive). NATCP korvaa perinteisen TCP-järjestelmän lähettäjässä.

käsitelläkseen taaksepäin yhteensopivuusongelmaa he ehdottivat toista versiota nimeltä NACubic. Nacubic on taaksepäin yhteensopiva muotoilu, joka ei vaadi TCP: n muuttamista kytketyissä solmuissa. Nacubic käyttää saamansa palautteen ja asettaa cwnd: n (congrowth window) ylärajan ja vauhdin tarpeen mukaan.

muut TCP: n ruuhkia välttävät algoritmit

• nopea TCP
• yleistynyt nopea TCP
• H-TCP
• datakeskus TCP
• nopea TCP
• Hstcp-LP
• TCP-LP
• TCP-SACK
• skaalautuva TCP

TCP veno

• Westwood
• XCP
• joo-TCP
• TCP-fit
• ruuhkien välttäminen normalisoidulla aikavälillä (Canit)
• epälineaarinen neuroverkkojen ruuhkautumisen hallinta perustuen geneettiseen algoritmiin TCP/IP-verkoille

TCP new Reno oli yleisimmin toteutettu algoritmi, säkki tuki on hyvin yleinen ja on laajennus Reno / Uusi Reno. Useimmat muut ovat kilpailevia ehdotuksia, joita on vielä arvioitava. 2.6.8: sta alkaen Linux-ydin vaihtoi oletustoteutuksen uudesta Renosta BIC: hen. Oletustoteutus muutettiin jälleen KUUTIOMAISEKSI 2.6.19-versiossa. FreeBSD käyttää Oletusalgoritmina uutta Renoa. Se tukee kuitenkin useita muita vaihtoehtoja.

kun kaistanleveyden ja viiveen virtauskohtainen tulo kasvaa jonotusjärjestelmästä riippumatta, TCP: stä tulee tehoton ja altis epävakaudelle. Tämä tulee yhä tärkeämmäksi, kun Internet kehittyy sisällyttämään erittäin suuren kaistanleveyden optisia linkkejä.

TCP Interactive (iTCP) sallii sovellusten tilata TCP-tapahtumia ja vastata niiden mukaisesti mahdollistaen erilaiset toiminnalliset laajennukset TCP: hen TCP-kerroksen ulkopuolelta. Useimmat TCP-ruuhkajärjestelmät toimivat sisäisesti. iTCP mahdollistaa lisäksi kehittyneiden sovellusten suoran osallistumisen ylikuormituksen valvontaan, kuten lähteen tuotantonopeuden säätelyyn.

Zeta-TCP havaitsee ruuhkat sekä latenssi-että häviötaajuusmittareista, ja soveltaa erilaisia ruuhkautumisikkunan peruutusstrategioita, jotka perustuvat ruuhkien todennäköisyyteen hyvän suorituksen maksimoimiseksi. Siinä on myös pari muuta parannusta, joilla voidaan tarkasti havaita pakettihäviöt, välttää edelleenlähetyksen aikakatkaisu edelleenlähetys; ja nopeuttaa/ohjata saapuvaa (lataa) liikennettä.