The naming convention for congestion control algorithms (CCAs) may have originated in a 1996 paper by Kevin Fall and Sally Floyd.

A seguir está uma possível classificação de acordo com as seguintes propriedades:

1. o tipo e a quantidade de comentários recebidos da rede
2. incremental de capacidade de destacamento no atual da Internet
3. o aspecto de desempenho que tem como objetivo melhorar: alta largura de banda-produto de atraso de redes (B); perdas de links (L); equidade (F); vantagem para curto fluxos (S); variável-taxa de links (V); velocidade de convergência (C)
4. o critério de equidade que utiliza

alguns mecanismos bem conhecidos de prevenção de congestionamentos são classificados neste regime da seguinte forma::

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 largura de banda	Max-min
VERMELHO	Perda	Router	Redução de atraso
REC	de um Único bit de sinal	Remetente, Receptor, Roteador	Redução de perdas

TCP Tahoe e RenoEdit

TCP Reno Tahoe e algoritmos foram retrospectivamente nomeado após a versões ou sabores do 4.3 BSD, sistema operacional no qual cada apareceu pela primeira vez (quais eram, em si, nomeado após Lake Tahoe e a vizinha cidade de Reno, em Nevada). O Tahoe algoritmo apareceu pela primeira vez em 4.3 BSD-Tahoe (que foi feita para apoiar a CCI Poder 6/32 “Tahoe” minicomputador), e mais tarde foi disponibilizado para não-AT&T licenciados como parte do 4.3 BSD Networking Release 1, garantindo sua ampla distribuição e implementação. Melhorias foram feitas em 4.3 BSD-Reno e posteriormente lançado ao público como lançamento de rede 2 e mais tarde 4.4 BSD-Lite.

Enquanto ambos considerar o tempo limite de retransmissão (RTO) e ACKs duplicados como a perda de pacotes eventos, o comportamento do Reno Tahoe e diferem principalmente na forma como eles reagem a ACKs duplicados:

• Tahoe: se três ACKs duplicados recebidos (i.e. quatro Ack reconhecendo o mesmo pacote, que não são acumulados em dados e não alterar o receptor anunciado janela), Tahoe executa uma retransmissão rápida, define o slow start threshold para a metade da atual janela de congestionamento, reduz a janela de congestionamento para 1 MSS, e retorna para o início lento do estado. Reno: se três ACKs duplicados são recebidos, Reno irá realizar uma retransmissão rápida e ignorar o lento início da fase de por em vez de reduzir para metade a janela de congestionamento (em vez de defini-la para 1 MSS como Tahoe), definindo o slow start threshold igual a nova janela de congestionamento, e entrar em uma fase chamada de rápida recuperação.

em Tahoe e Reno, se um tempo de saída ACK (tempo limite RTO), início lento é usado, e ambos os algoritmos reduzem a janela de congestionamento para 1 MSS.artigo principal: TCP Vegas

até meados da década de 1990, todos os tempos-limite definidos do TCP e os atrasos de ida e volta medidos foram baseados apenas no último pacote transmitido no buffer de transmissão. Os pesquisadores da Universidade do Arizona Larry Peterson e Lawrence Brakmo introduziram o TCP Vegas (nomeado em homenagem a Las Vegas, A maior cidade do Nevada) em que os tempos foram definidos e os atrasos de ida e volta foram medidos para cada pacote no buffer de transmissão. Além disso, o TCP Vegas USA aumentos aditivos na janela de congestionamento. In a comparison study of various TCP CCAs, TCP Vegas appeared to be the smoothest followed by TCP CUBIC.

TCP Vegas was not widely deployed outside Peterson’s laboratory but was selected as the default congestion control method for DD-WRT firmware v24 SP2.

TCP New RenoEdit

TCP New Reno, definido pela RFC 6582 (que obsoleta as definições anteriores na RFC 3782 e na RFC 2582), melhora a retransmissão durante a fase de recuperação rápida do TCP Reno. Durante a recuperação rápida, para manter a janela de transmissão cheia, para cada ACK duplicado que é devolvido, um novo pacote não enviado do final da janela de congestionamento é enviado. Para cada ACK que faz progresso parcial no espaço de sequência, o remetente assume que o ACK aponta para um novo buraco, e o próximo pacote além do número de sequência ACK é enviado.

