Resumo

Diversas pesquisas avaliando as implementações TCP sobre redes ATM via satélite são encontradas em teses e artigos. A conclusão obtida pelos estudos indica que o TCP SACK (Selective Acknowledgement) apresenta uma performance superior ao TCP Tahoe, Reno e New-Reno. Essa superioridade ocorre porque com o SACK, o transmissor pode obter informações suficientes do receptor com referência aos segmentos recebidos corretamente e dessa forma é capaz de retransmitir múltiplos segmentos perdidos de uma janela de congestionamento durante um RTT (Round Trip Time). Este artigo descreve o comportamento do TCP Vegas operando sobre uma rede ATM via satélite, apresenta a performance por ele alcançada em função de diferentes tipos de tráfego e compara os resultados obtidos por meio de simulações do TCP SACK e Vegas. Além disso, neste artigo é realizado um estudo do desempenho das duas implementações utilizando o recurso da janela de dados TCP aumentada e da janela de congestionamento inicial maior que um segmento.

1 Introdução

ATM é uma técnica de comutação rápida de pacotes baseada em padrões abertos que possui recurso tecnológico para servir de transporte comum para todos os tipos de tráfego, como voz, dados, imagem, texto, vídeo e aplicações multimídia. Atualmente, existe um grande reconhecimento dos benefícios e das vantagens da implantação de uma rede ATM via satélite pelos seguintes motivos:

• Conectividade em regiões de difícil acesso para instalação de infra-estrutura terrestre.
• A rede ATM sobre satélite pode oferecer serviços de alta velocidade e com QoS para uma ampla área geográfica.
• Independência de infra-estrutura terrestre.

A arquitetura TCP/IP baseia-se no serviço de transporte orientado à conexão fornecido pelo TCP (Transmission Control Protocol) e em um serviço de rede não orientado à conexão fornecido pelo IP (Internet Protocol). Essa arquitetura é a mais utilizada mundialmente por apresentar as seguintes características:

• Arquitetura desenvolvida para interligar diferentes tecnologias de redes.
• Independência de tecnologia.
• Protocolo simples e eficiente.

O objetivo deste artigo é investigar a performance obtida pelo TCP Vegas que de acordo com a literatura pesquisada, ainda não foi avaliado num ambiente de rede ATM sobre satélite para então efetuar uma avaliação comparativa com o TCP SACK. Esta pesquisa é conduzida iniciando com uma pequena abordagem da característica de uma rede ATM via satélite. Em seguida é apresentado o modo de operação do protocolo TCP, seus pontos fracos e o motivo da realização do estudo comparativo entre o TCP Vegas e o TCP SACK. Na seção 4 é realizada a avaliação do TCP SACK e do TCP Vegas através de simulações utilizando um modelo de rede específica. A seção 5 discute o impacto causado no desempenho da rede ATM via satélite em função do aumento da janela de dados TCP e do aumento da janela de congestionamento inicial. A última seção descreve o resultado conclusivo da avaliação comparativa realizada entre as duas implementações TCP.

2 Redes ATM Via Satélite

A estrutura básica de uma rede ATM via satélite [1] é constituída de terminais de computador, da ASIU (ATM Satellite Internetworking Unit), modems para satélite, antenas e o satélite. A figura 1 ilustra a pilha de protocolo para uma rede ATM via satélite. A ASIU é o componente principal dessa arquitetura, fazendo o papel de interface entre o switch ATM e o modem específico do satélite. Esse equipamento é responsável pelo gerenciamento e controle dos recursos do sistema.

3 Visão Geral do TCP

