Controle de congestionamento TCP - TCP congestion control

O protocolo de controle de transmissão (TCP) usa um algoritmo de prevenção de congestionamento de rede que inclui vários aspectos de um esquema de aumento aditivo / diminuição multiplicativa (AIMD), juntamente com outros esquemas, incluindo início lento e janela de congestionamento , para evitar congestionamento. O algoritmo de prevenção de congestionamento TCP é a base principal para o controle de congestionamento na Internet. De acordo com o princípio de ponta a ponta , o controle de congestionamento é em grande parte uma função dos hosts da Internet , não da própria rede. Existem várias variações e versões do algoritmo implementado em pilhas de protocolo de sistemas operacionais de computadores que se conectam à Internet .

Operação

Para evitar o colapso congestivo , o TCP usa uma estratégia de controle de congestionamento multifacetada. Para cada conexão, o TCP mantém uma janela de congestionamento , limitando o número total de pacotes não confirmados que podem estar em trânsito de ponta a ponta. Isso é um pouco análogo à janela deslizante do TCP usada para controle de fluxo . O TCP usa um mecanismo chamado início lento para aumentar a janela de congestionamento depois que uma conexão é inicializada ou após um tempo limite . Ele começa com uma janela, um pequeno múltiplo do tamanho máximo do segmento (MSS). Embora a taxa inicial seja baixa, a taxa de aumento é muito rápida; para cada pacote reconhecido, a janela de congestionamento aumenta em 1 MSS, de modo que a janela de congestionamento dobra efetivamente para cada tempo de ida e volta (RTT).

Quando a janela de congestionamento excede o limite de início lento, ssthresh , o algoritmo entra em um novo estado, chamado de prevenção de congestionamento. No estado de prevenção de congestionamento, desde que ACKs não duplicados sejam recebidos, a janela de congestionamento aumenta adicionalmente em um MSS a cada tempo de ida e volta. Isso corresponde ao algoritmo AIMD descrito abaixo .

Janela de congestionamento

No TCP, a janela de congestionamento é um dos fatores que determina o número de bytes que podem ser enviados a qualquer momento. A janela de congestionamento é mantida pelo remetente e é um meio de impedir que um link entre o remetente e o receptor fique sobrecarregado com muito tráfego. Isso não deve ser confundido com a janela deslizante mantida pelo emissor, que existe para evitar que o receptor fique sobrecarregado. A janela de congestionamento é calculada estimando quanto congestionamento existe no link.

Quando uma conexão é configurada, a janela de congestionamento, um valor mantido independentemente em cada host, é definida como um pequeno múltiplo do MSS permitido nessa conexão. Mais variância na janela de congestionamento é ditada por uma abordagem de aumento aditivo / diminuição multiplicativa (AIMD). Isso significa que se todos os segmentos forem recebidos e as confirmações chegarem ao remetente a tempo, alguma constante será adicionada ao tamanho da janela. Quando a janela atinge ssthresh , a janela de congestionamento aumenta linearmente na taxa de 1 / (janela de congestionamento) segmento em cada nova confirmação recebida. A janela continua crescendo até que ocorra um tempo limite. No tempo limite:

  1. A janela de congestionamento é redefinida para 1 MSS.
  2. ssthresh é definido para metade do tamanho da janela de congestionamento antes do tempo limite.
  3. o início lento é iniciado.

Um administrador do sistema pode ajustar o limite máximo do tamanho da janela ou ajustar a constante adicionada durante o aumento aditivo, como parte do ajuste do TCP .

O fluxo de dados em uma conexão TCP também é controlado pelo uso da janela de recepção anunciada pelo receptor. Comparando sua própria janela de congestionamento com a janela de recepção , um remetente pode determinar quantos dados ele pode enviar a qualquer momento.

Início lento

O início lento faz parte da estratégia de controle de congestionamento usada pelo TCP em conjunto com outros algoritmos para evitar o envio de mais dados do que a rede é capaz de encaminhar, ou seja, evitar causar congestionamento na rede. O algoritmo é especificado pelo RFC  5681 .

Embora a estratégia seja referida como início lento, o crescimento da janela de congestionamento é bastante agressivo, mais agressivo do que a fase de prevenção de congestionamento. Antes do início lento ser introduzido no TCP, a fase inicial de prevenção de pré-congestionamento era ainda mais rápida.