porque o tempo-limite é reiniciado sempre que há progresso no buffer de transmissão, o novo Reno pode preencher grandes buracos, ou múltiplos buracos, no espaço de sequência – muito parecido com o saco TCP. Como o novo Reno pode enviar novos pacotes no final da janela de congestionamento durante a rápida recuperação, alta produtividade é mantida durante o processo de preenchimento de buracos, mesmo quando há vários buracos, de vários pacotes cada. Quando o TCP entra em recuperação rápida, ele registra o maior número de sequência de pacotes não reconhecido. Quando este número de sequência é reconhecido, o TCP retorna ao estado de evitar congestionamentos.

um problema ocorre com o novo Reno Quando não há perdas de pacotes, mas em vez disso, os pacotes são reordenados por mais de 3 números de sequência de pacotes. Neste caso, a New Reno entra erradamente em rápida recuperação. Quando o pacote reordenado é entregue, o progresso do número de sequência ACK ocorre e de lá até o final da recuperação rápida, todo o progresso do número de sequência produz uma retransmissão duplicada e desnecessária que é imediatamente acada.

New Reno executa bem como SACK em baixas taxas de erro de pacotes, e supera substancialmente Reno em altas taxas de erro.

TCP HyblaEdit

tcp Hybla tem como objetivo eliminar penalidades às conexões TCP que incorporam uma alta latência de ligações de rádio terrestres ou via satélite. As melhorias de Hybla são baseadas na avaliação analítica da dinâmica da janela de congestionamento.

TCP BICEdit

Binary Increase Congestion control (BIC) is a TCP implementation with an optimized CCA for high speed networks with high latency, known as long fat networks. O BIC é usado por padrão em kernels Linux 2.6.8 a 2.6.18.

TCP CUBICEdit

CÚBICO é uma técnica menos agressiva e mais sistemática derivados do BIC, em que a janela é uma cúbicos função do tempo desde a última congestionamento do evento, com o ponto de inflexão definido para a janela antes do evento. CUBIC é usado por padrão em kernels Linux entre as versões 2.6.19 e 3.2.

Agile-SD TCPEdit

Agile-SD é um CCA baseado em Linux que é projetado para o núcleo Linux real. É um algoritmo do lado receptor que emprega uma abordagem baseada em perdas usando um novo mecanismo, chamado agility factor (AF). aumentar a utilização da largura de banda através de redes de alta velocidade e de curta distância (redes de baixa BDP), como redes locais ou redes de fibra óptica, especialmente quando o tamanho do buffer aplicado é pequeno. Ele foi avaliado comparando seu desempenho ao Compound-TCP (o CCA padrão no MS Windows) e CUBIC (o padrão do Linux) usando o simulador NS-2. Melhora o desempenho total até 55% em termos de rendimento médio.

TCP Westwood+Edit

Westwood+ is a sender-only modification of TCP Reno that optimizes the performance of TCP congestion control over both wired and wireless networks. O TCP Westwood+ é baseado na estimativa de largura de banda extremo-a-extremo para definir a janela de congestionamento e o limiar de arranque lento após um episódio de congestionamento, ou seja, após três reconhecimentos duplicados ou um tempo-limite. A largura de banda é estimada pela média da taxa de retorno de pacotes de agradecimentos. Em contraste com o TCP Reno, que cega para metade a janela de congestionamento após três ACKs duplicados, o TCP Westwood+ define adaptativamente um limiar de arranque lento e uma janela de congestionamento que leva em conta uma estimativa da largura de banda disponível no momento em que o congestionamento é experimentado. Em comparação com Reno e novo Reno, Westwood+ aumenta significativamente o rendimento através de ligações sem fio e melhora a equidade nas redes com fio.

composto TCPEdit

composto TCP é uma implementação da Microsoft TCP que mantém duas janelas de congestionamento diferentes simultaneamente, com o objetivo de alcançar um bom desempenho em LFNs, sem prejudicar a equidade. Ele tem sido amplamente implantado em versões do Windows desde o Microsoft Windows Vista e Windows Server 2008 e tem sido portado para versões mais antigas do Microsoft Windows, bem como Linux.

TCP Proportional Rate ReductionEdit

tcp Proportional Rate Reduction (PRR) é um algoritmo projetado para melhorar a precisão dos dados enviados durante a recuperação. O algoritmo garante que o tamanho da janela após a recuperação é o mais próximo possível do limiar de arranque lento. Nos testes realizados pelo Google, o PRR resultou em uma redução de 3-10% na latência média e os tempos de recuperação foram reduzidos em 5%. O PRR está disponível em kernels Linux desde a versão 3.2.

