UNIVERSIDADE FEDERAL DO PARANÁ LUIS EDUARDO PEREIRA BUENO
LUIS EDUARDO PEREIRA BUENO
ESTUDO DO DESEMPENHO DO PROTOCOLO TCP EM REDES SEM FIO
Projeto de Graduação apresentado ao Curso de Graduação em Engenharia Elétrica da Universidade Federal do Paraná como requisito para obter o título de Engenheiro Eletricista.
Resumo
As redes sem fio tem características diferentes das redes cabeadas. As versões do protocolo TCP tradicionais apresentam um desempenho menor frente as adversidades comunmente encontradas em ambientes de redes sem fio, como interferências, mobilidade dos nós e colisões frequentes. Para comprovar isso, foram realizadas simulações do desempenho das versões Tahoe, Reno, New-Reno, Sack e Vegas do protocolo TCP em redes sem fio de infra-estrutura utilizando o software
Network Simulator 2. As simulações apontam alguns pontos falhos destes
algorítimos em redes sem fio, motivando o estudo de novos algorítimos que se melhor adequem às redes sem fio. Em seguida, são apresentadas algumas versões do protocolo TCP desenvolvidas especificamente para redes sem fio e são analisados os seus funcionamentos ressaltando que vantagens teriam sobre os algorítimos tradicionais. Finalmente, concluí-se que nenhum dos protocolos apresentados tem um desempenho satisfatório ao lidar com todas as características das redes sem fio, sendo um tópico em potencial para novas pesquisas.
Abstract
Wireless networks have different characteristics than wired networks. The traditional TCP versions have a worse performance due to problems commonly found in wireless networks, as interferences, node mobility and frequent collisions. To prove that, performance simulations of TCP versions Tahoe, Reno, New-Reno, Sack and Vegas in infrastructure networks were realized using the software Network Simulator 2. The simulations show that these algorithms fail in some aspects, motivating the study of new protocols that better adjust to wireless networks. Next, some TCP versions developed specifically for wireless networks are studied and their advantages over the traditional TCP algorithms are highlighted. At the end, is concluded that none of the protocols presented has a satisfactory performance dealing with all the wireless networks characteristics, suggesting it's a potential
Sumário
1. Introdução...2 2. Protocolo TCP...4 2.1 TCP Tahoe...4 2.2 TCP Reno...6 2.3 TCP New-Reno...7 2.4 TCP SACK...7 2.5 TCP Vegas...83. Redes sem fio...9
3.1 Características das redes sem fio...9
3.2 Problemas encontrados nas redes sem fio...10
3.3 Protocolo CSMA/CA...11
4. Network Simulator 2...14
4.1 Simulação de rede cabeada...15
4.2 Simulação de rede sem fio...16
5. Simulações...17 5.1 Congestionamento...17 5.2 Colisões...19 5.3 Interferência...22 6. Novas abordagens...27 6.1 Freeze-TCP...27 6.2 ILC-TCP...28 6.3 TCP-Peach/TCP-Peach+...29 6.4 TCP Westwood/TCP Westwood+...30 6.5 ATCP...32 7. Conclusão...33 8. Referências bibliográficas...35
Apêndice A – Script TCL para rede cabeada...37
Apêndice B – Script TCL para rede sem fio...38
1. Introdução
Este trabalho tem o objetivo de estudar o protocolo TCP, analisar o seu desempenho em redes sem fio 802.11 e apresentar alternativas divulgadas na literatura.
O protocolo IP apenas fornece conectividade entre dois nós, porém não dá garantia de entrega do pacote. O protocolo TCP é um protocolo de camada de transporte que roda sobre o IP e que fornece transferência confiável de dados sobre uma rede não confiável.
O TCP foi desenvolvido para dinamicamente adaptar-se às condições da rede fornecendo controle de congestionamento. Existem dois mecanismos de controle de congestionamento. O controle de congestionamento fim-a-fim e o assistido pela
rede. No assistido pela rede, os roteadores fornecem realimentação para os
remetentes sobre o estado de congestionamento da rede. Já no mecanismo fim-a-fim, a camada de rede não fornece qualquer informação de congestionamento. O congestionamento da rede deve ser detectado de alguma forma pelos sistemas finais. O TCP utiliza o método fim-a-fim na maioria dos casos.
Congestionamentos na rede são detectados através de perdas ou atrasos de pacotes. O controle do congestionamento é feito através de uma janela de congestionamento. Esta janela define quantos segmentos podem ser enviados pelo remetente. O tamanho da janela é variável, aumentando na medida em que os segmentos enviados são reconhecidos. Por outro lado, a janela também pode diminuir ao ocorrer um evento de perda de pacote pois o TCP interpreta que a perda do pacote tenha ocorrido por descarte numa fila cheia, como consequência de
congestionamento.
Nas redes cabeadas, uma perda de pacote geralmente significa que há congestionamento e que o TCP deve diminuir o fluxo de dados. Já em uma rede sem fio uma perda de pacote pode significar que simplesmente houve uma colisão ou interferência. Por este motivo, o comportamento padrão do TCP em redes sem fio não é o mais eficiente, pois uma colisão de um único pacote pode ser erroneamente interpretada como congestionamento e diminuir drasticamente a taxa de transmissão.
O TCP possuí diferentes versões com diferentes abordagens de controle e detecção de congestionamento. Com isso, as diferentes versões do protocolo TCP podem ter grandes diferenças de desempenho em redes sem fio. Este trabalho irá analisar as diferenças de desempenho das versões mais comuns do TCP entre redes cabeadas e redes sem fio padrão 802.11 e apresentar algumas alternativas à estas versões.
2. Protocolo TCP
Como explicado anteriormente, o protocolo TCP utiliza uma janela para controle do fluxo de dados. A janela limita segmentos pacotes podem ser enviados simultaneamente. Conforme os segmentos já enviados são reconhecidos, a janela move-se e aumenta, permitindo que novos segmentos de dados sejam enviados.
Ao longo dos tempos foram feitas alterações no protocolo TCP, resultando em várias versões com diferentes características. Basicamente estas diferenças consistem no modo em que irão aumentar ou diminuir a janela e como reagir a perdas de pacotes. Isto faz com que estas versões tenham diferentes desempenhos em situações diferentes.
Estas versões coexistem nas redes atualmente. A seguir, explica-se o funcionamento das versões mais comumente encontradas do TCP.
2.1 TCP Tahoe
É a primeira versão do protocolo TCP desenvolvida. Possuí um funcionamento simples. Como pode-se ver no diagrama a seguir, inicia-se na fase partida lenta, ou slow start (SS). Nesta fase, a janela de congestionamento é definida inicialmente como 1MSS e aumenta exponencialmente. MSS significa
maximum segment size, ou tamanho máximo de segmento. A cada ACK recebido , a
janela aumenta em 1MSS. Em um RTT, a janela terá dobrado de tamanho. A janela aumenta até atingir o Slow Start Treshold (sstresh), ou limiar da partida lenta. Ao
chegar neste limiar, inicia-se o processo de prevenção de congestionamento.
Fig. 1 – funcionamento do TCP Tahoe
Se ocorrer um evento de perda durante a partida lenta, o sstresh é diminuído pela metade, a janela é definida como 1MSS e o processo de partida lenta reinicia.
A fase de prevenção de congestionamento, ou collision avoidance (CA), também é conhecida por AIMD (additive increase, multiplicative decrease). A cada
segmento reconhecido a janela aumenta em 1MSS x1MSS
cwnd . Isto significa que
quando todos os segmentos da janela forem reconhecidos, a janela terá aumentado em 1MSS. Portanto, nesta fase, a janela aumenta linearmente. Ao ocorrer um evento de perda, o sstresh é diminuído pela metade e inicia-se novamente partida lenta.
O TCP Tahoe não considera ACKs duplicados, logo sempre que um segmento for perdido a fase de partida lenta irá iniciar novamente após o timeout (Kurose, 2003).
2.2 TCP Reno
O TCP Reno funciona de um modo parecido com o TCP Tahoe. Diferencia-se apenas na resposta a ACKs duplicados. São implementados dois novos algorítimos:
retransmissão rápida e recuperação rápida.
A retransmissão rápida consiste no reenvido automático de um segmento perdido ao receber três ACKs duplicados. Deste modo, não é necessário aguardar pelo timeout para perceber que o segmento foi perdido.
Depois da retransmissão rápida, apesar da perda do pacote, o TCP não volta para a partida lenta. O TCP Reno considera que se o remetente receber três ACKs duplicados, apenas um segmento foi perdido e os outros da seqüência chegaram ao destino, logo é provável que não houve congestionamento na rede. O sstresh é definido como metade do tamanho da janela de congestionamento e o cwnd é definido para o mesmo valor de ssthresh. Esta é a recuperação rápida.
O TCP Reno apresenta um problema se múltiplos pacotes são perdidos. Para cada pacote perdido o TCP Reno irá entrar na recuperação rápida, diminuir a janela de congestionamento e retornar para o modo normal. Logo, se houver duas perdas de pacotes na mesma janela, o TCP Reno entrará no modo de recuperação rápida duas vezes a janela será reduzida 2 vezes.
Outra limitação deste protocolo ocorre quando a janela é muito pequena. Neste caso, se houver uma perda, o procolo não recebe 3 ACKs duplicados e só detecta a perda depois do timeout (University of Californica, 2002).
2.3 TCP New-Reno
O TCP New-Reno consegue detectar melhor perdas de segmentos, contornando os problemas do TCP Reno.
O TCP New-Reno aguarda todos os pacotes já enviados serem reconhecidos antes de sair da retransmissão rápida, evitando diminuir várias vezes a janela.
Uma desvantagem do New-Reno é o fato de demorar um RTT para detectar que mais de um pacote foi perdido, pois somente quando o reconhecimento do primeiro segmento retransmitido é recebido que é detectada a perda de outro segumento (University of California, 2002).
2.4 TCP SACK
O TCP com reconhecimento seletivo é uma extensão do TCP Reno e elimina os problemas do Reno e New-Reno de perdas de múltiplos pacotes e retransmissões de mais de um pacote perdido por RTT. Nesta implementação, os segmentos são reconhecido seletivamente e não cumulativamente. Assim, o remetente consegue saber precisamente quais segmentos chegaram ao destino e quais precisam ser retransmitidos.
“Reconhecimento seletivo” é uma opção do TCP habilitada ao se definir um determinado bit no primeiro segmento (SYN) ao iniciar a conexão. Se ambos os lados suportarem esta característica, reconhecimentos seletivos serão usados na comunicação (University of California, 2002).
2.5 TCP Vegas
O TCP Vegas é uma abordagem pro-ativa de controle de congestionamento. Esta implementação detecta perdas de segmentos através da estimativa do RTT. Se o reconhecimento de segmentos demorarem mais do que o RTT estimado, é considerado que ocorreu uma perda (University of California, 2002).
Na fase de prevenção de congestionamento, o TCP Vegas não detecta congestinamento por perdas de pacotes e sim por uma redução na taxa de envio comparada com a taxa esperada. Da mesma forma, o TCP Vegas aumenta a taxa se estiver abaixo da taxa esperada. Desta forma, o TCP Vegas tem um melhor controle de congestionamento, evitando saturar a banda disponível para depois diminuir a janela.
O TCP Vegas também introduz modificações na slow-start, para evitar gerar congestionamento na rede aumentando demais a janela de congesionamento. A janela de congestionamento só aumenta exponencialmente a cada RTT. Entre RTTs, o TCP Vegas calcula a taxa real e compara com a esperada. Quando a diferença for maior que um certo limite inicia-se a fase de prevenção de congestionamento (Brakmo, 1995).
3. Redes sem fio
Existem dois tipos de redes sem fio. As redes de infraestrutura e redes ad-hoc. Nas redes de infraestrutura, tem-se um access point (AP) que concentra todos os pacotes. Qualquer nó da rede irá sempre encaminhar os pacotes para o AP, que irá fazer o roteamento. Já nas redes ad-hoc, cada nó faz o seu próprio roteamento, permitindo que os nós comuniquem-se entre si sem intervenção de um AP. Os tipos de redes analisadas neste trabalho são as de infraestrutura.
3.1 Características das redes sem fio
As redes sem fio apresentam características diferentes das redes cabeadas. Estas características devem ser consideradas no desenvolvimento do protocolo TCP, pois influenciam no desempenho da comunicação de dados (Leung, 2006).
Colisões
Apesar da utilização do protocolo CSMA/CA, que tem como objetivo evitar colisões, terminais ocultos podem gerar em colisões (Kurose, 2003).
Desvanecimento do sinal
O sinal transmitido pode ter sua intensidade diminuída por obstáculos, pela distância percorrida e até mesmo por reflexões. O desvanecimento de sinal pode causar perdas de pacotes pois o sinal pode não ser reconhecido pelo
receptor. Mobilidade
Em redes 802.11 com mais de um AP, o usuário pode movimentar-se entre diferentes áreas de cobertura. A mudança do controle de um AP para outro chama-se handoff. Pacotes podem ser perdidos ou entregues fora de ordem neste procedimento.
Energia
Equipamentos sem fio precisam ser eficientes no uso da energia para maximizar a duração da bateria. Para que isto ocorra, devem ser evitadas retransmissões desnecessárias de pacotes.
Half duplex
As redes 802.11 são half duplex, ou seja, enquanto um nó transmite não pode ao mesmo tempo receber dados. Nas redes cabeadas a transmissão e recepção simultâneas são possíveis.
3.2 Problemas encontrados nas redes sem fio
As implementações do TCP apresentadas assumem que as perdas de pacotes são decorrentes exclusivamente de congestionamentos na rede. Em redes cabeadas, normalmente este é o caso, porém em redes sem fio as perdas de pacotes podem ocorrer por diferentes motivos e de diferentes formas, como explicado a seguir (Leung, 2006).
Perdas aleatórias
É normal em redes wifi a perda de pacotes aleatórios devido a colisões e interferências.
Perdas em rajada
Perdas em rajada podem ocorrer durante interferências prolongadas, causando a perda de vários pacotes sem que tenha havido congestionamento.
Pacotes reordenados
Como explicado anteriormente, pacotes podem pegar caminhos diferentes devido a handoffs. Logo, é normal que os pacotes cheguem ao seu destino fora de ordem.
3.3 Protocolo CSMA/CA
Em redes padrão 802.11 é usado o protocolo CSMA/CA como protocolo MAC. CSMA/CA significa acesso múltiplo com detecção de portadora e prevenção de colisão. Cada estação sonda o canal antes de transmitir e não transmite quando percebe que o mesmo está ocupado (Kurose, 2003).
Diferentemente do CSMA/CD, este protocolo tem como objetivo evitar as colisões ao invés de detectá-las. Isto deve-se às razões a seguir:
• Para detectar colisões, os terminar devem ter a capacidade de enviar o seu próprio sinal e detectar se alguma estação está transmitindo no momento. Como o sinal enviado é normalmente muito mais forte que o recebido, é caro construir um equipamento para detectar colisões.
• Os nós podem não detectar colisões devido a terminais escondidos, como mostrado na imagem abaixo.
Fig. 2 – Obstáculo entre dois nós resultando em terminais ocultos
O nó A não consegue receber sinal do nó B e vice-versa. Neste caso, é impossível para ambos os nós detectarem qualquer tipo de colisão.
• Devido a distância entre dois nós, é possível que o sinal de um nó A que está transmitindo chegue ao AP mas não chegue a outro outro nó B mais distante. Assim, é possível que o nó B não detecte o sinal de A e transmita simultaneamente.
RTS/CTS
O 802.11 possui um sistema de reserva de canal opcional que ajuda a evitar colisões mesmo na presença de terminais ocultos e desvanecimento de sinal. Uma estação pode enviar um quadro RTS (Request to Send) para reservar canal para ela. Ao receber o quadro CTS (Clear to Send) como resposta, o nó sabe que o canal está
livre para transmitir. Fig. 3 – RTS / CTS
Os quadros RTS e CTS só são utilizados quando quadros longos vão ser transmitidos, diminuindo o overhead que causaria se fossem usados para todos os pacotes. O problema de terminal oculto é atenuado visto que um quadro longo é transmitido somente quando o canal é reservado (Kurose, 2003).
4. Network Simulator 2
Para as simulações foi usado o simulador de redes Network Simulator 2.34
(ns2). O ns2 é um simulador voltado para pesquisas em redes e provê suporte a
simulações de diversos protocolos de roteamento, redes cabeadas, redes sem fio, geradores de tráfego, etc.
O ns2 é baseado em duas linguagens: C++ e TCL. Através de scripts TCL, é possível especificar a topologia da rede, definir a largura de banda e delay dos links, entre outras opções.
Basicamente, para realizar um simulação, devem ser definidos os nós da rede, os links entre eles, o tipo de protocolo de camada de transporte utilizado e os geradores de tráfego.
São disponibilizados diversos geradores de tráfego. Por exemplo, o FTP e o CBR são geradores de tráfego determinísticos. O FTP que que gera tráfego em cima do protocolo TCP e o CBR gera tráfego a uma taxa constante sobre o UDP. Também podem ser utilizados geradores de tráfego estocásticos, como o exponencial, que gerá pacotes com intervalos aleatórios de acordo com uma distribuição exponencial. Estes geradores devem ser associados a um agente, que é o protocolo da camada de transporte. O agente, por sua vez, é associado ao nó remetente. Outro agente é associado ao nó de destino, indicando que este nó irá receber os dados do remetente.
Como resultado da simulação, tem-se o arquivo de trace. Este arquivo contém informações de cada evento ocorrido. A partir dele, pode-se fazer análises do
desempenho da rede, do funcionamento de protocolos, etc.
4.1 Simulação de rede cabeada
No Apêndice A encontra-se um script modelo para simulação do cenário da figura 4. O primeiro nó envia dados a uma taxa constante para o segundo nó utilizando um gerador de tráfego CBR sobre UDP.
Fig. 4 – dois nós comunicando-se
Abaixo está o trace do primeiro pacote enviado pelo nó 0. + 0 0 1 cbr 1000 --- 0 0.0 1.0 0 0
- 0 0 1 cbr 1000 --- 0 0.0 1.0 0 0 r 0.009 0 1 cbr 1000 --- 0 0.0 1.0 0 0
Cada linha do trace corresponde a um evento. O primeiro campo define o tipo de evento ocorrido, o segundo é o tempo em que o evento ocorreu e o terceiro e quarto campos definem o nó de origem e o nó de destino do pacote, respectivamente. Neste trace, pode-se ver que inicialmente o nó 0 gera um pacote e coloca na fila (+) em 0s, ou seja no início da simulação. Logo em seguida, como a fila está vazia, o pacote é retirado da fila e enviado para o destino (-). No tempo 0.009s, o pacote é recebido (r) pelo nó 1.
Através desta análise deste trace, pode-se ver que o primeiro pacote enviado chega ao destino em 0.009s. Através do cálculo abaixo, chega-se ao tempo de 8ms para o envio do pacote.
R=L T ⇒T =
8000 kb
1Mb / s ⇒T =8ms
Porém, como o link tem um delay de 1ms, o tempo correto é de 9ms, conforme mostrado no trace. Este é um pequeno exemplo de como utilizar o trace do ns2 para levantar informações da rede.
4.2 Simulação de rede sem fio
O script do Apêndice B simula uma rede com um nó móvel comunicando-se com um access point, conforme a topologia da figura 5. O nó 1 envia dados para o nó 0 através de um gerador de tráfego FTP sobre TCP.
Fig. 5 – um nó móvel comunicando-se com o AP
O trace de redes sem fio é diferente do trace da rede cabeada. As redes sem fio utilizam um novo modelo de trace. Além das informações contidas no trace tradicional, o novo trace tem informações da posição de cada nó e da potência do sinal recebido ou enviado.
5. Simulações
Para demonstrar as falhas dos protocolos TCP tradicionais em redes sem fio foram realizadas as simulações apresentadas abaixo utilizando o ns2.
5.1 Congestionamento
O congestionamento normalmente ocorre nos links do ISP, que geralmente não são sem fio, como mostrado na imagem abaixo.
Fig. 6 – congestionamento em rede cabeada do ISP
Como não é possível mesclar na mesma simulação uma rede sem fio com uma rede cabeada, não foi possível comparar o desempenho de uma rede sem fio com uma rede cabeada na presença de congestionamento. Porém, foi utilizada uma topologia mais simples, com dois nós sem fio, para demonstrar o desempenho do protocolo TCP quando o congestionamento ocorre no enlace sem fio. Foi utilizada a topologia abaixo:
Fig. 7 – Um nó móvel comunicando-se com um AP
O nó 1 utiliza um agente FTP e um agente CBR transmitindo para o AP. O agente CBR foi configurado com taxa fixa de 8.0Mb/s. O meio tem largura de banda de 11Mb/s, gerando um pequeno congestionamento.
O gráfico abaixo mostra o tamanho da janela de congestionamento para cada protocolo neste cenário.
Fig. 7 – congestionamento em redes sem fio
No gráfico anterior, todas as versões do TCP, com exceção do TCP Vegas, tiveram exatamente o mesmo desempenho. Por isso, as linhas do gráfico ficaram sobrepostas.
Pode concluir pela análise do gráfico que todos os algorítimos conseguiram lidar bem com congestionamento e não tiveram grandes problemas ao aumentar a janela, como ocorreria em uma rede cabeada. Isto deve-se ao fato de os TCP tradicionais serem desenvolvidos para exatamente este fim, lidar com congestionamentos na rede. Logo, tanto em redes cabeadas como em redes wireless, o desempenho seria semelhante em congestionamentos.
5.2 Colisões
Para gerar colisões foram colocados alguns nós sem fio comunicando-se com o access point. Do resultado da simulação, foi retirada a quantidade colisões que ocorreram nos primeiros 20 segundos de simulação. O RTS/CTS não estava ativado.
Primeiramente, foi utilizado um nó sem fio, como mostrado na figura abaixo.
Fig. 8 – Somente um nó móvel comunicando-se com o AP
O nó móvel 1, utilizando FTP sobre TCP, envia pacotes indefinidamente para o access point. Ao longo de 20 segundos não foi detectada nenhum colisão, visto que o nó 1 é o único a transmitir.
Fig. 9 – Dois nós móveis comunicando-se simultaneamente com o AP
Neste cenário, os dois nós comunicam-se com o access point simultaneamente. Em 20 segundos, ocorreram 369 colisões.
Com três nós, percebe-se que o número de colisões aumenta exponencialmente.
Fig. 10 – Três nós transmitindo simultaneamente para o AP No mesmo período, neste cenário, ocorreram 1061 colisões.
Através dos dados levantados, foi montado o gráfico abaixo.
Fig. 11 – Comparação de número de colisões com quantidade de pacotes
Através deste gráfico, pode-ver que com o aumento de colisões, diminui-se a quantidade de pacotes transmitidos apesar de aumentarem o números de nós transmitindo. Com isto, pode-se concluir que o protocolo TCP tem um desempenho menor devido às colisões como é comprovado no gráfico a seguir.
Neste gráfico, percebe-se que, apesar das colisões, o TCP continua a aumentar a janela sem voltar para a partida ou entrar em retransmissão rápida e recuperação rápida. Tem-se apenas um dificuldade maior em abrir a janela.
Um método de diminuir a quantidade de colisões na rede seria utilizando RTS e CTS, conforme explicado anteriormente. Porém, esta abordagem é opcional e não encontra-se implementada atualmente para redes de infraestrutura no ns2.
Como a queda no desempenho do protocolo foi mínima, pode-se concluir que o CSMA/CA funciona bem em campo aberto e sem terminais ocultos com agentes TCP. Porém, o desempenho tende a diminuir exponencialmente conforme aumentam o número de nós na rede. Isto pode tornar-se um problema para uma rede grande.
5.3 Interferência
Para simular interferências na rede foi utilizada uma rede cabeada visto que o ns2 não implementa gerador de erros para redes sem fio. As simulações foram válidas pois, apesar da camada de enlace e camada física serem diferentes, o protocolo TCP é o mesmo e os erros introduzidos simulam interferências na rede, como ocorreria em redes sem fio.
Foram realizadas simulações sem interferência e com interferência que causam 0.5%, 1% e com 2% de perda de pacotes. Cada ambiente tem seu próprio nível de ruído, podendo estar dentro desta faixa ou muito acima dela.
Fig. 13 – Simulação do desempenho do TCP Tahoe frente a interferência
Fig. 15 – Simulação do desempenho do TCP New-Reno frente a interferência
Fig. 17 – Simulação do desempenho do TCP Vegas frente a interferência
Observou-se uma queda de desempenho muito grande quando são introduzidos ruídos no enlace, sugerindo que todas as abordagens apresentadas apresentam falhas ao lidar com perdas aleatórias de pacotes, mesmo com 0.5% de perdas.
O melhor desempenho foi apresentado pelo TCP SACK. Porém, por diversas vezes, a janela cai a 1 e inicia-se novamente a partida lenta. O TCP Vegas apresentou uma janela relativamente constante mesmo com uma taxa de erros de 2%, apesar de manter a janela pequena. Isto deve-se ao fato do TCP Vegas não utilizar perdas de pacotes como sinalizador de congestionamento, como explicado anteriormente.
Estas simulações demonstram que o TCP pode ter seu desempenho muito prejudicado em redes sem fio, pois nestes cenários, ruídos são comuns.
6. Novas abordagens
A seguir são apresentadas algumas abordagens diferentes de controle de congestionamento no TCP.
O Freeze-TCP e o ILC-TCP são abordagens de suspensão de estado, ou seja, detectam o estado da rede para decidir quando a comunicação deve ser suspensa e quando deve ser retomada. Já o TCP Westwood e o TCP-Peach utilizam a abordagem de detecção de colisão, medem as condições da rede para determinar se ocorreu congestionamento ou não. Uma terceira abordagem é chamada de
abordagem de atraso de resposta, na qual o cliente TCP atrasa a ativação de
controle de tráfego para aliviar os problemas em redes sem fio. Já o ATCP utiliza uma abordagem híbrida, que envolve as três abordagens apresentadas.
6.1 Freeze-TCP
É uma solução de suspensão de estado implementada no lado do destino e não do remetente. O nó móvel monitora o sinal recebido para detectar um handoff iminente. Neste momento, ele envia Zero Window Advertisements (ZWAs) para forçar o remetente a entrar no "modo persistente" aproximadamente um RTT antes de ocorrer o handoff. Em seguida, são enviados Zero Window Probes (ZWPs) para o destino. Quando os ZWPs são respondidos com uma advertisement window positiva, o recebedor sai do modo persistente e retorna a operação normal (Leung, 2006).
O Freeze-TCP tem alguns problemas:
• São necessárias alterações na pilha de protocolos para comunicação entre camadas (potência do sinal para camada de transporte)
• O nó móvel precisa prever quando uma desconexão pode ocorrer
• Não há garantia de que a largura de banda disponível no novo link após o handoff seja o mesmo do link anterior. Se for menor, pode gerar
congestionamento na rede.
• Falha ao identificar perdas de segmentos aleatórios
6.2 ILC-TCP
É uma solução do lado do servidor para prevenir deterioração de performance devido a desconexões temporárias.
As decisões são definidas de acordo com um gerenciador de estados. Este gerenciador guarda as informações da rede passadas através das camadas. Especificamente, a camada de enlace reporta ao gerenciador de estados o estado de um link quando ele muda. Um estado ruim indica que um handoff é iminente.
No timeout de um segmento, a fonte primeiro verifica com o gerenciador de estados se a conexão está estável. Se estiver, ele assume que a rede está congestionada e ativa os mecanismos de controle de congestionamento padrões do TCP. Caso contrário, é considerado que houve uma desconexão temporária e a conexão é congelada. Quando a conexão estiver estável novamente, a conexão é recuperada (Leung, 2006).
6.3 TCP-Peach/TCP-Peach+
O TCP-Peach foi desenvolvido para redes de satélites com longos delays e alta taxa de erros. São introduzidos dois novos algorítimos, sudden start e rapid
recovery.
Segmentos dummy são usados como sonda da largura de banda disponível. Um segmento dummy recebido com sucesso significa que ainda há recursos disponíveis na rede. Bits não usados no cabeçalho do TCP são usados para marcar os segmentos como dummy.
Quando o remetente recebe o ACK, ele incrementa o valor de cwnd em um se
wsnd for zero. wsnd é um contador que controla se a janela de congestionamento
deve aumentar ao receber um ACK.
A sudden start substitui a partida lenta. Seu objetivo é abrir a janela de congestionamento muito mais rapidamente. A sudden start inicia com cwnd igual a 1 e wdsn igual 0. Depois que o primeiro segmento é enviado, é transmitido um segmento dummy a cada τ/awnd até awnd-1 segmentos dummy terem sido enviados. τ é o RTT estimado da conexão e awnd é o tamanho da advertisement window em segmentos. Deste modo, cwnd pode aumentar até o valor máximo em um RTT. Após este ponto, inicia-se a prevenção de congestionamento.
A rapid recovery substitui a recuperação rápida. Na perda de um segmento, cwnd é dividido por 2. wdsn é definido como w/2, sendo que w é o valor de cwnd antes da perda. Quando um ACK chega, a fonte envia dois segmentos dummy até o total de w segmentos dummy terem sido enviados. Ao receber um ACK para um segmento dummy, wdsn é decrementada até chegar a 0. Para qualquer ACK que chegar depois que wdsn=0, cwdn é incrementada. Uma desvantagem deste
algorítimo é que os segmentos dummy não carregam dados úteis.
Para melhorar o uso da rede, foi desenvolvido o TCP Peach+. Neste algorítimo, os segmentos dummy são substituídos por segmentos NIL, que carregam dados ainda não reconhecidos. Sudden start e rapid recovery são substituídos por
jump start e quick recovery. Jump start é como sudden start, exceto que segmentos
NIL são usados ao invés de segmentos dummy. O quick recovery usa SACK (selective ACK) para ajudar na retransmissão de segmentos perdidos. Ao receber um ACK na fase de quick recovery, um segmento NIL só pode ser enviado depois que não há mais segmentos a serem enviados. A fase de quick recovery termina quando quando um ACK reconhece todos os segmentos enviados antes da fase de recuperação iniciar.
Este algorítimo precisa de alterações nos roteadores para descartar primeiro os segmentos dummy ou NIL (Leung, 2006).
6.4 TCP Westwood/TCP Westwood+
Em outras abordagens, a janela de congestionamento é ajustada sem levar em consideração o nível de congestionamento da rede. O TCP Westwood, implementado no lado do remetente, ajusta a janela de congestionamento monitorando a taxa de pacotes reconhecidos. A cada ACK recebido, é feita uma estimativa da largura de banda disponível baseada na quantidade de dados reconhecidos. Quando é recebido um ACKn no tempo tn, a largura de banda para
aquele ACK é calculada por bn=
Ln tn−tn−1
Utilizando um filtro, obtém-se a largura de banda da conexão:
bn=nbn−1 1−nbnbn−1 2
onde αn é um valor calculado a partir da frequência de corte do filtro.
A partida lenta e retransmissão rápida são modificadas para que o ssthresh seja definido como o produto da largura de banda estimada pelo RTT mínimo da conexão divido pelo tamanho de um segmento:
ssthresh=bn . RTTmín MSS
O TCP Westwood apresenta um problema quando ocorre compressão de ACKs. Compressão de ACKs ocorre quando os ACKs chegam no destino com um espaçamento menor do que foram enviados devido a enfileiramentos nos roteadores. Isto faz com que o TCP Westwood calcule erroneamente a largura de banda disponível. Para resolver este problema, foi desenvolvido o TCP Westwood+, que ao invés de estimar a largura de banda a cada ACK recebido, faz isso a cada RTT (Leung, 2006).
6.5 ATCP
A idéia do ATCP é a de introduzir uma camada entre o TCP e o IP. Assim, o ATP pode monitorar o TCP e mudar de estado quando necessário.
Apesar de ser um algorítimo voltado para redes ad hoc, é o único que tenta resolver todos os problemas de redes sem fio, e vale a pena ser
estudado. Fig. 19 – Diagrama do funcionamento do ATCP Há quatro estados: normal, congestionado, perda e desconectado. Inicia-se no estado normal. Quando ocorre congestionamento, o roteador define a flag ECN nos pacotes. Também uma mensagem ICMP (source quench) pode ser enviada. Quando o TCP recebe uma dessas duas mensagens, muda para o estado de congestionamento e não interfere no comportamento do TCP. Ele volta ao estado normal depois que um novo segmento é enviado. Quando há 3 ACKs duplicados ou o timer expira, a rede está com perdas ou há reordenação de pacotes. Neste caso, o ATCP entra no modo persistente e no estado de perda. São enviados segmentos não reconhecidos. Quando um novo ACK é recebido, o ATCP volta para o estado normal.
O ATCP entra no modo persistente e no estado desconectado quando recebe uma mensagem ICMP destination unreachable. Isso indica que a rede está instável devido a mobilidade. A fonte gera pacotes de sonda e ao receber um ACK, é retornado para o estado normal. A partida lenta é ativada pois a largura de banda pode ter mudado (Leung, 2006).
7. Conclusão
Neste trabalho foi analisado o desempenho das versão do TCP mais utilizadas em redes sem fio. Primeiramente foi feito um estudo teórico do TCP e os seus possíveis pontos falhos em redes sem fio. Em seguida, utilizando o simulador Network Simulator 2, foram realizadas simulações demonstrando o comportamento destas diferentes versões do TCP.
Nas simulações de congestionamento, como o esperado as versões tradicionais do TCP apresentaram um desempenho semelhante ao que teriam em uma rede cabeada. Isto ocorreu porque os TCP simulados estão preparadas para tratar colisões e não tiveram outros tipos de adversidades na rede. Já nas simulações de interferência, percebeu-se que estes algorítimos tem dificuldades de tratar estes eventos comuns em redes sem fio. Como pode ser observado claramente nas simulações de interferências, o melhor desempenho apresentado foi o do TCP Vegas, que mostrou-se um protocolo mais conservador. O TCP Vegas conseguiu manter a janela estável por mais tempo do que as outras abordagens, apesar de não ter conseguido aumentá-la para mais do que 5MSS. Porém, em redes sem adversidades, o TCP Vegas apresentou um desempenho muito menor do que os outros protocolos, sendo muito conservador ao aumentar a janela.
Também foi verificada uma grande quantidade de colisões numa rede sem fio e uma tendência para aumento exponencial destas colisões conforme aumenta-se a rede. Estas colisões devem ser detectadas e evitadas na camada de enlace, porém protocolo TCP deve saber lidar com este tipo de evento. Conforme já comentado, o
uso de reserva de canal através dos pacotes RTS e CTS poderia diminuir a quantidade de colisões e melhorar o desempenho.
Observando os resultados das simulações, pode-se concluir que nenhum protocolo teve um desempenho satisfatório nas redes sem fio. Isto motivou o desenvolvimento de algumas alternativas. Estas novas versões do TCP foram especialmente desenvolvidas para sanar os pontos falhos dos TCPs tradicionais em redes sem fio. As novas abordagens apresentadas não foram simuladas neste trabalho por falta de suporte do simulador utilizado.
Percebeu-se que a maioria destes novos algorítimos são muito específicos, tendo um bom desempenho apenas em cenários específicos e considerando apenas alguns dos problemas das redes sem fio, com exceção do ATCP. Apesar do ATCP ter como foco as redes ad hoc, é o único que visa tratar todas as falhas introduzidas por redes sem fio, sendo um bom ponto de referência para o desenvolvimento um protocolo igualmente completo para redes de infraestrutura.
Com isso, pode-se concluir que ainda não há nenhum algorítimo que trate todos os eventos de rede sem fio, sendo uma área em potencial para o desenvolvimento de novas pesquisas.
8. Referências bibliográficas
BRAKMO, Lawrence S, 1995, TCP Vegas: End to end congestion avoidance on a global Internet, disponível em
<http://www.cs.ucsb.edu/~almeroth/classes/F05.276/papers/vegas.pdf>, acesso em 22/07/2009.
University of California, 2002, A Comparative Analysis of TCP Tahoe, Reno, New-Reno, SACK and Vegas, disponível em
<http://inst.eecs.berkeley.edu/~ee122/fa05/projects/Project2/SACKRENEVEGAS.pdf >, acesso em 23/07/2009.
DRAKOS, Nikos; MOORE, Ross, 2009, Explanation of new trace format, disponível em <http://www.isi.edu/nsnam/ns/doc/node186.html>, acesso em 22/07/2009.
FLOYD, S.; HENDERSON, T., 1999, RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm.
GEIER, Jim., 2002, Understanding 802.11 Frame Types. Disponível em
<http://www.wi-fiplanet.com/tutorials/article.php/1447501>, acesso em 03/08/2009.
JONES, Evan. 802.11 Simulations Using ns2. Disponível em <http://evanjones.ca/ns2>, acesso em 22/07/2009.
JUN, Takei, 2008, 802.11 specifications, disponível em
<http://www.soi.wide.ad.jp/class/20070044/slides/02/index_44.html>, acesso em 03/08/2009.
KUROSE, James; ROSS, Keith., 2003, Redes de Computadores e a Internet, 3. ed, Addison Wesley.
wireless networks: issues, approaches, and challenges, IEEE Communications Survey.
The Network Simulator – ns-2, disponível em <http://www.isi.edu/nsnam/ns>, acesso em 18/11/2009.
NSNAM: NS-2 Trace Formats,
disponível em <http://nsnam.isi.edu/nsnam/index.php/NS-2_Trace_Formats>, acesso em 22/07/2009.
Steps to set up a wireless simulation in ns-2, disponível em:
<http://www.geocities.com/vin_sdm/ns2-wireless.htm>, acesso em 22/07/2009.
NYGAARD, Bent., 2002, 802.11 standard, Disponível em
<http://wlan.nat.sdu.dk/802_11standard.htm>, acesso em 03/08/2009
STEVENS, W., 1997, RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms.
Apêndice A – Script TCL para rede cabeada
Script TCL modelo para simulação de rede cabeada no ns2.set ns [new Simulator] # cria o simulador set nf [open cbr.tr w] # abre o arquivo de trace set n0 [$ns node] # cria o nó 1
set n1 [$ns node] # cria o nó 2
$ns duplex-link $n0 $n1 1Mb 1ms DropTail # cria o link entre os nós $ns trace-queue $n0 $n1 $nf # realiza o trace entre os dois nós $ns queue-limit $n0 $n1 1000 # muda o tamanho da fila para 1000 set udp0 [new Agent/UDP] # cria o agente UDP
$ns attach-agent $n0 $udp0 # associa o UDP ao nó 0
set cbr0 [new Application/Traffic/CBR] # cria o gerador de tráfego CBR $cbr0 set packetSize_ 1000 # gera pacotes com 1kB
$cbr0 set rate_ 1.0M # a uma taxa de 1.0Mb/s
$cbr0 attach-agent $udp0 # associa o agento UDP ao CBR set null0 [new Agent/Null] # cria o null
$ns connect $udp0 $null0 # inidica que o null irá receber os dados do UDP $ns attach-agent $n1 $null0 # associa o null ao nó 1
$ns at 0.0 "$cbr0 start" # inicia o CBR $ns at 10.0 "$cbr0 stop" # para o CBR
$ns at 20.0 "finish" # termina a simulação $ns run # roda a simulação
proc finish {} { # função para terminar a simulação global ns nf
$ns flush-trace close $nf exit 0 }
Apêndice B – Script TCL para rede sem fio
Script TCL modelo para simulação de rede sem fio no ns2.set val(chan) Channel/WirelessChannel ;# Channel Type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in ifq set val(nn) 2 ;# number of mobilenodes set val(rp) DumbAgent ;# routing protocol - infraestrutura set val(x) 600
set val(y) 600
set ns [new Simulator] ;# cria o objeto simulador
$ns use-newtrace ;# usa o novo formato de trace set nf [open wireless.tr w] ;# abre o arquivo de trace
$ns trace-all $nf ;# realizada trace de todos os eventos Mac/802_11 set dataRate_ 11Mb ;# define a taxa do link
set topo [new Topography] ;# topografia $topo load_flatgrid $val(x) $val(y)
create-god $val(nn) ;# cria o god
set chan_1_ [new $val(chan)] ;# cria o canal $ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -movementTrace OFF \ -channel $chan_1_
for {set i 0} {$i < [expr $val(nn)]} {incr i} { ;# cria os nós set n($i) [$ns node]
set mac_($i) [$n($i) getMac 0] $mac_($i) ScanType PASSIVE $n($i) set Z_ 0.0
}
$n(0) set X_ 10.0 ;# define as posições dos nós $n(0) set Y_ 10.0
$n(1) set X_ 0.0 $n(1) set Y_ 10.0
set AP_ADDR1 [$mac_(0) id] ;# define o nó 0 como o access point $mac_(0) ap $AP_ADDR1
set tcp1 [new Agent/TCP] ;# cria o TCP $tcp1 set fid_ 1 ;#
$tcp1 set packetSize_ 1000 ;# define o tamanho do pacote como 1kB $ns attach-agent $n(1) $tcp1 ;# associa o TCP ao nó 1
set ftp1 [new Application/FTP] ;# cria o FTP
$ftp1 attach-agent $tcp1 ;# associa o FTP ao TCP
set sink1 [new Agent/TCPSink] ;# cria o TCP Sink - irá receber os dados do FTP $ns connect $tcp1 $sink1 ;# o sink irá receber os dados do TCP1
$ns attach-agent $n(0) $sink1 ;# associa o sink ao nó 0 ;# termina a simulação proc finish {} { global ns nf $ns flush-trace close $nf exit 0 } $ns at 1.0 "$ftp1 start" ;# inicia o FTP $ns at 5.0 "$ftp1 stop" ;# para o FTP
$ns at 5.0 "finish" ;# termina a simulação $ns run ;# roda a simulação
Apêndice C – Mini manual do ns2 para redes
sem fio
Será utilizada a rede abaixo para explicar como montar um script TCL básico para o ns2.
Fig. C.1 – Posições dos nós
Serão criados três nós, sendo um deles definido como o access point. O nó 1 irá enviar pacotes para o nó 2 usando FTP sobre TCP e vice-versa.
Primeiramente, deve-se definir algumas opções gerais da simuação. set val(chan) Channel/WirelessChannel ;# tipo do canal
set val(prop) Propagation/TwoRayGround ;# modelo de propagação set val(netif) Phy/WirelessPhy ;# tipo da interface de rede
set val(mac) Mac/802_11 ;# MAC
set val(ifq) Queue/DropTail ;# tipo da fila
set val(ll) LL ;# tipo da camada de enlace
set val(ant) Antenna/OmniAntenna ;# modelo da antena set val(ifqlen) 50 ;# tamanho máximo da fila
set val(nn) 3 ;# número de nós
set val(rp) DumbAgent ;# protocolo de roteamento ;# modo de infraestrutura
Em seguida, criam-se os objetos principais.
set ns [new Simulator] ;# cria o objeto simulador $ns use-newtrace ;# usa o novo formato de trace set nf [open wireless.tr w] ;# abre o arquivo de trace wireless.tr $ns trace-all $nf ;# realizada trace de todos os eventos Mac/802_11 set dataRate_ 11Mb ;# define a taxa do link para 11Mb/s set topo [new Topography] ;# topografia
$topo load_flatgrid 100 100 ;# terreno de 100m x 100m
create-god $val(nn) ;# cria “General Operations Director” usado ;# internamente pela camada de enlace
Agora, definem-se as configurações dos nós.
;# configura os nós de acordo com as variáveis definidas anteriormente
$ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \
-agentTrace ON \ ;# faz trace no nível dos agentes -routerTrace ON \ ;# faz trace no nível de roteamento
-macTrace ON \ ;# faz trace no nível MAC
-movementTrace OFF \ ;# não faz trace de movimentações dos nós -channel $chan_1_
Com as configurações dos nós definidas, eles podem ser criados.
;# cria nó por nó
for {set i 0} {$i < [expr $val(nn)]} {incr i} { set n($i) [$ns node]
set mac_($i) [$n($i) getMac 0] $mac_($i) ScanType PASSIVE }
;# define as posições dos nós de acordo com o figura C.1
$n(0) set X_ 10.0 $n(0) set Y_ 10.0 $n(0) set Z_ 0.0 $n(1) set X_ 0.0 $n(1) set Y_ 10.0 $n(1) set Z_ 0.0 $n(2) set X_ 10.0 $n(2) set Y_ 0.0 $n(2) set Z_ 0.0
Os três nós foram criados como nós móveis, porém queremos que o nó 0 seja o access point. Os dois comandos abaixo dizem para o ns2 que o nó 0 será o AP.
set AP_ADDR1 [$mac_(0) id] $mac_(0) ap $AP_ADDR1
Agora serão criados os geradores de tráfego e os agente TCP.
set tcp1 [new Agent/TCP] ;# cria o TCP
$tcp1 set fid_ 1 ;# identificação do fluxo
$tcp1 set packetSize_ 1000 ;# define o tamanho do pacote como 1kB
$ns attach-agent $n(1) $tcp1 ;# associa o TCP ao nó 1
set ftp1 [new Application/FTP] ;# cria o FTP 1
$ftp1 attach-agent $tcp1 ;# associa o FTP 1 ao TCP 1
set sink1 [new Agent/TCPSink] ;# cria o TCP Sink 1
$ns connect $tcp1 $sink1 ;# o sink irá receber os dados do TCP1
$ns attach-agent $n(2) $sink1 ;# associa o sink ao nó 2 set tcp2 [new Agent/TCP] ;# cria o TCP 2
$tcp2 set fid_ 2 ;# identificação do fluxo
$tcp2 set packetSize_ 1000 ;# define o tamanho do pacote como 1kB
$ns attach-agent $n(2) $tcp2 ;# associa o TCP ao nó 2
set ftp2 [new Application/FTP] ;# cria o FTP 2
$ftp2 attach-agent $tcp2 ;# associa o FTP 2 ao TCP 2
set sink2 [new Agent/TCPSink] ;# cria o TCP Sink 2
$ns connect $tcp2 $sink2 ;# o sink irá receber os dados do TCP 2
$ns attach-agent $n(1) $sink2 ;# associa o sink ao nó 1
Fig. C.2 – Fluxo dos pacotes na rede
2) são conectadas aos agentes TCP 1 e TCP 2. Os agentes, por sua vez, são conectadas aos sinks respectivos, que irão receber todos os segmentos correspondentes.
Finalmente, os comandos abaixo iniciam a simulação e terminam nos tempos definidos.
$ns at 0.0 "$ftp1 start" ;# inicia o FTP 1 no começo da simulação $ns at 1.0 “$ftp2 start” ;# inicia o FTP 2 em 1s
$ns at 5.0 "$ftp1 stop" ;# para o FTP 1 em 5s $ns at 7.5 “$ftp2 stop” ;# para o FTP 2 em 7.5s
$ns at 10.0 "finish" ;# termina a simulação em 10s $ns run ;# roda a simulação
;# fecha o arquivo de trace $ns flush-trace
close $nf
Depois de realizada a simulação, será gerado um arquivo de trace chamado
wireless.tr. Este arquivo contém todos os eventos ocorridos durante a simulação.
Abaixo são apresentados dois eventos ocorridos na simulação.
s -t 0.000810000 -Hs 0 -Hd -2 -Ni 0 -Nx 10.00 -Ny 10.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 0 -Md ffffffff -Ms 0 -Mt 0
r -t 0.001386033 -Hs 1 -Hd -2 -Ni 1 -Nx 0.00 -Ny 10.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 0 -Md ffffffff -Ms 0 -Mt 0
O primeiro campo indica o tipo do evento. s significa que o pacote foi enviado. r significa que o pacote foi recebido. O campo precedido por -t indica o tempo em que o evento ocorreu. Os três campos seguintes indicam o nó de origem, o nó de destino e a identificação do nó, respectivamente. A posição do nó que gerou o evento pode
ser vista nos campos -Nx, -Ny e -Nz. Outro campo importante é o campo -Nl, que indica em qual nível aquele evento ocorreu, podendo ser AGT (agente), RTR (roteamento) e MAC. Para maiores informações sobre os campos do arquivo trace, consultar (DRAKOS, 2009).