O início lento começa inicialmente com um tamanho de janela de congestionamento (CWND) de 1, 2, 4 ou 10 MSS. O valor para o tamanho da janela de congestionamento será aumentado em um com cada confirmação (ACK) recebida, efetivamente dobrando o tamanho da janela a cada tempo de ida e volta. A taxa de transmissão será aumentada pelo algoritmo de início lento até que uma perda seja detectada ou a janela anunciada do receptor (rwnd) seja o fator limitante ou ssthresh seja atingido. Se ocorrer um evento de perda, o TCP assume que é devido ao congestionamento da rede e toma medidas para reduzir a carga oferecida na rede. Essas medidas dependem do algoritmo de prevenção de congestionamento TCP exato usado.

TCP Tahoe
Quando ocorre uma perda, uma retransmissão rápida é enviada, metade do CWND atual é salva como ssthresh e o início lento começa novamente a partir de seu CWND inicial. Assim que o CWND atinge ssthresh , o TCP muda para o algoritmo de prevenção de congestionamento, onde cada novo ACK aumenta o CWND por MSS / CWND. Isso resulta em um aumento linear do CWND.
TCP Reno
Uma retransmissão rápida é enviada, metade do CWND atual é salvo como ssthresh e como novo CWND, pulando assim o início lento e indo diretamente para o algoritmo de prevenção de congestionamento. O algoritmo geral aqui é chamado de recuperação rápida.

Uma vez que ssthresh é alcançado, o TCP muda do algoritmo de início lento para o algoritmo de crescimento linear (prevenção de congestionamento). Neste ponto, a janela é aumentada em 1 segmento para cada tempo de retardo de ida e volta (RTT).

O início lento pressupõe que os segmentos não reconhecidos são devidos ao congestionamento da rede. Embora essa seja uma suposição aceitável para muitas redes, os segmentos podem ser perdidos por outros motivos, como baixa qualidade de transmissão da camada de enlace . Portanto, o início lento pode ter um desempenho ruim em situações com recepção ruim, como redes sem fio .

O protocolo de início lento também funciona mal para conexões de curta duração. Os navegadores mais antigos criariam muitas conexões consecutivas de curta duração com o servidor da web e abririam e fechariam a conexão para cada arquivo solicitado. Isso manteve a maioria das conexões no modo de início lento, o que resultou em um tempo de resposta insatisfatório. Para evitar esse problema, os navegadores modernos abrem várias conexões simultaneamente ou reutilizam uma conexão para todos os arquivos solicitados de um servidor da web específico. As conexões, no entanto, não podem ser reutilizadas para os vários servidores de terceiros usados ​​por sites para implementar publicidade na web , compartilhar recursos de serviços de rede social e scripts de contador de análise da web .

Aumento aditivo / diminuição multiplicativa

O algoritmo de aumento aditivo / diminuição multiplicativa (AIMD) é um algoritmo de controle de malha fechada . O AIMD combina o crescimento linear da janela de congestionamento com uma redução exponencial quando ocorre um congestionamento. Múltiplos fluxos usando o controle de congestionamento AIMD eventualmente convergirão para usar quantidades iguais de um link em disputa.

Este é o algoritmo descrito na RFC  5681 para o estado de "prevenção de congestionamento".

Retransmissão rápida

Retransmissão rápida é um aprimoramento do TCP que reduz o tempo que um remetente espera antes de retransmitir um segmento perdido. Um remetente de TCP normalmente usa um temporizador simples para reconhecer segmentos perdidos. Se uma confirmação não for recebida para um segmento específico dentro de um tempo especificado (uma função do tempo de retardo de ida e volta estimado ), o remetente presumirá que o segmento foi perdido na rede e retransmitirá o segmento.