O TCP [2] é um protocolo que fornece um serviço full-duplex, orientado à conexão, destinado ao transporte confiável de diversas aplicações (WEB, SMTP, FTP, TELNET, etc.). O TCP é responsável pelo transporte, controle de fluxo, verificação de erros e, caso necessário a retransmissão dos dados do transmissor até o receptor. Para este protocolo, cada vez que o transmissor envia um segmento ele aciona um temporizador. Ao receber o segmento o receptor retorna um aviso com o número de confirmação (ACK) igual ao próximo número de seqüência que espera receber. Se o temporizador do transmissor expirar antes de a confirmação ser recebida, o segmento será retransmitido. A janela de congestionamento (CWND) controla o fluxo de segmentos na rede durante todo o intervalo de tempo de uma transmissão. Então o TCP utiliza a estratégia do mecanismo de aumento aditivo e diminuição multiplicativa para alterar o tamanho da janela de congestionamento em função do estado de congestionamento na rede [3,4]. A transmissão é iniciada com o envio de um segmento e a CWND é aumentada exponencialmente para cada ACK não duplicado recebido até atingir a máxima capacidade disponível no canal de transmissão. Essa operação é conhecida como técnica Slow Start e a capacidade estimada como limite máximo permitido de segmentos na rede é chamada de limitante (SSTHRESH - Slow Start Threshold) [5]. Quando a janela de congestionamento atinge o valor do limitante, o TCP passa a operar com a técnica Congestion Avoidance, aumentando a janela de congestionamento de um segmento a cada RTT. O aumento da janela é interrompido quando uma perda de segmentos é detectada ou quando atinge o tamanho da janela fornecida pelo receptor. Dois mecanismos estão disponíveis para detecção de perdas: o timeout e o algoritmo Fast Retransmit que reduz a janela de congestionamento para a metade do valor atual quando notifica a presença de ACKs duplicados. A técnica Fast Recovery é empregada após a fase Fast Retransmit quando o TCP transmissor recebe o primeiro ACK de um novo segmento e nesse instante a CWND é ajustada para o valor de SSTHRESH e a técnica Congestion Avoidance entra em operação. Se o tempo de retransmissão dos segmentos descartados ultrapassar o timeout, o TCP passa a operar com a técnica Slow Start.

Para as redes ATM via satélite, devido à grande distância entre os hosts e o satélite, o atraso de propagação é elevado e conseqüentemente a eficiência dos mecanismos de controle de congestionamento TCP é baixa. Pode–se citar os seguintes fatores responsáveis por essa baixa performance:

• O tempo de propagação em ambientes de satélite geoestacionários é muito alto, fazendo com que o TCP transmissor espere um longo tempo pelo ACK (mais que 200 ms).
• O valor do BDP (Bandwidth Delay Product) é muito alto, possibilitando a transmissão de muitos segmentos sem a necessidade do recebimento de reconhecimento proveniente do receptor. Mesmo assim o protocolo TCP apresenta uma baixa eficiência devido ao descarte de segmentos que ocorre durante a transmissão, acionando diversas vezes o algoritmo Slow Start.
• Os enlaces de satélite apresentam um valor de BER (Bit Error Rate) muito maior que os enlaces terrestres devido à alta incidência de ruídos. Conseqüentemente, o TCP interpreta a recepção com erros e/ou perda de segmentos durante uma transmissão como sendo ocasionada pelo congestionamento, o que provoca uma redução desnecessária do tamanho da CWND.
• O tamanho da CWND é reduzido a 1 segmento toda vez que o TCP inicia a fase Slow Start. Isso implica numa baixa capacidade de utilização da banda passante do canal durante os instantes iniciais do Slow Start. Com intuito de elevar a performance do TCP foram desenvolvidas diversas implementações TCP, sendo as mais conhecidas o TCP Tahoe, Reno, New-Reno, SACK e Vegas.

O TCP Tahoe [6] opera com as técnicas Slow Start, Congestion Avoidance e Fast Retransmit. O principal problema desse algoritmo ocorre quando muitos segmentos são perdidos fazendo acionar a técnica Slow Start diversas vezes e provocando, dessa forma, uma baixa eficiência na rede.

O TCP Reno [7] difere do TCP Tahoe, pois o ACK é realizado para cada segmento enviado e, além disso, a técnica Fast Recovery é incluída fazendo com que a janela de congestionamento seja aumentada pelo número de ACKs duplicados que o TCP transmissor recebe antes do recebimento de um novo ACK. A baixa eficiência do TCP Reno ocorre quando múltiplos segmentos são perdidos de uma CWND, porque este algoritmo não retorna para a fase Slow Start e sim aciona a fase Congestion Avoidance, reduzindo a CWND para a metade do seu valor diversas vezes. Entretanto, se o timeout expirar, o TCP Reno começa a transmissão pela fase Slow Start.

O TCP New-Reno [8] modifica a ação tomada pelo recebimento de novos ACKs. O TCP deixa a fase Fast Recovery quando ele recebe um ACK reconhecendo todos os segmentos incluindo o recover ( número de mais alta seqüência enviado). A limitação do TCP New-Reno relativa ao TCP SACK é mais pronunciada quando o TCP opera com um valor elevado para janela de congestionamento sob enlaces com alto valor de BER, causando um grande número de descartes de segmentos na janela de dados TCP. O problema da retransmissão de mais de um segmento a cada RTT resulta num atraso substancial no envio de outros segmentos. Além disso, se o transmissor é limitado pela janela de anúncio do receptor durante o período de recovery, então o transmissor fica incapaz de utilizar de modo efetivo a banda passante disponível no canal.