TCP Bcredit

largura de banda do gargalo e tempo de propagação de ida e volta (BBR) é uma CCA desenvolvida no Google em 2016. Enquanto a maioria das CCAs são baseadas em perdas, na medida em que elas dependem da perda de pacotes para detectar congestionamento e taxas de transmissão mais baixas, o BBR, como o TCP Vegas, é baseado em modelos. O algoritmo usa a largura de banda máxima e o tempo de ida e volta no qual a rede entregou o mais recente voo de pacotes de dados de saída para construir um modelo da rede. Cada reconhecimento cumulativo ou seletivo de entrega de pacotes produz uma amostra de taxa que registra a quantidade de dados entregues ao longo do intervalo de tempo entre a transmissão de um pacote de dados e o reconhecimento desse pacote. Como controladores de interface de rede evoluem a partir de um megabit por segundo, e gigabit por segundo de desempenho, a latência associada com bufferbloat em vez de perda de pacotes torna-se mais confiável marcador da taxa de transferência máxima, tornando o modelo-base as aac, que proporcionam maior rendimento e menor latência, como BBR, mais confiável alternativa mais populares perda baseado em algoritmos como o TCP CUBIC.

BBR está disponível para Linux TCP desde Linux 4.9. Ele também está disponível para QUIC.

BBR versão 1 (BBRv1) é eficiente e rápido, mas sua justiça para fluxos não-BBR é contestada. Quando implementado no YouTube, o BBRv1 rendeu uma média de 4% maior de rendimento da rede e até 14% em alguns países. Enquanto a apresentação do Google mostra BBRv1 co-existente bem com CUBIC, pesquisadores como Geoff Huston e Hock, Bless e Zitterbart acham injusto para outros fluxos e não escalável. Hock et al também encontrou “algumas questões graves inerentes, tais como o aumento dos atrasos na fila, injustiça e perda massiva de pacotes” na implementação BBR do Linux 4.9.Soheil Abbasloo et al. (autores do C2TCP) mostram que o BBRv1 não tem bom desempenho em ambientes dinâmicos como redes celulares. Eles também mostraram que a BBR tem um problema de injustiça. Por exemplo, quando um fluxo cúbico (que é a implementação padrão TCP em Linux, Android e MacOS) coexiste com um fluxo BBR na rede, o fluxo BBR pode dominar o fluxo cúbico e obter toda a largura de banda de ligação a partir dele (ver Figura 18 em ).

Versão 2 tenta lidar com a questão da injustiça ao operar ao lado da Gestão de congestionamento baseada em perdas, como CUBIC. No BBRv2, o modelo utilizado pelo BBRv1 é aumentado para incluir informações sobre a perda de pacotes e informações de notificação explícita de congestionamento (REC). Embora o BBRv2 possa, por vezes, ter um rendimento inferior ao BBRv1, considera-se geralmente que tem um rendimento melhor.

C2TCPEdit

atraso celular controlado TCP (C2TCP) foi motivado pela falta de uma abordagem flexível de extremo-a-extremo TCP que pode satisfazer vários requisitos QoS de diferentes aplicações sem exigir quaisquer alterações nos dispositivos de rede. O C2TCP tem como objetivo satisfazer os requisitos de latência ultra-baixa e largura de banda de aplicações como a realidade virtual, Videoconferência, Jogos online, sistemas de comunicação veicular, etc. em um ambiente altamente dinâmico, como o atual LTE e futuras redes celulares 5G. O C2TCP funciona como um complemento do TCP baseado em perdas (por exemplo, Reno, NewReno, CUBIC, BIC, etc …) e torna o atraso médio dos pacotes limitado aos atrasos desejados definidos pelas aplicações.

pesquisadores da NYU mostraram que o C2TCP supera o atraso/desempenho de vários sistemas TCP de última geração. Por exemplo, eles mostraram que, em comparação com BBR, CUBIC e Westwood, em média, C2TCP diminui o atraso médio dos pacotes em cerca de 250%, 900% e 700%, respectivamente, em vários ambientes de rede celular.

C2TCP só é necessário para ser instalado no lado do servidor.

elástico-TCPEdit

