TCP congestion control
the naming convention for congestion control algorithms (CCA ‘ s) kan zijn ontstaan in een paper uit 1996 van Kevin Fall en Sally Floyd.
het type en de hoeveelheid feedback ontvangen van het netwerk
sommige bekende congestievermijdingsmechanismen worden door dit schema als volgt ingedeeld:
| 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 bandbreedte | Max-min |
| ROOD | Verlies | Router | minder vertraging | |
| ECN | Single-bit signaal | de Afzender, de Ontvanger, Router | Minder verlies |
TCP Tahoe en RenoEdit
TCP Reno Tahoe en algoritmes werden met terugwerkende kracht vernoemd naar de versies of smaken van de 4.3 BSD besturingssysteem die elke verscheen voor het eerst (die zelf vernoemd naar Lake Tahoe en de nabijgelegen stad Reno, Nevada). Het Tahoe-algoritme verscheen voor het eerst in 4.3 BSD-Tahoe (dat werd gemaakt om de CCI Power 6/32 “Tahoe” minicomputer te ondersteunen), en werd later beschikbaar gesteld aan niet-AT&T licentiehouders als onderdeel van de 4.3 BSD Networking Release 1; dit zorgde voor een brede distributie en implementatie. Verbeteringen werden gemaakt in 4.3 BSD-Reno en vervolgens vrijgegeven aan het publiek als Networking Release 2 en later 4.4 BSD-Lite.
Hoewel beide overwegen retransmission timeout (RTO) en dubbele ack ’s als packet loss events, het gedrag van Reno Tahoe en verschillen voornamelijk in de manier waarop zij reageren op dubbele ack’ s:
- Tahoe: als drie dubbele ack ’s worden ontvangen (dat wil zeggen vier ack’ s erkennen hetzelfde pakket, die niet piggybacking op gegevens en wijzig niet de ontvanger van de vermelde venster), Tahoe voert een fast retransmit, stelt de trage start is de drempel om de helft van de huidige congestie venster, vermindert de congestie venster voor 1 GEBRUIKER, en stelt trage start staat.
- Reno: als er drie dubbele Ack ‘ s worden ontvangen, zal Reno een snelle heruitzending uitvoeren en de langzame startfase overslaan door in plaats daarvan het congestievenster te halveren (in plaats van het in te stellen op 1 MSS zoals Tahoe), de drempel voor langzame start gelijk te stellen aan het nieuwe congestievenster, en een fase in te voeren genaamd snel herstel.
in zowel Tahoe als Reno wordt, als een ACK-time-out (RTO-time-out) wordt een langzame start gebruikt, en beide algoritmen verminderen het congestievenster tot 1 MSS.
TCP VegasEdit
tot het midden van de jaren 90 waren alle ingestelde timeouts en gemeten vertragingen van de retourvlucht gebaseerd op alleen het laatst verzonden pakket in de verzendbuffer. Onderzoekers van de Universiteit van Arizona Larry Peterson en Lawrence Brakmo introduceerden TCP Vegas (vernoemd naar Las Vegas, de grootste stad in Nevada) waarin timeouts werden ingesteld en Round-trip vertragingen werden gemeten voor elk pakket in de zendbuffer. Bovendien, TCP Vegas maakt gebruik van additieve verhogingen in de congestie venster. In een vergelijking studie van verschillende TCP CCA ‘ s, TCP Vegas bleek de meest vloeiende gevolgd door TCP CUBIC.
tcp Vegas werd niet op grote schaal gebruikt buiten Peterson ‘ s laboratorium, maar werd geselecteerd als de standaard congestie controle methode voor DD-WRT firmware v24 SP2.
TCP nieuwe RenoEdit
TCP nieuwe Reno, gedefinieerd door RFC 6582 (die eerdere definities in RFC 3782 en RFC 2582 veroudert), verbetert de doorgifte tijdens de snelle herstelfase van TCP Reno. Tijdens snel herstel, om het verzendvenster vol te houden, wordt voor elke dubbele ACK die wordt geretourneerd, een nieuw niet verzonden pakket vanaf het einde van het congestievenster verzonden. Voor elke ACK die gedeeltelijke vooruitgang maakt in de sequentieruimte, neemt de afzender aan dat de ACK wijst naar een nieuw gat, en het volgende pakket voorbij het ACKed sequence nummer wordt verzonden.
omdat de time-out wordt gereset wanneer er vooruitgang is in de verzendbuffer, kan New Reno grote gaten, of meerdere gaten, vullen in de sequentieruimte – net als TCP SACK. Omdat nieuwe Reno nieuwe pakketten kan verzenden aan het einde van het congestievenster tijdens snel herstel, wordt een hoge doorvoer gehandhaafd tijdens het gatvullingsproces, zelfs wanneer er meerdere gaten zijn, van meerdere pakketten elk. Wanneer TCP fast recovery invoert, registreert het het hoogste uitstaande, niet-erkende pakketvolgorde-nummer. Wanneer dit volgnummer wordt bevestigd, keert TCP terug naar de staat van congestievermijding.
een probleem doet zich voor met nieuwe Reno wanneer er geen pakketverliezen zijn, maar in plaats daarvan worden pakketten opnieuw gerangschikt met meer dan 3 pakketreeksnummers. In dit geval komt Nieuwe Reno per ongeluk snel herstel binnen. Wanneer het opnieuw geordende pakket wordt geleverd, ACK sequence-number vooruitgang optreedt en vanaf daar tot het einde van snel herstel, alle sequence-number vooruitgang produceert een duplicaat en onnodige doorgifte die onmiddellijk ACKed.
New Reno presteert net zo goed als SACK bij lage pakketfoutpercentages, en presteert aanzienlijk beter dan Reno bij hoge foutenpercentages.
TCP HyblaEdit
TCP Hybla heeft tot doel sancties op TCP-verbindingen die terrestrische of satellietradioverbindingen met hoge latentie bevatten, op te heffen. Hybla verbeteringen zijn gebaseerd op analytische evaluatie van de congestie venster dynamiek.
TCP BICEdit
Binary Increase Congestion control (Bic) is een TCP implementatie met een geoptimaliseerde CCA voor high speed netwerken met hoge latency, bekend als long fat netwerken. BIC wordt standaard gebruikt in Linux kernels 2.6.8 tot en met 2.6.18.
TCP CUBICEdit
kubieke is een minder agressieve en meer systematische afgeleide van BIC, waarin het venster een kubieke functie is van de tijd sinds de laatste congestiegebeurtenis, met het buigpunt ingesteld op het venster voorafgaand aan de gebeurtenis. CUBIC wordt standaard gebruikt in Linux kernels tussen versies 2.6.19 en 3.2.
Agile-SD TCPEdit
Agile-SD is een op Linux gebaseerde CCA die is ontworpen voor de echte Linux kernel. Het is een ontvanger-side algoritme dat een op verlies gebaseerde benadering gebruikt met behulp van een nieuw mechanisme, genaamd agility factor (AF). om het bandbreedtegebruik te verhogen via netwerken met hoge snelheid en korte afstand (low-BDP-netwerken) zoals lokale netwerken of glasvezelnetwerk, vooral wanneer de toegepaste buffergrootte klein is. Het is geëvalueerd door de prestaties te vergelijken met Compound-TCP (de standaard CCA in MS Windows) en CUBIC (de standaard van Linux) met behulp van NS-2 simulator. Het verbetert de totale prestaties tot 55% in termen van gemiddelde doorvoer.
TCP Westwood+Edit
Westwood+ is een alleen-afzender wijziging van TCP Reno die de prestaties van TCP congestie controle over zowel bekabelde als draadloze netwerken optimaliseert. TCP Westwood + is gebaseerd op end-to-end bandbreedteschatting om het congestievenster en slow-start drempel in te stellen na een congestie-episode, dat wil zeggen na drie dubbele bevestigingen of een time-out. De bandbreedte wordt geschat door het gemiddelde van de snelheid van het retourneren van bevestigingspakketten. In tegenstelling tot TCP Reno, dat blindelings het congestievenster na drie dubbele Ack ‘ s halveert, stelt TCP Westwood+ adaptief een slow-startdrempel in en een congestievenster dat rekening houdt met een schatting van de beschikbare bandbreedte op het moment dat er sprake is van congestie. In vergelijking met Reno en New Reno verhoogt Westwood+ de doorvoer via draadloze verbindingen aanzienlijk en verbetert de eerlijkheid in bekabelde netwerken.
Compound Tcpedit
Compound TCP is een Microsoft-implementatie van TCP die twee verschillende congestievensters tegelijkertijd onderhoudt, met als doel goede prestaties op LFNs te bereiken zonder afbreuk te doen aan eerlijkheid. Het is op grote schaal gebruikt in Windows-versies sinds Microsoft Windows Vista en Windows Server 2008 en is geporteerd naar oudere Microsoft Windows-versies en Linux.
TCP Proportional Rate ReductionEdit
tcp Proportional Rate Reduction (PRR) is een algoritme dat is ontworpen om de nauwkeurigheid van gegevens die tijdens herstel worden verzonden, te verbeteren. Het algoritme zorgt ervoor dat de venstergrootte na herstel zo dicht mogelijk bij de slow start drempel ligt. In tests uitgevoerd door Google, PRR resulteerde in een 3-10% vermindering van de gemiddelde latency en herstel time-outs werden verminderd met 5%. PRR is beschikbaar in Linux kernels sinds versie 3.2.
TCP BBREdit
Bottleneck Bandwidth and Round-trip propagation time (BBR) is een CCA ontwikkeld door Google in 2016. Terwijl de meeste CCA ‘ s loss-based zijn, omdat ze afhankelijk zijn van pakketverlies om congestie en lagere transmissiesnelheden te detecteren, is BBR, net als TCP Vegas, modelgebaseerd. Het algoritme maakt gebruik van de maximale bandbreedte en retourtijd waarbij het netwerk de meest recente vlucht van uitgaande datapakketten leverde om een model van het netwerk te bouwen. Elke cumulatieve of selectieve bevestiging van pakketlevering produceert een tariefsteekproef die de hoeveelheid geleverde gegevens registreert over het tijdsinterval tussen de verzending van een datapakket en de bevestiging van dat pakket. Naarmate netwerkinterface controllers evolueren van megabit per seconde naar gigabit per seconde prestaties, wordt de latentie geassocieerd met bufferbloat in plaats van pakketverlies een betrouwbaarder marker van de maximale doorvoer, waardoor modelgebaseerde CCA ‘ s die een hogere doorvoer en lagere latentie bieden, zoals BBR, een betrouwbaarder alternatief voor meer populaire verliesgebaseerde algoritmen zoals TCP CUBIC.
BBR is beschikbaar voor Linux TCP sinds Linux 4.9. Het is ook beschikbaar voor QUIC.
BBR versie 1 (BBRv1) is efficiënt en snel, maar de eerlijkheid ervan ten opzichte van niet-BBR streams wordt betwist. Bij implementatie op YouTube leverde BBRv1 gemiddeld 4% hogere netwerkdoorvoer en in sommige landen tot 14%. Terwijl Google ‘ s presentatie toont BBRv1 co-bestaande goed met CUBIC, onderzoekers zoals Geoff Huston en Hock, Bless en Zitterbart vindt het oneerlijk om andere streams en niet schaalbaar. Hock et al vonden ook “enkele ernstige inherente problemen zoals verhoogde wachtrijvertragingen, oneerlijkheid en enorm pakketverlies” in de BBR-implementatie van Linux 4.9.
Soheil Abbasloo et al. (auteurs van C2TCP) laten zien dat BBRv1 niet goed presteert in dynamische omgevingen zoals cellulaire netwerken. Zij hebben ook aangetoond dat BBR een oneerlijke behandeling heeft. Bijvoorbeeld, wanneer een kubieke stroom (wat de standaard TCP implementatie is in Linux, Android en MacOS) naast een BBR stroom in het netwerk bestaat, kan de BBR stroom de kubieke stroom domineren en de hele link bandbreedte eruit halen (zie figuur 18 in ).
versie 2 probeert het probleem van oneerlijkheid aan te pakken wanneer het naast op verlies gebaseerd congestiebeheer zoals CUBIC werkt. In BBRv2 wordt het door BBRv1 gebruikte model uitgebreid met informatie over pakketverlies en informatie uit expliciete Congestiemelding (ECN). Hoewel BBRv2 soms een lagere doorvoer kan hebben dan BBRv1, wordt over het algemeen aangenomen dat het een betere goodput heeft.
C2tcpedit
Cellular Controlled Delay TCP (C2TCP) werd gemotiveerd door het ontbreken van een flexibele end-to-end TCP-benadering die kan voldoen aan verschillende QoS-vereisten van verschillende toepassingen zonder dat er wijzigingen in de netwerkapparaten nodig zijn. C2TCP streeft naar ultra-lage latency en hoge bandbreedte eisen van toepassingen zoals virtual reality, video conferencing, online gaming, voertuig communicatie systemen, enz. in een zeer dynamische omgeving zoals de huidige LTE en toekomstige 5G cellulaire netwerken. C2TCP werkt als een add-on op de top van verlies gebaseerde TCP (bijvoorbeeld Reno, NewReno, kubieke, BIC, …) en maakt de gemiddelde vertraging van pakketten begrensd tot de gewenste vertragingen die door de toepassingen worden ingesteld.
onderzoekers aan de NYU toonden aan dat C2TCP beter presteert dan de delay/Jitter prestaties van verschillende state-of-the-art TCP schema ‘ s. Bijvoorbeeld, ze toonden aan dat in vergelijking met BBR, CUBIC, en Westwood gemiddeld, c2tcp vermindert de gemiddelde vertraging van pakketten met ongeveer 250%, 900%, en 700% respectievelijk op verschillende mobiele netwerkomgevingen.
C2TCP hoeft alleen op de server geïnstalleerd te worden.
Elastic-TCPEdit
Elastic-TCP is in februari 2019 voorgesteld door Mohamed A. Alrshah et al. om het gebruik van de bandbreedte over high-BDP-netwerken te verhogen om recente toepassingen zoals cloud computing, big data-overdracht, IoT, enz. te ondersteunen. Het is een Linux-gebaseerde CCA die is ontworpen voor de Linux kernel. Het is een algoritme aan de ontvangerzijde dat gebruik maakt van een Loss-delay-gebaseerde benadering met behulp van een nieuw mechanisme, genaamd Window-gecorreleerde Wegingsfunctie (WWF). Het heeft een hoog niveau van elasticiteit om te gaan met verschillende netwerkkenmerken zonder de noodzaak voor menselijke tuning. Het is geëvalueerd door de prestaties te vergelijken met Compound-TCP (de standaard CCA in MS Windows), CUBIC (de standaard van Linux) en TCP-BBR (de standaard van Linux 4.9 door Google) met behulp van NS-2 simulator en testbed. Elastic-TCP verbetert aanzienlijk de totale prestaties in termen van gemiddelde doorvoer, Verlies verhouding, en vertraging.
NATCP/NACubicEdit
Recently, Soheil Abbasloo et. al. voorgesteld NATCP (Network-Assisted TCP) een controversieel TCP-ontwerp gericht op mobiele Randnetwerken zoals MEC. Het belangrijkste idee van NATCP is dat als de kenmerken van het netwerk van tevoren bekend waren, TCP beter zou zijn ontworpen. Daarom maakt NATCP gebruik van de beschikbare functies en eigenschappen in de huidige MEC-gebaseerde cellulaire architecturen om de prestaties van TCP dicht bij de optimale prestaties te duwen. NATCP gebruikt een out-of-band feedback van het netwerk naar de servers in de buurt. De feedback van het netwerk, waaronder de capaciteit van de cellulaire toegang link en de minimale RTT van het netwerk, leidt de servers om hun verzendsnelheden aan te passen. Uit voorlopige resultaten blijkt dat NATCP beter presteert dan de state-of-the-art TCP-schema ‘ s door ten minste 2x meer vermogen te bereiken (gedefinieerd als doorvoer/vertraging). NATCP vervangt het traditionele TCP schema bij de afzender.
om achterwaartse compatibiliteitsproblemen aan te pakken, stelden ze een andere versie voor, genaamd NACubic. NACubic is een achterwaarts compatibel ontwerp, dat geen verandering in TCP op de aangesloten knooppunten vereist. NACubic maakt gebruik van de ontvangen feedback en dwingt een cap op het congestievenster (CWND) en de pacing rate zoals vereist.
Andere TCP congestie vermijden algorithmsEdit
- SNELLE TCP
- Gegeneraliseerde SNEL TCP
- H-TCP
- Data-Center TCP
- Hoge Snelheid TCP
- HSTCP-LP
- TCP-Illinois
- TCP-LP
- TCP ZAK
- Schaalbare TCP
- TCP Veno
- Westwood
- XCP
- Ja-TCP
- TCP-FIT
- Congestie Vermijden met Genormaliseerde Interval van Tijd (CANIT)
- Niet-lineaire neurale netwerk congestie controle op basis van de genetische algoritme voor het TCP/IP-netwerken
TCP Nieuwe Reno was de meest geïmplementeerd algoritme, SACK ondersteuning is zeer gebruikelijk en is een uitbreiding op Reno / nieuwe Reno. De meeste andere zijn concurrerende voorstellen die nog moeten worden geëvalueerd. Beginnend met 2.6.8 schakelde de Linux kernel de standaard implementatie van nieuwe Reno naar BIC. De standaard implementatie werd opnieuw gewijzigd in CUBIC in de 2.6.19 versie. FreeBSD gebruikt het nieuwe Reno als standaardalgoritme. Het ondersteunt echter een aantal andere keuzes.
wanneer het per-flow product van bandbreedte en latentie toeneemt, ongeacht het wachtrijschema, wordt TCP inefficiënt en instabiel. Dit wordt steeds belangrijker naarmate het Internet evolueert om optische verbindingen met zeer hoge bandbreedte op te nemen.met
TCP Interactive (iTCP) kunnen toepassingen zich abonneren op TCP-gebeurtenissen en dienovereenkomstig reageren en verschillende functionele uitbreidingen van TCP van buiten de TCP-laag mogelijk maken. De meeste TCP-congestiesystemen werken intern. iTCP stelt geavanceerde toepassingen bovendien in staat om rechtstreeks deel te nemen aan congestiebeheersing, zoals het regelen van de brongeneratiesnelheid.
Zeta-TCP detecteert de congesties op basis van zowel de latency-als de loss rate-metingen, en past verschillende back-offstrategieën voor congestievensters toe op basis van de waarschijnlijkheid dat de congesties de goodput maximaliseren. Het heeft ook een paar andere verbeteringen om het pakket verliezen nauwkeurig te detecteren, het vermijden van retransmissie time-out retransmissie; en versnellen / controleren van de inkomende (download) verkeer.