A opção SACK [9] aumenta a performance do TCP em redes de alta velocidade e com alto atraso. Com a técnica SACK, o transmissor obtém informações suficientes sobre os segmentos recebidos corretamente pelo receptor e dessa forma é capaz de retransmitir em um RTT múltiplos segmentos perdidos de uma janela de dados. Muitos estudos foram realizados com as implementações TCP sobre uma rede ATM via satélite [10,11,12,13] e os resultados obtidos mostram que o TCP SACK comparado ao Tahoe, ao Reno e ao New-Reno é a implementação TCP que obteve o melhor desempenho.

O TCP Vegas [14,15,16] é uma implementação introduzida no TCP por meio de algumas modificações realizadas no mecanismo de controle de congestionamento no lado do transmissor. O TCP Vegas transmissor antecipa o princípio de congestionamento monitorando a diferença entre a taxa esperada e a taxa real. O Vegas usa a estratégia de ajuste da taxa de envio de dados da origem (janela de congestionamento) na tentativa de manter um pequeno número de pacotes armazenados nos switches durante uma transmissão.
O TCP Vegas é essencialmente uma combinação de diferentes técnicas, possuindo um algoritmo de início de conexão, um para o estado estacionário e um para controlar as retransmissões. As três técnicas que empregam o aumento da eficiência e a redução das perdas no TCP são:

1. Mecanismo de Retransmissão
   O tempo despendido no envio de cada segmento é lido e registrado pelo TCP Vegas. Para um segmento enviado, quando o ACK é recebido, o Vegas faz a leitura do tempo e calcula o RTT usando esse valor e o tempo registrado do segmento. O Vegas usa essa estimação precisa de RTT para retransmitir segmentos nas duas situações a seguir:
   • Quando um reconhecimento duplicado é recebido, o Vegas verifica se a diferença entre o tempo atual e o tempo registrado para o último segmento não reconhecido é maior que o valor do timeout. Se for, o segmento é retransmitido sem a necessidade de esperar por três ACKs duplicados. Esse mecanismo é vantajoso em redes que operam com alto índice de congestionamento causado por um fluxo elevado de dados que podem provocar perdas de segmentos.
   • Quando um reconhecimento normal é recebido, sendo este o primeiro ou o segundo após uma retransmissão, o Vegas atua do mesmo modo, comparando o instante do envio do último segmento e o instante de tempo atual. Se a diferença for maior que o valor do timeout, o segmento é retransmitido.
2. Mecanismo Congestion Avoidance
   O método Congestion Avoidance do Vegas utiliza uma técnica de achatamento da taxa de envio em caso de indicativo de congestionamento. Esse mecanismo no Vegas é baseado no cálculo da estimativa da vazão da conexão. O mecanismo limita o valor mínimo e máximo para a vazão de uma conexão TCP. O algoritmo opera de modo a manter a vazão dentro desse limite, executando esse controle por meio da janela de congestionamento. Ele compara a medida da vazão real(medida) com o valor da vazão esperada. A idéia é simples, pois o número de bytes em trânsito é diretamente proporcional à vazão esperada e, por isso, como o tamanho da janela aumenta a cada RTT, o número de bytes em trânsito também aumenta, elevando a eficiência da conexão. O Vegas usa a idéia de medir e controlar a quantidade de dados que não foram enviados porque a quantidade de bits em trânsito na conexão ocupa toda a banda passante disponível na rede.
3. Slow Start
   O TCP Vegas visa monitorar a banda passante disponível na conexão de modo a detectar e evitar perdas de segmentos na fase Slow Start. A mudança realizada no Vegas permite que ocorra um crescimento exponencial do número de segmentos a ser enviado apenas a cada dois intervalos de RTT. Durante um dos intervalos de RTT, a janela de congestionamento fica fixa e desse modo realiza-se uma comparação entre a taxa esperada e a taxa real. Quando a taxa real é menor que a taxa esperada, o Vegas muda da fase de Slow Start para o modo linear increase/decrease. O motivo de se medir a taxa real com uma janela de congestionamento mantida fixa é que a taxa real representa a banda passante permitida pela conexão. Então pode-se apenas enviar o número de dados que foram reconhecidos dentro do ACK.
   Os mecanismos de controle de congestionamento fornecidos pelas categorias de serviço ATM tratam do controle de congestionamento na rede através do policiamento do espaço de buffer dos switches. Em ambientes de satélite ocorrem muitas perdas de células ocasionadas por erro de transmissão (BER elevado). O TCP entende como congestionamento qualquer segmento perdido ou o recebimento de três ACKs fora de ordem e desse modo reduz o valor da sua janela de congestionamento para dar continuidade ao processo de transmissão de novos segmentos. Nesse contexto o UBR é bem apropriado porque não possui nenhum mecanismo de controle de congestionamento, sua implementação é simples e apresenta um custo/benefício bem satisfatório. Na utilização do UBR todo o controle de congestionamento na rede é executado exclusivamente pelo TCP. Um dos problemas do estudo de redes ATM via satélite é a baixa utilização da banda passante do canal de transmissão, Os switches usados para transmissão via satélites podem possuir uma capacidade de armazenamento de células maior que o valor do BDP, logo não há necessidade de usar um rigoroso policiamento. Goyal [10,17] demonstra que a utilização de gerenciamento de buffer não é um fator relevante para o aumento da eficiência do TCP em ambientes de satélite.
   Por não ser imprescindível o policiamento de buffer do switch, o mecanismo de Tail Drop (TD) para o UBR é indicado, porque permite compartilhar todo o espaço de buffer entre as conexões. O TD utiliza a regra de enfileiramento FIFO (a primeira célula que entra é a primeira que sai do switch). Quando o tamanho de buffer do switch atinge 100% da sua capacidade, as próximas células recebidas são descartadas na seqüência em que chegam e o TCP se responsabiliza pela retransmissão. Nesse contexto as próximas seções terão como objetivo primordial avaliar qual das implementações Congestion Avoidance TCP apresenta o melhor desempenho em redes ATM utilizando a categoria de serviço UBR com policiamento Tail Drop sobre satélites geoestacionários.