A confirmação duplicada é a base para o mecanismo de retransmissão rápida. Depois de receber um pacote, uma confirmação é enviada para o último byte de ordem de dados recebido. Para um pacote em ordem, este é efetivamente o número de sequência do último pacote mais o comprimento da carga útil do pacote atual. Se o próximo pacote na sequência for perdido, mas um terceiro pacote na sequência for recebido, o receptor poderá reconhecer apenas o último byte de dados da ordem, que é o mesmo valor que foi confirmado para o primeiro pacote. O segundo pacote é perdido e o terceiro não está em ordem, então o último byte de dados em ordem permanece o mesmo de antes. Assim, ocorre uma confirmação duplicada . O remetente continua a enviar pacotes e um quarto e um quinto pacotes são recebidos pelo receptor. Novamente, o segundo pacote está faltando na sequência, então o último byte na ordem não foi alterado. Confirmações duplicadas são enviadas para ambos os pacotes.

Quando um remetente recebe três confirmações duplicadas, ele pode estar razoavelmente seguro de que o segmento que transportava os dados que se seguiram ao último byte em ordem especificado na confirmação foi perdido. Um remetente com retransmissão rápida irá então retransmitir este pacote imediatamente, sem esperar pelo seu tempo limite. Ao receber o segmento retransmitido, o receptor pode reconhecer o último byte de ordem de dados recebido. No exemplo acima, isso reconheceria o final da carga útil do quinto pacote. Não há necessidade de reconhecer os pacotes intermediários, uma vez que o TCP usa reconhecimentos cumulativos por padrão.

Algoritmos

A convenção de nomenclatura para algoritmos de controle de congestionamento (CCAs) pode ter se originado em um artigo de 1996 de Kevin Fall e Sally Floyd.

O seguinte é uma classificação possível de acordo com as seguintes propriedades:

  1. o tipo e a quantidade de feedback recebido da rede
  2. implantabilidade incremental na Internet atual
  3. o aspecto do desempenho que visa melhorar: redes de produtos com alto atraso de largura de banda (B); links com perdas (L); justiça (F); vantagem para fluxos curtos (S); links de taxa variável (V); velocidade de convergência (C)
  4. o critério de justiça que usa

Alguns mecanismos de prevenção de congestionamento bem conhecidos são classificados por este esquema da seguinte forma:

Variante Comentários Mudanças necessárias Benefícios Justiça
(Novo) Reno Perda - - Atraso
Vegas Atraso Remetente Menos perda Proporcional
Alta velocidade Perda Remetente Alta largura de banda
BIC Perda Remetente Alta largura de banda
CÚBICO Perda Remetente Alta largura de banda
C2TCP Perda / Atraso Remetente Latência ultrabaixa e alta largura de banda
NATCP Sinal multi-bit Remetente Desempenho quase ótimo
Elastic-TCP Perda / Atraso Remetente Largura de banda alta / curta e longa distância
Agile-TCP Perda Remetente Largura de banda alta / curta distância
H-TCP Perda Remetente Alta largura de banda
VELOZES Atraso Remetente Alta largura de banda Proporcional
TCP composto Perda / Atraso Remetente Alta largura de banda Proporcional
Westwood Perda / Atraso Remetente eu
Jersey Perda / Atraso Remetente eu
BBR Atraso Remetente BLVC, Bufferbloat
BRAÇADEIRA Sinal multi-bit Receptor, roteador V Max-min
TFRC Perda Remetente, Receptor Sem retransmissão Atraso mínimo
XCP Sinal multi-bit Remetente, receptor, roteador BLFC Max-min
VCP Sinal de 2 bits Remetente, receptor, roteador BLF Proporcional
MaxNet Sinal multi-bit Remetente, receptor, roteador BLFSC Max-min
JetMax Sinal multi-bit Remetente, receptor, roteador Alta largura de banda Max-min
VERMELHO Perda Roteador Atraso reduzido
ECN Sinal de bit único Remetente, receptor, roteador Perda reduzida

TCP Tahoe e Reno

Os algoritmos TCP Tahoe e Reno foram nomeados retrospectivamente após as versões ou sabores do sistema operacional 4.3BSD em que cada um apareceu pela primeira vez (que foram nomeados após Lake Tahoe e a cidade vizinha de Reno, Nevada ). O algoritmo Tahoe apareceu pela primeira vez no 4.3BSD-Tahoe (que foi feito para suportar o minicomputador CCI Power 6/32 "Tahoe" ), e mais tarde foi disponibilizado para licenciados não AT&T como parte do 4.3BSD Networking Release 1; isso garantiu sua ampla distribuição e implementação. Melhorias foram feitas no 4.3BSD-Reno e posteriormente lançadas ao público como Networking Release 2 e mais tarde 4.4BSD-Lite.

