Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO PARANÁ
LUIS EDUARDO PEREIRA BUENO
ESTUDO DO DESEMPENHO DO PROTOCOLO TCP EM REDES SEM FIO
Curitiba2009
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.Orientador: Eduardo Parente Ribeiro.
Curitiba2009
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
subject for new researchs.
Sumário1. Introdução...............................................................................................................................22. 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.......................................................................................................................8
3. 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..............................................................................................................................338. Referências bibliográficas.....................................................................................................35Apêndice A – Script TCL para rede cabeada............................................................................37Apêndice B – Script TCL para rede sem fio.............................................................................38Apêndice C – Mini manual do ns2 para redes sem fio.............................................................40
1
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
2
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.
3
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
4
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 1MSSx1MSScwnd
. 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).
5
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).
6
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).
7
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).
8
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
9
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).
10
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.
11
• 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.
12
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).
13
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
14
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.
15
R=LT⇒T=
8000 kb1Mb / 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.
16
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:
17
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.
18
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.
Em seguida, aumentou-se o número de nós para dois.
19
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.
20
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.
Fig. 12 – Variação do tamanho da janela de acordo com a quantidade de nós transmitindo simultaneamente
21
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.
Seguem os gráficos das simulações para cada protocolo TCP apresentado.
22
Fig. 13 – Simulação do desempenho do TCP Tahoe frente a interferência
Fig. 14 – Simulação do desempenho do TCP Reno frente a interferência
23
Fig. 15 – Simulação do desempenho do TCP New-Reno frente a interferência
Fig. 16 – Simulação do desempenho do TCP SACK frente a interferência
24
Fig. 17 – Simulação do desempenho do TCP Vegas frente a interferência
Fig. 18 – Comparação de todos os algorítimos a 1% de interferência
25
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.
26
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).
27
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).
28
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
29
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
t n−t n−1
onde Ln é a quantidade dados reconhecidos por ACKn.
30
Utilizando um filtro, obtém-se a largura de banda da conexão:
bn=nbn−11−n
bnbn−12
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 .RTT mínMSS
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).
31
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).
32
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
33
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.
34
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.
[LEUNG, Ka-Cheong; LI, Victor O. K., 2006, Transmission Control Protocol (TCP) in
35
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.
36
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 }
37
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) 600set 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
38
$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
39
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 canalset val(prop) Propagation/TwoRayGround ;# modelo de propagaçãoset val(netif) Phy/WirelessPhy ;# tipo da interface de redeset val(mac) Mac/802_11 ;# MACset val(ifq) Queue/DropTail ;# tipo da filaset val(ll) LL ;# tipo da camada de enlaceset val(ant) Antenna/OmniAntenna ;# modelo da antenaset val(ifqlen) 50 ;# tamanho máximo da filaset val(nn) 3 ;# número de nósset val(rp) DumbAgent ;# protocolo de roteamento
;# modo de infraestrutura
40
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
41
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
Como pode ser visto na figura C.2, as aplicações geradoras de tráfego (FTP 1 e FTP
42
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-traceclose $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
43
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).
44