4 Avaliação da Performance

Para investigar e comparar o TCP Vegas com o TCP SACK, este artigo utiliza um modelo simples de rede ilustrado na figura 2. O modelo de rede é uma interconexão ponto a ponto entre uma empresa situada em São Paulo e sua filial em Cuiabá. Esta seção discute o resultado obtido pelas simulações.

4.1 Resultados das Simulações

Neste artigo foi usado um simulador de rede de evento discreto conhecido como NS, versão 2.1b6, desenvolvido no laboratório de Berkeley [18] para análise da performance do TCP Vegas e SACK atuando sobre o modelo de configuração da rede ATM via satélite mostrado na figura 2.

4.2 Configuração da rede

Para investigar a performance do TCP Vegas e do TCP SACK as simulações são realizadas utilizando as fontes de tráfego CBR, Exponencial e Pareto de modo a obter um resultado mais confiável e seguro da análise comparativa entre os dois algoritmos TCP operando sobre uma rede ATM via satélite.
Para a realização das simulações os principais parâmetros de entrada que foram utilizados nas simulações são mostrados abaixo:

1. Tamanho de buffer do switch da Embratel e dos backbones das universidades igual a 12.000 células e 1.200 células para o tamanho de buffer dos switches dos laboratórios.
2. Erro Exponencial pela taxa = 5 % para o enlace de satélite.
3. Estação de Cuiabá: latitude = 15° 38’ 40,2” e longitude = 56° 0’ 30,9”
4. Estação de São Paulo: Latitude = 23,54° e longitude = 46,71°
5. Satélite: BRASILSAT–2 = 65°
6. Tamanho máximo do segmento (MSS) = 9.180 Bytes

4.3 Análise das Simulações

A análise do desempenho dos dois algoritmos TCP é executado com as fontes de tráfego CBR e VBR com distribuiçao exponencial e Pareto.

1 Fonte de Tráfego CBR

Para as fontes de tráfego CBR, os resultados obtidos com relação a CWND, número de de segmentos recebidos pelo TCP de destino e a eficiência são mostrados na figura 3.
Pela análise dos gráficos pode-se constatar que o tamanho da janela de congestionamento do TCP Vegas foi superior ao do TCP SACK. Em conseqüência disso o TCP Vegas transmitiu uma quantidade maior de segmentos do que o TCP SACK durante os 40 s em que ocorreu a simulação. Nesse contexto, o TCP Vegas obteve a melhor performance quando uma fonte de tráfego CBR foi aplicada sobre o modelo da rede ATM utilizando a categoria de serviço UBR via satélite.
O TCP Vegas forneceu a melhor eficiência para a rede porque o controle de congestionamento foi realizado sem a necessidade da ocorrência de perdas. O TCP Vegas controla o congestionamento na rede monitorando o resultado obtido da diferença entre a taxa real e a taxa esperada para então ajustar o tamanho da janela de congestionamento.
O TCP SACK proporciona ao TCP transmissor obter informação suficiente dos segmentos que foram recebidos corretamente de uma determinada janela de congestionamento por parte do receptor. Porém sob um estado de perdas severo aconteceu o descarte da informação de SACK e o transmissor passou a enviar os segmentos iniciando com uma janela de congestionamento de tamanho unitário, como pode ser visto na figura 3, com o gráfico relacionado a CWND em função do tempo. Isso ocasionou a redução no desempenho do TCP SACK.