Embora ambos considerem o tempo limite de retransmissão (RTO) e ACKs duplicados como eventos de perda de pacote, o comportamento de Tahoe e Reno diferem principalmente em como eles reagem a ACKs duplicados:

  • Tahoe: se três ACKs duplicados são recebidos (ou seja, quatro ACKs reconhecendo o mesmo pacote, que não são associados aos dados e não alteram a janela anunciada do receptor), Tahoe executa uma retransmissão rápida, define o limite de início lento para metade do congestionamento atual janela, reduz a janela de congestionamento para 1 MSS e redefine para o estado de início lento.
  • Reno: se três ACKs duplicados forem recebidos, Reno executará uma retransmissão rápida e pulará a fase de início lento, reduzindo pela metade a janela de congestionamento (em vez de defini-la para 1 MSS como Tahoe), definindo o limite de início lento igual à nova janela de congestionamento e entrar em uma fase chamada recuperação rápida .

Em Tahoe e Reno, se um ACK atingir o tempo limite (tempo limite de RTO), o início lento é usado e ambos os algoritmos reduzem a janela de congestionamento para 1 MSS.

TCP Vegas

Até meados da década de 1990, todos os tempos limites definidos e atrasos de ida e volta medidos do TCP baseavam-se 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 (em homenagem a Las Vegas , a maior cidade de Nevada), no qual os tempos limites 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. Em um estudo de comparação de vários TCP CCA s, TCP Vegas pareceu ser o mais suave, seguido por TCP CUBIC.

O TCP Vegas não foi amplamente implantado fora do laboratório de Peterson, mas foi selecionado como o método de controle de congestionamento padrão para o firmware DD-WRT v24 SP2.

TCP New Reno