elástico-TCP foi proposto em fevereiro de 2019 por Mohamed A. Alrshah et al. aumentar a utilização da largura de banda em redes de alta BDP para suportar aplicações recentes como computação em nuvem, transferência de grandes dados, IoT, etc. É um CCA baseado em Linux que é projetado para o kernel Linux. É um algoritmo do lado do receptor que emprega uma abordagem baseada em perda-Atraso usando um novo mecanismo, chamado função de ponderação correlacionada com a janela (WWF). Tem um alto nível de elasticidade para lidar com diferentes características de rede sem a necessidade de ajuste humano. Ele foi avaliado comparando seu desempenho ao Compound-TCP (o CCA padrão no MS Windows), CUBIC (o padrão do Linux) e TCP-BBR (o padrão do Linux 4.9 pelo Google) usando simulador NS-2 e testbed. Elástico-TCP melhora significativamente o desempenho total em termos de rendimento médio, rácio de perdas e atraso.

NATCP/NACubicEdit

Recentemente, Soheil Abbasloo et. al. proposta NATCP (Network-Assisted TCP) um projeto controverso TCP visando redes de borda móvel, como MEC. A ideia chave do NATCP é que se as características da rede fossem conhecidas de antemão, o TCP teria sido projetado de uma forma melhor. Portanto, o NATCP emprega as características e propriedades disponíveis nas atuais arquiteturas celulares baseadas no MEC para empurrar o desempenho do TCP para perto do desempenho ideal. NATCP usa um feedback fora de banda da rede para os servidores localizados nas proximidades. O feedback da rede, que inclui a capacidade do link de acesso celular e o RTT mínimo da rede, orienta os servidores para ajustar suas taxas de envio. Como os resultados preliminares mostram, o NATCP supera os sistemas TCP de última geração, alcançando, pelo menos, uma potência 2x mais elevada (definida como rendimento/atraso). O NATCP substitui o esquema TCP tradicional no remetente.

para lidar com problemas de compatibilidade retroativa, eles propuseram outra versão chamada NACubic. NACubic é um projeto reverso compatível, que não requer nenhuma alteração no TCP nos nós conectados. NACubic emprega o feedback recebido e impõe uma tampa na janela de congestionamento (CWND) e a taxa de ritmo conforme necessário.

Outros TCP evitar congestionamento algorithmsEdit

• FAST TCP
• Generalizada FAST TCP
• H-TCP
• Centro de Dados TCP
• TCP de Alta Velocidade
• HSTCP-LP
• protocolo TCP-Illinois
• protocolo TCP-LP
• TCP SACK
• Scalable TCP
• TCP Veno
• Westwood
• XCP
• Sim-TCP
• TCP-FIT
• para Evitar Congestionamento com Normalizado Intervalo de Tempo (CANIT)
• Não-linear de rede neural o controle de congestionamento baseado em algoritmo genético para redes TCP/IP

TCP New Reno era o mais comumente aplicada algorithm, SACK support is very common and is an extension to Reno / New Reno. A maioria das outras são propostas concorrentes que ainda precisam de ser avaliadas. Começando com 2.6.8 o kernel Linux mudou a implementação padrão de novo Reno para BIC. A implementação padrão foi novamente alterada para CUBIC na versão 2.6.19. O FreeBSD usa o novo Reno como algoritmo padrão. No entanto, apoia uma série de outras opções.

Quando o produto por fluxo de largura de banda e latência aumenta, independentemente do esquema de Fila, o TCP torna-se ineficiente e propenso à instabilidade. Isto torna-se cada vez mais importante à medida que a Internet evolui para incorporar ligações ópticas de banda muito alta.

tcp Interactive (iTCP) permite às aplicações assinarem eventos TCP e responderem de acordo, permitindo várias extensões funcionais para TCP de fora da camada TCP. A maioria dos sistemas de congestionamento TCP funciona internamente. o iTCP também permite que aplicações avançadas participem diretamente no controle de congestionamentos, como controlar a taxa de geração de fontes.

Zeta-TCP detecta os congestionamentos a partir de ambas as medidas de latência e taxa de perda, e aplica diferentes estratégias de backoff de janela de congestionamento com base na probabilidade de congestões para maximizar o goodput. Ele também tem um par de outras melhorias para detectar com precisão as perdas de pacotes, evitando retransmissão timeout retransmissão; e acelerar/controlar o tráfego de entrada (download).