2 Fonte de Tráfego VBR com distribuição exponencial

A segunda análise do desempenho das implementações TCP é realizada com uma fonte de tráfego VBR utilizando uma distribuição exponencial. Para a primeira análise o valor do tempo da rajada (BT-Burst Time) foi fixado em 1 s e o tempo de ociosidade (IT-Idle Time) variou como pode ser visto na figura 4.

Pela análise do gráfico do número de segmentos enviado em função do tempo de ociosidade pode ser verificado que a performance das duas implementações é reduzida à medida que o tempo de ociosidade da fonte de tráfego aumenta. A performance do TCP Vegas foi superior à do TCP SACK até o tempo de ociosidade igual a 1 s. Para valores de IT acima de 1 s, o TCP SACK passou a fornecer um desempenho superior na rede. Esse resultado ocorre devido ao princípio de operação dos algoritmos conforme foi descrito na seção 3.
O melhor resultado obtido ocorreu quando o tempo de ociosidade da fonte de tráfego foi de 0,5 s fazendo com que o TCP Vegas fosse capaz de transmitir 368 segmentos durante os 40 s de simulação. Para essa condição ocorreu a máxima eficiência na rede ATM via satélite o que pode ser observado visualizando o gráfico da eficiência com relação ao Idle Time.
Para o valor de Burst Time fixado em 10 s, novamente a performance dos dois algoritmos foi reduzida à medida que se aumentou o valor de IT, como pode ser observado na figura 5.

Novamente, o TCP Vegas forneceu a melhor performance na rede até o tempo de ociosidade máximo de 1 s. Para valores de IT superiores a 1 s, o TCP SACK passou a fornecer o melhor desempenho. A melhor condição obtida pela rede aconteceu quando o tempo de ociosidade foi de 0,5 s, o que ocasionou uma transmissão de 335 segmentos pelo TCP Vegas conforme mostrado no gráfico do número de segmentos em função do Idle Time na figura 5. Em conseqüência disso a eficiência fornecida por esse algoritmo foi de 0,45 % como pode ser visto no gráfico referente à eficiência. Os resultados obtidos quando o tempo da rajada foi de 30 s são mostrados na figura 6.

A performance do TCP Vegas se sobresaiu ao SACK até o valor de IT igual a 6 s. O máximo desempenho observado na rede ocorreu quando IT foi igual a 0,5 s onde o TCP Vegas transmitiu 338 segmentos durante o intervalo de tempo da simulação conforme pode ser visualizado no gráfico referente ao número de segmentos enviados em função do Idle Time. Para essa situação a eficiência fornecida pelo TCP Vegas na rede foi de 0,46 %. Esse resultado pode ser verificado através do gráfico da eficiência em função do Idle Time.

3 Fonte de Tráfego VBR com distribuição Pareto

Esta etapa mostra o resultado obtido quando a fonte de tráfego VBR com distribuição Pareto é aplicada sobre as implementações Vegas e SACK utilizando os parâmetros para a condição (shape- SH) da distribuição de Pareto igual a 1 e 2.
Para o valor de SH igual a 1, foi constatado através das simulações realizadas que, para qualquer valor de BT e de IT, a resposta obtida para o número de segmentos enviados e consequentemente para a eficiência manteve-se inalterado para as duas implementações TCP. A tabela 1 apresenta o resultado obtido para o TCP Vegas e SACK.
Para essa condição, o desempenho do TCP SACK foi superior ao do TCP Vegas.

Tabela 1. Resultados obtidos pelo TCP Vegas e SACK – distribuição Pareto com shape = 1

	Números de segmentos transmitidos	Eficiência %
SACK	328	0,45
Vegas	225	0,3

Para o valor de SH igual a 2, a primeira análise é realizada com o tempo da rajada fixado em 1 s e os resultados obtidos nas simulações são mostradas na figura 7.
Pela figura pode-se constatar que, à medida que o valor do tempo de ociosidade aumenta, a performance das duas implementações é reduzida. O TCP Vegas obteve performance superior à do TCP SACK até o tempo máximo de ociosidade igual a 1 s.

O melhor desempenho obtido na rede foi obtido para IT igual a 0,5 s. Para essa condição o TCP Vegas apresentou a melhor performance transmitindo 358 segmentos e atingindo uma taxa de eficiência igual a 0,49 %, como pode ser observado através do gráfico da eficiência em função do Idle Time.
Os resultados obtidos quando o valor do shape foi igual a 2 e o tempo da rajada fixado em 10 s são mostrados na figura 8.

