Controle de Congestionamento com Vegas

Introdução ao Controle de Congestionamento

Pelo fato dos emissores e receptores, nas redes de computadores, serem de potência variada, o buffer de um receptor pode ter sua capacidade esgotada por um emissor mais veloz, fazendo com que o uso dessa tecnologia não funcione perfeitamente.
As consequências destes colapsos de congestionamento são o aumento no tempo de entrega dos pacotes, diminuição em sua vazão e desperdício de recursos. A partir desta demanda, o controle de congestionamento foi proposto por Van Jacobson em 1997 [RFC 2001 e revisada em RFC 2581] e continua sendo aprimorado.
Os principais algoritmos de controle de congestionamento de redes com protocolo TCP são Slow-Start (Partida Lenta), Congestion Avoidance (Prevenção de Congestionamento), Fast Retransmit e Fast Recovery (Reno) [2].

O Vegas

A implementação do TCP Vegas resume-se ao lado do transmissor, sendo sua politica de reconhecimentos a mesma do TCP Reno. A proposta de Lawrence Brakmo, Sean Malley e Larry Peterson em 1994 era aumentar a taxa de transferência e reduzir a perda de segmentos em períodos de congestionamento. Alguns especialistas consideram que o TCP Vegas é pró-ativo e ou cauteloso, por que tem o poder de observar um congestionamento e prevenir-se das perdas.

Congestion Avoidance

Através da estimativa de vazão da conexão, o mecanismo de Congestion Avoidance do Vegas são arbitrados em um limite mínimo e máximo de vazão. A janela de congestionamento (CWND – Congestion Window) se responsabiliza de manter a vazão nestes limites.

Slow-Start

No início de uma conexão do TCP Vegas ocorre um aumento exponencial, porém a cada dois RTTs. Diferenciando-se do TCP Reno que gera congestionamento na rede sempre que inicia uma conexão.

Retransmissão

Devido a um relógio de baixa resolução, encontrado em geral nas implementações do TCP, que dá um tick a cada 500ms (resolução baixa para RTTs de time-outs 100ms), o TCP Vegas tenta eliminar a dependência do TCP de temporizadores de baixa precisão.
A estimativa do RTT é feita a cada segmento enviado e a cada ACK recebido. O Vegas sempre lê o relógio do sistema e registra o tempo de round-trip. O cálculo do RTT é feito usando os mesmos algoritmos do Reno, porém as medidas são mais exatas [4].
Visando garantir que o TCP Vegas não baixe sua taxa de transmissão, a janela de congestionamento é diminuída a cada perda de segmento e é feita apenas uma vez na janela de dados [3].

Simulação de rede

Topologia da Rede

Para exemplificar e ou comparar o desempenho das variantes do TCP, foi escolhido a topologia composta por dois terminais utilizando Vegas e Reno. A Figura 1, representa melhor o cenário.

Figura 1. Topologia de Rede

Há dois terminais, um Vegas e outro Reno, sendo suas configurações:

  • Tipo de conexão: FTP
  • Tamanho do pacote: 552 bytes
  • Tamanho máximo da janela: 8000
  • Limite máximo de segmentos: 100
  • Largura da banda: 10 Mbps
  • Tempo de atraso até o gargalo da rede: 10ms

O enlace de congestionamento (n0 até n1) possui a seguinte configuração:
Largura de Banda: 0,7 Mbps
Atraso dos Pacotes: 20 ms
Tamanho Máximo da Fila de Congestionamento: 10 Mbps

Na Prática

O controle de congestionamento foi realizado sem a necessidade da ocorrência de perdas, todavia a implementação TCP Vegas se saiu melhor na análise.
Durante o teste o TCP Vegas precisou passar, somente na fase inicial, pelo Slow-Start e logo após cresceu exponencialmente. Em alguns períodos entrou em Congestion Avoidance, ajustando a taxa de transmissão para evitar congestionamento.
Por não ser uma medida preventiva, a implementação Reno chegou em muitos momentos ao Slow-Start. Diferenciando-se assim do Vegas, que conseguiu observar o congestionamento e se prevenir.

Figura 2. Teste Janela de Congestionamento

Na Figura 3 é possível observar a linha verde que representa o fluxo médio e na linha vermelha a vazão dos pacotes transmitidos.
A implementação Reno consegue momentos de pico na vazão dos pacotes, porém não consegue um fluxo médio tão interessante quanto o Vegas. O Vegas se demonstra uma implementação cautelosa e eficiente, mantendo sempre uma média sem muita oscilação.

Figura 3. Comparação de Vazão

Conclusão

A partir da demanda de atender diferentes potencias de computadores e ao número cada vez maior de usuários das redes de computadores, os estudos na área de implementação do TCP se tornaram comum e fundamental, sendo um dos temas mais ativos da informática. Os protocolos Vegas e Reno são os que mais se destacam, e foram escolhidos para comparação. Contudo o Vegas é a implementação que consegue a menor perda de pacotes e o menor atraso médio.

Referências

“TCP Vegas Simulation using NS2”, http://students.cs.tamu.edu/ssingh/files/TCP_Vegas_simulation.pdf, 01/10/09.
Prete R. Lígia, Shinoda A. Ailton “Análise do Comportamento das Variações do Protocolo TCP”, www.congresscentral.com.br/cnmac2009/pub/arquivos/153_a1703_(resubmitted)_(002553)_artigocnmac2009v2.pdf, 01/10/09.
Ferreira J. Cleiton “Controle de Congestionamento”, http://www.oficinadanet.com.br/artigo/968/controle_de_congestionamento, 01/10/09.
Antonelli A. André, Burgos P. Mercelo “Estudo das Variações do Protocolo TCP”, www.daeln.ct.utfpr.edu.br/~tcc-daeln/TCCs2007/Protocolo%20TCP.pdf, 01/10/09.

Anúncios