TCP New Reno, definido pelo RFC  6582 (que torna obsoletas as definições anteriores no RFC  3782 e 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 é retornado, um novo pacote não enviado do final da janela de congestionamento é enviado. Para cada ACK que faz progresso parcial no espaço de seqüência, o remetente assume que o ACK aponta para um novo buraco, e o próximo pacote além do número de seqüência ACKed é enviado.

Como o tempo limite é redefinido sempre que houver progresso no buffer de transmissão, o New Reno pode preencher grandes lacunas, ou múltiplas lacunas, no espaço de sequência - de modo muito semelhante ao TCP SACK . Como o New Reno pode enviar novos pacotes no final da janela de congestionamento durante a recuperação rápida, a alta taxa de transferência é mantida durante o processo de preenchimento de lacunas, mesmo quando há vários buracos, de vários pacotes cada. Quando o TCP entra em recuperação rápida, ele registra o número de sequência de pacote não confirmado mais alto pendente. Quando esse número de sequência é confirmado, o TCP retorna ao estado de prevenção de congestionamento.

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 pacote. Nesse caso, o Novo Reno entra por engano em recuperação rápida. Quando o pacote reordenado é entregue, o progresso do número de sequência ACK ocorre e a partir daí 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 ACKed.

O novo Reno tem um desempenho tão bom quanto o SACK em baixas taxas de erro de pacote e supera substancialmente o Reno em altas taxas de erro.

TCP Hybla

O TCP Hybla visa eliminar as penalidades para as conexões TCP que incorporam links de rádio via satélite ou terrestre de alta latência. As melhorias do Hybla são baseadas na avaliação analítica da dinâmica da janela de congestionamento.

TCP BIC

O controle binário de aumento de congestionamento (BIC) é uma implementação de TCP com um CCA otimizado para redes de alta velocidade com alta latência, conhecidas como redes longas de gordura (LFNs). O BIC é usado por padrão nos kernels Linux 2.6.8 a 2.6.18.

TCP CUBIC

CUBIC é uma derivada menos agressiva e mais sistemática de BIC, em que a janela é uma função cúbica do tempo desde o último evento de congestionamento, com o ponto de inflexão definido para a janela anterior ao evento. CUBIC é usado por padrão nos kernels do Linux entre as versões 2.6.19 e 3.2.

Agile-SD TCP

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

TCP Westwood +

Westwood + é uma modificação somente do remetente do TCP Reno que otimiza o desempenho do controle de congestionamento do TCP em redes com e sem fio . O TCP Westwood + é baseado na estimativa de largura de banda de ponta a ponta para definir a janela de congestionamento e o limite de início lento após um episódio de congestionamento, ou seja, após três confirmações duplicadas ou um tempo limite. A largura de banda é estimada pela média da taxa de retorno dos pacotes de confirmação. Em contraste com o TCP Reno, que cegamente reduz pela metade a janela de congestionamento após três ACKs duplicados, o TCP Westwood + ajusta de forma adaptativa um limite de início lento e uma janela de congestionamento que leva em consideração uma estimativa da largura de banda disponível no momento em que o congestionamento ocorre. Comparado com Reno e New Reno, Westwood + aumenta significativamente a taxa de transferência em links sem fio e melhora a justiça em redes com fio.

TCP composto

O TCP composto é uma implementação do TCP da Microsoft que mantém duas janelas de congestionamento diferentes simultaneamente, com o objetivo de obter um bom desempenho em LFNs sem prejudicar a imparcialidade . Ele foi amplamente implantado em versões do Windows desde o Microsoft Windows Vista e Windows Server 2008 e foi transferido para versões anteriores do Microsoft Windows, bem como para Linux .

Redução da taxa proporcional de TCP

A redução da taxa proporcional (PRR) do TCP é 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 seja o mais próximo possível do limite de início lento. Em testes realizados pelo Google , o PRR resultou em uma redução de 3 a 10% na latência média e os tempos limite de recuperação foram reduzidos em 5%. PRR está disponível em kernels Linux desde a versão 3.2.

TCP BBR

Gargalo de largura de banda e tempo de propagação de ida e volta (BBR) é um CCA desenvolvido no Google em 2016. Embora a maioria dos CCAs seja baseada em perdas, na medida em que dependem da perda de pacotes para detectar congestionamento e taxas mais baixas de transmissão, BBR, como TCP Vegas , é baseado em modelo. O algoritmo usa a largura de banda máxima e o tempo de ida e volta em que a rede entregou o voo mais recente de pacotes de dados de saída para construir um modelo da rede. Cada confirmação cumulativa ou seletiva de entrega de pacote produz uma amostra de taxa que registra a quantidade de dados entregue durante o intervalo de tempo entre a transmissão de um pacote de dados e a confirmação desse pacote. À medida que os controladores de interface de rede evoluem de megabit por segundo para gigabit por segundo de desempenho, a latência associada ao bufferbloat em vez de perda de pacote torna-se um marcador mais confiável da taxa de transferência máxima, tornando os CCAs baseados em modelo que fornecem maior taxa de transferência e menor latência, como BBR , uma alternativa mais confiável para algoritmos baseados em perdas mais populares, como TCP CUBIC .

A BBR está disponível para Linux TCP desde Linux 4.9. Também está disponível para QUIC .

A versão 1 da BBR (BBRv1) é eficiente e rápida, mas sua imparcialidade para transmissões não-BBR é contestada. Quando implementado no YouTube , o BBRv1 gerou uma taxa de transferência de rede 4% maior e até 14% em alguns países. Enquanto a apresentação do Google mostra BBRv1 coexistindo bem com CUBIC, pesquisadores como Geoff Huston e Hock, Bless e Zitterbart consideram injusto para outras correntes e não escalável. Hock et al também encontraram "alguns problemas inerentes graves, como atrasos de enfileiramento aumentados, 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 um bom desempenho em ambientes dinâmicos, como redes celulares. Eles também mostraram que o BBR tem um problema de injustiça. Por exemplo, quando um fluxo CUBIC (que é a implementação TCP padrão no Linux, Android e MacOS) coexiste com um fluxo BBR na rede, o fluxo BBR pode dominar o fluxo CUBIC e obter dele toda a largura de banda do link (veja a figura 16 pol.).

A versão 2 tenta lidar com a questão da injustiça ao operar junto com o gerenciamento de congestionamento baseado em perdas, como o CUBIC. No BBRv2, o modelo usado pelo BBRv1 é aumentado para incluir informações sobre perda de pacotes e informações de Notificação de Congestionamento Explícito (ECN). Embora o BBRv2 possa, às vezes, ter uma taxa de transferência menor do que o BBRv1, geralmente é considerado que tem um goodput melhor .

C2TCP

Cellular Controlled Delay TCP (C2TCP) foi motivado pela falta de uma abordagem TCP ponta a ponta flexível que pudesse satisfazer vários requisitos de QoS para diferentes aplicativos sem exigir nenhuma alteração nos dispositivos de rede. O C2TCP visa satisfazer os requisitos de latência ultrabaixa e largura de banda alta de aplicativos como realidade virtual , videoconferência , jogos online , sistemas de comunicação veicular , etc. em um ambiente altamente dinâmico, como LTE atual e futuras redes celulares 5G . C2TCP funciona como um add-on em cima do TCP baseado em perdas (por exemplo, Reno, NewReno, CUBIC , BIC , ...), ele só precisa ser instalado no lado do servidor e faz o atraso médio dos pacotes vinculados a os atrasos desejados definidos pelos aplicativos.

Pesquisadores da NYU mostraram que o C2TCP supera o desempenho de atraso e variação de atraso de vários esquemas 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 de pacotes em cerca de 250%, 900% e 700%, respectivamente, em vários ambientes de rede celular.

Elastic-TCP

O Elastic-TCP foi proposto em fevereiro de 2019 para aumentar a utilização da largura de banda em redes de alto BDP no suporte à computação em nuvem. É um CCA baseado em Linux projetado para o kernel Linux. É um algoritmo do lado do receptor que emprega uma abordagem baseada no atraso de perda usando um novo mecanismo chamado função de ponderação correlacionada à janela (WWF). Possui 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 com o TCP Composto (o CCA padrão no MS Windows), CUBIC (o padrão para Linux) e TCP-BBR (o padrão do Linux 4.9 usado pelo Google) usando o simulador NS-2 e o testbed. O Elastic-TCP melhora significativamente o desempenho total em termos de taxa de transferência média, taxa de perda e atraso.

NATCP

Soheil Abbasloo et. al. propôs o NATCP (Network-Assisted TCP), um projeto de TCP polêmico voltado para a computação de borda de acesso múltiplo (MEC). A ideia principal do NATCP é que, se as características da rede fossem conhecidas de antemão, o TCP teria sido projetado de forma diferente. Portanto, o NATCP emprega os recursos e propriedades disponíveis nas atuais arquiteturas celulares baseadas em MEC para empurrar o desempenho do TCP para perto do desempenho ideal. O 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 do celular e o RTT mínimo da rede, orienta os servidores a ajustar suas taxas de envio. Como mostram os resultados preliminares, o NATCP supera os esquemas TCP de última geração.

Outros algoritmos de prevenção de congestionamento TCP

TCP New Reno foi o algoritmo mais comumente implementado, o suporte a SACK é muito comum e é uma extensão do Reno / New Reno. A maioria dos outros são propostas concorrentes que ainda precisam de avaliação. A partir do 2.6.8, o kernel do Linux mudou a implementação padrão de New Reno para BIC . A implementação padrão foi novamente alterada para CUBIC na versão 2.6.19. O FreeBSD usa New Reno como algoritmo padrão. No entanto, ele oferece suporte a várias outras opções.

Quando o produto por fluxo de largura de banda e latência aumenta, independentemente do esquema de enfileiramento, o TCP se torna ineficiente e sujeito à instabilidade. Isso se torna cada vez mais importante à medida que a Internet evolui para incorporar links ópticos de largura de banda muito alta.

O TCP Interactive (iTCP) permite que os aplicativos assinem eventos TCP e respondam de acordo, permitindo várias extensões funcionais ao TCP de fora da camada TCP. A maioria dos esquemas de congestionamento TCP funciona internamente. O iTCP também permite que aplicativos avançados participem diretamente do controle de congestionamento, como controlar a taxa de geração da fonte.

O Zeta-TCP detecta os congestionamentos das medidas de latência e taxa de perda e aplica diferentes estratégias de recuo da janela de congestionamento com base na probabilidade dos congestionamentos para maximizar o goodput . Ele também tem algumas outras melhorias para detectar com precisão as perdas de pacotes, evitando retransmissão por tempo limite de retransmissão; e acelerar / controlar o tráfego de entrada (download).

Classificação por reconhecimento de rede

Os CCAs são classificados em relação ao reconhecimento da rede, ou seja, até que ponto esses algoritmos estão cientes do estado da rede e consistem em três categorias principais: caixa preta, caixa cinza e caixa verde.

Os algoritmos de caixa preta oferecem métodos cegos de controle de congestionamento. Eles operam apenas no feedback binário recebido no congestionamento e não assumem nenhum conhecimento sobre o estado das redes que gerenciam.

Os algoritmos de caixa cinza usam instâncias de tempo para obter medições e estimativas de largura de banda, contenção de fluxo e outros conhecimentos das condições da rede.

Os algoritmos de caixa verde oferecem métodos bimodais de controle de congestionamento que medem a parcela justa da largura de banda total que deve ser alocada para cada fluxo, em qualquer ponto, durante a execução do sistema.

Caixa preta

  • TCP de alta velocidade
  • O BIC TCP (Protocolo Binário de Controle de Aumento de Congestionamento) utiliza um aumento côncavo da taxa de origem após cada evento de congestionamento até que a janela seja igual à anterior ao evento, a fim de maximizar o tempo de utilização total da rede. Depois disso, ele testa agressivamente.
  • CUBIC TCP - uma derivada menos agressiva e mais sistemática do BIC, em que a janela é uma função cúbica do tempo desde o último evento de congestionamento, com o ponto de inflexão definido para a janela anterior ao evento.
  • AIMD-FC (aumento aditivo, diminuição multiplicativa com convergência rápida), uma melhoria do AIMD.
  • Mecanismos Binomiais
  • Protocolo SIMD
  • GAIMD

Caixa cinza

  • TCP Vegas - estima o atraso de enfileiramento e aumenta ou diminui linearmente a janela para que um número constante de pacotes por fluxo seja enfileirado na rede. Vegas implementa justiça proporcional.
  • FAST TCP - atinge o mesmo equilíbrio que Vegas, mas usa controle proporcional em vez de aumento linear e dimensiona intencionalmente o ganho à medida que a largura de banda aumenta com o objetivo de garantir a estabilidade.
  • TCP BBR - estima o atraso de enfileiramento, mas usa aumento exponencial. Intencionalmente, diminui a velocidade periodicamente para fins de justiça e diminuição do atraso.
  • TCP-Westwood (TCPW) - uma perda faz com que a janela seja redefinida para a estimativa do remetente do produto de atraso de largura de banda, que é o menor RTT medido vezes a taxa observada de recebimento de ACKs.
  • C2TCP
  • TFRC
  • TCP-Real
  • TCP-Jersey

Caixa verde

Os algoritmos a seguir exigem que campos personalizados sejam adicionados à estrutura do pacote TCP:

  • Protocolo de controle explícito (XCP) - os pacotes XCP carregam um cabeçalho de congestionamento com um campo de feedback, indicando o aumento ou diminuição da janela de congestionamento do remetente. Os roteadores XCP definem o valor de feedback explicitamente para eficiência e justiça.
  • MaxNet - MaxNet usa um único campo de cabeçalho, que carrega o nível máximo de congestionamento de qualquer roteador em um caminho de fluxo. A taxa é definida como uma função desse congestionamento máximo, resultando em justiça máx-mín .
  • JetMax - JetMax , como MaxNet, também responde apenas ao sinal de congestionamento máximo, mas também carrega outros campos aéreos

Uso do Linux

  • O BIC é usado por padrão nos kernels Linux 2.6.8 a 2.6.18. (Agosto de 2004 - setembro de 2006)
  • CUBIC é usado por padrão nos kernels do Linux desde a versão 2.6.19. (Novembro de 2006)
  • O PRR é incorporado aos kernels do Linux para melhorar a recuperação de perdas desde a versão 3.2. (Janeiro de 2012)
  • A BBR é incorporada aos kernels do Linux para permitir o controle de congestionamento baseado em modelo desde a versão 4.9. (Dezembro de 2016)

Veja também

Notas

Referências

Fontes

links externos