Pela análise do gráfico referente ao número de segmentos enviado em função do Idle Time, pode-se concluir que para essa condição o aumento do tempo de ociosidade causa redução da eficiência das duas implementações avaliadas. O TCP Vegas obteve desempenho superior ao do TCP SACK até o valor de IT igual a 8 s. O melhor desempenho alcançado pela rede ATM ocorreu utilizando o TCP Vegas quando IT foi igual 0,5 s e 1 s ocasionando uma transmissão de 337 segmentos resultando numa eficiência de 0,46 % conforme pode ser visto no gráfico da eficiência em função do Idle Time.
Para o valor de SH igual a 2 e o tempo de rajada fixada em 30 s, os resultados obtidos através das simulações são mostrados na figura 9. Pelos gráficos pode-se constatar que o TCP Vegas apresentou desempenho superior ao TCP SACK até o tempo de ociosidade igual a 8 s. O melhor desempenho obtido na rede ATM foi alcançado para o valor de IT igual a 1s. Para essa condição 355 segmentos foram transmitidos pelo TCP Vegas resultando numa eficiência igual a 0,46 %.

5 Avaliação do TCP Vegas e SACK em Função do Aumento da Janela de Dados TCP e da CWND

Um dos fatores importantes para que a arquitetura TCP/IP sobre redes ATM via satélite se torne atraente é fazer com que a banda passante disponível no enlace de satélite seja amplamente utilizada durante a transmissão de dados. Para que isso possa ocorrer, são propostas duas técnicas atuando no protocolo TCP.

• Aumento da janela de dados TCP
  A capacidade máxima da janela de dados do protocolo TCP (64KB) é bastante satisfatória para redes com enlaces terrestres. Porém num enlace de satélite, em que o tempo de atraso de propagação é alto, a eficiência é severamente afetada. A solução reside na ativação do campo window scale do cabeçalho TCP que proporciona o aumento do tamanho da janela de transmissão de dados para que mais segmentos possam ser enviados da origem ao destino em um determinado intervalo de tempo. A figura 10 mostra o resultado obtido da eficiência para o modelo da rede ATM via satélite da figura 2 sem a presença de erros nos enlaces e quando submetida a uma taxa de erro de 5 % utilizando a distribuição Exponencial.
  Pela análise dos gráficos, pode-se observar que se a rede operar em condição de erro igual ou próximo de zero, a eficiência dos dois protocolos aumenta consideravelmente. Taxa de erro igual a zero

  

  O TCP Vegas obteve uma eficiência máxima de 12,4 % a partir da janela de dados TCP igual a 2 MB. Para essa condição, verifica-se que o TCP SACK obteve um desempenho excelente com o aumento da janela de dados TCP atingindo uma eficiência da ordem de 90,8 % e se aproximando do desempenho que seria obtida utilizando somente enlaces terrestres. Para que esse desempenho ocorra na rede, o emprego da técnica de FEC (Forward Error Correction) é sugerido. A técnica FEC consiste na recuperação de bits corrompidos dos segmentos enviados pelo transmissor e desse modo fornece um BER entre 10-11 e 10-13 para a rede ATM via satélite, como pode ser comprovado observando a eficiência alcançada pelo TCP SACK na condição de erro igual a zero. A vantagem do emprego dessa técnica é que ela não interfere com os mecanismos TCP e desse modo é sugerida para utilização em redes ATM sobre satélite apesar do alto custo para sua implementação.
  Visualizando a figura 10, quando a rede é submetida a uma taxa de erro de 5 % verificase que a eficiência obtida pelos dois algoritmos é muito baixa e nessa situação em que não ocorre recuperação de erros e sim retransmissões de segmentos efetuadas pelas implementações TCP, o TCP Vegas obteve desempenho superior ao do TCP SACK. A máxima eficiência obtida pelo TCP Vegas foi de 0,67 % quando o tamanho da janela de dados TCP foi de 3 MB, contra 0,5 % obtida pelo TCP SACK para a janela de dados TCP de 500 KB. Esse resultado comprova que, na presença de uma alta incidência de erros, o TCP Vegas é mais apropriado para ser empregado numa rede ATM utilizando a categoria de serviço UBR sobre satélite quando nenhum mecanismo de controle de erro for utilizado.

• Aumento da Janela de Congestionamento Inicial
  O protocolo TCP inicia a transmissão de dados enviando um único segmento e aguardando o seu reconhecimento. A partir daí a cada intervalo de tempo (RTT) ocorre o aumento exponencial do número de segmentos a ser enviado da origem ao destino. O baixo desempenho do TCP ocorre exatamente durante os primeiros instantes da transmissão, quando o tamanho da janela de congestionamento é muito pequeno, ocasionando uma baixa utilização da banda passante disponível no canal de transmissão. A solução proposta é aumentar o tamanho inicial da CWND de modo a reduzir o tempo requerido para alcançar o valor do limitante. As vantagens da utilização da janela de dados inicial maior que o valor de um segmento se baseia nos seguintes fatos:
  1. Para uma conexão que transmite uma pequena quantidade de dados, uma janela inicial maior reduz o tempo de transmissão. Para transferências de e-mails e web pages que possuem tamanho menores que 4 KB, uma janela inicial maior reduz o tempo de transferência de dados para um único RTT.
  2. Para uma conexão que opera com uma janela de congestionamento inicial grande, essa modificação elimina mais do que três RTTs e um timeout por ACK atrasado durante a fase inicial de Slow Start.
  Essa pequena mudança no TCP gera grandes benefícios para a transferência de dados em enlaces de satélite. O valor máximo recomendado segundo a RFC 2581 [13] é CWND inicial igual a 2 segmentos para ambientes de satélite. Porém diversas pesquisas mostraram que o valor inicial da CWND inicial igual a 4 segmentos não provoca degradação da performance na rede [20,21]. O tamanho apropriado da janela de congestionamento inicial para o TCP Vegas e SACK que fornece a maior eficiência sobre redes ATM via satélite é mostrado na figura 11.
  Pela análise dos gráficos mostrado abaixo constata-se que, para a fonte de tráfego CBR de 64 KB e de 1 MB com ou sem incidência de erro aplicado ao TCP Vegas e SACK, o aumento da janela de congestionamento inicial não surtiu grandes vantagens e desse modo pode–se afirmar que, para o transporte de um grande arquivo de dados, o aumento da CWND inicial não aumentou de modo satisfatório a eficiência do modelo da rede ATM via satélite utilizada neste artigo.

  

  Porém, para o transporte de um pequeno arquivo de dados, como WEB e SMTP, a performance alcançada pelos dois algoritmos é mostrado na figura 12.
  Observando o gráfico pode-se verificar que o aumento da CWND inicial elevou substancialmente o desempenho dos dois algoritmos principalmente para o tamanho de janela de dados igual a 1 MB. Para a situação em que não ocorreram erros de transmissão, o TCP SACK obteve desempenho superior ao Vegas.

  

6 Conclusão

O protocolo de controle de transporte TCP foi desenvolvido com intuito de conectar as diversas redes de diferentes fabricantes numa única rede tornando-se o protocolo mais utilizado mundialmente. Para a arquitetura TCP/IP sobre a rede ATM via satélite, a categoria de serviço UBR foi empregada por ser uma implementação simples e principalmente porque não possui um mecanismo de controle de congestionamento. Quando o tamanho de buffer do switch é maior que o valor do BDP (Bandwidth Delay Product), o UBR não afeta o serviço executado pelo protocolo TCP. Desse modo as implementações TCP são exclusivamente responsáveis pelo controle de congestionamento na rede.
Este artigo apresentou a análise do desempenho alcançado pelo TCP Vegas em redes ATM via satélite para então compará-lo ao TCP SACK, que, segundo diversas pesquisas já realizadas, mostrou-se superior aos algoritmos TCP Tahoe, Reno e New-Reno.
Com intuito de obter uma avaliação comparativa mais criteriosa, este artigo abordou o desempenho das duas implementações quando submetidas as fontes de tráfego CBR e VBR com distribuição exponencial e Pareto. As conclusões obtidas referente a performance dos dois algoritmos atuando sobre a rede ATM via satélite são enumeradas abaixo.

1. Para a fonte de tráfego CBR aplicada às duas implementações TCP, constatou-se que o TCP Vegas apresentou desempenho superior ao TCP SACK. Isso é justificado devido ao seu princípio de operação que monitora o estado da rede a cada RTT, ajustando a CWND controlando assim o congestionamento na rede. Esse procedimento diferencia o Vegas dos outros algoritmos TCP que necessitam da ocorrência de alguma perda de segmento para reduzir a CWND e conseqüentemente baixar o desempenho da rede.
2. Para o tráfego VBR com distribuição exponencial, o TCP Vegas apresentou melhor performance que o TCP SACK para um tempo de ociosidade máximo de 1 s que corresponde ao máximo valor realístico para uma fonte “ on/off ”. Quanto maior foi o valor do tempo da rajada e menor o tempo de repouso as aplicação, o TCP Vegas foi muito mais propicio para ser utilizado na rede do que o TCP SACK.
3. Para o tráfego VBR com distribuição Pareto aplicado sobre o TCP Vegas e SACK, quando o valor de shape foi igual a 1, a performance do TCP manteve-se inalterada para qualquer valor do tempo da rajada e do tempo de ociosidade da fonte. Para essa situação o TCP SACK forneceu melhor performance que o Vegas na rede ATM utilizada. Quando o valor de SH foi igual a 2 constatou-se que quanto maior foi o tempo da rajada, mesmo que o intervalo de tempo de ociosidade da fonte fosse maior que 1 s, o TCP Vegas garantiu a melhor performance na rede. O aumento do valor de shape ocasionou um aumento na eficiência das duas implementações independente do tempo da rajada.
4. Com relação ao resultado obtido pelos dois algoritmos para uma janela de dados TCP igual a 1 MB, o desempenho do TCP SACK mostrou-se extraordinariamente superior ao do Vegas quando a rede possui um mecanismo de correção de erro como o FEC. Sem a presença de técnicas que executam a correção de segmentos com bits corrompidos, o TCP Vegas obteve melhor performance para o modelo da rede ATM utilizada neste artigo.
5. A análise do aumento da CWND inicial mostrou que, para transferência de arquivos de dados pequenos, iniciar a CWND com valor maior que 1 segmento proporciona um aumento substancial na performance da rede. Porém para a transmissão de um arquivo de dados grande, o aumento do valor da CWND inicial provoca um pequeno aumento da performance das implementações TCP avaliadas.

Referências Bibliográficas:

[1] AKYILDIZ, I.F., JEONG, S., Satellite ATM Network: A Survey, IEEE Communications Magazine, p. 30-43, July 1997.
[2] STEVENS,W., TCP/IP Illustrated, volume 1: The Protocols, Addison Wesley, 1994.
[3] STALLINGS, High-Speed Networks – TCP/IP and ATM Networks, Ed. PeH, 1rd, 1995.
[4] COMER, D., Internetworking with TCP/IP, volume 1, Principles, Protocols and Architecture, PeH, 3rd, 1995.
[5] STEVENS,W., TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms,RFC 2001, January 1997.
[6] FALL, K., FLOYD, S., Simulation-based Comparisons of Tahoe, Reno and SACK TCP, Computer Communication, vol 26, p.5-21, July 1996.
[7] LAKSHMAN, T.V., The Performance of TCP/IP for Networks with High Bandwidth Delay Products and Random Loss, IEEE ACM Transactions on Networking, vol 5, n 3, p. 336-350, June 1997.
[8] HOE, J.C., Improving the Start-up Behavior of a Congestion Control Scheme for TCP, Proceedings of ACM SIGCOMM`96, August 1996.
[9] MATHIS, M., MAHDAVI, J., FLOYD, S., ROMANOV, A ., TCP Selective Acknowledgment Option RFC 2018, , October 1996.
[10] GOYAL, R., Traffic Management for TCP/IP over Asynchronous Transfer Mode (ATM) Networks, PHD thesis, Ohio State University,1999.
[11] CHARALAMBOUS, C.P., Performance Evaluation and Analysis of TCP on ATM over High Bandwidth Delay Products Networks, Master thesis, University at Colorado at Denver, 1996.
[12] CHARALAMBOUS, C.P. et. Al., Experimental and Simulations Performance Results of TCP/IP over High-Speed ATM over ACTS, Proceedings of 1996 IEEE International Conference on Communications, Atlanta, Georgia, June 1998.
[13] CHARALAMBOUS, C.P. et. Al., Experiments and Simulations of TCP/IP over ATM over High Data Rate Satellite Channel, Report: ITTC-FY98-TR-10980-25, February 1998.
[14] MO, J. et.al., Analysis and Comparison of TCP Reno and Vegas, Department of Electrical Engineering and Computer Sciences, University of California at Berkeley, July 1998.
[15] STEVEN, L., PETERSON, L., WANG, L., Understanding TCP Vegas-Theory and Practice, University of Melbourne and Princeton University, TR 616-00, February 2000.
[16] BRAKMO, L., O`MALLEY, S.W., PETERSON, L.L., TCP Vegas: New Techniques for Congestion Detection and Avoidance , In Proceedings of ACM SIGCOMM´94, May 1994.
[17] GOYAL, R., Traffic Management for TCP/IP over Satellite ATM Networks, IEEE Communications Magazine p.56-61, March 1999.
[18] MCCANNE,S., FLOYD,S., NS (Network Simulator), available at http://www-mash.cs.berkeley.edu/ns/.
[19] ALLMAN,M., STEVENS, W., TCP Congestion Control – RFC 2581, April 1999.
[20] HAYES, C., OSTERMANN, S., An Evaluation of TCP with Large Initial Windows, ACM Computer Communication Review, July 1998.
[21] ALLMAN, M., et al., Ongoing TCP Research Related to Satellites – RFC 2760, February 2000.

---