UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RENATO FERNANDO SILVA GONÇALVES
TCP-UEM: uma abordagem para controle de congestionamento sensível a falhas
em enlaces sem fio
Maringá 2012
RENATO FERNANDO SILVA GONÇALVES
TCP-UEM: uma abordagem para controle de congestionamento sensível a falhas
em enlaces sem fio
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação do Departamento de Informática, Centro de Tecnologia da Universidade Estadual de Maringá, como requisito parcial para obtenção do título de Mestre em Ciência da Computação
Orientadora: Prof.a Dr.a Valéria Delisandra
Feltrim
Maringá 2012
"Dados Internacionais de Catalogação-na-Publicação (CIP)" (Biblioteca Setorial - UEM. Nupélia, Maringá, PR, Brasil)
G635t
Gonçalves, Renato Fernando Silva, 1980- TCP-UEM : uma abordagem para controle de congestionamento sensível a falhas em
enlaces sem fio / Renato Fernando Silva Gonçalves. -- Maringá, 2012. 159 f. : il. Dissertação (mestrado em Ciência da Computação)--Universidade Estadual de
Maringá, Dep. de Informática, 2012. Orientador: Profª. Drª. Valéria Delisandra Feltrim.
1. TCP-UEM (Transmission Control Protocol - UEM). 2. Wireless. 3.Redes de
computadores sem fio – Camada de transporte. I. Universidade Estadual de Maringá. Departamento de Informática. Programa de Pós-Graduação em “Ciência da Computação”.
CDD-23. ed. -004.62 NBR/CIP - 12899 AACR/2
Maria Salete Ribelatto Arita CRB 9/858 João Fábio Hildebrandt CRB 9/1140
Dedico este trabalho a minha
esposa e filhas, pelo amor e
compreensão incondicionais
desprendidos ao longo desta
caminhada.
AGRADECIMENTOS
Agradeço primeiramente a Deus que me guiou e deu forças durante essa dura jornada.
À professora Dra. Luciana Andréia Fondazzi Martimiano pela excelente orientação sem a
qual não seria possível a realização deste trabalho.
À minha Esposa e filhas pelo amor, compreensão e paciência incondicionais, por entenderem
a minha ausência durante as horas dedicadas para a conclusão deste trabalho.
Ao Ministério Público Federal e aos seus servidores pela colaboração por disponibilizar sua
infraestrutura de redes para realização de testes de desempenho.
Ao Procurador da República Dr. Gustavo Moyses da Silveira e ao servidor Wagner Gomes da
Silva por permitirem a compensação das minhas faltas durante o expediente, necessárias para
conclusão dos créditos da pós-graduação.
Ao corpo docente e administrativo da Universidade Estadual de Maringá/PR.
Aos amigos, familiares, colegas de trabalho e de faculdade e a todos que colaboraram direta
ou indiretamente com a execução deste trabalho.
TCP-UEM: uma abordagem para controle de congestionamento sensível a falhas
em enlaces sem fio
RESUMO
O surgimento das redes de computadores proporcionou um grande avanço na computação. O
alto custo de um recurso computacional dos computadores de terceira geração foi um dos
principais propulsores que ajudaram a popularizar as redes de computadores. As redes de
computadores se tornaram um caminho sem volta. A união dessas redes possibilitou a criação
da Internet. O acesso à Internet pode ser feito praticamente em qualquer lugar do mundo, isso
graças à evolução das redes e aos equipamentos que garantem mobilidade dos usuários.
Empregar a tecnologia de protocolos, que evoluiu solidamente sobre a Internet cabeada, às
redes sem fio é um grande desafio. Há uma enorme diferença entre elas e as redes sem fio,
essas não possuem previsibilidade, pois usam o ar como meio físico de acesso. Redes sem fio
estão expostas a uma alta taxa de erros de transmissão, desconexões frequentes devido a
handoffs, obstáculos inesperados que atenuam a qualidade do sinal entre outros. A Internet
ajudou a popularização e a padronização de diversas tecnologias, ajudando a reforçar essa
afirmação exemplifica-se a “suíte” de protocolos TCP/IP. O protocolo TCP é o protocolo da
camada de transporte mais utilizado na Internet, contudo, seu projeto evoluiu para trabalhar
em um enlace estável, sem muita variação. Sua utilização em redes sem fio degrada seu
desempenho devido à sua incapacidade de distinguir entre dificuldades no enlace e
congestionamentos, provocando assim o disparo incorreto de seu mecanismo de controle de
congestionamento. Grandes esforços têm sido feitos para melhorar a eficiência das
comunicações em um enlace que usa o ar como meio físico. Algumas soluções abordadas
tentam tratar o problema na camada de transporte. Outras soluções recorrem ao auxílio da
camada de enlace. Há ainda as soluções que propõem a criação de um novo protocolo,
reprojetado exclusivamente para ambientes sem fio. De fato, há um consenso sobre as
fraquezas enfrentadas pelo TCP quando empregado em redes sem fio, bem como sobre quais
características um protocolo deve ter para ser eficiente nesse ambiente. Diante de tal cenário,
este trabalho, compara algumas das soluções existentes e apresenta uma nova variante, TCP-
UEM, cuja proposta é detectar falhas no enlace mantendo sua semântica fim a fim, ou seja,
sem contar com o auxílio de outras camadas para realizar essa detecção.
Palavras-chave: TCP. Redes sem fio. Protocolos. Transporte. Enlace. Redes de
computadores.
an approach to congestion control sensitive to failures in wireless links
ABSTRACT
The emergence of computer networks has provided great advances in computing. The high
cost of a computational resource at that time was one of the major responsibles for
popularizing computer networks. Expensive resources and data could be shared. Computer
networks have become a no-return road. The union of these networks made possible the
creation of the Internet. New technologies and protocols were developed. Access to the
Internet can be done virtually anywhere in the world thanks to the evolution of networks and
mobility technology. However, to use this technology, which evolved solidly on the wired
Internet, in wireless networks is a major challenge. There is a huge difference between wired
networks and wireless networks. Wireless Networks do not have predictability, using air as a
means of physical access. Wireless networks are subject to a high rate of transmission errors,
frequent disconnections due to handoffs, unexpected obstacles that attenuate the quality signal
and others. The Internet has helped to popularize and standardize several technologies, such
as the TCP / IP. The TCP protocol is transport layer protocol more used by applications on
Internet, but it has evolved to work in a stable link, without much variation. Thus, TCP is
inefficient when used in wireless networks, because TCP understands as a sign of congestion
packets losses faced by wireless networks, causing the control algorithm of TCP to be
activated erroneously causing degradation of the efficiency of the protocol. Several efforts
have been made to improve the efficiency of communications on a link that uses air as the
physical environment. Some solutions try to treat the problem at the transport layer. Others
seek assistance from the link layer. There are also the solutions which propose the creation of
a new protocol, redesigned exclusively for wireless environments. In fact, there is a consensus
about the weaknesses faced by TCP when used in wireless networks, as well as which
features a protocol must have to be effective. Facing such a scenary, this work compares some
of the existing solutions and presents a new variant of TCP-UEM whose purpose is to detect
link failures while keeping its end-to-end semantics, ie, without relying on the help of other
layers to perform this detection.
Keywords: TCP. wireless network, protocol, transport, new protocol, link, computers
network.
LISTA DE FIGURAS
Figura 1 - Modelos de referência OSI e TCP/IP (Tanenbaum, 2003). .....................................21 Figura 2 - A camada de enlace de dados (Kurose e Ross, 2010). ............................................23 Figura 3 - Formato do cabeçalho do segmento do protocolo TCP (RFC 793).........................24 Figura 4 - Divisão entre as abordagens que melhoram o desempenho do TCP em redes móveis (ELAARAG, 2009) ..................................................................................................................32 Figura 5 - Divisão de uma conexão ..........................................................................................43 Figura 6 - Redes Wi-Fi detectadas na cidade de Illinois em Chicago USA. (WIGLE, 2012) .49 Figura 7 - Planta baixa do ambiente onde os testes foram realizados. .....................................57 Figura 8 - Organização da rede em que foram realizados os testes..........................................57 Figura 9 - Descrição do ambiente em foi realizado o teste a uma distância de 5 metros. ........58 Figura 10 - Planta baixa do cenário em que ocorreram os testes. Host móvel a uma distância de 40 metros da estação base. (do autor) ..................................................................................59 Figura 11 - NAM – Network Animation (Nam network animator project, 2012) ...................62 Figura 12: Comportamento da janela de congestionamento do TCP-Newreno em um enlace 100% confiável. ........................................................................................................................67 Figura 13 - Evolução do número de sequência do protocolo TCP-Newreno em um enlace 100% confiável. ........................................................................................................................67 Figura 14 - Dinâmica do crescimento da janela de congestionamento do protocolo TCP.......69 Figura 15 - Comportamento da janela de congestionamento do protocolo TCP-Newreno sobre um enlace com taxa de erros de 12,5%. ...................................................................................70 Figura 16 - Evolução do número de sequência do protocolo TCP-Newreno sobre um enlace com taxa de erros de 12,5%......................................................................................................71 Figura 17 - Comportamento da janela de congestionamento do protocolo TCP-Newreno sobre um enlace com taxa de erros de 12,5% e sujeito a falhas.........................................................72 Figura 18 - Evolução do número de sequência do protocolo TCP-Newreno quando submetido a um enlace sujeito a 12,5% de erros e a falhas. ......................................................................73 Figura 19 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno, Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace 100% confiável. 74 Figura 20 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno, Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5%. ..................................................................................................................................74 Figura 21 - Evolução do número de sequência das variantes Tahoe, Reno, Newreno, Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5%...................................................................................................................................................75 Figura 22 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno, Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5% e sujeito a falhas. ......................................................................................................75 Figura 23 - Evolução do número de sequência das variantes Tahoe, Reno, Newreno, Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5% e sujeito a falhas. .........................................................................................................................76 Figura 24 - Dinâmica da janela de congestionamento do TCP. ...............................................78 Figura 26 - Janela de congestionamento do protocolo TCP fatiada em intervalos de tempo...85 Figura 27- Janela de congestionamento do protocolo TCP fatiada em intervalos de tempo. Última fatia com taxa de erros maior que as outras. ................................................................86 Figura 28 - Comportamento das janelas de congestionamento das variantes TCP-Newreno e TCP-UEM sobre um enlace 100% confiável. ..........................................................................97 Figura 29 - Convergência para a taxa ideal de transmissão com e sem redução da janela na primeira fase de partida lenta. ..................................................................................................98
Figura 30 - Comportamento das janelas de congestionamento das variantes TCP-Newreno e TCP-UEM sobre um enlace 100% confiável. ..........................................................................99 Figura 31 - Comportamento da janela de congestionamento da variante TCP-UEM submetido a um enlace com taxa de perdas de 12,5%. ............................................................................101 Figura 32 - Comportamento da janela de congestionamento da variante TCP-UEM submetida a um enlace com taxa de erros de 12,5% e sujeito a falhas no enlace....................................101 Figura 33 -Comparação da evolução do número de sequência das variantes TCP-UEM e TCP-Newreno. ................................................................................................................................102 Figura 34 - Comportamento da janela de congestionamento das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack e Fack. ...............................................................105 Figura 35 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack e Fack. ................................................................................106 Figura 36 - Handoff entre a estação base 1 e a estação base 2. Conexão estabelecida entre estação fixa 1 e estação móvel................................................................................................110 Figura 37 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack, Fack e Linux quando submetidos a handoff em um enlace sem fio. ...................................................................................................................................111 Figura 38 - Divisão do enlace entre os remetentes 1 e 2. .......................................................112 Figura 39: Evolução do número de sequência dos remetentes 1 e 2 que compartilharam um único enlace. ...........................................................................................................................113 Figura 40 - Comportamento da janela de congestionamento dos remetentes 1 e 2 ao compartilharem o mesmo enlace. ...........................................................................................114 Figura 41 - Avaliação do critério Justiça entre as variantes TCP-UEM, Newreno, Linux e NewJersey...............................................................................................................................115 Figura 42 - Largura de banda utilizada pelas variantes TCP-UEM, Newreno, Linux e NewJersey...............................................................................................................................116 Figura 43 - Desempenho das variantes TCP-UEM, Newreno, Linux e NewJersey compartilhando o mesmo enlace. ...........................................................................................117 Figura 44 - Simulação de uma rede ad hoc. ...........................................................................118 Figura 45 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack, Fack e Linux sobre uma rede ad hoc. ...............................120 Figura 46 - Médias obtidas na análise de variância com os dados da Tabela 16. ..................124 Figura 47 -Histograma dos dados constantes na Tabela 16....................................................126 Figura 48 - Histograma dos resultados do TCP-UEM constantes na Tabela 16. ...................127 Figura 49 - Função Probabilidade Cumulativa das variantes simuladas (Tabela 16) ............128
LISTA DE TABELAS
Tabela 1 - Comparação das características das redes cabeadas e redes sem fio ......................29 Tabela 2 - Resultados obtidos ao transferir dados utilizando como enlace os buffers do Sistema Operacional .................................................................................................................51 Tabela 3 - Descrição do circuito Tupã/SP x Macapá/AP .........................................................52 Tabela 4 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Macapá/AP composto por enlaces cabeados e enlace que utiliza sinal via satélite entre as cidades . .........52 Tabela 5 - Descrição do circuito Tupã/SP x Salvador/BA .......................................................53 Tabela 6 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Salvador/BA com enlaces cabeados. ........................................................................................53 Tabela 7 - Descrição do circuito Tupã/SP x Florianópolis/SC.................................................54 Tabela 8 - Resultados obtidos ao transferir dados utilizando circuito Tupã/SP x Florianópolis/SC composto de enlaces cabeados e que utilizam sinais de rádio .....................54 Tabela 9 - Descrição do circuito Tupã/SP x Assis/SC .............................................................55 Tabela 10 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Assis/SC composto de enlaces cabeados e que utilizam sinais de rádio..................................................55 Tabela 11 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a cinco metros da origem do sinal) ...........................................................................58 Tabela 12 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a 40 metros da origem do sinal) ................................................................................59 Tabela 13 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a 40 metros da origem do sinal com interferências) .................................................60 Tabela 14 - Desempenho das variantes TCP sobre um enlace sujeito a erros e a falhas no enlace. .....................................................................................................................................103 Tabela 15 - Desempenho das variantes TCP submetidas a uma rede ad hoc.........................118 Tabela 16 - Quantidade de dados transferidos por cada uma das variantes TCP utilizadas simuladas por 31 consecutivas utilizando 31 sementes diferentes. ........................................121 Tabela 17 - Resultado da análise estatística das simulações constantes da Tabela 15...........123
LISTA DE ABREVIATURAS E SIGLAS
ATCP Ad hoc Transport Control Protocol
ATP Ad-hoc Transport Protocol
BER Bit Error Rate
CWL Congestion Window Limit
EBSN Explicit Bad State Notification
ERCN Explicit Rate Change Notification
F-RTO Forward RTO-Recovery
ICMP Internet Control Message Protocol
I-TCP Indirect Transport Control Protocol
LAN Local Area Network
LRED & AP Link RED and Adaptative Pacing
Mbps Megabits por Segundo
MSS Maximum Segment Size
M-TCP Mobile Transport Protocol
RTO Retransmission Time Out
RTT Round Trip Time
RTTMin Round Trip Time mínimo
TCP Transmission Control Protocol
TCP-ECN TCP-Explicit Congestion Indentification
TCP-ELFN TCP-Explicit Link Failure Notification
TI Tecnologia da Informação
SUMÁRIO
1 INTRODUÇÃO.......................................................................................................................................... 15
1.1 ORGANIZAÇÃO DO TRABALHO ............................................................................................................ 18
2 REDES DE COMPUTADORES: O PROTOCOLO TCP ..................................................................... 20
2.1 REDES DE COMPUTADORES E A ARQUITETURA EM CAMADAS .............................................................. 20 2.1.1 Camada de Aplicação.................................................................................................................... 21 2.1.2 Camada de Transporte .................................................................................................................. 22 2.1.4 Camada de Enlace e Física ........................................................................................................... 23
2.2 A IMPORTÂNCIA DA CAMADA DE TRANSPORTE ................................................................................... 24 2.2.1 O mecanismo de controle de congestionamento do TCP .............................................................. 27
2.3 O USO DO TCP NAS REDES SEM FIO ..................................................................................................... 28 2.4 CONSIDERAÇÕES FINAIS ..................................................................................................................... 31
3 MELHORIAS NO TCP ............................................................................................................................. 32
3.1 ESTRATÉGIAS PARA MELHORAR O DESEMPENHO DO TCP EM REDES SEM FIO ................................ 32 3.2 ALGORITMOS BASEADOS NA ESTIMATIVA DE LARGURA DE BANDA .................................................... 33
3.2.1 TCP-Vegas .................................................................................................................................. 33 3.2.2 TCP-Westwood ........................................................................................................................... 35 3.2.3 TCP-Jersey .................................................................................................................................. 35
3.3 ALGORITMOS QUE USAM NOTIFICAÇÃO EXPLÍCITA DE FALHA NO ENLACE......................................... 37 3.3.1 Notificação Explícita de Falha no Enlace (ELFN) .................................................................. 37 3.3.2 ADTCP.......................................................................................................................................... 38
3.4 ALGORITMOS QUE EVITAM A RETRANSMISSÃO DESNECESSÁRIA DE SEGMENTOS............................ 39 3.4.1 TCP-EIFEL................................................................................................................................... 39
3.5 ALGORITMOS QUE EXPLORAM A CAPACIDADE DE “BUFFERIZAÇÃO” DOS NÓS INTERMEDIÁRIOS ...... 40 3.5.1 SPLIT-TCP................................................................................................................................... 41 3.5.2 TCP-BUS...................................................................................................................................... 41
3.6 ALGORITMOS QUE DIVIDEM A CONEXÃO COM O AUXÍLIO DA CAMADA DE ENLACE............................. 42 3.7 UM NOVO PROTOCOLO PARA A CAMADA DE TRANSPORTE PARA REDES AD HOC ............................. 45 3.8 CONSIDERAÇÕES FINAIS.................................................................................................................... 47
4 AVALIAÇÃO EMPÍRICA DA CONFIABILIDADE DO ENLACE SEM FIO .................................. 48
4.1 MOTIVAÇÃO PARA REALIZAÇÃO DOS EXPERIMENTOS ......................................................................... 50 4.2 FERRAMENTA UTILIZADA .................................................................................................................... 50 4.3 PRIMEIRO EXPERIMENTO ..................................................................................................................... 51 4.4 SEGUNDO EXPERIMENTO ..................................................................................................................... 51
4.4.1 Considerações com relação ao segundo experimento................................................................... 56 4.5 TERCEIRO EXPERIMENTO..................................................................................................................... 56 4.6 CONSIDERAÇÕES FINAIS ...................................................................................................................... 60
5 ANÁLISE DO COMPORTAMENTO DO TCP EM UM SIMULADOR DE REDES........................ 61
5.1 SIMULADOR DE REDES DE COMPUTADORES......................................................................................... 62 5.2 CONSIDERAÇÕES SOBRE SIMULAÇÃO DE REDES .................................................................................. 63 5.3 TCP EM UM AMBIENTE SIMULADO ...................................................................................................... 65 5.4 CONSIDERAÇÕES FINAIS ...................................................................................................................... 76
6 TCP-UEM: UMA NOVA ABORDAGEM............................................................................................... 78
6.1 DINÂMICA DA JANELA DE CONGESTIONAMENTO DO TCP.................................................................... 78 6.2 RFC 5681 – CONTROLE DE CONGESTIONAMENTO DO TCP ................................................................. 79 6.3 UMA NOVA ABORDAGEM..................................................................................................................... 82 6.4 TCP-UEM – UMA NOVA PROPOSTA................................................................................................... 88
6.4.1 TCP-UEM – Tratamento de ACK válido....................................................................................... 88 6.4.2 TCP-UEM – Ocorrência de timeout.............................................................................................. 91
6.5 TCP-UEM - O PROBLEMA DA CONVERGÊNCIA DEMORADA ............................................................... 98 6.6 RFC 5681 X TCP-UEM...................................................................................................................... 99 6.7 SIMULAÇÕES DO TCP-UEM ............................................................................................................. 100
6.7.1 TCP-UEM SUBMETIDO A 12,5% DE PROBABILIDADE DE ERRO........................................................ 100 6.8 CONSIDERAÇÕES FINAIS .................................................................................................................... 108
7 SIMULAÇÕES E ANÁLISES ESTATÍSTICAS DOS RESULTADOS ............................................. 109
7.1 SIMULAÇÃO: TCP-UEM SUBMETIDO A UM HANDOFF ....................................................................... 109 7.2 SIMULAÇÃO: TCP-UEM AMIGÁVEL ................................................................................................. 112 7.3 SIMULAÇÃO: TCP-UEM EM REDES AD-HOC...................................................................................... 117 7.4 ANÁLISE DE VARIÂNCIA ................................................................................................................... 121 7.5 TESTE DE HSU.................................................................................................................................. 123 7.6 PROBABILIDADES .............................................................................................................................. 126 7.7 CONSIDERAÇÕES FINAIS ................................................................................................................... 128
8 CONCLUSÃO.......................................................................................................................................... 131
REFERÊNCIAS ................................................................................................................................................ 135
APÊNDICE A .................................................................................................................................................... 141
15
1. Introdução
A chamada “Revolução sem fio” teve como causas os recentes avanços na área de
comunicação sem fio, o crescimento da telefonia celular, a popularidade e aceitação pelo
mercado consumidor por dispositivos de computação móveis e portáteis, e o crescimento
emergente de redes locais sem fio (Boukerche, et al, 2009).
Tipos de serviços com acesso a Internet por meio de um aparelho celular,
estabelecimentos comerciais disponibilizando pontos de acesso a Internet (“cybercafé”),
popularização e barateamento de computadores portáteis (notebooks, netbooks, dentre outros)
e compartilhamento de informações entre aparelhos sem que haja uma infraestrutura de rede
pré-estabelecida são exemplos que norteiam o futuro promissor das redes sem fio, as quais
têm em seu favor a mobilidade de seus usuários em contraste com as redes com fio.
Integração e compatibilidade entre os dispositivos, tolerância a falhas, redes
distribuídas compostas por diferentes tecnologias, consumo eficiente de energia, acesso
ubíquo a rede e mobilidade irrestrita são os grandes desafios que devem ser enfrentados por
essa emergente área.
Nicolas G. Carr publicou um artigo na Harvard Business Review defendendo que o
uso estratégico de TI (Tecnologia da Informação) já não era mais uma vantagem competitiva
para as empresas, pois a estabilização da tecnologia e sua adoção teriam como resultado a
transformação da Internet, de algo novo, em um recurso onipresente (Carr, 2003). Para Carr, a
Internet passaria a ser uma concessionária pública da informação, um mecanismo utilizado
pelas pessoas para acessar informação e contatar outras pessoas de qualquer lugar, utilizando
qualquer dispositivo. Como consequência, a conectividade das redes sem fio motivou a
melhoria, o reprojeto das redes, sistemas, algoritmos e aplicações.
1
16
Redes móveis sem fio e seus enlaces são fundamentalmente diferentes das redes
estacionárias (com fio), pois permitem que os usuários estejam livres para se movimentar e
acessar informações em qualquer lugar a qualquer momento. Entretanto, desempenhos
inferiores aos das redes cabeadas não podem ser justificados pelo ganho de mobilidade,
devendo essa tecnologia propiciar total transparência para o usuário, impedindo que ele tenha
condições de distinguir se está utilizando um enlace cabeado ou sem fio. Contudo, muitas das
tecnologias que se tornaram padrão na Internet e evoluíram sobre a antiga infraestrutura
cabeada são usadas também nas atuais infraestruturas de redes sem fio sem que antes fossem
adequadas para essa nova tecnologia.
Redes sem fio enviam e recebem dados usando sinais de rádio por intermédio do ar.
Essa forma de transmissão está sujeita a alta taxa de colisões, alta taxa de erros de
transmissões (BER – Bit Error Rate), topologia dinâmica e variações na capacidade do
enlace. Transmissões sobre enlaces sem fio sofrem atrasos, estão sujeitas a mobilidade dos
nós e a frequentes desconexões causadas por handoffs (procedimento transparente ao usuário
que é empregado em redes sem fio para tratar a transição de uma unidade móvel de uma
célula para outra preservando a conexão). Dessa forma, essas características causam a falsa
identificação e o disparo inoportuno do mecanismo de controle de congestionamento no TCP
(Transmission Control Protocol) (Institute, 1981) transmissor, consequentemente diminuindo
seu desempenho (Mustafa, 2008).
TCP é o protocolo da camada de transporte mais utilizado na Internet. Ele foi
projetado para oferecer um fluxo de bytes fim a fim confiável em uma inter-rede não
confiável (Tanenbaum, 2003). TCP é um protocolo orientado a conexão que garante a entrega
confiável de dados mesmo estando sobre um canal não confiável. A evolução do TCP teve
como base as redes com fio e seu emprego em redes sem fio degrada seu desempenho.
Com o domínio das redes cabeadas o protocolo TCP sofreu poucas alterações desde a
sua versão original. Algumas versões são: TCP-Tahoe (Jacobson, 1988), TCP-Reno (Stevens,
et al, 1999), TCP-Newreno (Floyd, 1999), TCP-Vegas (Brakmo e Peterson, 1995), TCP-Sack
(Floyd, et al, 1996), TCP-Westwood (Casetti, et al, 2002), TCP-Jersey (Ansari e Tian, 2004),
dentre outras.
Para fazer com que o TCP se torne robusto para suportar as imprevisibilidades das
redes sem fio, muitas pesquisas foram feitas resultando no desenvolvimento de novos
esquemas e variações no mecanismo de controle de congestionamento do TCP original. Esses
esquemas incluem TCP-Veno (Fu e Liew, 2003), TCP- Freeze (Goff, et al, 2000), TCP-Eifel
(Ludwig e Katz, 2000), TCP-Bus (Choi, et al, 2001), TCP-Snoop (Balakrishnan, et al, 1995),
TCP-ECN (Floyd, 1998), TCP-Peach (Akyildiz, et al, 2001), Split-TCP (Faloutsos, et al,
17
2002), TCP-ELFN (Bharghaan, et al, 2000), CWL (Chen, et al, 2003), LRED & AP (Fu, et al,
2003), F-RTO (Sarolahti, et al, 2003), ADTCP (Fu, et al, 2002), ATCP (Liu e Singh, 2001), I-
TCP (Khan e Zaghal, 2006), M-TCP (Brown e Singh, 1997), WAP-Wireless Aplication
Protocol (WAP Fórum), EBSN (Bikram, et al, 1997), ERCN (Wang e Lee, 2005), ATP
(Sundaresan, et al, 2003).
Novos protocolos para a camada de enlace também foram propostos, os quais podem
auxiliar o protocolo TCP a melhorar seu desempenho sobre redes sem fio, tais como: RLP
(Karn, 1990) e AIRMAIL (Ayanoglu, et al, 1994).
Todos esses esquemas e soluções apresentados são resultados de estudos e pesquisas,
os quais garantem uma grande quantidade de informação para possíveis novos esquemas.
A grande quantidade de soluções demonstra a quantidade de pesquisa e esforços já
efetuados, os quais tentam tornar o protocolo TCP mais robusto quando empregado em
ambientes de redes sem fio. Contudo, cada solução apresenta algumas das fraquezas do TCP
original, de modo que a maioria das soluções não resolve todos os problemas e alguns
problemas são resolvidos de diferentes maneiras.
Nesse cenário, observa-se que as redes de computadores têm sido cada vez mais
heterogêneas por proporcionar a interligação dos mais variados tipos de dispositivos, sejam
eles móveis ou não. Essa característica só é possível graças à sua arquitetura em camadas.
Assim sendo, mantê-la é fator fundamental para continuar propiciando a evolução das redes
de computadores, que caminham para ubiquidade. Nesse contexto, as motivações para a
presente pesquisa são:
• Cada solução proposta para melhorar o TCP visa a sua aplicação em um determinado
contexto ou quando empregado sobre uma determinada tecnologia, porém, nem sempre as
soluções propostas são intercambiáveis, o que evidencia o quão difícil é reuni-las para
torná-lo robusto diante dos diversos problemas que cada tecnologia ou determinado
ambiente traz;
• Algumas soluções contam com o auxílio de outras camadas para solucionar um
determinado problema, de modo que a semântica fim a fim não é respeitada;
• Uma boa solução deve estar preparada para suportar futuras tecnologias mantendo
compatibilidade com as já existentes. Nem sempre isso é obedecido, uma vez que algumas
propostas dependem do auxílio de tecnologias específicas;
18
• A camada de transporte exerce papel fundamental nas redes de computadores, pois são de
sua responsabilidade a garantia de entrega e o controle de fluxo da transmissão de dados;
• A grande aceitação dos usuários pelas redes sem fios além de proporcionar sua
ubiquidade, também expande os serviços oferecidos pela Internet, os quais podem estar
disponíveis também de forma ubíqua.
Inicialmente, o objetivo deste trabalho era simular as melhores propostas de variantes
TCP escolhidas dentre àquelas que demonstrassem possuir bom desempenho quando
utilizadas em redes sem fio. As simulações só seriam possíveis desde que essas propostas
possuíssem implementação no simulador escolhido. Depois de escolhidas, essas seriam
simuladas em diversos cenários e com base nos resultados obtidos, verificar-se-ia a
possibilidade dessas soluções serem intercambiáveis, possibilitando a integração dessas
soluções numa única solução.
Entretanto, no decorrer das simulações observou-se um padrão que se repetia com
todas as variantes simuladas quando quedas no enlace ocorriam. Esse fato encorajou a
pesquisa no sentido de dar ao protocolo TCP a capacidade necessária para detectar esse
padrão, o que possibilitou a criação de uma nova variante. Essa variante, denominada TCP-
UEM, no ambiente de simulação, ao detectar a ocorrência do padrão observado, interpretou
essa ocorrência como falha no enlace e não como congestionamento.
A capacidade de detecção de falhas no enlace pela nova variante TCP-UEM não
dependeu do auxílio das camadas de rede inferiores ou superiores, o que preservou a
semântica fim a fim do TCP.
Por fim, foram realizadas várias simulações em diversos cenários visando comparar a
nova variante TCP-UEM com outras, demonstrando quais são os benefícios em detectar
falhas no enlace durante uma conexão1, considerando redes de acesso ou de última milha.
1.1 Organização do trabalho
A seguir é apresentada a organização deste trabalho. O tópico 2 aborda de uma forma
resumida as redes de computadores e sua arquitetura em camadas. Também nesse tópico é
enfatizada a importância da camada de transporte e o problema do emprego do protocolo TCP
nas redes sem fio. No Tópico 3 são apresentadas melhorias ou estratégias que têm por
1 O uso da palavra conexão neste trabalho refere-se à conexão entre dois hosts finais, ou seja, é o
estabelecimento lógico entre remetente e destinatário, não importando qual o número de conexões estabelecidas
pelas camadas inferiores da rede para proporcionar essa ligação
19
finalidade melhorar o controle de congestionamento do TCP para que ele possa se tornar mais
robusto diante das dificuldades inerentes às redes sem fio. O tópico 4 mostra os resultados de
experiências realizadas em redes reais com o objetivo de mensurar a confiabilidade dos
enlaces utilizados nessas redes. No Tópico 5 são descritos os resultados das simulações
realizadas no protocolo TCP em um simulador de redes. O tópico 6 apresenta uma nova
variante do TCP, denominada TCP-UEM. O tópico 7 apresenta os resultados obtidos nas
simulações do TCP-UEM em comparação com outras variantes, além também de apresentar
uma análise estatística dos resultados. Finalmente, o tópico 8 apresenta as considerações
finais, as contribuições deste trabalho e trabalhos futuros.
20
2. Redes de computadores: O protocolo
TCP
2.1 Redes de computadores e a arquitetura em camadas
Redes de computadores podem ser definidas como um conjunto de computadores
interligados capazes de compartilhar recursos entre si. Elas podem estar conectadas a outras
redes, formando assim uma rede ainda maior. Um bom exemplo de redes interconectadas é a
Internet.
A Internet é um sistema extremante complexo, a qual é constituída de inúmeras
aplicações, protocolos, vários tipos de sistemas finais e roteadores, os quais utilizam vários
tipos de meios físicos de enlace para se conectarem (Kurose e Ross, 2010). Os enlaces podem
utilizar cabos de cobres, fibra ótica, satélite, dentre outros meios.
O conceito de camadas foi introduzido para facilitar o projeto e a manutenção das
redes de computadores. Cada camada é responsável por uma tarefa específica e bem definida
em um sistema grande e complexo. A modularidade é uma das principais vantagens de se
utilizar uma arquitetura em camadas, pois permite a independência entre elas, propiciando que
uma camada possa ser completamente modificada sem afetar suas camadas adjacentes. Isso só
é possível se a camada modificada continuar oferecendo os mesmos serviços para a camada
superior, e continuar usando os mesmos serviços da camada inferior. Uma desvantagem
potencial desse modelo é que uma camada pode duplicar a funcionalidade de uma camada
inferior (Kurose e Ross, 2010). Por exemplo, várias camadas podem oferecer o mesmo
serviço de recuperação de erros.
2
21
A comunicação entre dois sistemas distintos é feita por meio de regras conhecidas por
ambos, tais regras são conhecidas como protocolos de comunicação. Cada camada utiliza
serviços fornecidos pela camada inferior para se comunicar com sua entidade homóloga no
sistema destino. A camada inferior acrescenta um serviço de valor à camada superior,
realizando uma tarefa que somente, em tese, poderia ser realizada pela camada inferior.
Há dois principais modelos de referência de arquitetura de camadas empregadas em
redes de computadores: o modelo de referência OSI - Open Systems Interconnection e o
modelo de referência TCP/IP (Transmission Control Protocol / Internet Protocol)
(Tanenbaum, 2003). Na Figura 1 é possível visualizar as diversas camadas que compõem cada
modelo.
Figura 1 - Modelos de referência OSI e TCP/IP (Tanenbaum, 2003).
Embora haja dois modelos de referência, o modelo usado na Internet é conhecido
como modelo híbrido. O modelo híbrido reduz o excesso de camadas do modelo OSI (modelo
didático) e preenche as lacunas existentes no modelo TCP/IP. A seguir as camadas do modelo
híbrido (com cinco camadas) são descritas.
2.1.1 Camada de Aplicação
Situa-se no topo da pilha e usa serviços oferecidos pela camada de transporte. É nessa
camada que residem os protocolos de alto nível tais como: HTTP (Hyper Text Transfer
Protocol), utilizado por aplicações WWW (World Wide Web), DNS (Domain Name Service),
utilizado para resolução de nomes e seus respectivos endereços na Internet, FTP (File
Transfer Protocol), utilizado como protocolo de transferência de arquivos, TELNET, para
terminais remotos, etc.
22
2.1.2 Camada de Transporte
É a camada responsável por transportar mensagens vindas da camada de aplicação e
entregá-las à aplicação destinatária. Os principais protocolos dessa camada são TCP e UDP
(User Datagram Protocol) (RFC 768) (Kurose e Ross, 2010). O protocolo TCP é orientado a
conexão e garante a entrega confiável dos dados da origem até o destino, não importando a
confiabilidade dos canais pelos quais atravessou. O protocolo TCP também é responsável
pelo controle de fluxo e controle de congestionamento em uma conexão estabelecida. O
protocolo UDP é um protocolo não orientado a conexão e não garante a entrega confiável dos
dados do remetente até o destinatário. As unidades de dados desses protocolos são conhecidas
como segmento TCP e datagrama UDP.
2.1.3 Camada de Rede
A camada de Rede ou Interredes possui a tarefa de permitir que os nós participantes da
rede injetem informações (divididas em pacotes) até o destinatário. Os pacotes trafegarão até
o destino de forma independente (atravessando outras redes) podendo até mesmo chegar a
uma ordem diferente daquela em que foram enviados (Tanenbaum, 2003).
Ela provê o serviço de entrega dos segmentos vindos da camada de transporte origem
para a camada de transporte na máquina destinatária (Kurose e Ross, 2010).
Nesta camada encontra-se o protocolo IP (RFC 791) (Institute, 1981), que é o
responsável pelo endereçamento, ou seja, a identificação única de cada host na Internet.
Fazendo uma analogia, o protocolo IP é o cavalo que puxa a carroça levando como carga
protocolos (TCP, UDP, ICMP (RFC 792), etc.) da camada superior (Stevens, 2001).
Todos os componentes da Internet que têm uma camada de rede devem executar esse
protocolo (Kurose e Ross, 2010). Alguns componentes que pertencem a uma rede não
executam todas as camadas, por exemplo, hubs ou concentradores executam somente a
camada física repetindo ou intensificando os sinais que recebem.
A camada de Rede é responsável também pelo roteamento dos pacotes. Há vários
protocolos (RIP – Routing Information Protocol, OSPF - Open Shortest Path First, BGP –
Border Gateway Protocol) que executam essa tarefa definindo as melhores rotas para que o
pacote de informação chegue até o destino. Porém, entregá-los até o destino final é tarefa do
protocolo IP, sendo ele o protocolo fundamental que mantém a integridade da Internet
(Kurose e Ross, 2010).
23
2.1.4 Camada de Enlace e Física
A camada de enlace está relacionada aos protocolos de redes locais, pois atua somente
no âmbito local de cada rede. Sua tarefa é fornecer serviços para a camada de rede. Na
camada de enlace a informação, denominada quadro, é transportada por enlaces individuais.
Em uma conexão, um pacote da camada de rede pode ser transportado por diversos
enlaces até chegar ao destino. Na Figura 2 é possível visualizar os diversos enlaces que são
utilizados em uma conexão. A camada de enlace também oferece outros serviços, tais como:
controle de fluxo, detecção de erros e controle de acesso ao meio. Exemplos de protocolos
utilizados são: HDLC, PPP (point-to-point protocol), CSMA, ALOHA (Kurose e Ross, 2010).
A camada física é responsável pela transmissão física de bits em um canal de
comunicação (Tanenbaum, 2003). Enquanto as outras camadas movimentam segmentos,
pacotes e quadros, a camada física é responsável por movimentar bits individuais (Kurose e
Ross, 2010). Os bits podem ser transportados por canais de comunicação compostos de fios
de cobres, fibra ótica e a atmosfera.
Figura 2 - A camada de enlace de dados (Kurose e Ross, 2010).
24
2.2 A importância da camada de transporte
A camada de transporte é o núcleo de toda a hierarquia de protocolos. Sem a camada
de transporte todo o conceito de protocolos em camadas faria pouco sentido (Tanenbaum,
2003).
Posicionada entre as camadas de aplicação e de rede, ela exerce um papel fundamental
na arquitetura de redes em camadas. A camada de transporte tem o objetivo de ampliar o
serviço de entrega entre a camada de rede e a camada de aplicação (Kurose e Ross, 2010).
O protocolo TCP é de longe o protocolo mais usado na camada de transporte. Ele
possui como características:
• Confiabilidade: Fornece para a camada de aplicação um serviço de entrega de dados
confiável, em outras palavras, garante a entrega íntegra dos dados para a aplicação
destinatária. O protocolo recebe os dados vindos da camada de aplicação e encapsula-os em
segmentos (os dados podem ou não ser divididos para caberem em um segmento). A cada
segmento é adicionado um cabeçalho. A Figura 4 mostra o formato do cabeçalho do segmento
TCP.
Figura 3 - Formato do cabeçalho do segmento do protocolo TCP (RFC 793).
• Orientado a conexão: Para que um processo de aplicação possa começar a enviar dados a
um processo destinatário, antes é necessário que eles se apresentem. Remetente e destinatário
trocam segmentos preliminares para que os parâmetros de transferência de dados sejam
25
estabelecidos. As conexões são estabelecidas por meio do handshake de três vias (RFC 793).
Durante a troca desses segmentos, parâmetros como número de sequência inicial e tamanho
máximo de segmento (MSS – Maximum Segment Size) são definidos entre remetente e
destinatário.
• Início e fim de conexão explícitos: Antes que remetente e destinatário possam trocar
informações é necessário que o lado cliente (remetente), primeiramente, informe ao servidor
(destinatário) sua vontade em estabelecer uma conexão. O lado cliente faz isso enviando um
segmento TCP com o bit SYN ativado (1º segmento para se estabelecer uma conexão TCP).
Esse segmento é denominado segmento SYN (sincronismo). O servidor ao receber esse
segmento saberá que o cliente quer estabelecer uma conexão. O segmento SYN também leva
em seu cabeçalho um número sequencial inicial (“client_isn”) escolhido aleatoriamente pelo
cliente (RFC 793). Após o recebimento do segmento SYN, o destinatário, caso concorde em
estabelecer uma conexão, envia um segmento denominado SYN/ACK para o cliente (2º
segmento para se estabelecer uma conexão TCP). O segmento SYN/ACK, além do bit SYN
ativado, também possui o bit ACK ativado e o número de sequência inicial escolhido pelo
servidor (“server_isn”). O bit ACK (Acknowledgement) quando ativado, avisa o cliente que
esse segmento contém um valor de reconhecimento (“client_isn +1”), em outras palavras, o
segmento SYN/ACK está dizendo, “Recebi seu segmento SYN com seu número de sequência
inicial, concordo em estabelecer a conexão. Meu número de sequência inicial é
(“server_isn”)” (Kurose e Ross, 2010). O cliente, ao receber o segmento SYN/ACK do
servidor, envia um segmento ACK reconhecendo o segmento de confirmação da conexão do
servidor (“server_isn + 1”) (3º e último segmento para se estabelecer uma conexão TCP).
Esse procedimento é conhecido como three way handshake. Quando um dos lados
pertencentes à conexão quer encerrar a conexão, o interessado envia um segmento com o bit
FIN ativado. Esse segmento diz ao outro lado que este lado da conexão não possui mais dados
para enviar. Tendo em vista que uma conexão TCP é full duplex (tráfego de dados em ambas
as direções), o encerramento de uma conexão pode ser vista como duas conexões simplex
(tráfego de dados em apenas uma direção). Cada conexão simplex pode ser encerrada de
forma individual.
• Não duplicação na entrega de segmentos: Dois dos principais campos do cabeçalho do
segmento TCP são os campos número de sequência e número de reconhecimento. Esses
campos são fundamentais para implementar o serviço de entrega confiável de dados do TCP
(Kurose e Ross, 2010). O TCP vê o fluxo de dados transmitidos como uma cadeia de bytes
ordenados. O campo número de sequência para um segmento é o número da posição relativa
26
ao “client_isn” do primeiro byte que o segmento leva (RFC 793). Dessa forma, o destinatário
tem condições de identificar se um segmento carrega dados duplicados, em caso afirmativo, o
segmento é descartado, caso contrário, os dados são entregues ao respectivo processo na
camada de aplicação.
• Entrega os segmentos em ordem: Em uma rede comutada por pacotes é provável que
segmentos pertencentes a uma mesma conexão utilizem caminhos diferentes para chegar até o
destinatário. Conforme descrito anteriormente, o campo número de sequência dá condições
para o TCP destinatário reordenar os segmentos que chegam fora de ordem, para que eles
possam ser entregues de forma ordenada para a camada de aplicação.
• Controle de fluxo: É o mecanismo que o protocolo TCP utiliza para respeitar a
capacidade do destinatário em receber informações. A cada segmento de confirmação de
recebimento (ACK) que o destinatário envia ao remetente, o destinatário informa qual é o
estado atual de seu buffer de recepção. Essa informação é conhecida como anúncio de janela
de recepção, ela é informada no cabeçalho do segmento TCP no campo janela de recepção.
• Mecanismos para impedir congestionamento: Enquanto o controle de fluxo impede que
o buffer de recepção do destinatário seja saturado, fazendo com que o remetente obedeça aos
limites estabelecidos pelo destinatário em uma conexão fim a fim, os mecanismos de controle
do congestionamento do TCP impõem outro limite à taxa a qual um remetente pode enviar
dados para dentro da rede (Kurose e Ross, 2010). A abordagem adotada pelo TCP é obrigar
que cada remetente limite sua taxa de transmissão para sua conexão em função do
congestionamento de rede percebido (Kurose e Ross, 2010). Com o auxílio de uma variável
adicional, denominada janela de congestionamento (CongWin), cada lado da conexão
monitora sua variável CongWin, a qual impõe uma limitação à taxa de transmissão. Assim, o
remetente possui duas limitações: i) ele não deve ultrapassar a janela de recepção do
destinatário; e ii) sua janela de congestionamento (a que for menor). O TCP usa perda de
segmentos como indicação de congestionamento da rede, ajustando sua transmissão de acordo
com sua janela de congestionamento. Em redes com fio, devido ao fato de que taxas de erro
de transmissão são muito baixas, o mecanismo de impedimento de congestionamento do TCP
trabalha muito bem.
27
2.2.1 O mecanismo de controle de congestionamento do TCP
O mecanismo de controle de congestionamento do TCP, descrito na RFC 5681, é
baseado em perda de segmentos, quer seja por meio do recebimento de ACKs duplicados,
quer seja por meio de timeouts (expiração do tempo de espera pela chegada de confirmação
do recebimento de um dado segmento transmitido). O mecanismo é disparado para aliviar o
congestionamento na rede.
Basicamente, remetente e destinatário, ao estabelecerem uma conexão, utilizam uma
janela de congestionamento, a qual determina a quantidade máxima de bytes que podem ser
transmitidos pelo remetente sem que haja uma confirmação de recebimento desses bytes. No
destinatário, a janela de congestionamento determina a quantidade máxima de bytes que o
host destinatário está apto a receber (anúncio do tamanho da janela) (Kurose e Ross, 2010).
Ao detectar um congestionamento, o TCP ajusta o tamanho da janela de forma
apropriada, objetivando manter uma taxa de envio em um nível ideal, qual seja a capacidade
máxima do enlace. Esse mecanismo é formado pela junção dos quatro mecanismos descritos
a seguir (RFC 5681):
• Partida Lenta: Resumidamente, o TCP quando estabelece uma conexão (ou mesmo
depois de um tempo grande de desconexão) define sua janela de congestionamento com o
valor 1 (congwin = 1), portanto, o remetente pode enviar apenas um segmento por vez. A
cada segmento enviado e confirmado, o tamanho da janela é incrementado exponencialmente
até atingir o valor de limiar (threshold). O valor de limiar contém o tamanho máximo
alcançado pela janela de congestionamento durante seu crescimento, a qual foi impedida de
continuar crescendo devido à ocorrência de um evento de perda. Quando a janela do
remetente atinge o valor de limiar, o TCP entra na fase de controle de congestionamento
(congestion avoidance). Nessa fase, o incremento da janela do remetente passa a ser linear e
cresce até atingir o limite da janela anunciada pelo destinatário. A ocorrência de uma perda de
segmento identificada pelo remetente também é uma restrição que impede o crescimento da
janela do remetente.
• Prevenção de Congestionamento (Congestion Avoidance): O TCP tenta impedir
congestionamentos na rede reduzindo sua janela de congestionamento. Quando o protocolo
detecta perda de segmentos, ele reduz sua janela de congestionamento reduzindo assim a taxa
de transmissão. Quando isso acontece, o TCP estabelece um valor de limiar (threshold =
congwin / 2), que é igual à metade da janela atual. Após isso, o TCP diminui o tamanho da
janela para um (congwin = 1), a qual cresce de forma exponencial até atingir o valor de
28
limiar. Atingindo o valor do limiar a janela cresce lentamente sendo incrementada em uma
unidade. Esse comportamento se repete quando o remetente identifica uma perda de
segmento. Dessa forma, o TCP tenta identificar a capacidade máxima de transmissão do
enlace. Diz-se que o TCP é autorregulado por possuir esse comportamento (Kurose e Ross,
2010).
• Retransmissão e recuperação rápidas: O TCP usa duas formas para identificar
possíveis perdas de segmentos. Uma das formas é a ocorrência de um timeout relacionado a
um segmento transmitido, para o qual não foi recebida uma confirmação de recebimento
(ACK) do destinatário num tempo predeterminado. Entretanto, essa forma é ineficiente
quando a conexão estabelecida possui tempo de retransmissão muito grande. Para essa
situação o TCP foi modificado (TCP Reno) para implementar a retransmissão rápida. A
retransmissão rápida é disparada quando o remetente recebe três DUPACKs (ACKs
duplicados). Considerando que a rede conseguiu entregar os ACKs duplicados, o protocolo
então retransmite todos os segmentos possivelmente não recebidos conforme indicados pelos
ACKs recebidos. Recuperação rápida é executada após uma retransmissão rápida. Aquela é
executada da seguinte forma: primeiramente o valor de limiar (threshold) recebe a metade da
janela corrente (congwin / 2) e a janela corrente recebe o seguinte valor: congwin = threshold
+ 3 (a constante 3 reflete a possibilidade do envio seguro de três segmentos devido ao fato
que o remetente recebeu três ACKs duplicados). Se novas confirmações duplicadas chegam,
então a janela é incrementada por uma unidade, caso contrário, o TCP sai da fase de
recuperação rápida e entra na fase de prevenção de congestionamento atribuindo o valor de
limiar (threshold) para o valor da janela de congestionamento. Recuperação rápida impede
que a janela de congestionamento entre na fase de partida lenta, impedindo que o valor da
janela de congestionamento receba o valor um (1) (RFC 5681).
2.3 O uso do TCP nas redes sem fio
O projeto original e as melhorias ocorridas no TCP durante sua evolução foram
baseados apenas em redes com fio. Há grandes diferenças entre redes com fio e redes sem fio.
A Tabela 1 apresenta algumas dessas diferenças:
29
Tabela 1 - Comparação das características das redes cabeadas e redes sem fio
Redes cabeadas Redes sem fio
Alta largura de banda Largura de banda limitada
Mudanças na topologia física da rede ocorrem com pouca ou raríssima frequência
Topologia da rede dinâmica, ou seja, muda constantemente e de forma imprevisível
Baixa taxa de erro de transmissão (BER – Bit Error Rate)
Alta taxa de erro de transmissão (high BER)
A infraestrutura pode estar protegida fisicamente
Enlace exposto devido à utilização da atmosfera como meio de transmissão
O único obstáculo físico que pode ocorrer é a desconexão do fio
Qualidade do enlace variável devido a obstáculos físicos
Hosts estáticos Hosts móveis
Fonte de energia ilimitada (dependente da rede elétrica)
Hosts alimentados por bateria resultando em autonomia de funcionamento limitada
O principal problema de se usar TCP em redes sem fio é a forma com que ele trata a
perda de segmentos. Isso ocorre porque TCP foi projetado para presumir que há um
congestionamento na rede quando detecta seguidas perdas de segmentos. Dessa forma, o TCP
irá executar seu algoritmo de prevenção de congestionamento quando receber três vezes o
mesmo segmento de confirmação (DUPACKs) ou quando ocorrer timeouts de segmentos que
aguardam confirmação. Entretanto, perdas de segmentos em redes sem fio ocorrem com muita
frequência devido às suas características, como por exemplo, a ocorrência da mobilidade de
um determinado host ou perda da qualidade do sinal ocasionada por algum obstáculo
temporário (Sarkar, et al, 2008).
Enquanto o mecanismo de controle de congestionamento do TCP trabalha muito bem
em redes com fio, por reduzir a taxa de transmissão do remetente, aliviando assim o enlace,
esse mecanismo não funciona bem em redes sem fio. Falhas no enlace e rotas que se tornaram
inexistentes devido à mudança repentina da topologia dominam os fatores que causam perdas
de pacotes em redes sem fio (Boukerche, et al, 2009).
O TCP em sua forma original não possui mecanismos para distinguir, por exemplo,
entre congestionamento de rede e desvanecimento do sinal em um ambiente de redes sem fio.
Assim, nesses casos, TCP inicia desnecessariamente o seu mecanismo de controle de
congestionamento e reduz desnecessariamente a taxa de transferência do remetente. Isso
resulta em desperdício de largura de banda e redução de seu desempenho (Boukerche, et al,
2009). Os principais fatores para a degradação de desempenho resumidamente são:
30
• Alta taxa de erro de transmissão (BER – High Bit Error Rate): A transmissão do sinal
pelo ar está sujeita a degradação devido às condições climáticas, às interferências no sinal e
aos obstáculos.
• Mobilidade: Ocorrem frequentemente desconexões, muitas mudanças de rotas, podendo
implicar também em mudanças de endereços dos hosts.
• Imprevisibilidade: A variação natural da qualidade do sinal em redes sem fio dificulta
estimar corretamente valores para RTT (Round Trip Time – Tempo de ida e volta de uma
informação em uma dada conexão) e valores de timeouts.
• Disputa pelo canal: O uso de um canal compartilhado limita o acesso ao enlace por um
determinado nó, pois este nó concorre com todos os outros que estão ao alcance do sinal.
Quando uma rota falha, pacotes enviados armazenados nos buffers dos nós
intermediários são perdidos. Essa grande quantidade de pacotes perdidos é responsável pela
ocorrência de timeouts nos nós remetentes. Ao detectar timeouts, o TCP no remetente irá
disparar o mecanismo de controle de congestionamento, reduzindo o tamanho da janela.
Adicionalmente, o valor de RTO (Retransmission Timeout - tempo de retransmissão) será
dobrado.
Esses comportamentos causam no remetente dois efeitos colaterais: 1) depois que a
rota é estabelecida, o remetente, com valores de janela e limiar reduzidos, terá uma taxa de
transmissão bem inferior à taxa de transmissão real da rede naquele momento; 2) com o valor
de RTO dobrado, o remetente irá demorar para convergir para um RTO ideal.
Outro fator de degradação do TCP é sua interpretação errônea em confundir falhas no
enlace com congestionamento da rede. A qualidade do enlace em redes sem fio é
naturalmente instável, pois o canal sofre com interferências e deterioração do sinal de forma
intermitente e imprevisível.
A camada de enlace com seus mecanismos de recuperação do enlace não é capaz de
impedir perda de pacotes provenientes da camada de transporte. Exposto isso, o TCP
remetente poderá receber ACKs repetidos. Normalmente o recebimento de três DUPACKs
faz com que o TCP remetente interprete erroneamente um congestionamento de rede,
disparando seus algoritmos de retransmissão e recuperação rápidas de forma desnecessária.
O TCP não somente foi capaz de interconectar nós móveis com hosts de uma
infraestrutura fixa, como também possibilitou a construção de aplicações portáveis entre redes
com fio e redes sem fio (Boukerche, et al, 2009).
31
Muitos esforços em pesquisas estão sendo feitos com o objetivo de melhorar o
desempenho do TCP sobre redes sem fio em vez de se propor um novo protocolo.
Desses estudos, melhorias foram obtidas, porém, muitas dessas melhorias visavam
apenas a melhorar o TCP em um determinado contexto e não solucionavam todos os
problemas. Unir todas as soluções existentes é uma boa ideia, porém, nem todas são
compatíveis.
2.4 Considerações Finais
A arquitetura em camadas permitiu a compatibilidade e a interligação das redes de
computadores do mundo todo, possibilitando a viabilidade da Internet. Graças à arquitetura
em camadas, é possível que redes heterogêneas, utilizando equipamentos de diferentes
fornecedores, possam trocar informações. A portabilidade é garantida respeitando a
padronização e a utilização dos protocolos definidos em cada camada, possibilitando a
diminuição da complexidade do projeto.
Cada camada possui responsabilidades bem definidas. Nesse sentido, a camada de
transporte representa papel fundamental nessa arquitetura por ser responsável pela entrega
confiável da informação por meio de um canal não confiável.
O protocolo TCP é o protocolo da camada de transporte mais utilizado na Internet,
porém, seu amadurecimento ocorreu sobre enlaces cabeados que permitem negligenciar as
taxas de erros oriundas desse tipo de canal. Os enlaces sem fio trouxeram novas dificuldades
que não existiam nos enlaces cabeados, tais como: alta taxa de erros de transmissão,
obstáculos repentinos capazes de atenuar o sinal sem fio, mobilidade do nó e desconexões
frequentes, entre outros. Essas dificuldades não são suportadas pelo protocolo TCP sem que
causem diminuição de seu desempenho tendo em vista que os problemas típicos de
transmissão em redes sem fio não implicam congestionamento ao longo do caminho.
Ajustar o protocolo TCP para permitir que ele seja robusto diante dessas novas
dificuldades mantendo a semântica fim a fim proposta pela arquitetura em camadas tem sido
um grande desafio. No próximo tópico, são descritas algumas variações do TCP que foram
desenvolvidas para melhorar seu desempenho em redes sem fio e cabeadas.
32
3. Melhorias no TCP
Após descrição dos problemas enfrentados pelo TCP, neste tópico são descritas
algumas soluções que procuram melhorar a eficiência no controle de congestionamento deste
protocolo, seja em redes cabeadas ou redes sem fio. Os algoritmos são divididos da seguinte
maneira: algoritmos baseados na estimativa da largura de banda, algoritmos que usam
notificação explícita de falha no enlace, algoritmos que exploram a capacidade de
“bufferização” dos nós intermediários, algoritmos que dividem a conexão com o auxílio da
camada de enlace, o tópico apresenta também um novo protocolo para camada de transporte
para redes ad hoc.
3.1 Estratégias para melhorar o desempenho do TCP em
redes sem fio
Há algumas estratégias para adaptar o TCP para redes sem fio. A primeira estratégia é
fazer com que o TCP seja informado sobre o estado do enlace por meio de mecanismos de
apoio de protocolos subjacentes com o objetivo de diminuir o impacto causado pela
mobilidade. A segunda estratégia é usar a pilha de protocolos subjacentes ao TCP para lidar
com os problemas das redes sem fio, de forma que se torne transparente para o TCP todos os
problemas enfrentados pelas redes sem fio. A terceira estratégia é desenvolver um novo
protocolo capaz de se adaptar melhor em ambientes sem fio. Outra forma de fazer essa
classificação é apresentada por Elaarag (2009), conforme a Figura 4.
Figura 4 - Divisão entre as abordagens que melhoram o desempenho do TCP em redes móveis
(ELAARAG, 2009)
3
33
Os protocolos que atuam na camada de enlace (Link Layer Protocols) tentam
incrementar a qualidade do enlace, escondendo da camada de transporte as dificuldades que
por ventura surgirem. A ideia por trás dessa abordagem é adotar o seguinte lema: o problema
é causado por falha no enlace e deve ser tratado pela camada correspondente, ou seja, a
camada de enlace.
Os protocolos que mantêm a característica fim a fim do TCP adquirem habilidades
para tratar diretamente os problemas enfrentados pela rede sem fio. Todo o mecanismo de
controle é mantido na camada de transporte.
Por fim, estão os protocolos que dividem a conexão tentando isolar os problemas
relacionados à rede sem fio dos protocolos já existentes. Isso é feito com o auxílio de uma
estação base, isolando a conexão entre host fixo, que utiliza rede com fio, do host móvel, que
utiliza rede sem fio (Bourkerche, et al, 2009).
3.2 Algoritmos baseados na estimativa de largura de
banda
Como já descrito anteriormente, o mecanismo de controle de congestionamento do
TCP baseado em perda de pacotes não consegue ajustar de forma acurada uma taxa de envio
ideal quando trabalha sobre um enlace de rede sem fio.
Modificações na versão original do TCP foram propostas com o objetivo de tornar
mais eficiente seu mecanismo de controle de congestionamento. Diferentemente do TCP
original, que usa perda de pacotes para ajustar sua janela, novos esquemas tentam ajustar sua
janela de congestionamento baseados em estimativas de largura de banda. Esses esquemas
foram denominados como: TCP-Vegas (Brakmo e Peterson, 1995), TCP-Westwood (Casetti,
et al, 2002) e TCP-Jersey (Ansari e Tian, 2004).
3.2.1 TCP-Vegas
Esse esquema usa um mecanismo de controle de congestionamento baseado em taxa
de transferência. Essa variação, em relação ao protocolo original, usa uma técnica baseada em
monitorar a taxa de transferência da conexão para controlar a janela de congestionamento.
Esse monitoramento compara dois valores: velocidade de transferência esperada com a
velocidade de transferência atual de cada RTT. A velocidade de transferência esperada é
calculada em (1):
34
min(RTT)
atualjaneladaTamanho=adaênciaEsperDeTransferVelocidade
___
(1)
A velocidade de transferência atual é calculada em (2):
K)irmação(ACeceberConftempoParaR
segmento)f(TamanhoBytesTransQuantidade=ênciaAtualDeTransferVelocidade
_
(2)
Para um dado α < β, tem-se que:
• Se a diferença entre esses dois valores é menor que um dado α, TCP-Vegas
incrementa a janela de congestionamento de forma linear para o próximo RTT.
• Se a diferença entre esses dois valores é maior que um dado β, TCP-Vegas
decrementa linearmente a janela de congestionamento para o próximo RTT.
• Se a diferença entre esses dois valores está entre α e β, o TCP-Vegas não altera a
janela de congestionamento.
O TCP-Vegas incrementa ou decrementa a janela de congestionamento de forma
linear. Essa alteração no tamanho da janela só ocorre quando há um RTT que fica fora da
faixa de tolerância estabelecida pelos valores α e β.
As vantagens e desvantagens desse modelo são as seguintes:
• Vantagens: O crescimento exponencial da janela de congestionamento usado pelo
mecanismo de partida lenta do TCP original usualmente causa perda de pacotes, o esquema
TCP-Vegas impede essa perda de pacotes durante a fase de partida lenta. Essa melhoria se dá
pelo fato de que o TCP-Vegas somente aumenta exponencialmente a janela de
congestionamento após avaliar cada RTT (RTT esperado com RTT medido). Outra vantagem
está no fato que o TCP-Vegas preserva a semântica fim a fim do TCP (Boukerche, et al,
2009).
• Desvantagens: TCP-Vegas também herda do TCP original muitas fraquezas quando
aplicado em redes sem fio. Esse esquema é incapaz de manipular os efeitos causados por falha
nas rotas e erros no enlace em tais redes. Por exemplo, uma simples alteração de rota em uma
conexão causa a invalidação do RTT base, o qual é usado pelo TCP-Vegas para calcular a
taxa de transferência esperada, ou seja, o protocolo trabalhará com valores incorretos para a
nova rota (Anantharam, et al, 1999).
35
3.2.2 TCP-Westwood
O TCP-Westwood é baseado na medição da taxa de transferência da conexão. A
principal ideia do TCP-Westwood é ficar monitorando a taxa média de transferência de uma
dada conexão e usar essa informação para auxiliar na tomada de decisões quando perdas de
pacotes ocorrem.
A taxa média de transferência é alcançada usando o tempo de retorno de segmentos
ACKs. Depois de uma indicação de perda de pacotes, que pode ser devido a qualquer erro de
enlace ou congestionamento na rede, o remetente usa a taxa de transferência estimada
disponível para definir corretamente a janela de congestionamento e o limiar (threshold) de
partida lenta.
As vantagens e desvantagens são as seguintes:
• Vantagens: É um protocolo robusto para lidar com erros em redes sem fio, porque ele
impede uma redução excessiva da taxa de envio por causa de perdas de pacotes causados por
erros em vez de causa ser congestionamento na rede. Esse esquema mantém a semântica fim a
fim do TCP.
• Desvantagens: Não lida explicitamente com falhas de rotas em redes sem fio. Quando
uma falha de rota ocorre, a taxa de transferência estimada tende a se tornar zero. Isso leva o
protocolo a ter um desempenho fraco quando novas rotas são estabelecidas. Semelhante ao
TCP-Vegas, o TCP-WestWood também usa um valor de RTTmin para estimar sua taxa de
transferência esperada. Nesse caso, se houver uma mudança de rota, o valor de RTTmin se
tornará inválido e a estimativa da taxa de transferência também será inválida (Bourkerche, et
al, 2009).
3.2.3 TCP-Jersey
Essa modificação do TCP pode ser considerada como uma extensão da variante TCP-
Westwood. A versão TCP-Jersey além de utilizar estimativa de taxa de transferência esperada
também utiliza notificação explícita proveniente dos nós intermediários para distinguir se as
perdas de pacotes são causadas por problemas na rede sem fio ou se realmente há um
congestionamento na rede (Bourkerche, et al, 2009).
36
A forma que a variante TCP-Jersey utiliza para medir a taxa de transferência de uma
conexão é a mesma utilizada na variante TCP-Westwood (por meio do recebimento de
ACKs), porém há uma diferença em relação ao TCP-Jersey, pois essa variante utiliza essa
estimativa somente com o auxílio de um sinal explícito de congestionamento (Ansari, et al,
2004).
Além de estimar a largura de banda disponível, a variante TCP-Jersey recebe um sinal
denominado aviso de congestionamento (CW – Congestion Warning) vindo de “roteadores”
intermediários, os quais auxiliam o remetente a distinguir entre perdas de pacotes causados
por congestionamento na rede ou por dificuldades enfrentadas pelo canal sem fio.
Quando um nó de uma rede sem fio está atuando como roteador de pacotes, ou seja,
está fazendo o papel de encaminhar pacotes de dados para um destinatário, esse nó deve
garantir o encaminhamento. Supondo que o nó roteador receba um novo pacote para um
determinado destinatário sem ter conseguido entregar o pacote anterior, o nó roteador deverá
enfileirar em um buffer os pacotes que ele ainda não conseguiu entregar ao destinatário.
A variante TCP-Jersey monitora o buffer de pacotes que ainda não foram entregues
nos nós que atuam como roteadores de uma rede sem fio e, caso esse buffer alcance um
determinado limiar, esse nó então marca a flag CW (Congestion Warning) em todos os
pacotes que passarem por ele enquanto a utilização de seu buffer permanecer acima do limiar.
Dessa forma, quando um remetente recebe um segmento ACK com a flag CW marcada, ele
toma ciência de que a rede está enfrentando um congestionamento. Por outro lado, quando o
remetente recebe repetidos ACKs (DUPACKs) com a flag CW desmarcada, é assumido que
perdas de pacotes foram ocasionadas por problemas no canal de rede sem fio.
As vantagens e desvantagens são as seguintes:
• Vantagens: TCP-Jersey possui os mesmos pontos fortes da variante TCP-Westwood pelo
fato de ambos usarem a ideia de estimar a taxa de transferência esperada (largura de banda).
Entretanto, o TCP-Jersey, em alguns casos, tem desempenho superior ao da variante TCP-
Westwood. Isso se dá pelo fato de que o TCP-Jersey usa congestionamento explícito por meio
de avisos de nós intermediários para notificar o remetente de possíveis congestionamentos na
rede, utilizando o mecanismo de controle de congestionamento somente quando recebe ACKs
(ou DUPACKs) com a flag CW marcada, assim ele pode proativamente evitar o
congestionamento mais rapidamente. Além disso, o TCP-Jersey estima a taxa de transferência
esperada de forma mais robusta, pois ele, diferentemente do TCP-Westwood, não utiliza um
RTTmin. Devido a esse fato sua estimativa de taxa de transferência (largura de banda) não é
diretamente afetada pelas mudanças de rota (Boukerche, et al, 2009).
37
• Desvantagens: Como ponto fraco, o TCP-Jersey, assim como o TCP tradicional, não tem
um mecanismo para manipular os efeitos quando rotas falham. Outro ponto fraco está na
dificuldade de usá-lo, uma vez que conta com a colaboração de muitos nós na rede
(Boukerche, et al, 2009). Outra desvantagem está no fato que esse esquema não mantém a
semântica fim a fim do TCP, pois conta com auxílio de outros nós da rede.
3.3 Algoritmos que usam notificação explícita de falha no
enlace
Corroborando os esforços para melhorar o TCP convencional, são apresentadas duas
novas abordagens denominadas ELFN – Explicit Link Failure Notification (Bharghaan, et al,
2000) e ADTCP (TCP-Friendly Transport Protocol for Ad Hoc Wireless Networks) (Fu, et al,
2002).
3.3.1 Notificação Explícita de Falha no Enlace (ELFN)
É um esquema que auxilia o TCP remetente a distinguir entre perdas de pacotes
causadas por falhas no enlace e perdas de pacotes causadas por congestionamento da rede.
Em uma rede sem fio, quando uma falha no enlace ocorre em um nó cujo papel é o de
retransmitir pacotes de um remetente para um destinatário, esse nó irá enviar ao remetente
uma mensagem ICMP (Internet Control Message Protocol) do tipo 3 código 1 (“host
inalcançável”). O TCP remetente, após receber essa mensagem, desabilita todos seus
temporizadores de retransmissão e entra em estado de dormência (“standby”) (Romanowicz,
2008). O TCP remetente, em estado de dormência, envia mensagens periódicas a fim de
sondar se a rota foi restabelecida. O TCP, ainda em estado de dormência, ao receber uma
resposta positiva, ou seja, ao receber um ACK referente a alguma mensagem de sondagem
(implicando no restabelecimento da rota), restaura seus temporizadores ao estado anterior ao
da falha. Dessa maneira, o TCP remetente impede que ele entre na fase de partida lenta.
As vantagens e desvantagens são as seguintes:
• Vantagens: Esse esquema simples e eficiente melhora o desempenho do TCP quando
usado em redes sem fio. ELFN previne que o TCP remetente dispare o seu mecanismo de
controle de congestionamento desnecessariamente quando há uma falha no enlace. Além
disso, o mecanismo, utilizando mensagens periódicas que fazem a sondagem para saber se o
enlace foi restabelecido, contribui consideravelmente para impedir que a largura de banda seja
desperdiçada na fase de restabelecimento do enlace (Romanowicz, 2008).
38
• Desvantagens: ELFN depende do auxílio de nós intermediários para que o TCP
remetente seja notificado sobre falhas no enlace, e esse aspecto dificulta sua implementação e
uso. Além disso, pelo fato do TCP remetente usar informações de estado anterior à falha no
enlace para voltar a transmitir, esses valores podem não ser apropriados, visto que o estado
atual do enlace restabelecido pode não ser condizente com o estado anterior (estado antes da
falha no enlace). Outro problema está no fato de que somente o TCP remetente que recebeu a
mensagem ICMP é notificado da falha no enlace, isto é, todos os outros TCP remetentes que
estão usando o mesmo enlace não são notificados (Boukerche, et al, 2009).
3.3.2 ADTCP
O ADTCP é uma versão modificada do TCP NewReno para redes móveis ad hoc. É
um esquema fim a fim que usa múltiplas métricas para determinar a causa de perda de
pacotes, permitindo que o TCP reaja apropriadamente. O ADTCP divide uma conexão em
quatro estados: congestionamento, erro no enlace, mudança de rota e desconexão.
Classificando uma determinada conexão dessa forma, o protocolo impede a execução
errônea do mecanismo de controle de congestionamento. O ADTCP usa várias métricas para
identificar corretamente qual é a razão que está motivando a perda de segmentos:
• Diferença de tempo entre pacotes (IDD - Interpacket Delay Difference): calcula o
tempo entre a chegada de pacotes consecutivos.
• Vazão em um determinado intervalo (STT - Short-Term Throughput): calcula qual é a
capacidade de transferência de dados da conexão em um determinado tempo de observação.
• Taxa de entrega de pacotes fora da ordem (POR - Packet Out-of-order Delivery
Ratio): é a taxa de recebimento do número de pacotes fora da ordem em relação ao número de
pacotes recebidos durante um pequeno intervalo de observação.
• Taxa de perda de pacotes (PLR - Packet Loss Ratio): é a taxa do número de pacotes
perdidos dentro da janela de recebimento durante um pequeno intervalo de observação.
O mais importante é que essas métricas podem ser obtidas sem a necessidade do
auxílio de nós intermediários, ou seja, o protocolo ADTCP mantém a característica fim a fim
do TCP original.
As vantagens e desvantagens são as seguintes:
39
• Vantagens: Melhora o desempenho do TCP identificando o estado corrente da conexão e
reagindo de forma apropriada a perdas de pacotes. Além disso, o ADTCP não depende de
feedback de nós intermediários (Fu, et al, 2002).
• Desvantagens: Para que o ADTCP possa calcular o IDD, é necessário armazenar
temporariamente informações sobre os segmentos que foram enviados causando um overhead
no protocolo do nó remetente. Além disso, para que ADTCP possa trabalhar de maneira
eficiente, faz-se necessário um cálculo cuidadoso para a definição de valores de limiar para
que se possa definir quais valores podem ser considerados altos ou baixos para as métricas
utilizadas (Boukerche, et al, 2009).
3.4 Algoritmos que evitam a retransmissão desnecessária
de segmentos
Retransmissão desnecessária de segmentos é uma consequência da incapacidade do
TCP em tolerar e lidar com picos repentinos de atraso. Esses picos súbitos causam timeouts
nos temporizadores da janela de envio do TCP remetente, ocasionando desnecessariamente a
retransmissão dos segmentos.
Esse comportamento faz com que o TCP remetente também altere
desnecessariamente os valores de seus temporizadores, tamanho da janela, e valor do limiar
(Boukerche, et al, 2009). Para tentar tratar esse problema, uma solução denominada TCP-
EIFEL (Ludwig e Katz, 2000) é apresentada.
3.4.1 TCP-EIFEL
O protocolo TCP-EIFEL é uma técnica especialmente projetada para detectar e
manipular retransmissão desnecessária de segmentos. Sua implementação baseia-se na
utilização de um valor chamado timestamp, o qual é colocado no campo opção do segmento
TCP.
Segundo os autores, foi necessário somente o acréscimo de menos de 20 novas linhas
de código para alterar a versão original no TCP remetente. Não há necessidade de alterações
no código TCP receptor nem em qualquer outro protocolo (Ludwig e Katz, 2000).
Seu funcionamento se dá da seguinte forma: a cada segmento transmitido, o TCP
remetente inclui um valor contendo o momento (timestamp) em que o segmento foi
transmitido. Esse valor é mandado de volta pelo destinatário, desde que não haja uma
40
alteração do cabeçalho do segmento original. O remetente também registra o momento da
primeira retransmissão. Quando um ACK reconhecendo um segmento recentemente
retransmitido chega ao remetente, o remetente pode comparar o timestamp do ACK com o
tempo registrado, podendo assim determinar se a retransmissão foi realmente necessária ou
não.
Se o timestamp do ACK é menor que o valor do timestamp da retransmissão do
segmento, significa que o ACK recebido refere-se ao segmento transmitido e não ao da sua
retransmissão. Para o TCP-EIFEL essa ocorrência significa retransmissão desnecessária.
Se houve uma retransmissão desnecessária, então o TCP remetente irá restaurar os
valores do tamanho da janela (congwin) e do limiar (threshold) para valores anteriores ao da
retransmissão.
Se mais de uma retransmissão foi realizada, o valor de limiar (threshold) é reduzido
pela metade. Se exatamente duas retransmissões foram realizadas, o tamanho da janela
(congwin) é definido com o mesmo valor de limiar (threshold) (que tinha sido reduzido para
metade anteriormente). Se mais de duas retransmissões foram realizadas, o tamanho da janela
de congestionamento (congwin) é definido com o valor um.
As vantagens e desvantagens são as seguintes:
• Vantagens: É robusto no reconhecimento de picos de timeouts. Ele identifica
retransmissões desnecessárias e evita retransmitir pacotes que tiveram seus ACKs retardados,
evitando assim uma interpretação errônea de que foram perdidos. Ele também preserva a
semântica fim a fim do TCP original (Ludwig e Katz, 2000).
• Desvantagens: Requer o armazenamento do momento (timestamp) de cada pacote
transmitido, causando modificações no cabeçalho TCP para permitir a detecção de falsas
retransmissões. Memória e processamento extras são necessários para armazenar o momento
(timestamp) de cada pacote transmitido e ainda não confirmado (Boukerche, et al, 2009).
3.5 Algoritmos que exploram a capacidade de
“bufferização” dos nós intermediários
No TCP convencional, falhas nas rotas podem degradar muito o desempenho das
transmissões que passam por essas rotas. Por exemplo, quando ocorre uma falha na rota,
muitos dos pacotes transmitidos e ainda não entregues são perdidos ou sofrem grandes atrasos
pelos nós intermediários, sendo necessário retransmiti-los.
41
Para resolver esse problema, alguns esquemas foram construídos para explorar a
capacidade de “bufferização (armazenamento)” dos nós intermediários e melhorar o
desempenho do TCP convencional. Dentre esses esquemas estão SPLIT-TCP (Faloutsos, et
al, 2002) e TCP-BUS (Choi, et al, 2001).
3.5.1 SPLIT-TCP
Quando uma conexão TCP é estabelecida em uma rede sem fio, poderá haver certos
nós ao longo da rota que funcionarão como proxies da conexão. Esses proxies devem
assegurar que os pacotes oriundos do remetente sejam entregues até o próximo proxy ou até o
destinatário.
Uma maneira de visualizar essa situação é olhar para esta conexão TCP como um
conjunto de pequenas conexões TCP entre os nós que formam a rota entre remetente e
destinatário. Cada uma dessas pequenas conexões tem seu próprio mecanismo local de
controle de congestionamento, controle de taxa de transferência e asseguram a confiabilidade
ao entregar segmentos ao próximo proxy. As vantagens e desvantagens são as seguintes:
• Vantagens: Com o esquema SPLIT-TCP, a “bufferização” de pacotes nos nós
intermediários (proxies) permite que qualquer pacote perdido durante a transmissão entre
remetente e destinatário seja feito pelo nó intermediário que recebeu o pacote mais
recentemente, ou seja, pelo nó intermediário que não conseguiu entregar o pacote.
• Desvantagens: Essa solução apresenta um alto custo em relação ao TCP convencional
devido ao fato que cada nó intermediário que integra a rota entre remetente e destinatário
deverá ter uma grande capacidade em seu buffer, o qual é responsável por armazenar os
segmentos ainda não confirmados. Outra grande dificuldade está no fato que os nós
intermediários deverão compartilhar o estado da janela de congestionamento com o nó
remetente (Boukerche, et al, 2009). SPLIT-TCP não preserva a semântica fim a fim do TCP
original.
3.5.2 TCP-BUS
O esquema TCP-BUS (Choi, 2001) define duas mensagens: Notificação Explícita de
Desconexão de Rota (ERDN - Explicit Route Disconnection Notification) e Notificação
Explícita de Restabelecimento de Rota (ERSN - Explicit Route Successful Notification).
42
Quando há uma falha na rota, uma mensagem do tipo ERDN é propagada pelos nós
intermediários até o remetente para avisar que uma falha na rota ocorreu.
Durante esse processo todas as transmissões ao longo da rota são notificadas para
parar. O remetente também para de transmitir e congela o seu estado atual. Quando uma
mensagem do tipo ERSN é recebida, o remetente continua suas operações. A camada de rede
é a responsável por notificar o remetente sobre o estado da rota.
Quando uma falha na rota ocorre, os segmentos que estão “flutuando” na conexão, ou
seja, estão entre o remetente e o destinatário, são armazenados no buffer do nó intermediário
que sofreu uma falha no enlace. Consequentemente, o valor do timeout de retransmissão
desses pacotes “bufferizados” é dobrado no remetente.
As vantagens e desvantagens são as seguintes:
• Vantagens: O uso de mensagens explícitas de desconexão e de restabelecimento de rota
permite que o remetente reaja a esses eventos de forma mais rápida e eficaz. Como o
remetente tem conhecimento que os segmentos que foram transmitidos estão armazenados em
um nó intermediário da rota, ele irá definir valores maiores de timeouts para cada
retransmissão, o que pode potencialmente reduzir retransmissões desnecessárias (Choi, 2001).
• Desvantagens: O uso de notificação explícita requer o auxílio dos nós intermediários,
tornando complexo seu emprego e sua implementação. Além do mais, TCP-BUS requer a
alteração do protocolo da camada de roteamento para lidar com suas operações e tem
problemas de escalabilidade porque necessita de um nó intermediário para armazenar os
pacotes e os estados dos diferentes fluxos que passam por eles (Boukerche, et al, 2009).
3.6 Algoritmos que dividem a conexão com o auxílio da
camada de enlace
A Figura 5 representa o cenário de uma topologia de rede em que um host fixo se
comunica com um host móvel por meio de uma estação base. Nesse esquema é possível
melhorar o desempenho do TCP utilizando o auxílio da camada de enlace. O esquema TCP-
ECN (Floyd, 1998) é apresentado para este cenário.
43
Figura 5 - Divisão de uma conexão
Para o cenário apresentado, Jacobson e Stevens propuseram uma melhoria no
desempenho do TCP, mais precisamente em sua versão denominada TCP-RENO, a qual passa
a ser auxiliada pela camada de enlace.
Não há mudanças nos hosts fixos, apenas nos hosts móveis e estações bases. A
mudança se dá adicionando um bit na estrutura do formato do segmento do TCP, denominado
bit ECN – Explicit Congestion Network, o qual é utilizado para distinguir entre
congestionamento e perda do enlace.
Há um aproveitamento da tecnologia existente, pois muitos dispositivos móveis usam
protocolos da camada de enlace, a qual fornece retransmissões locais e recuperação de erros
na conexão. Essa característica torna as retransmissões de segmentos do TCP na camada de
transporte um processo redundante. Em ambientes ruidosos, como em redes sem fio, a
camada de enlace pode utilizar transmissão confiável com o uso de números de sequência e
confirmações (Tanenbaum, 2003).
Uma dessas soluções propôs que as estações base descartassem os reconhecimentos
duplicados (DUPACKs). Essa solução causava overhead como efeito colateral. Outra solução
propôs que as confirmações repetidas (DUPACKs) fossem atrasadas. No entanto, decidir
sobre a duração de atraso é um problema complexo.
A vantagem de se adotar essa abordagem está na possibilidade de manter a
responsabilidade em identificar e corrigir o problema em uma estação base, o que garante que
o TCP não sofra nenhuma alteração, isso ajuda a manter compatibilidade com a tecnologia já
existente.
As desvantagens surgem diante das necessidades de adicionar “inteligência” e
capacidade de memória utilizada nos buffers nas estações base. Essa memória é utilizada para
manter os estados das conexões gerenciadas pela estação base. A capacidade de
armazenamento dessa memória torna-se um fator limitador para que novas conexões sejam
aceitas.
Com base nessa abordagem, uma nova variante TCP foi desenvolvida, denominada
TCP-ECN. Ela se baseia na recuperação da camada de enlace local. Utiliza como conceito de
44
projeto um bit denominado ECN que ajuda o host móvel a diferenciar entre congestionamento
e perda do enlace. A variante TCP-SNOOP também implementa esse conceito.
A estação base mantém uma lista de números de sequência de segmentos referentes às
conexões gerenciadas por ela. A estação base é a ponte de ligação entre o host fixo e o host
móvel. Sua tarefa é “esconder” do host fixo as dificuldades enfrentadas pelo host móvel ao
utilizar o enlace sem fio. Ela também “esconde” do host móvel as dificuldades enfrentadas
pelo host fixo e causadas pelo enlace cabeado.
Ao detectar uma falha no enlace sem fio, a estação base enviará para o host fixo um
segmento contendo um tamanho de janela de recepção com tamanho zero, isso faz com que o
host fixo pare de transmitir. A estação base ao detectar que host móvel voltou a se conectar
“descongela” o host fixo, o qual volta a transmitir dados.
Monitorando os segmentos de uma dada conexão, a estação base é capaz de identificar
quando o enlace cabeado está congestionado. Ao fazer essa detecção, a estação base envia
para o host móvel um segmento com o bit ECN ativado. O host móvel ao receber esse
segmento retém os segmentos de confirmação repetidos (DUPACKS). Esse comportamento
impede que o host fixo dispare seu mecanismo de recuperação rápida desnecessariamente.
Quando o host móvel se conecta em uma nova estação base, ela é atualizada com o
auxílio de um agente denominado “Home and foreing Mobile IP”, o qual envia uma lista de
número de sequência e poucos segmentos “bufferizados” que pertenciam à estação base
antiga.
Esse controle de fluxo assistido pela estação base melhora o desempenho da rede, pois
esta abordagem impede antecipadamente que a vazão seja degradada, pois a situação
alcançada só seria tomada posteriormente, quando os hosts identificassem por si só a perda da
conexão ou um congestionamento no canal.
A estação base controla os segmentos de confirmação das conexões que ela gerencia.
Para fazer isso ela verifica o número de sequência do ACK que acabou de receber,
analisando-o para saber se ele pertence a uma de suas conexões gerenciadas. Em caso
afirmativo, a estação base então verifica se este ACK é repetido, se isso ocorrer, a estação
base descarta o ACK. Quando o ACK não é repetido, então a estação base atualiza sua base
de conhecimento, descartando os ACKs mais antigos valendo-se da propriedade do TCP de
reconhecimento cumulativo.
Por outro lado, se o bit ECN está “setado”, então o host móvel envia os ACKs
repetidos para o host fixo, considerando que a perda ocorreu na rede com fio.
Os resultados alcançados pelo TCP-ECN tiveram um resultado superior aos da versão
TCP-RENO e TCP-RENO com SNOOP, conforme dados dos autores.
45
O desempenho superior se manteve mesmo quando a taxa de erro de transmissão em
uma rede sem fio aumentava e quando a taxa de perda por congestionamento aumentava
(Floyd, et al, 2001).
3.7 Um novo protocolo para a camada de transporte para
redes ad hoc
Um novo protocolo da camada de transporte foi projetado para ser utilizado em redes
ad hoc sem fio. O protocolo, denominado ATP (Ad hoc Transport Protocol), foi proposto por
SUNDARESAN et al, (2003). Sua construção não foi baseada no TCP, apresentando
desempenho superior a todos os esquemas e melhoramentos já feitos sobre o TCP
convencional quando utilizados em redes ad hoc (Boukerche, et al, 2009). Seu funcionamento
se dá pelos seguintes aspectos:
• Coordenação entre camadas: ATP usa informação da camada inferior e feedbacks
explícitos vindos de nós intermediários que auxiliam as operações da camada de transporte.
Essas informações incluem:
� Taxa inicial de feedback usada para início rápido;
� Taxa regular baseada em feedbacks vindos de nós intermediários para controlar a
taxa de transferência;
� Notificação explícita de falha no caminho, utilizada para detecção de falhas na
rota;
� Transmissões baseadas em taxas, que são constantemente medidas, em vez de
utilizar transmissão baseadas em janelas.
• Separação do controle de congestionamento da confiabilidade: Ao contrário do que
faz o TCP convencional, ATP separa o controle de congestionamento da confiabilidade
(entrega confiável). ATP não requer a chegada de pacotes de reconhecimento (ACKs), porém,
depende de um feedback da rede para executar o seu controle de congestionamento. Para
garantir a confiabilidade, o ATP não emprega reconhecimento cumulativo, pelo contrário, ele
conta somente com o uso de reconhecimento seletivo (SACK), o qual é periodicamente
enviado pelo destinatário para identificar pacotes perdidos.
• Controle de congestionamento assistido: ATP requer que cada nó intermediário da
conexão mantenha duas informações. A primeira informação, denominada Qt, é a média de
46
atraso na fila experimentado pelos pacotes que atravessaram aquele nó. A segunda informação
é a média de atraso de transmissão, denominada Tt, experimentada pelo pacote chamado de
head-of-line que atravessou aquele nó. Qt está relacionado com a “disputa” entre os pacotes
pertencentes a fluxos diferentes no mesmo nó (nó local congestionado). Tt está relacionado
com a “disputa” entre pacotes no vizinho do nó (nós vizinhos congestionados). Cada nó
possui um valor Qt e Tt, assim, ao somar Qt + Tt, o maior valor dentre os nós é enviado para
frente até chegar ao destinatário. O destinatário, de posse do maior valor (Qt + Tt), envia essa
informação de volta para o remetente. O remetente então usa essa informação para controlar
sua taxa de transmissão.
As vantagens e desvantagens são as seguintes:
• Vantagens: O ATP torna-se bem adequado para redes ad hoc sem fio, pois ao usar
feedbacks dos nós intermediários, consegue identificar os gargalos de banda no caminho de
envio até o destinatário, identificando a taxa de transmissão máxima com precisão, isso tudo
sem depender da largura de banda do caminho inverso. Essa abordagem está em contraste
com as estimativas de banda utilizadas pelos esquemas TCP-Westwood, TCP-Vegas e TCP-
Jersey, as quais, de certa forma, implicitamente são afetadas pela disponibilidade da banda no
caminho reverso (chegada de ACKs). Outra vantagem proporcionada pelo uso de feedbacks
baseados na estimativa da taxa é que o ATP não exige a chegada de ACKs (confirmação de
recebimento de pacotes pelo destinatário), portanto, tornando-se mais robusto em relação à
perdas de segmentos de confirmação e reduzindo a sobrecarga de tráfego causada pelos
pacotes ACKs no caminho inverso. A utilização de reconhecimento seletivo (SACK) pelo
ATP também permite a recuperação de mais de um segmento de cada vez, portanto, é mais
eficiente e robusto em ambientes com alta taxa de perda de dados. Outra vantagem é que
durante a sondagem para se calcular a taxa de transferência de dados, o remetente pode se
recuperar de forma rápida quando há uma alteração na rota. Outra grande vantagem é que
utilizando apenas um RTT, o ATP consegue utilizar o máximo de banda disponível já no
início da conexão, ou seja, quando ela é estabelecida (Boukerche, et al, 2009).
• Desvantagens: O ATP torna-se difícil de implementar e de ser aplicado, pois depende da
cooperação de nós intermediários e do auxílio da camada inferior para executar suas
operações. Devido à sua incompatibilidade com o TCP, muitas aplicações existentes que
foram originalmente construídas sobre o TCP não funcionarão sobre o ATP caso não haja
modificações extensas. Outra desvantagem do ATP está no tempo em que ele pode detectar e
se recuperar de pacotes perdidos, pois esse tempo pode ser inaceitável, já que dependendo de
47
confirmações seletivas pelo destinatário, essas confirmações poderão demorar (a cada um
segundo por padrão) (Boukerche, et al, 2009).
3.8 Considerações Finais
Neste tópico foram apresentadas algumas soluções desenvolvidas para melhorar o
desempenho do TCP quando utilizado sobre enlaces sem fio e redes ad hoc.
Acredita-se que o emprego de soluções que dependam do auxílio de outras camadas
ou de nós intermediários deve ser desencorajado por quebrarem a semântica fim a fim. Essa
dependência pode prejudicar a evolução das redes de computadores, pois se determinada
camada se tornar dependente de outra, futuras alterações em sua tecnologia ou estrutura
necessariamente provocarão alterações na camada dependente. Essa dependência entre as
camadas poderá prejudicar a escalabilidade das redes, qualidade essa responsável por
proporcionar a criação e manutenção da Internet.
Dentre as soluções que preservam a semântica fim a fim, observa-se que algumas são
intercambiáveis podendo ser empregadas simultaneamente em uma única variante, como por
exemplo, TCP-EIFEL e TCP-Westwood, tornado o TCP mais robusto.
É importante ressaltar que este tópico, ao mostrar algumas soluções, não esgotou todas
as soluções existentes.
No próximo tópico são mostradas algumas experiências realizadas em uma rede de
abrangência territorial nacional composta por enlaces heterogêneos (cabo, satélite, rádio, wifi)
objetivando mensurar a qualidade da transmissão oferecida por esses enlaces. Os dados
obtidos ao realizar essas experiências serviram como parâmetro para utilização em futuras
simulações.
48
4. Avaliação Empírica da Confiabilidade
do Enlace sem Fio
A grande demanda por serviços oferecidos pela Internet (e-mail, informações, redes
sociais) viabiliza sua onipresença. Os grandes atrativos para os usuários optarem por conectar
seus equipamentos por intermédio das redes sem fio são a preservação da mobilidade, e a não
necessidade de criação de uma infraestrutura, evitando a passagem de cabos por paredes e
canaletas.
Algumas desvantagens devem ser consideradas, como por exemplo, a segurança e a
baixa qualidade do serviço. A segurança é prejudicada, pois um sinal de rede sem fio é mais
suscetível à interceptação. A baixa qualidade do serviço é devida à alta taxa de erros
ocasionada por interferências no canal.
Entretanto, apesar das desvantagens, os usuários têm demonstrado uma grande
aceitação por essa tecnologia. Segundo a Wi-Fi Alliance (2011) – organização formada pelos
fabricantes de equipamentos, a qual é responsável por certificar produtos para utilizar o
padrão 802.11, a taxa de certificações de produtos tem aumentado exponencialmente desde
que a organização foi criada e isso reflete a importância da tecnologia Wi-Fi no mundo
conectado. Apesar de ter demorado oito anos para alcançar o marco de 5.000 certificações,
mais de 2.000 certificações foram concedidas somente em 2010.
Locais públicos com abrangência setorial ou até mesmo metropolitana poderão prover
conectividade por meio do padrão 802.11 (Carvalio, 2010). O baixo custo e a baixa
complexidade de instalação fazem com que as redes WLAN sejam uma alternativa atraente de
infraestrutura sem fio, sendo utilizada em diversos locais empresariais, comerciais ou
residenciais (Carvalio, 2010). O crescimento das redes Wi-Fi pode ser visualizado na Figura
6.
4
49
Figura 6 - Redes Wi-Fi detectadas na cidade de Illinois em Chicago USA. (WIGLE, 2012)
A popularização das redes sem fio tem exigido das tecnologias empregadas na
Internet uma rápida adaptação, quando não, essas tecnologias acabam sendo empregadas sem
qualquer tipo de ajuste ou adaptação.
Mensurar o quanto o enlace sem fio degrada o desempenho do TCP é de fundamental
importância no sentido de auxiliar a pesquisa em busca de soluções, principalmente quando as
soluções propostas são primeiramente testadas em ambientes simulados.
Nesse sentido, as seções seguintes apresentam os resultados de testes realizados em
diversos cenários reais que utilizam tecnologias sem fio como meio de transmissão, visando
mensurar a confiabilidade dessas tecnologias.
50
4.1 Motivação para realização dos experimentos
A tentativa de solucionar problemas dando enfoque somente a uma das camadas,
quando se estuda as redes de computadores, leva o pesquisador a não considerar a evolução
das outras camadas, podendo deixar a impressão que elas estão estagnadas tecnologicamente.
Esse pensamento parecer injusto, pois ao mesmo tempo em que pesquisas são
realizadas visando à melhoria de uma determinada camada, concorrentemente outras
pesquisas são realizadas em outras camadas, seja aperfeiçoando-as ou adaptando-as para
novas tecnologias que surgem.
É de se considerar que o benefício alcançado por uma camada notadamente é refletido
para outras camadas. Por exemplo, a melhoria de desempenho de protocolos responsáveis
pelo roteamento de pacotes na camada de rede, inevitavelmente proporcionará um benefício
para todas as outras camadas.
Sem dúvida, as tecnologias utilizadas nas camadas abaixo da camada de transporte
foram e estão sendo melhoradas. Necessário saber sobre quais condições estão operando os
protocolos da camada de transporte quando utilizam as tecnologias dessas camadas inferiores.
Foram realizados experimentos em cenários de redes reais, objetivando mensurar as reais
condições proporcionadas por esses enlaces. Dessa forma, é possível ter uma ideia geral da
qualidade desses enlaces, nos dias atuais, em algumas infraestruturas reais.
4.2 Ferramenta utilizada
Para subsidiar esses experimentos foi desenvolvida uma ferramenta composta de dois
programas denominados ClienteUDP e ServidorUDP, ambos desenvolvidas na linguagem
Java, cujos códigos fontes encontram-se no Apêndice A. Suas funcionalidades se resumem na
transferência de uma rajada de 1000 datagramas do servidor para o cliente, cada qual
contendo 500 bytes, com intervalo de 10 milissegundos entre o envio de um e outro. Ao final
da transferência dos 1000 datagramas, o programa ClienteUDP contabiliza o número de
datagramas recebidos. Com base nesse resultado, avaliou-se a confiabilidade do enlace sobre
o qual foram realizados os experimentos.
O protocolo de transferência de dados utilizado na camada de transporte foi o UDP. O
UDP é um protocolo da camada de transporte não orientado a conexão que além das funções
de multiplexação/demultiplexação e verificação de erros, não acrescenta nenhuma outra
funcionalidade às camadas superior e inferior. A aplicação ao escolher o protocolo UDP está
“falando” quase diretamente com o protocolo IP (Kurose e Ross, 2010).
51
A transferência de dados utilizando o protocolo UDP fará com que a aplicação
transmissora fique sujeita à confiabilidade das camadas inferiores de rede, uma vez que o
protocolo UDP não possui nenhum mecanismo de confiabilidade que garanta a entrega
confiável dos dados. Dessa forma, é possível mensurar a confiabilidade do enlace.
4.3 Primeiro experimento
O primeiro experimento foi realizado em um único microcomputador, ou seja, os
programas ClienteUDP e ServidorUDP (códigos fontes no Apêndice A) foram instanciados
no mesmo host. Ambos os programas utilizaram como enlace os buffers do sistema
operacional. O intervalo de 10 milissegundos utilizado para cada transferência de um novo
datagrama evitou a ocorrência de buffer overflow. A escolha desse cenário foi motivada por
ele ser um ambiente controlado, dessa forma, esperou-se uma confiabilidade do enlace de
100%. Os resultados desse primeiro experimento podem ser observados na Tabela 2.
Tabela 2 - Resultados obtidos ao transferir dados utilizando como enlace os buffers do Sistema
Operacional
Nº da
execução
Nº de datagramas transmitidos pela
aplicação ServidorUDP
Nº de datagramas recebidos pela
aplicação Cliente UDP.
Tipo de
enlace.
1 1000 1000 S.O.
2 1000 1000 S.O.
3 1000 1000 S.O.
4 1000 1000 S.O.
5 1000 1000 S.O.
6 1000 1000 S.O.
7 1000 1000 S.O.
8 1000 1000 S.O.
9 1000 1000 S.O.
10 1000 1000 S.O.
Os resultados obtidos após 10 execuções demonstram que houve uma comunicação
100% confiável entre as aplicações remetente e destinatário quando instanciadas no mesmo
ambiente de execução.
4.4 Segundo experimento
O primeiro experimento apenas confirmou resultados previsíveis além de demonstrar
que a aplicação desenvolvida ao ser executada funcionou da forma esperada. O próximo
cenário escolhido para a realização do segundo experimento foi executado em um ambiente
de rede real. Esse ambiente trata-se da Intranet pertencente ao Ministério Público Federal, o
52
qual é um órgão da administração pública federal direta presente em todo o Brasil, cuja
infraestrutura de redes é mantida pela Empresa Brasileira de Telefonia – Embratel.
A permissão concedida pelo órgão foi muito importante diante da dificuldade de se
estabelecer uma infraestrutura desse porte somente para realização de testes, vez que seria
totalmente inviável se não fosse com o auxílio de quem já possui essa infraestrutura de
amplitude continental, tendo em vista a extensão do território brasileiro.
Nesse ambiente foram executados quatro experimentos nos seguintes cenários: 1º)
Circuito formado por enlaces cabeados e Satélite entre as cidades de Tupã/SP e Macapá/AP;
2º) Circuito formado por enlaces cabeados entre as cidades de Tupã/SP e Salvador/BA; 3º)
Circuito formado por enlaces cabeados e via rádio entre as cidades de Tupã/SP e
Florianópolis/SC; 4º) Circuito formado por enlaces cabeados e via rádio entre as cidades de
Tupã/SP e Assis/SP.
No primeiro cenário em que se realizou o segundo experimento foi estabelecido um
circuito que permitiu a transferência de dados entre as unidades de Tupã/SP e Macapá/AP
daquele órgão. Os números dos IPs correspondentes a cada enlace não serão exibidos por
razões de segurança. O circuito para essa comunicação é composto de quatro enlaces,
conforme a Tabela 3.
Tabela 3 - Descrição do circuito Tupã/SP x Macapá/AP
Enlaces Delay Tipo de enlace
Enlace 1 1 ms Cabo
Enlace 2 11 ms Cabo
Enlace 3 21 ms Cabo
Enlace 4 518 ms Satélite
A aplicação ServidorUDP foi executada em um host pertencente à rede local na cidade
de Tupã/SP e a aplicação ClienteUDP foi executada em um host pertencente a rede local na
cidade Macapá/AP. Note-se que o enlace final do circuito utilizava a tecnologia de
transmissão via Satélite, a qual impôs ao circuito um atraso quinze vezes maior que a soma
dos atrasos impostos pelos enlaces pertencentes ao restante do circuito.
A capacidade de vazão na origem estava limitada a uma largura de banda de 1 Mbits/s.
A aplicação ServidorUDP ao transmitir um datagrama a cada 10 ms assegurou que a
capacidade do enlace na origem não excedesse, pois sua capacidade de transferência era de
100 datagramas por segundo. Dada essa característica, a aplicação ServidorUDP nunca
utilizaria mais que (100 * 500 * 8) = 400 Kbits/s da largura de banda.
Os resultados das execuções nesse cenário podem ser observados na Tabela 4.
Tabela 4 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Macapá/AP composto
53
por enlaces cabeados e enlace que utiliza sinal via satélite entre as cidades .
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 997 Cabo e Satélite
2 1000 981 Cabo e Satélite
3 1000 995 Cabo e Satélite
4 1000 1000 Cabo e Satélite
5 1000 1000 Cabo e Satélite
6 1000 998 Cabo e Satélite
7 1000 997 Cabo e Satélite
8 1000 1000 Cabo e Satélite
9 1000 1000 Cabo e Satélite
10 1000 1000 Cabo e Satélite
Conforme pode ser observado no resultado dos testes, metade das vezes (execuções nº
4,5,8,9 e 10) o circuito mostrou-se 100% confiável. A execução nº 2 teve o pior resultado, se
comparada com as outras, demonstrando uma confiabilidade do circuito de 98,1%. As
execuções restantes demonstraram que o canal manteve-se confiável a uma taxa superior a
99% (execuções nº 1, 3, 6 e 7). A média de confiabilidade, baseada nos resultados obtidos, foi
de 99,68%.
Um segundo cenário foi utilizado. Nesse cenário a aplicação ServidorUDP continuou
sendo executada na cidade de Tupã/SP, porém, o destinatário ClienteUDP foi executado em
um host localizado na cidade de Salvador/BA. O circuito referente a esse segundo cenário
possui cinco enlaces, conforme a Tabela 5.
Tabela 5 - Descrição do circuito Tupã/SP x Salvador/BA
Enlaces Delay Tipo de enlace
Enlace 1 1 ms Cabo
Enlace 2 18 ms Cabo
Enlace 3 48 ms Cabo
Enlace 4 49 ms Cabo
Enlace 5 48 ms Cabo
Após dez execuções realizadas nesse cenário, os resultados da Tabela 6 demonstraram
que o circuito estabelecido entre as cidades de Tupã/SP e a cidade Salvador/BA, por meio da
Intranet daquele órgão, demonstrou ser 100% confiável.
Tabela 6 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Salvador/BA com enlaces cabeados.
54
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 1000 Cabo
2 1000 1000 Cabo
3 1000 1000 Cabo
4 1000 1000 Cabo
5 1000 1000 Cabo
6 1000 1000 Cabo
7 1000 1000 Cabo
8 1000 1000 Cabo
9 1000 1000 Cabo
10 1000 1000 Cabo
Dando continuidade ao experimento dois, os testes foram realizados em um novo
cenário. Nesse cenário, dois dos enlaces que compõem o circuito utilizavam ondas de rádio
como tecnologia de transmissão de sinais. Nota-se que a tecnologia de transmissão via rádio
impõe ao circuito atrasos maiores que a tecnologia de cabo. Os detalhes desse novo cenário
são exibidos na Tabela 7.
Tabela 7 - Descrição do circuito Tupã/SP x Florianópolis/SC
Enlaces Delay Tipo de enlace
Enlace 1 1 ms Cabo
Enlace 2 13 ms Cabo
Enlace 3 18 ms Cabo
Enlace 4 180 ms Rádio
Enlace 5 31 ms Cabo
Enlace 6 250 ms Rádio
Enlace 7 1 ms Cabo
Novamente a aplicação ServidorUDP foi instanciada em um microcomputador da
rede local no Município de Tupã/SP, porém, a aplicação ClienteUDP foi executada em um nó
localizado na cidade de Florianópolis/SC. O teste foi repetido dez vezes e os resultados são
exibidos na Tabela 8.
Tabela 8 - Resultados obtidos ao transferir dados utilizando circuito Tupã/SP x Florianópolis/SC composto de enlaces cabeados e que utilizam sinais de rádio
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 1000 Misto de Cabo e
Rádio
2 1000 1000 Misto de Cabo e
Rádio
3 1000 1000 Misto de Cabo e
Rádio
4 1000 1000 Misto de Cabo e
Rádio
5 1000 1000 Misto de Cabo e
Rádio
6 1000 1000 Misto de Cabo e
55
Rádio
7 1000 1000 Misto de Cabo e
Rádio
8 1000 1000 Misto de Cabo e
Rádio
9 1000 1000 Misto de Cabo e
Rádio
10 1000 1000 Misto de Cabo e
Rádio
Nesse cenário, o circuito proporcionou aos hosts (cliente e servidor) um enlace 100%
confiável em cada execução.
Por fim, um novo e último cenário foi escolhido para realização dos testes, o qual era
composto por enlaces que utilizam cabo e ondas de rádio. A aplicação ServidorUDP
continuou sendo executada no Município de Tupã/SP, já a aplicação ClienteUDP foi
executada em outra unidade localizada na cidade de Assis/SP. Detalhes desse circuito são
exibidos na Tabela 9.
Tabela 9 - Descrição do circuito Tupã/SP x Assis/SC
Enlaces Delay Tipo de enlace
Enlace 1 1 ms Cabo
Enlace 2 12 ms Cabo
Enlace 3 23 ms Cabo
Enlace 4 249 ms Rádio
Dez novos testes foram realizados nesse cenário e seus resultados são
mostrados na Tabela 10. Conforme pode ser observado, a execução número 1 apresentou ser o
pior resultado durante os testes, tendo uma taxa de confiabilidade do canal de 98,5%. A taxa
média de confiabilidade do canal, conforme os resultados obtidos, foi de 99,27%.
Tabela 10 - Resultados obtidos ao transferir dados utilizando o circuito Tupã/SP x Assis/SC composto de enlaces cabeados e que utilizam sinais de rádio.
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 985 Misto de Cabo e
Rádio
2 1000 991 Misto de Cabo e
Rádio
3 1000 997 Misto de Cabo e
Rádio
4 1000 1000 Misto de Cabo e
Rádio
5 1000 987 Misto de Cabo e
Rádio
6 1000 995 Misto de Cabo e
56
Rádio
7 1000 986 Misto de Cabo e
Rádio
8 1000 993 Misto de Cabo e
Rádio
9 1000 995 Misto de Cabo e
Rádio
10 1000 998 Misto de Cabo e
Rádio
4.4.1 Considerações com relação ao segundo experimento
Algumas considerações devem ser feitas com relação ao experimento 2. Quatro
cenários foram utilizados, cada um com suas características. O primeiro cenário além de
utilizar enlaces cabeados fez uso da tecnologia de transmissão via satélite para completar o
circuito. Nesse cenário, embora o retardo ocasionado por essa tecnologia seja alto, o circuito,
durante os testes, manteve uma taxa de confiabilidade acima de 99%.
O segundo cenário utilizou apenas cabos, obtendo uma taxa de confiabilidade do canal
de 100%, essa taxa foi alcançada sem qualquer garantia oferecida pela camada de transporte.
Com relação aos terceiro e quarto cenários, esses utilizaram circuitos compostos de
enlaces cabeados e enlaces que utilizam ondas de rádio como meio físico de transmissão. O
terceiro cenário demonstrou ser 100% confiável, porém o quarto cenário obteve uma taxa
média de confiabilidade de 99,27%.
Os resultados deste segundo experimento foram obtidos por meio de infraestrutura de
redes reais atualmente em uso, os quais, com base nos testes realizados, apresentaram taxas de
confiabilidade acima de 99%.
Entretanto, esses cenários não são os únicos, nem mesmo os mais utilizados pela
grande maioria dos usuários. Nesse sentido, um novo experimento foi realizado, utilizando
como tecnologia o padrão 802.11. A execução desse experimento é o conteúdo da Seção 4.5.
4.5 Terceiro experimento
Conforme mencionado anteriormente, a grande facilidade de se estabelecer uma
infraestrutura de redes utilizando dispositivos sem fio é muito grande. Essa facilidade, entre
outras já mencionadas, encorajam cada vez mais a migração de usuários domésticos para essa
tecnologia de redes sem fio. A grande aceitação dessa tecnologia vem propiciando que sinais
de redes sem fio (padrão 802.11) tornem-se cada vez mais presentes em nosso dia a dia.
Não é difícil, nos dias atuais, encontrar redes sem fio em casas residenciais,
estabelecimentos comerciais, órgãos governamentais e instituições de ensino. Baseado nessa
57
afirmação, o experimento 3 foi realizado em um prédio comercial cuja construção e
disposição se assemelha a esses diversos ambientes. É possível visualizar a planta baixa do
prédio por meio da Figura 7.
Figura 7 - Planta baixa do ambiente onde os testes foram realizados.
Nesse prédio foi instalado um roteador wireless padrão 802.11n, o qual foi
configurado para estender a rede local cabeada, permitindo acessá-la por meio de dispositivos
de rede sem fio. Nesse cenário foram realizados três experimentos que são descritos a seguir.
Durante os experimentos, o roteador permaneceu instalado na sala de reuniões desse prédio. A
Figura 8 mostra a rede utilizada para a realização do experimento.
Figura 8 - Organização da rede em que foram realizados os testes.
No microcomputador estacionário foi executado o programa ServidorUDP e no
notebook, dispositivo dotado de mobilidade, foi executado o programa ClienteUDP.
58
Inicialmente ambos os pares permaneceram a uma distância de cinco metros um do
outro. Roteador e notebook permaneceram na mesma sala. Nessa configuração, o enlace sem
fio emanado do roteador não encontrou obstáculos físicos para alcançar o notebook, conforme
observado na Figura 9.
Figura 9 - Descrição do ambiente em foi realizado o teste a uma distância de 5 metros.
Dez execuções foram realizadas nesse cenário e os resultados, apresentados na Tabela
11, demonstram que a confiabilidade alcançada nessas condições foi de 100%.
Tabela 11 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a cinco metros da origem do sinal)
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 1000
2 1000 1000
3 1000 1000
4 1000 1000
5 1000 1000
6 1000 1000
7 1000 1000
8 1000 1000
9 1000 1000
10 1000 1000
Sem fio a 5
metros do
roteador sem
obstáculos.
Os testes seguintes foram realizados aumentando a distância e incluindo obstáculos
físicos entre transmissor e receptor. A distância utilizada nesses testes foi de 40 metros e
serviram como obstáculos as paredes de alvenaria e portas de madeira do ambiente. A Figura
10 mostra esse ambiente.
59
Figura 10 - Planta baixa do cenário em que ocorreram os testes. Host móvel a uma distância de 40 metros
da estação base. (do autor)
Novamente, dez execuções foram realizadas e os seus resultados, conforme podem ser
observados na Tabela 12, mostraram que o enlace nessas características foi em média 99,78%
confiável.
Tabela 12 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a 40 metros da origem do sinal)
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 997
2 1000 989
3 1000 995
4 1000 1000
5 1000 999
6 1000 998
7 1000 1000
8 1000 1000
9 1000 1000
10 1000 1000
Sem fio a 40
metros do
roteador, sujeito
a obstáculos.
O terceiro e último cenário é o mesmo do teste anterior, porém, fontes causadoras de
interferência no sinal foram introduzidas no ambiente. Foram escolhidos dois aparelhos
eletrônicos que operavam na mesma faixa de frequência do roteador, ou seja, na faixa ISM -
Industrial, Scientific and Medical de 2.4 Ghz. Os aparelhos escolhidos foram um forno de
microondas e um aparelho de telefone sem fio. A escolha desses dois aparelhos foi motivada
pelo fato de que eles são encontrados com grande facilidade em ambientes domésticos e
comerciais.
Os testes foram executados quando ambos os aparelhos estavam em uso, ou
seja, enquanto eram transferidos os datagramas entre remetente e destinatário, também
estavam em uso o forno microondas e o telefone sem fio. Tanto o notebook (destinatário)
quanto o forno de microondas e o aparelho de telefone sem fio encontravam-se um ao lado do
outro dentro da mesma sala. Os resultados desse experimento podem ser observados na
Tabela 13.
60
Tabela 13 - Resultados obtidos ao transferir dados utilizando enlace sem fio padrão 802.11n (receptor a 40 metros da origem do sinal com interferências)
Número da execução
Nº de datagramas UDP
transmitidos pela aplicação
UDPServer
Nº de datagramas UDP recebidos
pela aplicação UDPCliente Tipo de enlace
1 1000 882
2 1000 886
3 1000 850
4 1000 863
5 1000 883
6 1000 875
7 1000 881
8 1000 852
9 1000 877
10 1000 879
Wireless a 40
metros do
roteador +
dispositivos
causadores de
interferência
Diante dos resultados obtidos é possível notar que houve uma diminuição da
confiabilidade quando o enlace foi exposto a interferências se comparado ao segundo cenário.
A taxa média de confiabilidade obtida nos resultados foi de 87,28%.
4.6 Considerações finais
Levando-se em consideração que os experimentos foram realizados em cenários
compostos por redes reais, dentre as quais algumas de amplitude ou extensão nacional e
outras, embora não tão extensas, utilizadas por grande quantidade de usuários, tais tecnologias
demonstraram ser relativamente confiáveis.
Entretanto, conforme já mencionado, os sinais que usam a atmosfera como meio físico
de propagação estão sujeitos a interferências inesperadas. Foi o caso do último cenário
apresentado, em que propositadamente foram inseridos dispositivos causadores de
interferências, causando a diminuição da confiabilidade do enlace.
Com os resultados obtidos nesses experimentos foi possível ter uma ideia geral da
qualidade do enlace em ambientes reais nos dias atuais, os quais serão utilizados como
parâmetros para as taxas de erros aplicadas nas simulações
.
61
5. Análise do comportamento do TCP
em um simulador de redes
Este tópico descreve a evolução dos estudos que resultaram em uma nova proposta de
TCP a qual se propõe em detectar falhas no enlace mantendo a semântica fim a fim da
arquitetura em camadas das redes de computadores.
O objetivo inicial deste trabalho restringia-se a simular as variantes TCP existentes por
meio de critérios que escolheriam aquelas que atendessem uma das características necessárias
para o desenvolvimento de uma solução ideal e posteriormente seria analisada a possibilidade
dessas soluções serem intercambiáveis a ponto de proporcionar uma nova variante que unisse
todas essas soluções.
Durante os estudos dos impactos causados por falhas no enlace no TCP e suas
variantes, ao simular essas falhas, observou-se que elas causavam no TCP remetente,
independentemente da variante simulada, a estagnação de seu número de sequência e a
redução do tamanho da janela de congestionamento para o valor mínimo possível. Observou-
se também que o TCP remetente permanecia dessa forma enquanto o enlace se mantinha
falho.
Foi com base na observação dessas características que surgiu um novo objetivo, o
desenvolvimento de um mecanismo capaz de fazer com que o TCP pudesse identificar por si
só a ocorrência desse padrão mencionado, impedindo assim que falhas no enlace
promovessem a degradação de seu desempenho.
Toda a pesquisa foi realizada com o auxílio do simulador de redes NS2 (Network
Simulator – ns-2). Por meio dele também foram realizadas comparações com as variantes nele
implementadas. Os resultados obtidos nas simulações e o desenvolvimento da nova solução
são descritos no decorrer deste tópico.
5
62
5.1 Simulador de redes de computadores
Simuladores de redes permitem que sistemas de redes complexas sejam simulados,
possibilitando análises, em larga escala e por longos períodos, de seus comportamentos a um
custo baixo (McCanne e Floyd, 1999).
Para realização das simulações foi utilizado o simulador NS2, que é o resultado de um
projeto conhecido como VINT (Virtual InterNetwork Testbed). O projeto VINT resulta da
união de esforços entre UC Berkeley, USC/ISI, LBL, e Xerox PARC. O projeto também é
patrocinado pelo DARPA - Defense Advanced Research Projects Agency. O simulador é
gratuito e possui código fonte aberto. O projeto está totalmente documentado, sua principal
referência é conhecida como “The ns Manual” e pode ser encontrado no site oficial do
projeto.
O NS2, além de possibilitar a simulação de redes com fio e redes sem fio, também
permite a criação de diversas topologias sendo possível criar inúmeros cenários. O simulador
também oferece uma grande quantidade de protocolos implementados, inclusive os protocolos
TCP e UDP para simulações na camada de transporte.
O NS2 é um simulador de redes orientado a objeto escrito na linguagem C++. A
versão 2.34 utiliza a linguagem OTcl como frontend. Para aquelas simulações de redes cujos
protocolos já estão implementados no NS2, o simulador, por meio do frontend OTcl,
possibilita construções rápidas dos cenários para serem simulados.
Se o objetivo for simular novos protocolos ainda não implementados nele, há a
possibilidade de se desenvolver novas classes para novos protocolos, construídas em C++.
Basicamente, esse é o principal motivo que leva o NS2 a oferecer duas linguagens.
O simulador NS2 também conta com ferramentas que permitem a visualização gráfica
das simulações geradas pelo simulador. Uma das mais utilizadas e conhecidas é o NAM –
Network Animation, apresentada na Figura 11.
Figura 11 - NAM – Network Animation (Nam network animator project, 2012)
63
Com um script, utilizando o NS2, é possível criar um cenário de rede e simular o
comportamento de diversos protocolos, sendo possível posteriormente analisar de forma
meticulosa o comportamento de cada protocolo, seja com o auxílio de ferramentas de
visualização, seja com gráficos.
Acredita-se que a principal vantagem de se utilizar simuladores, além do baixo custo,
está na garantia de que o simulador reproduzirá o mesmo cenário de forma fidedigna quantas
vezes for necessário, condição essa praticamente impossível em ambientes reais. Essa
característica proporciona a comparação de vários protocolos de forma que nenhum deles
possa ser favorecido ou prejudicado por fatores que não podem ser controlados, o que
aconteceria caso fossem comparados em cenários reais.
5.2 Considerações sobre simulação de redes
Simulação de redes de computadores, na maioria das vezes, tem sido umas das
ferramentas de pesquisa escolhida pela maioria dos pesquisadores. Entre os anos de 2000 a
2005, foram publicados 151 artigos sobre MANETs na ACM’s MobiHoc Conference, um dos
eventos mais importantes sobre redes MANETs. Dentre os 151 artigos publicados nesse
período, 114 artigos (75,5% do total) usaram simulações na pesquisa.
Embora o uso de simulação tenha crescido, a credibilidade dos resultados obtidos nas
simulações tem diminuído segundo Kurkowski et al. (2005). Um bom trabalho utilizando
simulações deve dar condições para que outros leitores e pesquisadores, baseados nas
informações do artigo, sejam capazes de repetir as simulações apresentadas obtendo os
mesmos resultados apresentados.
Para que isso seja possível, o pesquisador deve incluir em sua publicação informações
como (Kurkowski, et al., 2005):
• Configuração da simulação: Informações como tipo da simulação utilizada
(terminativa ou estacionária), validação desse modelo, validação/inicialização do
gerador de números aleatórios utilizado, definição/inicialização das variáveis e do
cenário são importantes informações que devem estar disponíveis na apresentação
dos resultados da pesquisa.
• Execução da simulação: Como a execução das simulações gasta o maior tempo
do experimento, é importante conduzi-la corretamente. O não estabelecimento de
uma semente para o pseudogerador de números aleatórios – PGNA - é um dos
erros frequentemente encontrado em simulações utilizando o simulador de redes
NS2. Por padrão, o NS2 utiliza a semente 12345 para seu PGNA. Assim, se o
64
pesquisador repetir o experimento sem alterar esse valor, resultados idênticos serão
produzidos. A configuração do tipo correto de informação gerada como saída é um
dos pontos mais importantes na execução da simulação, dependendo da
informação que o pesquisador quer obter; assim, analisar somente o número de
pacotes enviados ou recebidos pode não ser suficiente para avaliar corretamente os
resultados.
• Análise dos resultados: Muitos trabalhos falham ao analisar incorretamente os
resultados obtidos. Uma das principais falhas está na decisão de tomar o primeiro
resultado como verdadeiro. Assim, haverá uma grande probabilidade que o único
resultado obtido não representa a estatística populacional desse resultado. É
preciso também assegurar a independência dos resultados obtidos, isso pode ser
feito assegurando que os resultados foram identicamente distrubuídos.
• Publicação: Devem-se dar condições para que os resultados obtidos nas
simulações publicadas nos artigos sejam repetidos pela comunidade de pesquisa.
Como exemplo, há 674 variáveis definidas no arquivo “ns-default.tcl”, um dos
arquivos de configuração do NS2. Para assegurar que a comunidade repita as
simulações, é necessário publicar as alterações feitas nos arquivos de configuração
dos simuladores utilizados.
Com base nessas informações, um trabalho que utiliza simulações deve se pautar em
quatro áreas para que se possa garantir sua credibilidade (Kurkowski, et al., 2005):
• Repetição: Outros interessados/pesquisadores devem ser capazes de repetir os
resultados publicados pelo trabalho.
• Imparcialidade: Os resultados não devem ser específicos para um cenário
específico no experimento.
• Rigor: Os cenários e condições construídos nas simulações devem repetir
fidedignamente o comportamento ou característica que ser quer experimentar.
• Análise estatística: As execuções e análises dos resultados devem ser baseadas
em princípios matemáticos.
As simulações apresentadas seguiram as recomendações desta seção. O simulador
utilizado foi o NS2, versão 2.34, e foi executado sobre o sistema operacional Linux, kernel
2.6.26, distribuição Debian.
O tipo de simulação utilizada foi do tipo terminativo, isso quer dizer que os ambientes
foram simulados por um período de tempo predeterminado, desse modo, a execução foi
interrompida de forma abrupta, diferentemente do tipo de simulação conhecida como “steady-
65
state” na qual a simulação só é interrompida quando o comportamento de um determinado
objeto que se está simulando é verificado ou não.
As simulações foram executadas sem que nenhuma alteração no código fonte do
simulador fosse feita, com exceção dos códigos fontes que foram adicionados no simulador,
os quais se referem à nova proposta descrita nesta dissertação.
Foi utilizado o pseudogerador de números aleatórios – PRNG - do NS2. Entretanto, há
importantes limitações desse PRNG que devem ser consideradas, como por exemplo, a
impossibilidade de se gerar fluxos separados para cada dimensão que se está simulando (ex:
atraso, ruído e jitter).
Outra questão importante diz respeito ao poder computacional atualmente disponível
para os pesquisadores. Esse poder computacional pode, em um curto espaço de tempo, causar
a repetição desses números gerados (Kurkowski, et al., 2005), fazendo com os números se
esgotem/repitam em 10 minutos de simulação. As simulações apresentadas não possuem
cenários complexos e períodos longos simulados. Assim, o PRNG do NS2 utilizado, cuja
magnitude é de 232 – 1, foi suficiente.
As variáveis encontradas nos arquivos de configuração do NS2 não foram alteradas.
Nas simulações que exigiram a alteração da semente do PRNG, o valor atribuído foi inserido
no próprio arquivo em que o cenário era configurado.
As simulações foram executadas com buffers e filas vazios, os quais eram alimentados
pelo próprio simulador durante a simulação. Os resultados obtidos nas simulações foram
submetidos a análises estatísticas.
Os cenários construídos direcionavam as simulações para que determinados eventos
fossem gerados, por exemplo, falhas nos enlaces em determinados instantes.
É possível afirmar que, dessa forma, as simulações realizadas ficaram isentas de
resultados tendenciosos.
5.3 TCP em um ambiente simulado
Depois de descritas as principais características do TCP, seu comportamento foi
analisado em um ambiente simulado. Uma das vantagens de simular o TCP está no fato de
que é possível analisar o comportamento de suas variáveis quando submetidas a certos
ambientes ou determinadas situações, sendo possível analisar o comportamento dessas
variáveis isoladamente. Nesse sentido, a primeira simulação do TCP apresentada, que durou
450 ms, submeteu-o a um ambiente cujo enlace foi configurado para ser 100% confiável.
A simulação consistiu em transferir dados entre dois hosts utilizando o protocolo TCP-
Newreno como protocolo da camada de transporte. A escolha da versão TCP-Newreno foi
66
motivada por ser ela uma modificação importante, sem destinação para um ambiente
específico, que trouxe melhorias às características originais do TCP.
Ambos os hosts estiveram conectados por um enlace cuja capacidade foi configurada
para 1 Mb/s e latência de 100 milissegundos. O remetente, por meio de uma aplicação FTP,
transmitiu para o destinatário segmentos contendo 536 bytes a cada 1 milissegundo por um
período de 400 milissegundos. Essa configuração garantiu que o remetente sempre atingiria o
limite do enlace, pois a aplicação no remetente inseria dados no canal a uma taxa de (1000 *
536 bytes * 8) 4.28 Mbits/s, valor superior ao limite de 1 Mbits/s pré estabelecido no enlace.
Assim, a cada vez que o limite do enlace era atingido, o TCP no remetente acionava seu
mecanismo de controle de congestionamento. Rassalta-se que os cabeçalhos de cada
protocolo foram considerados para efeito de utilização da capacidade do enlace.
A janela de congestionamento e o número de sequência foram as variáveis analisadas
nessa simulação. A análise dessas duas variáveis é importante tendo em vista que a janela de
congestionamento é a responsável por determinar a quantidade de dados que poderão ser
transmitidos a partir do remetente. Já o número de sequência está relacionado ao êxito
alcançado na transferência desses dados, ou seja, daqueles que foram transmitidos, quais
dados foram realmente entregues.
A Figura 12 mostra o comportamento da janela de congestionamento do TCP-
Newreno obtido na simulação. Observa-se na figura que no início da simulação, o TCP,
executando seu mecanismo de partida lenta, alcançou um tamanho de janela de 125
segmentos. Nesse instante o TCP remetente detectou uma perda de um desses segmentos
transmitidos, reduzindo sua janela de congestionamento para o tamanho de 1 (um) segmento.
Após isso, reajustou seu valor de limiar (threshold), iniciando novamente seu mecanismo de
partida lenta até entrar na fase de prevenção de congestionamento ao atingir o valor de limiar.
A versão TCP-Newreno possui a característica de impedir novas fases de partida lenta,
reduzindo a sua janela de congestionamento pela metade a cada nova ocorrência de perda.
Essas características dão ao TCP uma forma semelhante a dentes de serra.
67
Figura 12 - Comportamento da janela de congestionamento do TCP-Newreno em um enlace 100%
confiável.
A Figura 13 mostra o comportamento da variável número de sequência durante essa
simulação. Em um enlace 100% confiável, o crescimento do número de sequência foi
constante. O gráfico que representa a evolução do número de sequência é uma reta que pode
ser definida pela equação bax + .
Nesse cenário, o único obstáculo encontrado pelo remetente foi o limite máximo de
vazão do enlace, ou seja, o enlace foi capaz de transmitir b bits (constantemente) a cada a
tempo. A capacidade total desse enlace foi definida em 1 Mb/s, o qual teve uma capacidade
de vazão de 125.000 bytes/s (1.000.000 / 8).
Figura 13 - Evolução do número de sequência do protocolo TCP-Newreno em um enlace 100% confiável.
68
Observa-se na Figura 13 que o número de sequência alcançado pelo TCP-Newreno foi
de 47.733 bytes. Esse resultado alcançado chegou muito perto da capacidade total do enlace,
cuja capacidade permitia no máximo a transmissão de 50.000 bytes dentro dos 400
milissegundos de tempo disponível para a transmissão.
A diferença entre a capacidade alcançada pelo TCP e capacidade máxima do canal
pode ser explicada pelo fato de que o payload referente aos dados da aplicação FTP não são
os únicos dados que utilizam o enlace. A cada camada em que os dados trafegam, cabeçalhos
dessas respectivas camadas são adicionados aumentando assim o tamanho original do pacote.
A eficiência do TCP também está relacionada ao seu comportamento. Por meio da
Figura 12 é possível observar que a janela de congestionamento do TCP remetente,
responsável por regular a transferência de dados no remetente, variou constantemente entre
dois valores fixos, sendo o mínimo de 39 e máximo de 79 segmentos.
Desse modo, em um ambiente 100% confiável, o protocolo TCP-Newreno, ao utilizar
seus mecanismos de controle de fluxo, explorou muito bem a capacidade total do enlace. A
média de vazão alcançada pelo TCP nessas condições foi de 119,33 bytes a cada
milissegundo, valor bem próximo dos 125 bytes/milissegundos permitido pelo enlace com as
características já mencionadas.
Kurose e Ross (2010) ao discorrerem sobre a visão macroscópica da dinâmica do TCP
afirmam que a vazão média de uma conexão TCP nessas condições durante um grande
período de tempo é RTT
W*75,0
(1), sendo W o tamanho máximo da janela de congestionamento
em bytes alcançado durante a transmissão.
Nesse cenário de enlace 100% confiável, com RTT estimado de 200 milissegundos e
tamanho do segmento TCP de 1000 bytes e utilizando a fórmula de Kurose e Ross, a vazão
média do TCP alcançada nessa simulação seria de 250.2962,0
)1000*79(*75,0= bytes por
segundo. Essa taxa, conforme dito antes, é proposital e foi escolhida para provocar eventos de
perda ao superar a capacidade máxima do enlace.
Com base nessa fórmula, se a vazão de 296.250 bytes por segundo fosse alcançada no
cenário utilizado, o TCP remetente seria capaz de transmitir no máximo 118.500 bytes em
400 milissegundos (296.250 * 40 / 100), o que dá uma vazão média de 118,5 bytes por
milissegundo, que é um valor próximo dos 119,33 bytes alcançados na simulação.
Essa afirmação decorre da observação do comportamento do TCP que utiliza seu
mecanismo de controle de congestionamento para reduzir sua janela pela metade a cada
evento de perda.
69
Considerando que em um canal 100% confiável esse evento de perda ocorra somente
quando o limite da capacidade do enlace é alcançado e que a cada ocorrência de perda a janela
é reduzida pela metade, pode-se afirmar que essa janela sempre irá variar de 2
W
até W, tendo
um crescimento médio de ¼ de W. A vazão mínima sempre será ½ W e crescerá em média ¼
de W, portanto, sua vazão média será de ½ + ¼ = ¾ ou 0,75 de W. A Figura 14 auxilia a
entender melhor esse comportamento do crescimento da janela de congestionamento a cada
evento de perda.
Figura 14 - Dinâmica do crescimento da janela de congestionamento do protocolo TCP.
Adicionalmente, esses mesmos autores afirmam que essa fórmula não é a mais
adequada, pois ela não considera a taxa de erros do canal. Nesse sentido, os autores
mencionam que um modelo mais sofisticado de vazão média, relacionado à taxa de perda da
conexão, dado por LRTT
MSS22,1
(2).
Para calcular a fórmula (2), considera-se MSS o tamanho máximo de um segmento,
RTT o tempo de ida e volta entre remetente e destinatário e L a taxa de erros imposta pelo
enlace.
Deve-se considerar também que um segmento será perdido a cada vez que a janela de
congestionamento alcançar W, dessa forma a média de vazão é definida como o somatório das
janelas de congestionamento em crescimento até que ela atinja o seu limite em W em (1):
∑∑==
++=+=++++++
2
0
2
0 2)1
2(
2...)2
2()1
2(
2
W
n
w
n
nWW
nW
WWWW
(1)
Tem-se:
∑=
2
0
W
n
n
= 2
2)1
2(WW
+
(2)
Substituindo (2) em (1):
WWWWWW
WW
WW
4
3
8
3
48242
2)1
2(
2)1
2(
2
22
+=+++=
+
++
(3)
70
Para cada crescimento da janela, há um evento de perda ao atingir W. Dessa forma,
tem-se a função de perda WW
L
4
3
8
3
1
2+
=
.
Para valores muito grandes de W a fração W
4
3
pode ser desprezada. Tem-se então
2
8
3
1
W
L =
ou LW
3
8=
.
Ao aplicar a taxa de perda em RTT
W*75,0
tem-se
LRTT
MSS
RTT
MSS
LRTT
MSS
L
22,1
7320,1
8284,2
4
3
3
8
4
3==
.
Com isso, pode-se considerar que a taxa média de vazão de um enlace, considerando
que o enlace está sujeito a uma taxa de perda constante, é de LRTT
MSS22,1
. Essa fórmula parece
ser mais coerente, pois, ao contrário dos cenários idealizados, os enlaces reais estão sujeitos a
erros.
Tornando o cenário um pouco mais realista, a simulação do TCP-Newreno foi repetida
e dessa vez o enlace estava sujeito a uma taxa probabilística de erros de 12,5%, ou seja, a cada
1000 segmentos transmitidos 125 segmentos seriam perdidos. Essa taxa de erros está em
consonância com a obtida nos testes da Seção 4.5.
Conforme pode ser observado na Figura 15, após a simulação em um enlace sujeito a
erros, o comportamento da janela de congestionamento do TCP passou a ter um
comportamento caótico se comparado ao seu comportamento padrão de dentes de serra.
Figura 15 - Comportamento da janela de congestionamento do protocolo TCP-Newreno sobre um enlace
com taxa de erros de 12,5%.
71
Nessa simulação, os mecanismos do TCP-Newreno não foram suficientes para impedir
repetidas fases de partida lenta além da inicial, as quais se repetiram por 42 vezes.
Também houve alterações no gráfico que representa a evolução do número de
sequência, o qual diz respeito aos bytes transferidos do remetente para o destinatário. A
Figura 16 mostra que seu comportamento não é mais de uma reta, embora se assemelhe a
uma. É possível observar que o número de sequência não avança constantemente se
comparado ao gráfico da Figura 13. Nota-se que embora haja avanço do tempo de transmissão
isso não acontece com o número de sequência.
Figura 16 - Evolução do número de sequência do protocolo TCP-Newreno sobre um enlace com taxa de
erros de 12,5%.
Esse comportamento pode ser explicado pelo fato da janela de congestionamento no
remetente não dispor de espaço para aceitar novos dados para serem transmitidos, uma vez
que a aceitação de novos dados depende da confirmação dos já transmitidos.
Com essa dinâmica do TCP, a transmissão de novos segmentos resultaria em novas
perdas. Enviar novos segmentos quando um evento de perda é identificado pode ser uma
tarefa inútil seja por que o buffer do destinatário está cheio, seja por congestionamento na
rede ou mesmo por uma falha no enlace. Todas essas possibilidades causam a perda de
segmentos se eles forem transmitidos.
O esgotamento do buffer do destinatário causa a perda de novos segmentos que
chegam, se o TCP remetente não retransmitir esses segmentos perdidos, sua janela de
congestionamento ficará estagnada e não deslizará. Nesses momentos o número de sequência
no TCP remetente permanecerá estagnado.
Vale também observar que a taxa de erros de 12,5% no enlace não se traduziu em uma
diminuição de desempenho de 12,5% na quantidade de bytes transferidos pelo TCP
remetente, antes tivesse havido essa correlação, pois a queda do desempenho sofrida pelo
72
TCP nesse cenário foi de 90,89% se comparado ao desempenho do cenário anterior em que o
enlace era 100% confiável.
Dito isso, a próxima simulação além de aplicar uma taxa de probabilidade de erros
também submeteu o enlace a falhas. Durante os 400 milissegundos de simulação o enlace
ficou impedido de trafegar dados nos instantes: 10 a 30 ms; 80 a 120 ms; 160 a 200 ms; 220 a
240ms e 380 a 395ms, conforme Figura 17.
Figura 17 - Comportamento da janela de congestionamento do protocolo TCP-Newreno sobre um enlace
com taxa de erros de 12,5% e sujeito a falhas.
Conforme pode ser observado na Figura 17, nos instantes em que o enlace estava
submetido a falhas, a janela de congestionamento no TCP remetente foi reduzida ao tamanho
mínimo de um segmento, permanecendo com esse tamanho enquanto o enlace permanecia
falho. Esse comportamento é devido à impossibilidade de seu mecanismo de partida lenta
prosseguir, uma vez que o enlace encontrava-se impedido de receber e transmitir novos
segmentos. Isso impediu que sua janela de congestionamento aumentasse exponencialmente
na fase de partida lenta, ocasionados pelo não recebimento de novas confirmações (ACKs) ou
pela ocorrência de novos timeouts.
A Figura 18 mostra o comportamento da variável número de sequência do TCP
remetente durante essa simulação. As setas indicam as falhas no enlace. Conforme pode ser
observado, o TCP remetente não conseguiu transmitir novos dados entre as falhas no enlace
nos instantes 160 a 200 ms e 220 a 240 ms. Isso significa que durante os 20 milissegundos
que separaram uma falha da outra não houve qualquer transmissão de novos dados.
73
Figura 18 - Evolução do número de sequência do protocolo TCP-Newreno quando submetido a um enlace
sujeito a 12,5% de erros e a falhas.
Observa-se também que além da estagnação do tamanho da janela de
congestionamento, as falhas no enlace também causaram no TCP remetente a estagnação da
variável número de sequência. Na simulação anterior, as estagnações ocasionadas por perdas
de segmentos eram quase imperceptíveis, porém, elas se tornaram mais visíveis quando o
enlace foi submetido a falhas. Curioso é notar que mesmo aumentando as dificuldades no
enlace acrescentando falhas, nesse mesmo cenário o protocolo TCP-Newreno teve um
desempenho superior se comparado ao desempenho da simulação em que o enlace estava
configurado somente com uma taxa de erros de 12,5%.
Após essas simulações pode-se concluir que em um enlace 100% confiável o
protocolo TCP-Newreno utilizou quase a total capacidade do enlace. Já em um enlace mais
realista, sujeito a uma taxa de erros de 12,5%, o comportamento de sua janela de
congestionamento tornou-se imprevisível deixando de ter uma aparência uniforme de dentes
de serra.
Analisando também a evolução do número de sequência nesse ambiente, o seu
comportamento também é diferente daquele ambiente idealizado, deixando de se parecer com
uma reta. Essa reta foi deformada por pequenas estagnações ocasionadas por perdas de
segmentos.
Quando o enlace foi submetido a falhas, as estagnações das variáveis denominadas
janela de congestionamento e número de sequência tornaram-se mais evidentes durante as
falhas, sendo possível visualizá-las nos gráficos de forma mais evidente. Nesse caso, pode-se
74
afirmar que uma falha no enlace impõe ao TCP remetente a estagnação dessas variáveis e
consequentemente a dimunuição de sua janela.
Esse comportamento não é proveniente somente da versão TCP-Newreno, mas sim de
outras variações do TCP. Para demonstrar essa afirmação, as variantes do TCP Tahoe, Reno,
Westwood, Vegas, Jersey, Fack, Sack e Freeze também foram simuladas naqueles ambientes
e os resultados obtidos são mostrados na Figura 19.
Figura 19 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno,
Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace 100% confiável.
Conforme mostra a Figura 19, com exceção da variante TCP-Vegas cuja janela de
congestionamento teve comportamento linear, todas as outras variações do TCP tiveram
comportamento similar à versão TCP-Newreno. Essas variantes também foram submetidas ao
cenário cujo enlace foi configurado para operar com uma taxa de erros de 12,5%.
A Figura 20 mostra o comportamento da janela de congestionamento dessas versões.
Conforme os resultados, houve também um comportamento “caótico” para todas as versões
do TCP simuladas, ou seja, não sendo possível avaliar um padrão de comportamento.
Figura 20 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno,
Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5%.
75
Figura 21 - Evolução do número de sequência das variantes Tahoe, Reno, Newreno, Westwood, Vegas,
Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5%. A Figura 21 mostra o comportamento do número de sequência das variantes do TCP
simuladas nesse cenário. Pode-se concluir que seus comportamentos foram semelhantes à
versão TCP-Newreno com relação à evolução do número de sequência.
Continuando com a repetição das simulações usando outras variantes TCP, essas
foram submetidas àquele cenário sujeito a erros e falhas no enlace. A Figura 22 mostra o
comportamento da janela de congestionamento que cada variante obteve.
Figura 22 - Comportamento das janelas de congestionamento das variantes Tahoe, Reno, Newreno,
Westwood, Vegas, Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5% e sujeito a falhas.
Conforme é possível observar, assim como o TCP-Newreno, as janelas de
congestionamentos dessas variantes também foram reduzidas para o tamanho mínimo
76
permanecendo estáticas até que ocorresse a recuperação do enlace. Com base nesses
resultados pode-se depreender que esse comportamento é comum a essas variantes, assim
como foi mostrado nas simulações da variante TCP-Newreno.
Já a Figura 23 traz o comportamento do número de sequência dessas variantes TCP
comparando-as com a versão TCP-Newreno. Percebe-se que todas as versões tiveram um
comportamento semelhante ao TCP-Newreno quando houve falhas no enlace. Assim, pode-se
concluir que para todas essas variantes, o número de sequência estabilizou, ou seja, deixou de
crescer quando o enlace estava em estado falho.
Figura 23 - Evolução do número de sequência das variantes Tahoe, Reno, Newreno, Westwood, Vegas,
Jersey, Fack, Sack e Freeze sobre um enlace com taxa de erros de 12,5% e sujeito a falhas.
Com essas observações foi possível evidenciar um comportamento comum de duas
variáveis importantes do TCP durante as simulações, a estagnação da janela de
congestionamento e do número de sequência no remente decorrente de falha no enlace. Esse
estado durou enquanto o enlace permaneceu falho.
5.4 Considerações finais
Em um ambiente simulado é possível observar os comportamentos da janela de
congestionamento do protocolo TCP sobre diferentes situações. Em uma ambiente cujo enlace
possui 100% de confiabilidade, o protocolo TCP conseguiu utilizar quase que toda a
capacidade de transmissão disponibilizada pelo enlace. Entretanto, a inclusão de 12,5% de
taxa de erros no enlace fez com que o protocolo TCP tivesse uma queda de desempenho
77
acentuada, não proporcional a taxa de erros imposta. Especificamente, a inclusão de 12,5% de
erros provocou no TCP uma diminuição de desempenho acima de 90% se comparado seu
desempenho em um enlace 100% confiável.
Observa-se que falhas no enlace provocadas durante as simulações causam a
estabilização do número de sequência no TCP remetente e a diminuição de sua janela de
congestionamento para o valor mínimo possível, fatos esses observados em todas as variantes
do TCP simuladas.
78
6. TCP-UEM: Uma nova abordagem
Conforme se observou nas simulações mostradas no tópico anterior, falhas no enlace
provocam no TCP remetente estagnações das variáveis número de sequência e janela de
congestionamento. É com base nessa observação que este tópico apresenta a técnica utilizada
para dar ao TCP a capacidade de identificá-las como falhas no enlace.
6.1 Dinâmica da janela de congestionamento do TCP
Diz-se da janela de congestionamento do TCP que ela é uma janela deslizante, pois
durante a transferência de dados ela desliza, autorizando a camada de aplicação a inserir
novos dados para serem transmitidos. A Figura 24 mostra essa dinâmica.
Figura 24 - Dinâmica da janela de congestionamento do TCP.
Na Figura 24, os segmentos na cor cinza foram transmitidos com sucesso, indicando
para o remetente que esses segmentos não precisam ser retransmitidos. Os segmentos de cor
amarela foram transmitidos, porém aguardam confirmação de recebimento pelo destinatário, e
os segmentos da cor branca estão disponíveis para receber novos dados da camada de
aplicação.
Nesse exemplo, o segmento 6 é a base da janela e caso esse segmento receba uma
confirmação, a janela de congestionamento irá deslizar para frente incorporando os segmentos
6
79
14 e 15 a ela, alterando sua base para o segmento 8. O tamanho da janela dependerá de
eventos de confirmação ou perda de segmentos para aumentar ou diminuir seu tamanho.
Após o fim da conexão, a janela de congestionamento do TCP remetente terá se
comportado conforme o estado do enlace percebido, ou seja, as condições do enlace refletem
necessariamente no comportamento da janela de congestionamento do TCP.
6.2 RFC 5681 – Controle de congestionamento do TCP
Antes de apresentar a nova abordagem para o TCP, é necessário apresentar o padrão
da Internet vigente para o controle de congestionamento do TCP definido pela IETF - Internet
Engineering Task Force.
A IETF é um grupo informal e auto-organizado composto por voluntários (técnicos,
agências, fabricantes, fornecedores e pesquisadores) que contribuem para a engenharia e
evolução da Internet. É o principal organismo envolvido no desenvolvimento de novas
especificações e padronização da Internet (RFC 3160).
Os principais objetivos da IETF são descritos a seguir (RFC 3160):
• Identificar e propor soluções para urgentes problemas técnicos e operacionais na
Internet;
• Especificar a padronização no desenvolvimento e uso dos protocolos empregados
na Internet;
• Fazer recomendações para o IESG - Internet Engineering Steering Group sobre a
padronização dos protocolos utilizados na Internet;
• Facilitar a transferência de tecnologia do IRTF - Internet Research Task Force
para a comunidade da Internet;
• Realizar fóruns de discussão para troca de informações dentro da comunidade da
Internet entre os fornecedores, pesquisadores, agência e administradores de rede.
As padronizações definidas pela IETF são publicadas por meio dos RFCs (Request for
Comments). Um RFC é uma especificação de uma implementação bem sucedida,
caracterizada por um elevado nível técnico de maturidade e por uma crença generalizada de
que o protocolo ou o serviço especificado oferece um benefício significativo para a
comunidade da Internet (RFC 2026).
Atualmente, a especificação e padronização do controle de congestionamento do
protocolo TCP aceito pela IETF estão na RFC 5681. Essa RFC especifica quatro algoritmos
envolvidos no controle de congestionamento do TCP: partida lenta (slow start), prevenção de
80
congestionamento (congestion avoidance), recuperação e retransmissão rápidas (fast
retransmit and fast recovery).
Essa RFC utiliza as seguintes palavras-chaves para guiar o desenvolvedor na
implementação de um protocolo compatível para a Internet: DEVE, NÃO DEVE, EXIGIDO,
DEVERIA, NÃO DEVERIA, RECOMENDADO, PODERIA, OPCIONAL. Essas palavras
chaves e suas interpretações são descritas na RFC 2119. Desse modo, tais palavras ao serem
referenciadas serão escritas integralmente em letras maíusculas de forma a tornar evidente a
especificação da RFC 5681. O desenvolvedor, ao implementar sua versão do protocolo TCP
para torná-lo compatível com a Internet, deve seguir as especificações dessa RFC.
A RFC 5681 especifica que a implementação do TCP DEVE usar os algoritmos de
partida lenta e de controle de congestionamento para controlar a quantidade de dados que são
injetados dentro da rede pelo remetente.
Ainda, segundo a RFC, o algoritmo de partida lenta é usado quando o tamanho da
janela de congestionamento é menor que o limiar (cwnd < ssthresh), enquanto que o
algoritmo de controle de congestionamento é usado quando o tamanho da janela de
congestionamento é maior que o limiar (cwnd > ssthresh). Se cwnd e ssthresh são iguais, o
remetente PODE optar entre um ou outro algoritmo.
Na RFC, a janela de congestionamento do TCP é descrita como uma variável de
estado que limita a quantidade de dados que pode ser enviada pelo remetente. Ainda, segundo
esse documento, em algumas situações, PODE ser mais benéfico para o TCP remetente ser
mais conservador que o algoritmo de controle de congestionamento original do TCP. É
cecessário frisar que a RFC especifica que o controle de congestionamento do TCP a ser
implementado NÃO DEVE ser mais agressivo que o controle de congestionamento do TCP
original.
A RFC também define qual deve ser o valor inicial da janela de congestionamento
quando o TCP remetente inicia sua transferência de dados. O remetente DEVE usar a seguinte
estrutura condicional para defini-lo:
Sendo SMSS o tamanho máximo do segmento que o remetente é capaz de transmitir e
IW sendo o valor da janela inicial, tem-se:
Se SMSS > 2190 bytes, então
IW = (2 * SMSS bytes) e IW NÃO DEVE conter mais que dois segmentos
Se (SMSS > 1095 bytes) e (SMSS < 2190 bytes)
IW = (3 * SMSS bytes) e IW NÃO DEVE conter mais que três segmentos
Se (SMSS <= 1095 bytes)
IW = (4 * SMSS bytes) e IW NÃO DEVE conter mais que quatro segmentos
81
Conforme já mencionado, durante a fase de partida lenta, a janela de
congestionamento do remetente é aumentada em um SMSS a cada ACK recebido. Entretanto,
um destinatário pode induzir o remetente a aumentar artificialmente sua janela de
congestionamento, utilizando uma técnica conhecida como “ACK division”. Essa técnica
consiste no destinatário confirmar o recebimento de um único segmento de dados utilizando
múltiplos segmentos ACKs, em que cada segmento confirme apenas uma porção desses
dados.
Para evitar esse aumento artificial, a RFC 5681 RECOMENDA que o incremento da
janela de congestionamento no remetente seja feito utilizando a fórmula em (1):
cwnd+=mínimo(N,SMSS) (1)
na qual, N é o número de bytes que está sendo reconhecido pelo destinatário.
Também são definidos critérios para padronizar o crescimento da janela de
congestionamento no remetente. A RFC divide o crescimento da janela em duas fases: 1)
crescimento da janela quando o valor da janela é menor que o limiar; e 2) crescimento da
janela quando seu valor é maior que o limiar.
Na fase de partida lenta (cwnd < ssthresh), a janela é incrementada utilizando a
fórmula em (1). Na fase de prevenção de congestionamento (cwnd > ssthresh) a janela de
congestionamento DEVE ser incrementada obedecendo aos seguintes critérios especificados
pela RFC 5681:
Ela PODE ser incrementa por SMSS bytes;
DEVE SER incrementada utilizando a equação cwnd+= min (N, SMSS) a cada RTT;
NÃO DEVE incrementar a janela mais que SMSS bytes;
Com relação ao valor de limiar (ssthresh), a RFC EXIGE que seu valor seja
arbitrariamente alto, porém, esse valor DEVE ser reduzido em resposta a um
congestionamento detectado. Quando o remetente detectar um segmento perdido, tendo como
causa um timeout, desde que seja o primeiro timeout desse segmento, o valor do limiar
(ssthresh) DEVE ser ajustado para não mais que a metade dos dados que estão “flutuando na
rede” (segmentos não confirmados) (FlightSize/2) ou 2 * SMSS, o que for maior. Porém, se o
timeout se referir a um segmento que já foi transmitido ao menos uma vez, o valor de limiar
não é alterado.
Com relação aos algoritmos de recuperação e retransmissão rápidas a implementação
do protocolo TCP no destinatário DEVE enviar imediatamente um ACK duplicado quando
um segmento é entregue pela rede fora da ordem esperada. Adicionalmente, o destinatário
DEVE enviar imediatamente um ACK com a chegada de um segmento preenchendo a lacuna
causada pelo segmento entregue fora de ordem.
82
O protocolo TCP a ser implementado DEVE usar o algoritmo de retransmissão rápida
quando detectar a chegada de ACKs duplicados. Os detalhes de como implementar os
algoritmos de retransmissão e recuperação rápidas estão disponíveis nessa RFC.
Resumidamente, essas são as diretrizes que norteiam o desenvolvedor durante a
implementação do controle de congestionamento do protocolo TCP compatível com a
Internet, de modo que o desenvolvedor deve segui-las caso deseje que seu protocolo torne-se
compatível segundo os padrões da IETF.
Os quatro algoritmos que integram o controle de congestionamento do TCP original
são reconhecidos pela IETF por serem algoritmos de elevado nível técnico e maturidade que
são capazes de oferecer serviço de entrega confiável na Internet mantendo a integridade da
Internet. Dito isto, qualquer implementação futura do TCP deve atender esses padrões.
Conclui-se que a Internet necessita de uma padronização mínima capaz de mantê-la
utilizável. A falta de uma organização mínima na Internet poderia fazer com que ela entrasse
em um colapso impedindo sua utilização pela comunidade. Nesse sentido a IETF pode ser
enxergada como uma guardiã da Internet estabelecendo padrões para mantê-la. Desse modo,
há vários padrões que devem ser seguidos pelos seus participantes a fim de manter a rede
íntegra.
6.3 Uma nova abordagem
Conforme visto na Seção 6.1, é possível visualizar como se comportou a janela de
congestionamento do TCP remetente em cada instante da simulação realizada. Foi com base
nessa observação que surgiu a ideia de propor o modelo descrito a seguir. A ideia se baseia
em, utilizando uma abordagem simplista, “fatiar” o período de transmissão de uma conexão
TCP em períodos menores. Desse modo, cada “fatia” de tempo pode ser analisada a partir dos
seguintes aspectos: a quantidade de segmentos transmitidos e a quantidade de eventos de
perda disparados por timeouts, ou seja, a quantidade de segmentos reconhecidamente
perdidos. Essa ideia pode ser resumida com o auxílio da Figura 25 a seguir.
83
Sendo ti o tempo entre uma fatia e outra, e denotando Wi como a janela de
congestionamento corrente em ∆i, em que ∆i = ti – ti-1, e denotando Ei como o número de
segmentos perdidos no período ∆i, pode-se inferir que o total de segmentos transmitidos
durante o tempo t pode ser dado em (1).
∑=
−
t
i
iiEW
0 (1)
Essa expressão, no TCP remetente, representa a somatória de todos os segmentos
enviados excluindo-se os segmentos reconhecidamente perdidos ao longo da transmissão.
Diante do exposto, com a possibilidade de se analisar a janela de congestionamento
em um determinado instante mensurando sua quantidade de segmentos transmitidos
(segmentos confirmados) e a quantidade de segmentos perdidos, é possível então ao somar as
observações anteriores, determinar a média da confiabilidade do enlace por meio da fórmula
em (2):
∑
∑
=
=
=t
oi
i
t
oi
i
W
E
errosdetaxa __
(2)
Em outras palavras, a taxa de erros é obtida dividindo-se a quantidade de segmentos
perdidos pela quantidade de segmentos transmitidos/confirmados observados
cumulativamente desde o início da transmissão até o momento corrente da transmissão.
Essa estimativa considera todos os segmentos, incluindo os segmentos retransmitidos,
uma vez que segmentos novos e segmentos retransmitidos utilizam igualmente a capacidade
do enlace. Vale destacar que essa estimativa diz respeito ao já observado, não sendo possível,
obviamente, prever o comportamento futuro da janela de congestionamento.
t
ti-1 ti ti+1 ... ti+n -1 ti+n
Wi-1 – Ei-1
Wi – Ei
Wi+1 – Ei+1
…
Wi+n-1 – Ei+n-1
Wi+n – Ei+n
Figura 25 - Estimativa da taxa de transmissão de uma conexão TCP durante tempo t.
Total_transmitido =
84
Acredita-se que durante a conexão, o TCP remetente possa utilizar essa informação
valendo-se da taxa de erros até então mensurada para auxiliá-lo a tomar decisões mais
acertadas diante da ocorrência de eventos de perda.
Para isso, seria necessário que o TCP remetente armazenasse em memória a
quantidade de segmentos perdidos, acumulando em um contador as ocorrências de eventos de
perdas (timeouts e recebimento de ACKs duplicados) durante toda a transmissão. Seria
também necessário armazenar em um contador a quantidade de segmentos transmitidos com
sucesso (ACKs não repetidos). Para cada contador poderia ser utilizado uma variável do tipo
inteiro de 32 bits. Acredita-se que essas variáveis, ao serem implementadas, não causarão
overhead.
De posse da taxa de perdas percebidas até o momento, o TCP remetente ao reduzir sua
janela de congestionamento diante de um evento de perda, poderia aplicar essa taxa como
fator redutor da janela. Por exemplo, se a taxa de perda mensurada pelo TCP remetente é de
15%, na próxima ocorrência de um evento de perda, a janela de congestionamento poderia ser
reduzida em 15% do seu tamanho atual. Se a taxa de erros mensurada fosse menor, o TCP
remetente diminuiria menos sua janela de congestionamento.
A diminuição da janela de congestionamento passaria a ter um valor flexível, diferente
da abordagem utilizada pelo TCP original que utiliza um valor fixo, ou seja, a metade da
janela corrente, conforme já mencionado.
O principal inconveniente dessa abordagem é não respeitar a recomendação da RFC
5681 quando afirma que uma nova implementação do TCP NÃO DEVE ser mais agressiva
que o TCP original. O TCP original reduziria sua vazão pela metade e essa nova abordagem
reduziria sua vazão com base na taxa de erros observada, podendo ser mais ou menos que a
metade da janela.
Entretanto, caso o TCP original, depois de reduzir sua janela de congestionamento
pela metade, se recuperar e voltar a transmitir na mesma taxa de antes do evento de perda,
pode-se considerar que essa nova abordagem não foi mais agressiva que a versão original do
TCP.
O sucesso dessa abordagem irá depender muito da estabilidade do canal, pois se a
taxa média de erros desse canal se mantiver relativamente constante, a chance do TCP
remetente aplicar uma taxa de redução relativamente coerente com a realidade do enlace
torna-se muito maior.
Se o enlace tiver poucas variações em sua taxa de confiabilidade durante a conexão, a
decisão de diminuir a janela de congestionamento do TCP remetente, utilizando como fator de
85
redução a taxa de erros do enlace percebida, poderá permitir que sua janela de
congestionamento tenha poucas variações, permitindo assim uma melhor utilização do enlace.
Outra vantagem na utilização dessa abordagem está na possibilidade de comparar a
taxa de erros média com a taxa de erros da janela corrente. A comparação dessas duas
informações poderá dar ao TCP remetente a condição de perceber que naquele momento o
enlace apresenta um comportamento diferente do mensurado até o momento, a qual se
tornaria uma estratégia para fazer com que o TCP remetente reconhecesse a estagnação de
suas variáveis: janela de congestionamento e número de sequência, conforme mencionado na
Seção 5.3.
A Figura 26 ajuda a visualizar melhor essa afirmação mostrando uma conexão TCP
dividida em intervalos. A título de exemplo, cada intervalo contém uma janela, na qual é
possível visualizar, na cor azul, a quantidade de segmentos transmitidos com sucesso, e por
meio da cor vermelha, a quantidade de segmentos perdidos detectados.
Figura 26 - Janela de congestionamento do protocolo TCP fatiada em intervalos de tempo.
A soma dos eventos de perdas dividida pela soma dos segmentos transmitidos dará à
conexão uma taxa média de erros. Porém, se a janela de congestionamento corrente começar a
apresentar uma taxa de erros superior à média já mensurada, essa informação poderá
significar para o TCP remetente que o enlace passa por uma dificuldade diferente daquelas já
mensuradas.
86
Figura 27- Janela de congestionamento do protocolo TCP fatiada em intervalos de tempo. Última fatia
com taxa de erros maior que as outras.
Percebe-se na Figura 27 que a janela corrente apresenta uma taxa de perdas maior do
que a taxa de perdas das janelas anteriores. Essa comparação poderá ser feita com o auxílio da
fórmula em (3):
∑
∑−
=
−
=
>1
0
1
0
i
n
n
i
n
n
i
i
W
E
W
E
(3)
Em que i
i
W
E
denota a taxa de erro corrente e ∑
∑−
=
−
=
1
0
1
0
i
n
n
i
n
n
W
E
denota a taxa de erros média
acumulada até o momento i – 1. Se a taxa de erros da janela corrente (iésima janela) é maior
que a taxa de erros média mensurada (iésimas -1 janelas), pode-se afirmar que nesse momento
o enlace passa por uma dificuldade “diferente” daquelas já experimentadas por ele.
Essa comparação poderá ser utilizada toda vez que ocorrer eventos de perda de
segmento sequenciais pelo TCP remetente. Uma vez que constatada a ocorrência dessa
circunstância, haverá uma grande possibilidade do enlace estar sujeito a uma falha.
Acredita-se que essa condição sempre será satisfeita quando ocorrer uma falha no
enlace, uma vez que essa ocorrência provocará nas variáveis do TCP remetente um
comportamento diferente daquele em que o enlace proporcionaria ao estar em condições
relativamente normais.
87
Na prática, a quantidade de segmentos transmitidos pode ser computada utilizando-se
a quantidade de confirmações (segmentos ACKS) recebidas, e a quantidade de segmentos
perdidos pode ser computada utilizando-se a quantidade de eventos de perdas (timeouts)
percebidos.
Diante do exposto, o Fluxograma 1 mostra como essa ideia poderá ser implementada.
Fluxograma 1 - Detecção de falha no enlace.
Conforme pode ser visto, a cada ocorrência de um novo timeout, o TCP remetente
verifica se estão ocorrendo perdas sequenciais. Ao detectar timeouts sequenciais ele passará a
verificar se sua taxa de perda atual é maior que a taxa média de perda até então mensurada. Se
essa comparação for afirmativa, isso pode ser interpretado como falha no enlace, não restando
outra melhor alternativa para o TCP remetente senão reiniciar seus temporizadores para evitar
prematuros timeouts e passar então a sondar o estado do enlace.
Após detectar o restabelecimento do enlace, o TCP remetente poderá voltar a
transmitir nas mesmas condições anteriores à falha. Essa abordagem pode dar ao TCP um
melhor desempenho diante de tais eventos.
Conclui-se que, dispondo o TCP remetente da capacidade de realizar tais
comparações, seria dada a ele a capacidade de diferenciar entre congestionamento da rede e
falhas no enlace.
TIMEOUT SEQUENCIAL?
SIM NÃO
REDUZ JANELA USANDO COMO
FATOR DE REDUÇÃO A
TAXA DE PERDA TAXA DE PERDAS ATUAL >
TAXA DE PERDAS MÉDIA ?
NÃO
REINICIA OS TEMPORIZADORES
SONDA O ESTADO DO ENALCE
SIM
88
6.4 TCP-UEM – Uma Nova Proposta
A seção anterior mostrou que o TCP remetente, ao armazenar a quantidade de
segmentos transmitidos e a quantidade de eventos de perda durante sua conexão, poderá
utilizar essas duas informações para reduzir sua janela de congestionamento com base no
comportamento apresentado pelo enlace até a ocorrência de um evento de perda.
Também mostrou que a média de erros mensurada pelo TCP remetente pode ser usada
para ser comparada com a média de erros atual da conexão. Tal informação poderia ser
utilizada para detectar padrões diferentes dos já mensurados, dando ao remetente a capacidade
de interpretá-los como falhas no enlace.
Esta seção descreve como foi desenvolvido, passo a passo, com o auxílio de
algoritmos e fluxogramas, o TCP-UEM, cuja principal característica é a detecção de falhas no
enlace mantendo a semântica fim a fim do TCP original.
6.4.1 TCP-UEM – Tratamento de ACK válido
Nesta seção é descrita a implementação do procedimento responsável pelas ações
necessárias no TCP-UEM quando ele recebe do destinatário um segmento de confirmação
(ACK).
A chegada de um segmento ACK dispara no TCP original a execução de diversas
tarefas, tais como:
• Verificação da validade do segmento ACK;
• Verificação se esse segmento ACK é duplicado;
• Atualização de variáveis que permitem o deslizamento da janela de congestionamento;
• Cancelamento dos temporizadores e a liberação de dados em memória referentes aos bytes
que estão sendo confirmados pelo segmento de confirmação;
• Contabilização dos segmentos de confirmação duplicados que podem disparar no TCP
remetente seus mecanismos de retransmissão e recuperação rápidos (RFC 5681).
Essas tarefas são de vital importância para fazer com que a dinâmica do TCP funcione,
assim, por esse motivo, elas são mantidas no TCP-UEM. Observa-se que nenhuma
especificação da RFC 5681 é violada.
Entretanto, além dessas tarefas, esse procedimento no TCP-UEM é responsável por
auxiliar a variante na mensuração da taxa de erros do enlace. Esse auxílio se dá com a
89
atualização de algumas variáveis quando um segmento de confirmação válido é recebido.
Essa tarefa é realizada nos seguintes moldes:
Ao receber um ACK válido, o TCP-UEM atualiza o estado da variável denominada
queda_no_enlace, de tipo boleano, para falso. Essa variável é uma das principais, pois é ela
que indica para o TCP-UEM o estado do enlace.
É nesse procedimento que se identificará o restabelecimento no enlace, o qual ocorrerá
sempre que o TCP-UEM remetente receber um ACK válido e o valor de sua variável
queda_no_enlace for verdadeiro. Essa identificação causará a restauração dos valores do
limiar e da janela de congestionamento para valores anteriores a queda no enlace, garantindo
assim que o remetente volte a transmitir na mesma taxa em que transmitia antes da ocorrência
da falha.
Esses valores são obtidos das variáveis janela_anterior_queda_enlace e
limiar_anterior_queda_enlace. Essas duas variáveis são responsáveis por armazenar o estado
da janela de congestionamento do TCP-UEM antes da ocorrência de um evento de perda.
A identificação no restabelecimento do enlace causará no remetente a atualização das
variáveis quantidade_segmentos_validos e quantidade_segmentos_perdidos para o valor zero
(0). Essas duas variáveis armazenam a quantidade de segmentos transmitidos com sucesso e a
quantidade de segmentos perdidos, respectivamente. É com base nos valores dessas duas
variáveis que o TCP-UEM calculará a taxa de perdas mensurada do canal, ou seja, após o
TCP-UEM se recuperar de uma falha no enlace, a estatística anterior será desprezada.
A decisão de zerar essas variáveis quando o enlace sai do estado falho para o estado
normal assegura que o TCP-UEM remetente passará a obter uma nova estatística de
confiabilidade do enlace após o seu restabelecimento, pois esse enlace pode não apresentar as
mesmas condições daquelas anteriores à falha.
Independentemente da condição do estado do enlace, a chegada de um ACK válido
sempre atualizará as variáveis responsáveis pela estatística relacionada à condição do enlace.
Isso se dá com a atualização das variáveis quantidade_de_segmentos_validos e
contador_de_timeouts_sequenciais. A primeira é incrementada em uma unidade, ficando com
a tarefa de armazenar a quantidade de segmentos válidos entregues com sucesso para o
destinatário. A segunda tem seu valor reiniciado para zero, sendo essa variável responsável
por informar ao TCP-UEM remetente sobre a ocorrência de timeouts sequenciais. A chegada
de um ACK válido interrompe a contagem de timeouts sequenciais. Para o TCP-UEM a
ocorrência de dois timeouts seguidos é interpretada como perdas sequenciais.
90
As variáveis janela_anterior_queda_enlace e limiar_anterior_queda_enlace são
atualizadas, garantindo que os valores atuais da janela de congestionamento e seu limiar
sejam correntes.
Nesse procedimento a base da janela é sempre monitorada com o auxílio da variável
numero_base_janela_monitorado, a qual é responsável por informar ao TCP-UEM se sua
janela mantém-se estagnada.
Essa dinâmica é mais bem compreendida com o auxílio do algoritmo a seguir e do
Fluxograma 2:
PROCEDURE RECEBE_ACK
/* outras tarefas */
Se (ack_valido) {
/*outras tarefas*/
Se (queda_no_enlace) {
janela_atual = janela_anterior_queda_enlace;
limiar_atual = limiar_anterior_queda_enlace;
quantidade_segmentos_validos = 0;
quantidade_segmentos_perdidos = 0;
}
queda_no_enlace = false;
quantidade_segmentos_validos++;
janela_anterior_queda_enlace = janela_atual;
limiar_anterior_queda_enlace = limiar_atual;
numero_base_janela_monitorado = highest_ack_ + 1;
contador_de_timeouts_sequenciais = 0;
}
/* … */
91
Fluxograma 2: Procedimento para tratamento de segmento de confirmação.
6.4.2 TCP-UEM – Ocorrência de timeout
Esta seção descreve a implementação das ações realizadas pelo protocolo quando
ocorrerem timeouts. Esse é o procedimento mais importante para o TCP-UEM, pois é nesse
procedimento que a decisão de avaliar se o enlace está falho ou não é tomada.
No TCP original, a ocorrência de um timeout é interpretada como congestionamento
da rede. Esse evento provoca no TCP remetente a redução de sua janela de congestionamento
e essa redução pode ocorrer em maior ou menor grau dependendo da versão do TCP utilizada.
No TCP-UEM, além de manter essa característica, outras ações são realizadas.
A forma com que a variante TCP-UEM tenta identificar falhas no enlace começa com
a avaliação da base da janela de congestionamento a cada ocorrência de um evento de perda.
Essa avaliação consiste em verificar se sua base da janela de congestionamento encontra-se
estagnada. Isso é feito com o auxílio da variável numero_base_janela_monitorado. Essa
EXECUTAR OUTRAS TAREFAS
ACK VÁLIDO? SIM NÃO
EXECUTAR
OUTRAS
TAREFAS
QUEDA NO ENLACE? NÃO
SIM
RESTAURA JANELA E LIMIAR PARA ESTADO ANTERIOR
REINICIA MENSURAÇÃO CONFIABILIDA-DE DO ENLACE
ARMAZENA O ESTADO DA JANELA CORRENTE
MONITORA SEGMENTOS VÁLIDOS E BASE DA JANELA
ATUALIZA VARIÁVEL QUEDA_ ENLACE PARA FALSO E ZERA CONTAGEM DE TIMEOUTS SEQUENCIAIS
92
variável é utilizada para saber se a base da janela de congestionamento do TCP-UEM se
mantém inalterada a cada ocorrência de perda de segmento.
Cada vez que essa condição é satisfeita, a variável denominada
contador_de_timeouts_sequenciais passa a ser incrementada em uma unidade. Se seu valor
indicar a ocorrência de mais de um timeout, consequentemente a variável perda_sequencial
receberá o valor verdadeiro. A variável perda_sequencial é responsável por indicar ao TCP-
UEM que perdas ou timeouts sequenciais estão ocorrendo. Ademais, a cada evento de timeout
a variável quantidade_segmentos_perdidos é incrementada em uma unidade.
Depois de realizadas essas tarefas, o TCP-UEM realiza sua principal comparação para
identificar uma possível falha no enlace por meio da fórmula
∑
∑−
=
−
=
>1
0
1
0
i
n
n
i
n
n
i
i
W
E
W
E. Essa
comparação é realizada com o auxílio das variáveis quantidade_segmentos_perdidos e
quantidade_segmentos_validos, as quais representam a taxa de perdas do enlace acumulada
até então dado em (1).
validossegmentosquantidade
perdidossegmentosquantidade
W
E
i
n
n
i
n
n
__
__
1
0
1
0=
∑
∑−
=
−
=
(1)
Para mensurar a taxa de perdas atual, as variáveis cwnd e
contador_de_timeouts_sequenciais são utilizadas. A variável cwnd indica o tamanho da janela
atual. Dessa forma, a taxa de erros atual pode ser obtida por meio da fórmula em (2).
cwnd
ssequenciaitimeoutsdecontador
W
E
i
i___
= (2)
As duas taxas apresentadas em (1) e (2) são comparadas e verificando-se que a taxa de
perdas atual é maior que a taxa de perdas acumulada, o TCP-UEM atualizará sua variável
queda_no_enlace para o valor verdadeiro.
Após identificar a queda no enlace, o TCP-UEM reinicia todos os seus temporizadores
e envia um segmento de um único byte com o objetivo de testar o estado do enlace.
Todo esse procedimento é descrito por meio do algoritmo a seguir e do Fluxograma 3:
PROCEDURE TIMEOUT {
/* … */
Se (numero_base_janela_monitorado == (base_da_janela_atual)) então
93
contador_de_timeouts_sequenciais ++; // estagnação da janela
Se ((contador_de_timeouts_sequenciais > 1) && (!perda_sequencial) então
perda_sequencial = true;
quantidade_segmentos_perdidos ++;
Se ((quantidade_segmentos_perdidos / quantidade_segmentos_validos) >
(contador_de_timeouts_sequenciais / cwnd)) && (perda_sequencial)
então queda_no_enlace = true;
Se (queda_no_enlace) então {
envia_segmento(um_byte); //sondar o estado do enlace até o recebimento de um ACK.
reinicia_temporizadores();
return;
}
/* … */
}
94
Fluxograma 3 - Procedimento a ser realizado quando ocorrerem detecções de perda de segmento.
TIMEOUT? SIM NÃO
EXECUTAR
OUTRAS
TAREFAS
BASE DA JANELA ESTAGNADA?
ATUALIZA VARIÁVEL
PERDA_SEQUEN-CIAL PARA TRUE
SIM INCREMENTA ATUALIZADOR
DE PERDAS SEQUENCIAIS
PERDAS SEQUENCIAIS?
SIM
QUANTIDADE_ SEGMENTOS_ PERDIDOS++
ATUALIZA VARIÁVEL
QUEDA_ENLACE PARA TRUE
TAXA DE ERROS ATUAL > TAXA DE ERROS MÉDIA?
SIM
QUEDA NO ENLACE?
SIM SONDA ESTADO DO ENLACE
REINICIA TEMPORIZADORES
NÃO REDUZ
JANELA DE CONGESTIONA-
MENTO
95
6.4.3 TCP-UEM - Dinâmica da Janela de Congestionamento
O último procedimento implementado diz respeito à forma com que o TCP-UEM
reduz sua janela de congestionamento. A dinâmica utilizada é a mesma descrita na Seção 6.2,
em que a taxa de perdas é utilizada como fator para diminuição da janela de
congestionamento.
Já foi mencionado que o comportamento do TCP original é conhecido como "dentes
de serra". Esse comportamento é devido ao algoritmo AIMD (Aditive Increase and
Multiplicative Decrease) – Aumento Aditivo e Diminuição Multiplicativa, que faz com que a
diminuição da janela seja mais rápida que seu aumento.
Dependendo da versão do TCP, a janela de congestionamento é reduzida pela metade
ou para um MSS após a ocorrência de um evento de perda. Suponha que essa diminuição
ocorra, motivada por um evento de perda, por ter o remetente alcançado o limite do enlace.
Suponha também que o tamanho da janela era de 100 segmentos quando esse limite foi
alcançado. Na melhor das hipóteses o evento de perda reduzirá pela metade o tamanho da
janela.
Esse comportamento pode penalizar a taxa de transmissão do remetente, pois até que a
janela volte a alcançar novamente o tamanho de 100 segmentos, parte da capacidade do
enlace permanecerá ociosa.
A variante TCP-UEM, ao contrário do comportamento original do TCP, diminui a sua
janela de congestionamento utilizando como referência a taxa de erros mensurada desde a
ocorrência de uma falha no enlace ou, caso nenhuma falha tenha ocorrido, desde o
estabelecimento da conexão. Ressalta-se que essa abordagem pode fazer com que o TCP-
UEM não atenda uma das especificações da RFC 5681, que afirma que a janela de
congestionamento não deve ser mais agressiva que o algoritmo do TCP original.
A principal ideia é reduzir a amplitude do comportamento padrão de "dentes de serra"
do TCP original, permitindo que o tamanho de sua janela de congestionamento permaneça
sempre próximo da capacidade do enlace.
Além de utilizar a taxa de perdas para reduzir sua janela de congestionamento, a
variante TCP-UEM também faz uso de um fator potencializador que pode aumentar a
velocidade de diminuição da janela, considerando o valor armazenado nesse fator
potencializador. Nesse contexto, uma nova variável é utilizada, denominada
fator_de_redução, que é utilizada pelo TCP-UEM como um fator encorajador de redução de
janela, sendo seu valor multiplicado pela taxa de erros mensurada. O resultado dessa operação
determinará o valor de redução da sua janela.
96
O seu funcionamento se dá da seguinte maneira: a variável fator_de_redução ganhará
força a cada ocorrência de ACKs duplicados, em contrapartida perderá força a cada
recebimento de ACKs válidos. Seu valor nunca será inferior a um para assegurar que a taxa de
perdas nunca seja inferior a ela mesma. Em outras palavras, caso o número de ocorrências de
DUPACKs não ultrapasse o número de chegada de ACKs válidos, a redução da janela de
congestionamento nunca será inferior à taxa de perdas mensurada.
De outra forma, se em um dado momento o número de DUPACKs que chegam ao
remetente for superior ao número de ACKs válidos, a variável fator_de_redução ganhará
força e causará uma redução maior da janela de congestionamento ao ser multiplicado pela
taxa de perdas. Por exemplo, se a variável fator_de_redução contiver o valor dois, então a
redução será duas vezes a taxa de perdas. Essa dinâmica assegura que a janela de
congestionamento diminua de forma mais rápida quando o remetente estiver recebendo
muitos segmentos de confirmação repetidos.
Dessa forma o remetente diminui a probabilidade de enviar desnecessariamente novos
segmentos, tendo em vista que os buffers do destinatário podem estar esgotados se considerar
que para liberá-los o destinatário esteja aguardando dados mais antigos que tenham se perdido
durante a transferência.
O algoritmo a seguir descreve o comportamento da janela de congestionamento do
TCP-UEM.
PROCEDURE REDUZ_JANELA(VAR JANELA) {
/*…*/
quantidade_segmentos_perdidos++;
se (partida_lenta) {
limiar = janela;
janela = janela / 2;
partida_lenta = false;
} senão {
double taxa_de_perdas = (quantidade_segmentos_perdidos / quantidade_segmentos_validos) * janela;
limiar = janela;
taxa_de_perdas = taxa_de_perdas * fator_de_redução;
if (taxa_de_perdas < 1) then taxa_de_perdas = 1.0;
janela = limiar – taxa_de_perdas;
}
if (janela < 1) then janela = 1.0;
/*…*/
}
Conforme o algoritmo, o TCP-UEM realiza as seguintes tarefas: i) Reduz o tamanho
de sua janela de congestionamento e incrementa a variável quantidade_segmentos_perdidos;
97
ii) Calcula a taxa de perdas em valores de segmentos; iii) Diminui sua janela de
congestionamento pela metade caso o evento de perda tenha acontecido durante a primeira
fase de partida lenta; iv) Reduz o tamanho de sua janela de congestionamento utilizando para
isso a variável fator_de_redução; v) Assegura que a taxa de perdas não seja inferior a um
segmento; vi) Assegura que o tamanho mínimo de sua janela não seja inferior a um segmento.
Caso haja uma ocorrência de perda de segmento fora da fase de partida lenta, o TCP-
UEM atribuirá o tamanho de sua janela atual para o valor de seu limiar (threshold) fazendo
com que ele entre na fase de prevenção de congestionamento.
Cabe enfatizar uma peculiaridade da variante TCP-UEM, a qual diz respeito a reduzir
sua janela de congestionamento pela metade quando ele estiver pela primeira vez na fase de
partida lenta. A necessidade de se adotar essa estratégia é explicada na Seção 6.4.
Depois de implementada no simulador, essa estratégia foi submetida a uma simulação
cujo enlace possuia 100% de índice de confiabilidade. Os resultados dessa simulação são
apresentados na Figura 28, a qual mostra o comportamento da janela do TCP-UEM
comparado ao comportamento “dentes de serra” do TCP original.
Figura 28 - Comportamento das janelas de congestionamento das variantes TCP-Newreno e TCP-UEM
sobre um enlace 100% confiável.
Percebe-se na figura que o TCP-UEM manteve sua janela de congestionamento com
uma amplitude de variação menor que a do TCP-Newreno. Dessa forma o TCP-UEM
manteve o tamanho de sua janela de congestionamento variando sempre muito próximo da
capacidade limite do enlace.
98
6.5 TCP-UEM - O problema da Convergência Demorada
A fase de partida lenta do TCP original, devido ao aumento exponencial da sua janela,
alcança valores elevados no início, os quais não condizem com a real capacidade do enlace.
Isso faz com que o TCP supere rapidamente a capacidade do canal, nesse momento os
segmentos não serão confirmados, pois o enlace não é capaz de dar toda a vazão exigida pelo
TCP. A perda de segmentos continuará até que um evento de perda seja detectado.
Dito isso, o TCP-UEM, depois da fase de partida lenta, terá um valor de janela elevado
para só então aplicar seu mecanismo de redução. Quanto maior o valor da janela alcançado na
fase de partida lenta, mais demorada será a convergência para alcançar a taxa ideal do enlace.
Para resolver esse dilema, o TCP-UEM reduz sua janela de congestionamento pela
metade após a ocorrência do primeiro evento de perda enquanto ele estiver na sua primeira
fase de partida lenta. Essa estratégia assegura que o TCP-UEM convirja de forma mais rápida
para a taxa limite do enlace, uma vez que a possibilidade de perdas de segmentos durante o
novo crescimento da janela é menor, pois nessa fase o remetente não está sobrecarregando o
canal, permitindo que os segmentos transmitidos tenham grandes possibilidades de serem
entregues. Em contrapartida, se o TCP-UEM remetente mantiver os valores de pico
alcançados na fase de partida lenta, tendo em vista sua dinâmica de redução da janela, muitos
segmentos serão perdidos até que a taxa ideal de transmissão seja alcançada.
Com exceção da primeira redução da janela, todas as outras reduções utilizarão como
fator de redução a taxa de perdas mensurada pelo remetente.
A Figura 29 mostra o comportamento do TCP-UEM utilizando essas duas abordagens.
Figura 29 - Convergência para a taxa ideal de transmissão com e sem redução da janela na primeira fase
de partida lenta.
99
A abordagem de utilizar a taxa de perdas como fator de redução após a fase de partida
lenta fez com que o TCP-UEM demorasse a convergir para o limite da capacidade do enlace,
provocando assim muitas perdas de segmentos e, consequentemente, maior número de
retransmissões e menor quantidade de dados transmitidos no final.
A abordagem de reduzir a janela de congestionamento pela metade, após a fase de
partida lenta, assegura que o TCP-UEM alcance rapidamente o limite da taxa de transmissão
do enlace. É com base nessa dinâmica que o TCP-UEM reduzirá sua janela de
congestionamento toda vez que detectar um evento de perda.
Figura 30 - Comportamento das janelas de congestionamento das variantes TCP-Newreno e TCP-UEM
sobre um enlace 100% confiável.
6.6 RFC 5681 X TCP-UEM
Conforme descrito na Seção 6.2, a RFC 5681 especifica o controle de
congestionamento do TCP em seus quatros algoritmos: partida lenta, controle de
congestionamento, retransmissão e recuperação rápidas.
Cabe observar que a principal característica do TCP-UEM é a detecção de falha no
enlace mantendo a semântica fim a fim do TCP. Conforme demonstrado, isso é feito com o
auxílio de variáveis que contabilizam a quantidade de segmentos transmitidos e confirmados e
a quantidade de eventos de perdas.
As exigências da RFC 5681 resumem-se na obrigação de utilizar os quatros algoritmos
de controle de congestionamento na implementação do TCP.
O protocolo TCP-UEM usa os algoritmos de partida lenta, retransmissão e
recuperação rápidas do TCP original sem fazer nenhuma alteração mantedo-os originais.
100
O TCP-UEM altera a dinâmica do controle de congestionamento do TCP original
somente no modo como a janela é reduzida a cada evento de perda. Nesse ponto, o algoritmo
original de controle de congestionamento do TCP não é preservado.
Como o TCP-UEM reduz sua janela de congestionamento com base na taxa de erros
mensurada, essa redução pode proporcionar uma maior vazão no remetente. Essa maior vazão
pode ser considerada mais agressiva que o protocolo TCP original. Essa dinâmica mais
agressiva do TCP-UEM pode ser interpretada como uma desobediência a RFC 5681, que
exige que novas implementações do TCP não sejam mais agressivas que sua versão
especificada pela IETF.
Acredita-se que essa exigência do RFC pode fazer com que tentativas de melhoras de
desempenho do TCP original esbarrem nessa exigência, uma vez que inflexibiliza um ponto
fundamental do TCP, que é o seu mecanismo de ajuste de vazão. Porém, o desenvolvedor
deve ponderar entre desempenho e compatibilidade com a Internet.
Com essa restrição, o uso do TCP-UEM na Internet fica comprometido. Essa restrição
pode deixar de existir caso o TCP-UEM adote a dinâmica da janela de congestionamento
original do TCP, mantendo somente sua capacidade de detecção de falhas no enlace, uma vez
que a manutenção dessa capacidade não interfere no comportamento correto dos algoritmos
de partida lenta, prevenção de congestionamento, retransmissão e recuperação rápidas.
Se o desempenho for um fator preponderante na escolha do protocolo, nenhuma
alteração será necessária. Entretanto, a utilização do TCP-UEM ficará restrita para uso
somente nas bordas da Internet, ou seja, nas redes de acesso ou de última milha.
6.7 Simulações do TCP-UEM
Esta seção descreve as simulações realizadas para avaliar o funcionamento do
protocolo TCP-UEM.
6.7.1 TCP-UEM Submetido a 12,5% de Probabilidade de
Erro
Antes de serem realizadas simulações comparativas entre o TCP-UEM e outras
variantes do TCP, é necessário exibir as simulações do TCP-UEM nos ambientes já
apresentados, ou seja, exibir o comportamento da janela de congestionamento do TCP-UEM
não só em um ambiente 100% confiável, mas também nos ambientes sujeito a erros e falhas.
101
Figura 31 - Comportamento da janela de congestionamento da variante TCP-UEM submetido a um
enlace com taxa de perdas de 12,5%.
A Figura 31 exibe o comportamento da janela da variante TCP-UEM no ambiente
sujeito a 12,5% de probabilidade de erros. Percebe-se por meio da figura que o TCP-UEM,
durante a simulação, reduziu sua janela de congestionamento para o tamanho mínimo por 8
vezes, diferentemente do TCP-Newreno que nesse mesmo cenário, conforme mostrado na
Seção 5.3, reduziu sua janela de congestionamento para o tamanho mínimo por 42 vezes.
Figura 32 - Comportamento da janela de congestionamento da variante TCP-UEM submetida a um
enlace com taxa de erros de 12,5% e sujeito a falhas no enlace.
102
A Figura 32 exibe o comportamento da janela de congestionamento do TCP-UEM ao
ser submetido a um enlace sujeito a falhas. Esse ambiente é o mesmo utilizado na Seção 5.3, o
qual durante a simulação o enlace sofreu falhas nos instantes 10 a 30 ms, 80 a 120 ms, 160 a
200 ms, 220 a 240 ms e 380 a 395 ms.
O mais importante a ser observado é a constatação de que nos momentos em que o
enlace estava falho, após sua recuperação, a janela de congestionamento do TCP-UEM
manteve-se inalterada. Em outras palavras, o TCP-UEM conseguiu identificar as falhas no
enlace e por isso conseguiu se recuperar, voltando a transmitir na mesma taxa em que
transmitia antes da ocorrência da falha.
Acredita-se que essas características dão ao TCP-UEM a capacidade de transmitir
mais dados que outras variantes, uma vez que sua janela de congestionamento não sofre com
grandes variações, permitindo uma vazão (throughput) maior.
Outra vantagem está na detecção de quedas no enlace que impede que a janela de
congestionamento do TCP-UEM seja reduzida para o tamanho mínimo quando isso ocorre,
permitindo-lhe transmitir na mesma taxa que transmitia antes da ocorrência de falha no
enlace, propiciando também maior vazão.
Porém, resta saber o quanto essas características do TCP-UEM são mais eficientes se
comparado a outras variantes. Para responder essa questão, inicialmente são utilizados como
dados de comparação os resultados obtidos das simulações dos protocolos TCP-Newreno e
TCP-UEM no cenário sujeito a erros (12,5%) e a falhas no enlace. A Figura 33 mostra essa
comparação.
Figura 33 -Comparação da evolução do número de sequência das variantes TCP-UEM e TCP-Newreno.
103
Nota-se que o TCP-Newreno conseguiu alcançar o número de sequência de 2172, ou
seja, 2172 bytes foram transferidos para o destinatário durante a simulação. Já o TCP-UEM,
nesse mesmo cenário, teve um desempenho superior conseguindo transferir 6715 bytes para o
destinatário.
Esses resultados demonstram que o TCP-UEM teve um desempenho superior quando
comparado com o TCP-Newreno. Este resultado, além de encorajar novas simulações em
novos cenários, também estimulou comparações com outras variantes do TCP. A Seção 6.5.2
mostra os resultados das demais comparações.
6.7.2 Comparação do TCP-UEM com outras variantes
Conforme mencionado anteriormente, esta seção apresenta os resultados das
avaliações. A escolha das variantes utilizou como critério a existência de módulos
implementados para o simulador NS2.
Repetindo o cenário da Seção 5.3, o qual é caracterizado pela existência de um enlace
submetido a uma taxa de erros de 12,5% e falhas constantes nos instantes já mencionados, as
variantes TCP-Westwood, TCP-Sack, TCP-Fack, TCP-Vegas, TCP Jersey, TCP-Linux e
TCP-Freeze foram simuladas.
A Tabela 14 apresenta um comparativo com o resultado alcançado por cada variante.
Observa-se que mesmo após novas variantes terem sido incluídas nas comparações, a variante
TCP-UEM manteve-se com o melhor desempenho ao transferir 6715 bytes para o
destinatário.
Tabela 14 - Desempenho das variantes TCP sobre um enlace sujeito a erros e a falhas no enlace.
Variante TCP Número de sequência alcançado.
UEM 6715 JERSEY 2501
NEWRENO 2172 LINUX 2071 FREEZE 2026 VEGAS 1284
WESTWOOD 1259 SACK 1194 FACK 769
As outras variantes se comportaram da seguinte maneira: a variante Jersey foi a
segunda melhor, transferindo 2501 bytes; A variante Newreno teve o terceiro melhor
desempenho sendo capaz de transferir 2172 bytes; em quarto está a variante Linux que
alcançou o número de sequência de 2071, a variante Freeze teve o quinto melhor desempenho
104
alcançando o valor de 2026 bytes. Logo em seguida, com o sexto melhor desempenho,
encontra-se a variante Vegas que atingiu 1284 bytes transferidos. Em sétimo a variante
Westwood por ter alcançado 1259 bytes e em oitavo a variante Sack que transferiu 1194
bytes. Em último, com o pior desempenho está a variante Fack, a qual atingiu apenas 769
bytes transferidos.
O protocolo Jersey, segundo colocado em desempenho nessa simulação, atingiu
37,24% do total transmitido pelo TCP-UEM. Se a comparação for feita com o último
colocado, TCP-Fack, este atingiu 11,45% do desempenho do TCP-UEM.
A Figura 34 exibe o comportamento da janela de congestionamento de cada variante,
em que é possível visualizar como cada variante se comportou quando ocorreram quedas no
enlace. Desse modo, com exceção do TCP-UEM, todas as outras variantes apresentaram
comportamento semelhante com relação às suas janelas de congestionamento, conforme já
havia sido observado na Seção 5.3.
Destoando do comportamento aparentemente semelhante das variantes TCP
apresentadas, a variante TCP-UEM, conforme observado na figura, apresentou um
comportamento da janela de congestionamento diferente dos demais. Essa diferença é
consequência das seguintes características: diminuição da amplitude de variação da janela de
congestionamento durante a transmissão de dados e manutenção do tamanho da janela de
congestionamento após a ocorrência de falhas, conforme pode ser observado nos instantes 10
a 30 ms, 80 a 120 ms, 160 a 200 ms, 220 a 240 ms e 380 a 395 ms.
Essas duas características deram ao TCP-UEM a capacidade de transferir mais dados,
como pode ser observado na Figura 35, a qual mostra o desempenho de cada variante em
função do número de sequência alcançados por cada um deles conforme já demonstrado na
Tabela 14.
105
Figura 34 - Comportamento da janela de congestionamento das variantes TCP-UEM, Jersey, Newreno,
Freeze, Vegas, Westwood, Sack e Fack.
106
Figura 35 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas,
Westwood, Sack e Fack.
Tais comparações demonstram que a variante TCP-UEM obteve o melhor
desempenho quando comparado com as variantes TCP-Jersey, Newreno, Freeze, Vegas,
Westwood, Sack e Fack.
Essa comparação, favorável ao TCP-UEM, realizada apenas em um cenário por uma
única vez carece de comprovação científica, pois é possível afirmar que qualquer outra
simulação, utilizando diferentes sementes para geração de números aleatórios, pode dar a
qualquer outra variante TCP a possibilidade de se apresentar com o melhor desempenho.
Utilizando análise estatística, o próximo tópico mostra se a superioridade do TCP-
UEM perante as outras variantes não é devida ao acaso. A análise estatística também é
utilizada para embasar com cientificidade a afirmação de que a variante TCP-UEM possui
desempenho superior aos das outras variantes comparadas.
O código fonte da variante TCP-UEM para simulações no NS2 versão 2.34 está
disponível no Apêndice A. Todos os procedimentos necessários para implementação do TCP-
UEM estão descritos na máquina de estado finito a seguir:
108
6.8 Considerações finais
Neste Tópico, após mostrar a dinâmica da janela de congestionamento do TCP, foram
definidos os procedimentos para implementação do TCP-UEM, que depois de implementado
no simulador NS2, foi simulado nos ambientes descritos na Seção 5.3.
Os resultados dessas simulações mostraram que o TCP-UEM obteve desempenho
superior se comparado com outras variantes num cenário cujo enlace estava sujeito a erros e
falhas.
A capacidade de identificar falhas no enlace foi uma das principais características que
proporcionaram ao TCP-UEM obter um desempenho superior. Outra característica que
contribuiu para seu melhor desempenho foi a capacidade de diminuir a amplitude de variação
de sua janela de congestionamento, o que proporcionou uma maior vazão.
Porém, a diminuição da amplitude da janela de congestionamento do TCP-UEM o
torna mais agressivo que o TCP original, desrespeitando assim uma exigência da RFC 5681
que especifica padrões de compatibilização com a Internet, restringindo assim seu uso na
Internet. Dessa maneira, seu uso é mais indicado para as redes de acesso ou de última milha.
Ressalta-se que a capacidade do TCP-UEM de identificar falhas no enlace não
depende do auxílio de outras camadas da rede, o que preserva sua semântica fim a fim,
proporcionando sua fácil utilização bastando apenas atualizar o TCP remetente.
Na Seção 6.5 evidenciou o problema da convergência demorada que trata da
diminuição do desempenho causado pelo remetente quando este utiliza uma vazão maior que
a suportada pelo enlace por um longo período de tempo, causando muitas perdas e
retransmissões de segmentos. Esse problema foi corrigido dando ao TCP-UEM uma segunda
fase de partida lenta após a ocorrência do primeiro timeout.
Acredita-se que identificar falhas no enlace quando elas ocorrem impedindo que o
TCP inicie sua fase de partida lenta, proporcionando que a taxa de transmissão no remetente
se mantenha após o restabelecimento do enlace, o auxilia a conseguir uma melhor utilização
do enlace, principalmente nos cenários de redes sem fio em que tais falhas são comuns.
109
7. Simulações e análises estatísticas
dos resultados
O objetivo deste Tópico é apresentar uma análise estatística dos dados obtidos nas
simulações e avaliar se é possível descartar, respeitando o nível de significância
predeterminado, a seguinte hipótese nula: Nenhuma das variantes TCP simuladas interfere no
desempenho observado, o qual diz respeito à quantidade total de bytes transferidos para
destinatário, representado pela observação da variável número de sequência durante o período
de simulação.
O software Minitab® (Minitab, 2012), versão 15.1.30.0, foi utilizado para a realização
dessa análise estatística.
7.1 Simulação: TCP-UEM submetido a um handoff
Alterando o cenário de simulação para um ambiente um pouco mais realista, o
próximo cenário, descrito na Figura 36, é muito comum nas redes sem fio, o qual consiste na
comunicação entre uma estação fixa e uma estação móvel, de modo que durante a
transferência de dados por meio de uma conexão TCP, a movimentação da estação móvel
exija a utilização não simultânea de duas estações base. A escolha da estação base só
dependerá da distância entre elas e a estação móvel.
Inicialmente, a estação fixa denominada “A” inicia a transferência de dados para a
estação móvel por intermédio da estação base 1. O movimento da estação móvel, a qual se
desloca em direção a estação base 2, provoca um handoff entre ela e a estação base 1.
A estação móvel ao alcançar o sinal da estação base 2 restabelece a conexão (handon)
com a estação fixa “A” voltando a receber e transmitir dados por meio dessa conexão.
7
110
Figura 36 - Handoff entre a estação base 1 e a estação base 2. Conexão estabelecida entre estação fixa 1 e
estação móvel.
O objetivo dessa simulação é avaliar o comportamento da variante TCP-UEM quando
submetida a um evento de handoff, posteriormente comparando-a com outras variantes TCP a
fim de verificar se as características do TCP-UEM o deixam imune aos efeitos negativos
desse evento e, em caso afirmativo, qual o tamanho dessa vantagem em relação às outras
variantes TCP também simuladas nesse mesmo cenário.
Com relação a essa simulação, no instante 50ms ocorre o início da transferência de
dados entre a estação móvel e a estação fixa “A”. No decorrer da simulação, no instante
100ms a estação móvel começa a se movimentar em direção a estação base 2. No instante
120ms, ocorre o handoff.
O restabelecimento da conexão, por meio do handon, entre remetente e destinatário
ocorreu em momentos diversos dependendo da versão TCP utilizada. Nesse ambiente, foi
considerada melhor a variante que conseguiu transferir mais dados.
A Figura 37 exibe o comportamento do número de sequência, ou seja, a quantidade de
bytes transferidos por cada variante TCP no decorrer dessa simulação.
111
Figura 37 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas,
Westwood, Sack, Fack e Linux quando submetidos a handoff em um enlace sem fio.
Depreende-se da Figura 37 que a variante TCP-UEM obteve o melhor resultado tendo
ela alcançado a marca de 15.249 bytes transferidos. Com o segundo melhor desempenho
encontra-se a variante Linux, a qual alcançou 13.596 bytes. As variantes Vegas, Newreno,
Fack, Westwood, Sack, Freeze e Jersey alcançaram a marca de 10.719, 10.620, 10.619, 9.870,
7.576, 7.575 e 7548 bytes, respectivamente.
Além da quantidade total de bytes transmitidos, é importante também notar o
momento em que cada variante TCP conseguiu voltar a transmitir dados após estar ao alcance
do sinal da estação base 2, ou seja, restabelecimento da conexão (handon).
A variante TCP-UEM foi a mais rápida em se recuperar da ocorrência do handoff,
voltando a transmitir bytes no instante 170ms. A variante TCP-Linux se recuperou no instante
180ms. Já as outras variantes demoraram mais tempo para voltar a transmitir dados, as quais
só o fizeram no instante 220ms.
O TCP-UEM transmitiu dados durante 80% do tempo disponível (instantes 50 a
300ms) enquanto que a variante TCP-Linux transmitiu seus dados durante 76% do tempo
disponível. As outras variantes transmitiram dados durante 60% do tempo disponível, uma
vez que do início da transmissão (instante 50ms) até a ocorrência do handoff (instante 120ms)
houve transferência de bytes, a qual foi interrompida no instante 120ms, voltando a transferir
no instante 220ms até 300ms, ou seja, dos 250ms disponíveis para transmissão, a ocorrência
de handoff fez com que essas variantes transmitissem dados durante 150ms.
112
É também possível observar na Figura 37 que todas as variantes tiveram um início de
transmissão de dados idênticos, isso é explicado pela fase de partida lenta do TCP, comum
para todas as variantes TCP simuladas.
Acredita-se que a vantagem da variante TCP-UEM sobre as demais, nessas
circunstâncias, é devida ao fato de que ela identificou o handoff como falha no enlace. Com
essa identificação, seus valores de janelas e estimativas de tempo foram conservados,
impedindo que os valores de RTO aumentassem, os quais poderiam retardar o reinício da
transferência de dados.
Desse modo, com o valor de RTO mantido, a sondagem para verificação do
restabelecimento do enlace foi executada mais rápida, permitindo assim uma recuperação
mais rápida do TCP-UEM, proporcionando uma maior transferência de bytes.
7.2 Simulação: TCP-UEM Amigável
Uma das principais características do TCP é ser justo com outras conexões TCP ao
compartilharem o mesmo enlace. Isto significa que se N conexões estiverem compartilhando
o mesmo enlace, cada conexão deve obter N
M
da capacidade desse enlace (Kurose e Ross,
2010). Para verificar se o TCP-UEM mantém justiça ao compartilhar um enlace com outras
conexões TCP, um novo cenário para simulação foi construído. Esse cenário é mostrado por
meio da Figura 38.
Figura 38 - Divisão do enlace entre os remetentes 1 e 2.
Nesse cenário, durante a simulação, os nós remetentes 1 e 2 estabelecem conexões
com os nós destinatários 1 e 2, respectivamente. Percebe-se que há um único enlace
responsável por interligar a rede dos nós remetentes com a rede dos nós destinatários. Essa
configuração obriga que os nós remetentes compartilhem o mesmo enlace quando conectados
aos seus respectivos nós destinatários.
113
Todos os enlaces que compõem a rede da Figura 38 possuem a mesma capacidade de
vazão de 1 Mb/s com latência de 100 milissegundos, propositadamente assim definidos
provocando um gargalo no enlace que interliga as duas redes.
Para impedir que taxas de erros ou falhas nos enlaces influenciassem o comportamento
das conexões TCP-UEM em cada nó remetente, os enlaces foram configurados para serem
100% confiáveis. A simulação foi executada por um período de 1000ms, tendo os nós
remetentes iniciado sua transmissão de dados no instante 1ms, a qual perdurou até a
simulação ser finalizada.
Figura 39: Evolução do número de sequência dos remetentes 1 e 2 que compartilharam um único enlace.
A Figura 39 mostra a evolução dos números de sequência de cada nó remetente
alcançados na simulação. A evolução desses números de sequência ocorreu de forma
semelhante entre os remetentes 1 e 2. Nessa figura é possível perceber que há momentos, por
exemplo, nos instantes entre 190 e 280 ms, em que as linhas do gráfico se sobrepõe, isto é, os
números de sequência evoluem de forma idêntica entre os remetentes. Nos outros momentos,
a quantidade de bytes transmitidos pelo remetente 2 diverge do remetente 1, porém, mesmo
com essa diferença, há ainda um comportamento de evolução paralela entre as linhas. Esse
comportamento mostra uma relativa igualdade entre os remetentes. Desse modo, ambas
variantes TCP-UEM, ao transmitirem por um enlace compartilhado, permitiram uma divisão
equânime da largura de banda desse enlace.
114
Figura 40 - Comportamento da janela de congestionamento dos remetentes 1 e 2 ao compartilharem o
mesmo enlace.
A Figura 40 exibe o comportamento da janela de congestionamento de cada variante
TCP-UEM utilizada nos nós remetentes 1 e 2 durante os primeiros 400 milissegundos da
simulação. É possível notar que tanto a janela de congestionamento do remetente 1 quanto a
do remetente 2 possuem comportamentos semelhantes, ou seja, seus valores variaram dentro
de uma mesma faixa de valor. Essa característica é mais uma evidência que corrobora com a
afirmação de que o TCP-UEM é justo com outras conexões TCP-UEM. Resta verificar se o
TCP-UEM é justo com outras variantes TCP ao compartilharem o mesmo enlace.
Para verificar se o TCP-UEM se comporta de maneira justa com outras variantes TCP,
um novo cenário foi simulado. Esse novo cenário está detalhado na Figura 41.
Esse cenário é composto por oito nós e dois roteadores. Durante a simulação, quatro
nós da rede estavam ligados a um roteador e os outros quatros nós estavam ligados ao outro
roteador por meio de enlaces idênticos de 1 Mbits e latência de 100 ms. Ambos os roteadores
estavam ligados por um único enlace também de capacidade idêntica aos outros enlaces.
Dividindo os oito nós em dois grupos (direita e esquerda), cada nó da esquerda foi
conectado logicamente a um nó da direita por meio de uma conexão TCP, totalizando 4
conexões TCP ativas durante a simulação. Ambas as conexões compartilharam a capacidade
do enlace que ligava um roteador ao outro.
115
De modo aleatório, cada nó da esquerda utilizou uma variante TCP para estabelecer
uma conexão com seu par. As variantes utilizadas foram: TCP-UEM, Newreno, Linux e
NewJersey.
Os quatro nós remetentes utilizaram uma aplicação FTP (500 bytes de informação a
cada 1 milissegundo) para injetar dados na rede. E os enlaces foram configurados para serem
100% confiáveis, para que nenhuma taxa de erro pudesse interferir no resultado.
Figura 41 - Avaliação do critério Justiça entre as variantes TCP-UEM, Newreno, Linux e NewJersey.
Durante a simulação, cada conexão foi monitorada, sendo extraída de cada uma delas
a largura de banda média utilizada. Para realização desse monitoramento, a seguinte função
foi utilizada no script tcl para simulação no NS2:
proc recordBW {} {
global ns traceBWNode1 traceBWNode2 traceBWNode3 traceBWNode4 SinkNode1
SinkNode2 SinkNode3 SinkNode4 acumulado1 acumulado2 acumulado3 acumulado4
set time 50.0
set bandaNode1 [$SinkNode1 set bytes_]
set bandaNode2 [$SinkNode2 set bytes_]
set bandaNode3 [$SinkNode3 set bytes_]
set bandaNode4 [$SinkNode4 set bytes_]
set now [$ns now]
set acumulado1 [expr $acumulado1 + [expr $bandaNode1/$time*8/100000]]
set acumulado2 [expr $acumulado2 + [expr $bandaNode2/$time*8/100000]]
set acumulado3 [expr $acumulado3 + [expr $bandaNode3/$time*8/100000]]
set acumulado4 [expr $acumulado4 + [expr $bandaNode4/$time*8/100000]]
#registra a média do uso da largura de banda percebida pelo destinatário
116
puts $traceBWNode1 “$now [expr $acumulado1 / contador]
puts $traceBWNode2 “$now [expr $acumulado2 / contador]
puts $traceBWNode3 “$now [expr $acumulado3 / contador]
puts $traceBWNode4 “$now [expr $acumulado4 / contador]
$sinkNode1 set bytes_ 0
$sinkNode2 set bytes_ 0
$sinkNode3 set bytes_ 0
$sinkNode4 set bytes_ 0
set contador [expr $contador + 1]
$ns at [expr $now + $time] “recordBW”
}
Essa função registrou a média da largura de banda utilizada pelo remetente que pôde
ser percebida no destinatário. A simulação executou por um período de cem mil
milissegundos e o resultado é mostrado no gráfico da Figura 42. A figura mostra que houve
um compartilhamento equânime do enlace, significando que houve justiça no
compartilhamento do enlace disponível entre as variantes utilizadas.
Figura 42 - Largura de banda utilizada pelas variantes TCP-UEM, Newreno, Linux e NewJersey.
O resultado dessa simulação mostrou que a variante TCP-UEM se comportou de
maneira justa consumindo a mesma quantidade de largura de banda que as outras variantes.
Ressalta-se que as variantes Linux, Westwood e Newreno também se comportaram de
maneira justa ao permitirem o compartilhamento equânime do enlace.
Ademais, cabe ressaltar que o consumo de largura de banda equânime não significa
que as variantes tiveram a mesma eficiência. Essa afirmação pode ser verificada analisando a
quantidade de bytes que cada variante conseguiu transmitir com a largura de banda que estava
disponível, esses dados são mostrados na Figura 43.
117
Figura 43 - Desempenho das variantes TCP-UEM, Newreno, Linux e NewJersey compartilhando o mesmo
enlace.
Apesar da variante TCP-UEM possuir a mesma largura de banda que as outras
variantes, ela foi mais eficiente conseguindo transmitir mais bytes que as outras variantes.
7.3 Simulação: TCP-UEM em redes ad-hoc
O próximo cenário simulado consistiu em uma rede ad hoc formada por três
computadores portáteis, os quais, inicialmente, encontravam-se dispostos de forma que o sinal
sem fio de cada um alcançasse os outros dois, conforme mostra a Figura 44.
Durante a simulação, o host 1 estabeleceu uma conexão com o host 2, tendo aquele
transferido dados a uma taxa de envio constante para este. Entretanto, durante a transferência
o host 2 moveu-se de forma a ficar fora do alcance do sinal dos hosts 1 e 3.
O host 2, durante sua trajetória, antes de ficar inalcançável, esteve em um dado
momento somente sob o alcance do sinal do host 3. A conexão entre host 2 e o host 1
manteve-se válida devido ao mecanismo de roteamento das redes ad hoc, o qual fez com que
o host 3 intermediasse a conexão.
118
Figura 44 - Simulação de uma rede ad hoc.
O host 2 prosseguiu em sua trajetória até ficar fora do alcance dos hosts 1 e 3, não
sendo possível qualquer comunicação. A cada vez que o host 2 ficava fora do alcance do sinal
da rede ad hoc, sua trajetória mudava de direção para o sentido oposto, visando voltar ao
alcance do sinal da rede. Esse movimento de vai e vem foi repetido até o fim da simulação.
Nessa simulação, o sinal sem fio utilizou a frequência 2.4 Ghz com largura de banda
de 54 Mbps e com uma taxa de erros de 12,5%. Cada host não poderia armazenar em seus
buffers mais que 100 segmentos TCP.
As variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack, Fack e
Linux foram simuladas nesse cenário. A Tabela 15 apresenta os números de sequência
alcançados por cada uma das variantes ao final da simulação.
Tabela 15 - Desempenho das variantes TCP submetidas a uma rede ad hoc
Variante TCP Número de sequência alcançado.
UEM 20915 JERSEY 19818
NEWRENO 19757 FREEZE 19367
WESTWOOD 19136 SACK 19089 VEGAS 17224 LINUX 16426 FACK 12685
Embora o TCP-UEM tenha obtido o melhor desempenho, as variantes Jersey,
Newreno, Freeze, Westwood e Sack obtiveram desempenhos semelhantes. O bom
desempenho das variantes Jersey, Freeze e Westwood são esperados, uma vez que possuem
mecanismos para detecção de falhas no enlace, como é o caso das variantes Jersey e Freeze, e
119
de uma melhor estimativa da largura de banda, como é o caso das variantes Jersey e
Westwood.
As variantes Sack e Newreno, embora não tenham mecanismos voltados para esse tipo
de cenário, também obtiveram um bom desempenho. A única exceção foi a variante TCP-
Fack, a qual obteve um desempenho aquém se comparada às outras variantes.
Essa similaridade de desempenhos é mais bem visualizada com o auxílio da Figura 45,
a qual exibe a evolução do número de sequência de cada variante simulada. Observa-se que a
cada vez que o host 2 se distanciava dos outros hosts a ponto de ficar inalcançável, esse
isolamento impedia a evolução do número de sequência já que nenhum dado poderia ser
transmitido ou recebido.
Acredita-se que a similaridade de desempenho entre as variantes simuladas se deve a
eficiência do algoritmo de roteamento para redes ad hoc e a capacidade que tem cada nó de
“bufferizar” segmentos de uma determinada conexão, os quais são entregues para o nó
destinatário quando esse volta a estar ao alcance do sinal ou quando uma nova rota permite
seu alcance.
Devido a gama de possibilidades para se construir um cenário de simulação para redes
ad hoc, como exemplos, a variedade de algoritmos de roteamento, o tipo de antena utilizada, o
modelo de energia, a capacidade dos buffers, a tecnologia utilizada na camada física, não é
possível afirmar com uma única simulação se uma dada variante é melhor que outra nesse
cenário de redes ad hoc, sendo esse assunto, conteúdo suficiente para realização de outro
trabalho dirigido para explorar melhor a possibilidade de configurações possíveis de forma
que cada variante possa ser mais bem avaliada em cada uma dessas possibilidades.
120
Figura 45 - Evolução do número de sequência das variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas,
Westwood, Sack, Fack e Linux sobre uma rede ad hoc.
121
7.4 Análise de Variância
A necessidade de uma análise estatística é amparada pelo fato de que durante as
simulações o trabalho do experimentador pode sofrer influência de fatores não controlados, os
quais por força do acaso ou variação aleatória podem alterar completamente o resultado dos
experimentos. Dessa maneira, ao comparar duas variantes, pelo simples acaso, a pior delas
pode ser influenciada favoravelmente mostrando-se ser superior a outra.
Assim, é tarefa do experimentador verificar se a diferença observada entre as variantes
simuladas não são simplesmente influenciadas pelo acaso. Por outro lado, se novos resultados
comprovarem essa diferença, demonstrar-se-á que tais variantes TCP não são equivalentes.
Esses resultados dão condição de aceitá-las realmente como diferentes imputando a causa da
diferença a uma das variantes TCP simuladas.
Para assegurar um número suficiente de repetições nas simulações, cada variante TCP
foi simulada 31 vezes, assegurando-se em cada simulação a substituição da semente
responsável pela geração de números aleatórios.
No simulador NS2 essa semente é representada por um número inteiro, dessa maneira,
os números utilizados pertenciam a sequência compreendida entre número 9 até o número 39,
a qual foi escolhida de forma aleatória. Em outras palavras, cada variante TCP foi simulada
31 vezes utilizando 31 sementes diferentes.
O ambiente utilizado na simulação é o mesmo descrito na Seção 5, o qual impõe ao
enlace uma taxa de erros de 12,5% e falhas nos instantes 10 a 30 ms, 80 a 120 ms, 160 a 200
ms, 220 a 240 ms e 380 a 395 ms.
Os resultados obtidos nas simulações são apresentados na Tabela 16. O campo Nº da
simulação indica a ordem em que foi executada cada simulação. O campo Semente contém o
valor da semente utilizado para geração de números aleatórios no simulador NS2.
Percebe-se que as mesmas sementes foram utilizadas para todas as variantes TCP,
assegurando-se que cada variante fosse simulada em condições idênticas às outras, pois ao
utilizar da mesma semente, os valores aleatórios gerados são repetidos de forma idêntica a
cada vez que a simulação é repetida, independentemente da variante TCP simulada.
Tabela 16 - Quantidade de dados transferidos por cada uma das variantes TCP utilizadas simuladas por 31 consecutivas utilizando 31 sementes diferentes.
VARIANTE TCP Quantidade de bytes transferidos por cada variante a cada simulação
Nº
Simulação Semente
UEM Jersey Newreno Freeze Vegas Westwood Sack Fack Linux 1 9 6844 1346 1780 661 1713 1704 1476 643 1512
2 10 6129 1979 1262 1892 1117 1870 1275 533 862
3 11 3676 1957 1218 1497 1085 1882 990 455 520
122
4 12 5269 2264 607 1784 1895 2465 1376 662 1033
5 13 7020 2011 950 1670 945 1555 1344 731 802
6 14 6720 1406 150 158 602 1373 1551 735 1099
7 15 4840 2055 1202 1430 952 1767 1687 979 1239
8 16 4619 1998 1474 1314 415 2051 1170 567 998
9 17 6768 1366 1948 1382 1404 2141 762 808 1601
10 18 6643 1952 2467 107 1865 1934 670 868 159
11 19 7267 2103 2074 674 1333 1134 575 304 560
12 20 5254 1453 1724 687 1075 1338 1117 741 1107
13 21 5373 1826 1964 2199 1856 1201 904 683 792
14 22 6544 1920 695 946 372 2291 938 397 1274
15 23 7899 2082 1589 1591 1386 2138 1254 806 134
16 24 6831 2191 2092 1749 724 1356 1575 1152 1130
17 25 5767 1505 739 1601 1684 1223 990 453 1197
18 26 5980 1283 995 132 467 934 1121 571 1359
19 27 6523 2003 1450 1715 1151 1833 858 477 1090
20 28 7053 2124 1259 1408 410 1512 1014 744 1346
21 29 4286 2007 625 472 1366 409 1329 673 1157
22 30 5865 1982 193 1727 1090 1527 958 949 1431
23 31 5348 2512 955 1667 472 2156 1144 328 416
24 32 5976 2031 781 873 1371 1831 1327 620 73
25 33 6765 1989 1225 75 965 627 83 638 703
26 34 8065 2091 2283 1052 2083 1879 1390 780 800
27 35 2663 2074 1938 1430 1075 1956 1389 672 218
28 36 5311 2337 1733 1825 1809 2118 1234 619 1272
29 37 7343 1209 1793 1571 1267 1418 1397 825 441
30 38 7201 2549 987 1371 1185 1844 1117 764 778
31 39 6587 1955 1919 1667 1817 1927 1436 752 1292
Na tabela, cada coluna, identificada por uma variante TCP, armazena a quantidade de
bytes transmitidos a cada enésima simulação (n variando de 1 a 31) utilizando-se da iésima
semente (com i variando de 9 a 39).
Conforme pode ser observado, a título de exemplo, na simulação nº 1 que utilizou a
semente nº 9, as variantes TCP-UEM, Jersey, Newreno, Freeze, Vegas, Westwood, Sack,
Fack e Linux transferiram 6844, 1346, 1780, 661, 1713, 1704, 1476, 643, 1512 bytes
respectivamente.
A análise de variância foi realizada utilizando os dados apresentados na tabela. Com
essa análise é possível verificar a influência que cada variável independente (variantes TCP)
tem sobre os resultados obtidos (quantidade de bytes transferidos) e avaliando o resultado
123
dessa análise verifica-se se é possível rejeitar a hipótese nula sugerida: “Nenhuma das
variantes TCP simuladas interfiriu no desempenho observado”.
Ela pode ser aceita ou rejeitada dependendo do nível de significância que uma
determinada variante TCP teve sobre o percentual médio de bytes transferidos.
O nível de significância utilizado para realização dessa análise de variância é de
0,001%, o que dá uma possibilidade pequena para que a hipótese em questão seja rejeitada.
Isso quer dizer que qualquer variante TCP, para ser responsável por influenciar os resultados
obtidos, deve apresentar com diferença de 99,999% de todas as outras variantes.
Aceitando-se apenas uma margem de 0,001% de semelhança para que a hipótese nula
seja rejeitada, qualquer valor fora dessa margem impede sua rejeição, em outras palavras, uma
variante TCP deve ter um comportamento que se difere 99,999% das outras comparadas para
que a hipótese nula seja rejeitada.
7.5 Teste de HSU
A Tabela 17 mostra o resultado da análise de variância dos resultados obtidos nas
simulações. Conforme os dados apresentados na tabela, pode-se rejeitar a hipótese nula:
“Nenhuma das variantes TCP simuladas interfere no desempenho observado”, pois o nível de
significância representado pela coluna P ficou abaixo de 0,001%.
Ao aceitar essa hipótese nula, afirma-se que alguma variável independente (variante
TCP) teve influência nos resultados obtidos, em outras palavras, significa dizer que os
resultados obtidos foram alcançados por uma técnica ser mais efetiva que a outra.
Tabela 17 - Resultado da análise estatística das simulações constantes da Tabela 15
Variável
Independente Média da quantidade de bytes transferidos durante as simulações
---------+---------+---------+---------+
TCP-UEM 6078,4 (--*--)
JERSEY 1921,3 (--*--)
NEWRENO 1357,1 (-*--)
FREEZE 1236,4 (--*--)
VEGAS 1192 (--*--)
WESTWOOD 1657,9 (--*--)
SACK 1143,6 (--*--)
Variante TCP
FACK 675,1 (--*--)
124
LINUX 916 (--*--)
---------+---------+---------+---------+
1600 3200 4800 6400
SST SSR DFV DFE F P 672713779 93596361 8 270 242,57 0,000
Legenda:
SST = Soma dos quadrados entre os tratamentos
SSR = Soma dos quadrados dos resíduos
DFV = Graus de liberdade entre os tratamentos
DFE = Graus de liberdade dos resíduos
F = Teste estatístico
P = Nível de significância
Um nível de significância abaixo de 0,001% assegura que a quantidade média de bytes
transferidos teve influência direta da variável independente (variante TCP). O uso do nível de
significância abaixo de 5% também daria a possibilidade da hipótese nula ser rejeitada, porém
utilizando um nível de significância menor, rejeita-se com maior firmeza a hipótese nula.
Figura 46 - Médias obtidas na análise de variância com os dados da Tabela 16.
A Figura 46 mostra as médias obtidas pelas variantes assim dispostas no gráfico: 1-
TCP-UEM, 2-Jersey, 3-Newreno, 4-Freeze, 5-Vegas, 6-Westwood, 7-Sack, 8-Fack e 9-Linux.
125
Conforme pode ser observado, a média da variante TCP-UEM destoa das demais variantes,
ficando evidente sua diferença em relação à média dos tratamentos.
A variante TCP-Jersey também apresenta de forma mais tímida uma diferença acima
da média em relação aos outros tratamentos. Entretanto, a análise de variância pode apenas
afirmar que há uma variável independente influenciando estatisticamente nos resultados
obtidos sem poder afirmar qual dessas variáveis (variantes TCP) é a responsável pela
influência. Dito isso, outra técnica de análise estatística foi usada sobre as médias obtidas por
meio da análise de variância, conhecido como teste de HSU (Hsu, 1986). Esse teste realiza
comparações múltiplas com o objetivo de determinar se há alguma média máxima ou mínima
entre as médias analisadas.
Com o auxílio do software Minitab®, após a execução do teste foi obtido o seguinte
resultado:
Hsu's MCB (Multiple Comparisons with the Best)
Family error rate = 0,001
Critical value = 3,64
Intervals for level mean minus largest of other level means
Level Lower Center Upper +---------+---------+---------+---------
1 0,0 4157,1 4701,8 (-------------*-)
2 -4701,8 -4157,1 0,0 (-*-------------)
3 -5265,9 -4721,2 0,0 (-*---------------)
4 -5386,7 -4842,0 0,0 (-*---------------)
5 -5431,1 -4886,4 0,0 (-*---------------)
6 -4965,2 -4420,5 0,0 (-*--------------)
7 -5479,5 -4934,8 0,0 (-*---------------)
8 -5947,9 -5403,2 0,0 (-*-----------------)
9 -5707,1 -5162,4 0,0 (-*----------------)
+---------+---------+---------+---------
-6000 -3000 0 3000
É possível observar nos resultados obtidos que a média de tratamento obtida pela
variante TCP-UEM (Level 1) manteve seus valores positivos. Para o teste de HSU isso
significa que a variante TCP-UEM apresentou o melhor resultado se comparada às outras
variantes.
Ainda observando o resultado apresentado, todas as outras variantes possuem valores
negativos, tendo todas elas o valor zero como ponto final de seus intervalos de confiança, isso
significa que suas diferenças são estatisticamente significantes.
Apenas a variante TCP-UEM (Level 1) não possui o valor zero como ponto final em
seu intervalo de significância, isso quer dizer que sua diferença não é estatisticamente
significante, demonstrando assim o quanto sua média difere das outras, o que no caso
apresenta-se como a melhor.
É com base na análise de variância e no teste de HSU que se pode afirmar a
superioridade da variante TCP-UEM quando comparada com as variantes Jersey, Newreno,
126
Freeze, Vegas, Westwood, Sack, Fack e Linux quando simuladas em um cenário cujo enlace
apresenta erros e falhas.
7.6 Probabilidades
A análise de variância refutou a hipótese nula, que afirmava que nenhuma variante
TCP simulada foi capaz de influenciar consubstancialmente a média obtida. O teste de HSU
foi utilizado para descobrir qual variante TCP influenciou significamente na média dos
resultados constantes da Tabela 16.
Porém, essas duas técnicas não são capazes de responder a seguinte questão:
Aumentando o número de repetições da simulação o desempenho médio de cada variante TCP
será mantido?
É possível responder essa questão utilizando a função de distribuição de probabilidade
ou função de probabilidade cumulativa, a qual associa uma probabilidade a cada resultado
numérico de um experimento.
Os resultados constantes da Tabela 16 possuem como valor mínimo 73 bytes,
resultado obtido pela simulação da variante Linux na repetição 24. O valor máximo dessa
tabela é 8065 bytes, resultado obtido pela simulação da variante TCP-UEM na repetição
número 26. A média e o desvio padrão dos valores da Tabela 16 são, respectivamente, 1798 e
1660, conforme pode ser observado no canto superior direito da Figura 47.
A Figura 47 mostra a porcentagem da frequência dos resultados obtidos no intervalo
entre 0 e 9000 bytes dos dados contantes da Tabela 16. Aproximadamente 90% desses
resultados estão no intervalo entre aproximadamente 500 e 2700 bytes.
Figura 47 -Histograma dos dados constantes na Tabela 16
127
A Figura 48 mostra a distribuição normal dos resultados obtidos pela variante TCP-
UEM. Aproximadamente 90% dos resultados obtidos pelo TCP-UEM estão compreendidos
no intervalo 4000 e 8000 bytes. A média e o desvio padrão dos resultados alcançados pelo
TCP-UEM são 6078 e 1215 bytes, respectivamente.
Figura 48 - Histograma dos resultados do TCP-UEM constantes na Tabela 16.
Com base no Teorema do Limite Central (Rodrigues, 2009), é possível afirmar que
mesmo aumentando o número de repetições, a distribuição das porcentagens amostrais tende a
permanecer inalterada. Em outras palavras, aumentando o número repetições das simulações
feitas com o TCP-UEM, haverá 90% de chance dos resultados obtidos estarem no intervalo
compreendido entre 4000 a 8000 bytes transmitidos.
Uma comparação entre o histograma dos dados da Tabela 16 e o histograma dos
resultados obtidos pelo TCP-UEM mostra dois intervalos diferentes. Enquanto a média dos
resultados de todas as variantes simuladas é de 1798 bytes, a média dos resultados obtidos
pelo TCP-UEM é de 6078 bytes.
Os intervalos também são diferentes, enquanto 90% dos resultados estão dentro do
intervalo aproximado de 500 e 2700 bytes, 90% dos resultados obtidos pelo TCP-UEM estão
compreendidos entre aproximadamente 4000 e 8000 bytes.
Portanto, se novas simulações forem realizadas, aumentando assim o número de
repetições, haverá 90% de chance dos resultados obtidos pelo TCP-UEM estarem
compreendidos no intervalo aproximado de 4000 e 8000 bytes. A Figura 49 ajuda a visualizar
melhor essa afirmação, mostrando o gráfico da função de probabilidade cumulativa das
variantes TCP simuladas tendo como base os resultados constantes da Tabela 16.
128
Figura 49 - Função Probabilidade Cumulativa das variantes simuladas (Tabela 16)
Na Figura 49 é possível observar a probabilidade de ocorrência de um determinado
resultado obtido por uma determinada variante TCP. Ainda, é possível observar o
deslocamento para a direita da reta que representa o TCP-UEM, afastando-o da região que
agrupa as outras variantes.
Desse modo, se o número de repetições das simulações for maior, independentemente
da quantidade, haverá uma grande probabilidade dos resultados obtidos com as 31 repetições
se manterem inalterados.
7.7 Considerações Finais
Neste tópico foram apresentadas as simulações e uma análise estatística das variantes
TCP Jersey, Newreno, Freeze, Westwood, Sack, Vegas, Linux, Fack comparando-as com a
nova variante TCP-UEM.
Essas variantes foram simuladas em cenários com características comuns das redes
sem fio, como é o caso de handoff entre estações base e a perda do sinal por meio do
distanciamento entre host em uma rede ad-hoc. Também foi testada a capacidade de
“amigabilidade” do TCP-UEM por meio de uma simulação em que várias conexões
compartilharam o mesmo enlace. Observou-se a viabilidade de implementação do TCP-UEM
uma vez que nas simulações ele demonstrou um bom desempenho se comparado com as
variantes TCP simuladas nos mesmos cenários.
129
Após as simulações, o TCP-UEM foi submetido a uma análise estatística usando como
técnicas: i) ANOVA - análise de variância; ii) teste de HSU; e iii) função de probabilidade
cumulativa. Nas 31 simulações em que foram submetidas as variantes TCP, a técnica
ANOVA mostrou que houve, dentre as variantes TCP simuladas, uma variante capaz de
influenciar estatisticamente os resultados obtidos nas simulações. O teste HSU isolou a
variante TCP-UEM como a variante com a maior média obtida nas simulações. Já a função de
probabilidade cumulativa mostrou que: i) a média dos resultados obtidos pelo TCP-UEM é
uma média superior à média total; ii) mesmo com o aumento do número de repetições das
simulações (aumento do espaço amostral), haverá uma probabilidade grande dos resultados
permanecerem dentro da curva de distribuição normal observada com 31 repetições.
Acredita-se que os resultados obtidos com a nova variante TCP-UEM nas simulações
possam ser encorajadores para uma futura implementação e testes em situações reais.
A característica mais importante da nova variante TCP-UEM é sua habilidade em
detectar falhas no enlace. Essa habilidade pode ser mais bem explorada nas redes sem fio
visto que esses eventos são mais sucetíveis nesse ambiente.
As redes sem fio podem ser classificadas de acordo com o número de saltos que um
determinado pacote atravessa ou de acordo com sua infraestrutura (com ou sem estação base)
(Kurose e Ross, 2010):
• Salto único com infraestrutura: Rede sem fio que possui uma estação base conectada a
uma rede maior, por exemplo, a Internet. Esses tipos de redes estão na periferia da
Internet proporcionando mobilidade aos hosts finais que utilizam serviços da Internet.
Acreditamos que o uso da variante TCP-UEM nessas redes pode tornar os hosts finais
mais robustos diante dos eventos de desconexão repentina da estação base
proporcionando a esses hosts um maior desempenho nas transferências de dados.
• Múltiplos saltos com infraestrutura: Rede sem fio que possui estação base, porém
alguns dos hosts finais podem utilizar outros hosts finais para alcançar a estação base
cabeada a uma rede maior. Esse cenário também pode ser beneficiado com o uso do
protocolo TCP-UEM pelos mesmos motivos apresentados anteriormente.
• Múltiplos saltos sem infraestrutura: Rede que não utiliza estação base, exigindo dos
hosts participantes cooperação para se formar uma malha de comunicação,
proporcionando comunicação entre os integrantes dessa malha, mesmo que o sinal
desses nós não alcancem o nó destino diretamente. Os hosts intermediários cooperam
para que a informação chegue ao destinatário que não está ao alcance do remente. Esse
tipo de rede é bastante imprevisível, de modo que o emprego do TCP-UEM nesse tipo
de rede pode permitir um melhor desempenho na transferência dos dados entre os
130
hosts, uma vez que a saída repentina de um nó que cooperava para que o destinatário
fosse alcançado, pode ser detectada pelo TCP-UEM remetente como falha no enlace,
possibilitando uma pausa na transferência dos dados sem exigir do TCP remetente
retransmissões necessárias e reduções de sua janela de congestionamento.
De um modo geral, as redes sem fio são mais suscetíveis a eventos como redução da
força do sinal, interferência de outras fontes e propagação multivias (Kurose e Ross, 2010).
Esses eventos provocam, no remetente, efeitos indesejados, conforme já mencionado. Esses
efeitos indesejados podem ser atenuados com o uso da nova variante TCP-UEM, a qual é
capaz de detectá-los impedindo ou atenuando esses efeitos.
Relembrando que o TCP-UEM pode ter um comportamento mais agressivo que o
recomendado pela IETF, a utilização do protocolo TCP-UEM tende a ficar restrito a essas
redes de acesso ou de última milha, uma vez que cenários sem fio são mais frequentes.
131
8. Conclusão
Ao fazer uma revisão sobre o estado da arte das pesquisas relacionadas ao
desenvolvimento e aprimoramento dos protocolos pertencentes à camada de transporte,
mostrou que esse assunto é bastante pertinente e relevante, tendo em vista as dificuldades
enfrentadas pelo TCP (solidificado como o protocolo da camada de transporte mais utilizado
na Internet) quando submetido a enlaces sem fio.
As soluções propostas abordam a problemática de diversas maneiras, seja com a
criação de um novo protocolo, seja com o auxílio das camadas de redes subjacentes ou
simplesmente alterando o protocolo original.
Conforme demonstrado, a criação de um novo protocolo tem como principal entrave a
não compatibilidade com protocolos existentes. As soluções que dependem do auxílio das
camadas de redes subjacentes quebram a semântica fim a fim da arquitetura em camadas, e
por fim, a solução que altera as características originais do protocolo não consegue resolver de
uma só vez todos os problemas.
Com base nessas considerações, inicialmente, era analisar o desempenho das variantes
TCP existentes na literatura com o intuito de verificar quais das soluções eram compatíveis
entre si, e como a integração dessas soluções poderia culminar na construção de uma nova
variante mais robusta para enfrentar os diversos problemas decorrentes das redes sem fio.
Entretanto, no decorrer da pesquisa percebeu-se um padrão repetido a todas as
variantes TCP simuladas quando elas eram submetidas a falhas no enlace, qual seja a
estagnação do comportamento de suas janelas de congestionamento e a estagnação da
evolução dos seus números de sequência. Isso acontecia pelo fato do canal estar
impossibilitado em transmitir novas informações.
8
132
Reconsiderações foram feitas, o qual visou fornecer ao TCP a capacidade de
reconhecer esses padrões, possibilitando identificar falhas no enlace e mantendo a semântica
fim a fim.
Essa capacidade foi desenvolvida e para isso foi necessária a inclusão de novas
variáveis de controle nos procedimentos que já existiam no TCP original. As alterações
necessárias foram incluídas nos procedimentos responsáveis pelo recebimento de um
segmento de confirmação, pelo tratamento de um timeout, pela redução da janela de
congestionamento. Ambos os procedimentos fazem referência àqueles implementados no
simulador de redes NS2.
A ideia principal do TCP-UEM, de uma forma resumida, é contabilizar a quantidade
de segmentos transmitidos e a quantidade de segmentos perdidos. A quantidade de segmentos
transmitidos é incrementada a cada chegada de um segmento de confirmação (ACK). A
quantidade de segmentos perdidos é incrementada a cada ocorrência de timeout.
De posse desses valores, o TCP-UEM calcula a confiabilidade do enlace e a usa para
determinar o quanto sua janela de congestionamento será diminuída. Ele também usa esse
valor para comparar a taxa de erros atualmente percebida. Se a taxa de erros atual for superior
que a média até então mensurada o TCP-UEM reconhece uma queda no enlace.
Esse reconhecimento está embasado somente nessas mensurações, o que faz com que
possa haver um reconhecimento de uma falha no enlace sem que realmente tenha havido uma
falha.
Porém, os resultados das simulações demonstraram que o TCP-UEM reconheceu as
falhas no enlace no momento em que elas ocorreram e não foi possível perceber, com base
nos resultados obtidos nas simulações, que falsos positivos tenham ocorrido, entretanto, não
está descartada essa possibilidade.
Antes que as simulações pudessem ser realizadas, alguns testes foram realizados em
cenários de redes reais. Esses cenários consistiram na transferência de datagramas UDPs entre
hosts localizados em diferentes locais, de modo que com essa transferência a confiabilidade
do circuito em questão pudesse ser mensurada. Os resultados obtidos demonstraram uma taxa
de confiabilidade desses enlaces que ficaram entre 98% e 100%.
Também, por meio desses testes, avaliou-se a confiabilidade dos enlaces sem fio, mais
precisamente o padrão 802.11, o qual demonstrou no pior caso uma taxa de confiabilidade
acima de 87% mesmo quando seu sinal estava sujeito a interferências. Foi essa taxa de erros,
em torno de 12,5%, escolhida para as simulações.
Nas simulações apresentadas, a nova variante TCP-UEM demonstrou, inclusive
estatisticamente, possuir um desempenho superior quando comparada às variantes Jersey,
133
Newreno, Freeze, Westwood, Sack, Vegas, Linux e Fack. Em uma dessas simulações a nova
variante mostrou ter um desempenho 2,68 vezes melhor que a segunda colocada.
Acredita-se que a nova variante TCP-UEM possa ser incluída entre as variantes TCPs
capazes de enfrentar os problemas causados pelos enlaces sem fio, atendendo as seguintes
características:
• Impede o disparo errôneo do mecanismo de controle de congestionamento do TCP
quando falhas no enlace ocorrem;
• Impede timeouts sequenciais quando falhas no enlace ocorrem;
• Mantém compatibilidade com o TCP original e com as aplicações existentes;
• Preserva a semântica fim a fim;
• Tolera instabilidades no canal e alta taxa de erros;
Acredita-se também que a nova variante TCP-UEM traz novas ideias que contribuem
para a pesquisa e o desenvolvimento de uma versão do protocolo TCP mais robusta,
tornando-o mais eficiente e preparado para enfrentar os problemas decorrentes dos enlaces
sem fio.
Apesar do bom desempenho do TCP-UEM, essa nova variante não é a solução para
resolver todos os problemas do protocolo TCP quando submetido a enlaces sem fio. Há
problemas que ele não está preparado para enfrentar, como o das retransmissões
desnecessárias (spurious retransmission). Outro problema não enfrentado pelo TCP-UEM
está no fato dele não ser capaz de identificar mudanças de rotas nas redes ad-hoc.
A variante TCP-EIFEL é uma variante capaz de enfrentar o problema das
retransmissões desnecessárias que também preserva a semântica fim a fim. Como trabalho
futuro essa solução pode ser adicionada na variante TCP-UEM, tornando-a robusta para
enfrentar esse problema.
Com relação à preservação dos recursos limitados nos dispositivos móveis, tais como,
fonte de energia e largura de banda, não foi apresentado nenhum estudo capaz de afirmar que
a nova variante TCP-UEM preserva esses recursos escassos.
É necessário frisar que a técnica utilizada pelo TCP-UEM para identificar falhas no
enlace é baseada em estatísticas mensuradas ao longo da conexão, portanto, qualquer variação
brusca na largura de banda do enlace pode fazer com que o TCP-UEM reconheça como uma
falha. Se essa detecção for um falso positivo, o TCP-UEM demorará, em tese, o tempo de um
RTT para voltar a transmitir dados, prejudicando seu desempenho.
A implementação e testes em ambientes reais são objetos de trabalhos futuros, além de
simulações em novos cenários como as redes multihop. A junção de soluções compatíveis
134
com o TCP-UEM visando criar uma solução mais robusta para enfrentar os problemas
causados pelas redes sem fio também serão objetos de trabalhos futuros.
135
Referências
AKYILDIZ I. F., MORABITO G., PALAZZO S., TCP-Peach: A New Congestion Control
Scheme for Satellite IP Networks, In: Ieee/Acm Transactions On Networking, Vol. 9, No. 3,
Junho 2001, páginas: 307-321.
BAKRE A. e BADRINATH. R. B., I-TCP: Indirect TCP for mobile hosts. 15ª Conferência
Internacional em Sistemas Distribuídos, Computing Systems, Vancouver, BC, Canadá, Maio
1995, páginas: 136-143.
BALAKRISHNAN H., SESHAN S., e KATZ R., Improving Reliable Transport and Handoff
performance in Cellular Wireless Networks. In: ACM Wireless Networks, Vol. 1, 1995,
páginas: 1-19.
BIKRAM S. B., KRISHNA P., NITIN H. V. e DHIRAJ K. P., Improving Performance of
TCP over Wireless Networks, In: International Conference on Distributed Computing
Systems – ICDCS, 1997, páginas: 365-373.
BOUKERCHE A., Algorithms and Protocols For Wireless and Mobile Ad Hoc Networks.
Ottawa, Canada. Editora Wiley, 2009.
BRAKMO L. S., O’MALLEY S. W., e PETERSON L. L., TCP Vegas: New techniques for
congestion detection and avoidance. In: Proceedings of the SIGCOMM '94 Symposium,
Agosto 1994, páginas: 24-35.
BROWN K. e SINGH S., M-TCP : TCP for Mobile Cellular Networks, USA, Department of
Computer Science Univ. of South Carolina, ACM Computer Communications Review, 1997.
CARR, N. G., IT Doesn't Matter, In: Harvard Business Review, Disponível em:
http://www.nicholasgcarr.com/articles/matter.html, Acessado em: Outubro 2011.
136
CARVALIO D. J., Uma plataforma para avaliar a degradação da vazão causada por
interferência espectral em redes sem fio padrão IEEE 802.11. Dissertação de Mestrado.
Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo, São
Paulo/SP, Brasil, novembro de 2010, 72 páginas.
CASETTI C., GERLA M., MASCOLO S., SANADIDI M. Y., e WANG R., TCP Westwood:
End-to-end congestion control for wired/wireless networks. In: Wireless Networks, 2002,
páginas: 467–479.
CHEN K., XUE Y., E NAHRSTEDT K., On setting TCP’s congestion window limit in
mobile ad hoc networks. In: IEEE International Conference on Communications (ICC 2003),
Vol. 26, Maio 2003, páginas: 1080–1084.
FALL K., VARADHAN K., The NS Manual (formerly NS Notes and Documentation), The
VINT Project , 2010. Disponível em: http://www.isi.edu. Acesso em: Dezembro de 2010.
FLOYD S., RAMAKRISHNAN K. K., TCP with ECN: The Treatment of Retransmitted
Data Packets, Draft IETF. Disponível em https://tools.ietf.org/html/draft-ietf-tsvwg-tcp-ecn.
Acesso em: Outubro, 2011.
FU C. P., TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks,
In: IEEE Journal on Selected Areas In Communications, VOL. 21, NO. 2, Fevereiro 2003,
páginas: 216-228.
FU Z., GREENSTEIN B., MENG X., e LU S., Design and Implementation of a TCP-Friendly
Transport Protocol for Ad Hoc Wireless networks. In: Proceedings of IEEE ICNP, 2002,
páginas: 216-225.
FU Z., ZERFOS P., LUO H., LU S., ZHANG L., GERLA M., The impact of multihop
wireless channel on TCP throughput and loss, In: INFOCOM 2003 - Twenty-Second Annual
Joint Conference of the IEEE Computer and Communications. IEEE Societies,Volume: 3,
2003 , páginas: 1744 – 1753.
137
GOFF T., MORONSKI J., PHATAK D. S., Freeze-TCP: A true end-to-end TCP
enhancement mechanism for mobile environments, University of New York, Binghamton, In:
Proceedings of IEEE INFOCOM'2000, Tel Aviv INFOCOM’2000, 2000, páginas: 1537-
1545.
HOLLAND G. e VAIDYA N., Analysis of TCP performance over mobile ad hoc networks.
In: Proceedings of ACM/IEEE MobiCom, 1999, páginas 219–230.
HSU, J. C., Multiple Comparisons: Theory and Methods, Editora: Chapman & Hall. 1996.
INSTITUTE, I. S. User Datagram Protocol. [S.l.], 1980. Disponível em: http://www.faqs.org/rfcs/rfc768.html. Acesso em: Dezembro 2011. INSTITUTE, I. S. Internet Protocol. [S.l.], 1981. Disponível em: http://www.faqs.org/rfcs/rfc791.html. Acesso em: Dezembro 2011. INSTITUTE, I. S. Internet Control Message Protocol. [S.l.], 1981. Disponível em: http://www.faqs.org/rfcs/rfc792.html. Acesso em: Dezembro 2011. INSTITUTE, I. S. Transmission Control Protocol. [S.l.], 1981. Disponível em: http://www.faqs.org/rfcs/rfc793.html. Acesso em: Dezembro 2011.
INSTITUTE, I. S. The Internet Standards Process. [S.l.], 1996. Disponível em: http://www.faqs.org/rfcs/rfc2026.html. Acesso em: Dezembro 2012. INSTITUTE, I. S. Key words for use in RFCs to Indicate Requirement Levels. [S.l.], 1997. Disponível em: http://www.faqs.org/rfcs/rfc2119.html. Acesso em: Dezembro 2012. INSTITUTE, I. S. The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. [S.l.], 2001. Disponível em: http://www.faqs.org/rfcs/rfc3160.html. Acesso em: Dezembro 2012. INSTITUTE, I. S. TCP Congestion Control. [S.l.], 2001. Disponível em: http://www.faqs.org/rfcs/rfc5681.html. Acesso em: Dezembro 2012.
KAI X., TIAN Y., ANSARI N., Improving TCP performance in integrated wireless
communications networks. Computer Networks, Science Direct, 2005, páginas: 219-237.
KIM D., TOH C.-K., e CHOI Y., TCP-BUS: Improving TCP performance in wireless ad hoc
networks. Journal of Communications and Networks, junho 2001, páginas: 1707-1713.
KOPPARTY S., KRISHNAMURTHY S. V., FALOUTSOS M. e TRIPATHI S. K. Split TCP
for mobile ad hoc networks. In: Proceedings of IEEE GLOBECOM, 2002, páginas: 138–142.
138
KRISHNAN S. B., MOH M., MOH T., Enhancing TCP Performance in Hybrid Networks
with Fixed Senders and Mobile Receivers. Department of Computer Science San José, CA,
USA, In: GLOBECOM '07. IEEE Global Telecommunications Conference, 2007, páginas
5265-5270.
KURKOWSKI S., CAMP T., COLAGROSSO M., MANET Simulation Studies: The
Incredibles, Colorado School of Mines, Golden, Colorado, ACM International Symposium on
Mobile Ad Hoc Networking and Computing (MobiHoc), New York, USA, 2005.
KUROSE J. F. e ROSS K. W., Redes de Computadores e a Internet – Uma abordagem top-
down, tradução do original Computer Networking: a top-down approach featuring the
Internet, Editora Pearson, São Paulo, 2006.
LI M., AGRAWAL D., GANESAN D. e VENKATARAMANI A., Block-switched
Networks: A New Paradgm for Wireless Transport. In: Proceedings of the 6th ACM/USENIX
Symposium on Networked Systems Design and Implementation (NSDI 2009), Boston, Abril
2009, páginas: 423-436.
LIU J. e Suresh S., ATCP: TCP for Mobile Ad Hoc Networks, In: IEEE Journal on Selected
Areas in Communications, VOL. 19, NO. 7, julho 2001, páginas: 1300-1316.
LUDWIG R. e KATZ R. H., The Eifel algorithm: Making TCP robust against spurious
retransmissions. In: SIGCOMM Computer Communication Review, 2000, páginas: 30–36.
MATHIS M.,MAHDAVI J.,FLOYD S. E ROMANOW A., TCP-SACK - TCP Selective
Acknowledgment Options, RFC 2018, outubro 1996. Disponível em:
http://tools.ietf.org/html/rfc2018. acesso em: março de 2011.
Minitab, Minitab Inc., 2012. Disponível em: http://www.minitab.com. Acesso em: Outubro de
2011.
MONKS J., SINHA P., BHARGHAAN V., Limitations of TCP-ELFN for Ad hoc Networks,
Coordinated Science Laboratory, Universidade Illinois, In: Proceedings IEEE Mobicom,
Seatle, Agosto de 1999, páginas: 1-6.
139
MUSTAFA A. M. A., Comparison between Transmission Control Protocol Schemes on
Wireless Environment. Trabalho de conclusão de curso apresentado na Faculty of Computer
Science and Information System Universiti Teknologi, Malaysia, Novembro 2008.
NG C. H., CHOW J., TRAJKOVIC L., Performance Evaluation of TCP over WLAN 802.11
with the Snoop Performance Enhancing Proxy, Vancouver, British Columbia. Canada, In:
Proceedings of OPNETWORK, 2002, páginas 134-142.
RODRIGUES, C. K. O teorema central do limite: um estudo ecológico do saber e do didático. Tese (Doutorado em Educação Matemática). Pontifícia Universidade Católica de São Paulo, 2009.
ROMANOWICZ E., TCP with Explicit Link Failure Notification, Department of Computer
Science, York University, Toronto, Canada, Disponível em:
http://www.ewaromanowicz.com/academics/TCP_with_Explicit_Link_Failure_Notification.p
df, Acessado em: Janeiro de 2011.
SARKAR K. S., BASAVARAJU T. G., PUTTAMADAPPA C., Ad Hoc Mobile Wireless
Networks - Principles, Protocols, and Applications. New York, U.S.A. Editora Auerbach
Publications, 2008.
SAROLAHTI P., KOJO M., E RAATIKAINEN K., F-RTO: An Enhanced recovery
algorithm for TCP retransmission timeouts. In: SIGCOMM Computer Communication
Review, 2003, páginas: 51–63.
SCOTT K., BURLEIGH S., Bundle Protocol Specification, NASA Jet Propulsion Laboratory,
RFC 5050, Novembro, 2007, Disponível em: http://www.ietf.org/rfc/rfc5050.txt, Acesso em :
abril de 2011.
STEVENS W. R., GARY R. W., TCP/IP Illustrated, Volume 2: the implementation.
Indianapolis, Editora Pearson, Fevereiro de 2002.
STEVENS W. R., TCP/IP Illustrated: the protocols. Indianapolis, Editora Pearson, Novembro
de 2001.
140
STEVENS W., TCP RENO - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms, RFC 2001, Disponível em: ftp://ftp.rfc-editor.org, Acessado em:
Outubro de 2010.
SUNDARESAN K., VAIDYANATHAN S., HSIEH H. Y., e SIVAKUMAR R., ATP: A
reliable transport protocol for ad-hoc networks. In: Proceedings of ACM MobiHoc,
Annapolis, MD, 2003, páginas: 64–75.
TIAN Y., XU K., ANSARI N., TCP in Wireless Environments: Problems and Solutions, In:
IEEE Radio Communications, Março 2005, páginas: S27-S32.
V. JACOBSON., Congestion avoidance and control. In: Proceedings of ACM SIGCOMM '88
Symposium, agosto de 1988, páginas: 314-329.
WI-FI ALLIANCE, Wi-Fi CERTIFIED™ Remains a Key Market Enabler as Certifications
Reach 10,000. Disponível em: http://www.wi-fi.org. Acesso em: 15 de maio de 2011.
WIGLE. Wireless Geographic Logging Engine – Plotting WiFi on Maps. Disponível em:
http://www.wigle.net. Acessado em: 16 de maio de 2011.
XU K., TIAN Y., e ANSARI N., TCP-Jersey for wireless IP communications. IEEE Journal
on Selected Areas in Communications, 22(4), 2004, páginas: 747–756.
YAGHMAEE M. H., ADJEROH D., A Reliable Transport Protocol for Wireless Sensor
Networks. In: International Symposium on Telecommunications, 2008, páginas: 440-445.
141
Apêndice A
Código fonte da aplicação ClienteUDP em Java:
import java.net.DatagramPacket; import java.net.DatagramSocket; import java.net.InetAddress; /* * To change this template, choose Tools | Templates * and open the template in the editor. */ /* * UDPCliente.java * * Created on 10/09/2011, 19:21:45 */ /** * * @author RENATO */ public class UDPCliente extends javax.swing.JFrame { boolean parar = false; int MAX_PACKET_RECV = 1000; /** Creates new form UDPCliente */ public UDPCliente() { initComponents(); } /** This method is called from within the constructor to * initialize the form. * WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. */ @SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code">//GEN-BEGIN:initComponents private void initComponents() { jProgressBarRecepcao = new javax.swing.JProgressBar(); jButtonConectar = new javax.swing.JButton(); jLabelMensagem = new java.awt.Label(); jSpinnerIp1 = new javax.swing.JSpinner(); jSpinnerIp2 = new javax.swing.JSpinner(); jSpinnerIp3 = new javax.swing.JSpinner(); jSpinnerIp4 = new javax.swing.JSpinner(); label2 = new java.awt.Label(); label3 = new java.awt.Label(); jSpinnerPorta = new javax.swing.JSpinner(); jLabelNumPacotes = new java.awt.Label(); jButtonParar = new javax.swing.JButton(); setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
142
jButtonConectar.setText("Conectar ao Servidor"); jButtonConectar.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButtonConectarActionPerformed(evt); } }); jLabelMensagem.setText("Clique no botão para conectar-se ao servidor"); jSpinnerIp1.setModel(new javax.swing.SpinnerNumberModel(10, 0, 255, 1)); jSpinnerIp2.setModel(new javax.swing.SpinnerNumberModel(112, 0, 255, 1)); jSpinnerIp3.setModel(new javax.swing.SpinnerNumberModel(30, 0, 255, 1)); jSpinnerIp4.setModel(new javax.swing.SpinnerNumberModel(14, 0, 255, 1)); label2.setText("IP:"); label3.setText("Porta :"); jSpinnerPorta.setModel(new javax.swing.SpinnerNumberModel(5000, 1, 65534, 1)); jLabelNumPacotes.setText("0"); jButtonParar.setText("Parar"); jButtonParar.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButtonPararActionPerformed(evt); } }); javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); getContentPane().setLayout(layout); layout.setHorizontalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addGap(144, 144, 144) .addComponent(jButtonConectar)) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(jLabelMensagem, javax.swing.GroupLayout.DEFAULT_SIZE, 444, Short.MAX_VALUE)) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(label2, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)
143
.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jSpinnerIp1, javax.swing.GroupLayout.PREFERRED_SIZE, 46, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jSpinnerIp2, javax.swing.GroupLayout.PREFERRED_SIZE, 46, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jSpinnerIp3, javax.swing.GroupLayout.PREFERRED_SIZE, 46, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jSpinnerIp4, javax.swing.GroupLayout.PREFERRED_SIZE, 46, javax.swing.GroupLayout.PREFERRED_SIZE)) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(label3, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jSpinnerPorta, javax.swing.GroupLayout.PREFERRED_SIZE, 62, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jButtonParar)) .addGroup(layout.createSequentialGroup() .addContainerGap() .addComponent(jProgressBarRecepcao, javax.swing.GroupLayout.PREFERRED_SIZE, 363, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jLabelNumPacotes, javax.swing.GroupLayout.DEFAULT_SIZE, 71, Short.MAX_VALUE))) .addContainerGap()) ); layout.setVerticalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addContainerGap() .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addComponent(jProgressBarRecepcao, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED) .addComponent(jButtonConectar) .addGap(6, 6, 6)
144
.addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.TRAILING) .addComponent(label2, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addGroup(layout.createSequentialGroup() .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELINE) .addComponent(jSpinnerIp1, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addComponent(jSpinnerIp2, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addComponent(jSpinnerIp3, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addComponent(jSpinnerIp4, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)) .addGap(2, 2, 2))) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED, javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE) .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addComponent(label3, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addGroup(layout.createSequentialGroup() .addGap(5, 5, 5) .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELINE) .addComponent(jSpinnerPorta, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addComponent(jButtonParar)))) .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)) .addComponent(jLabelNumPacotes, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)) .addComponent(jLabelMensagem, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)) ); pack(); }// </editor-fold>//GEN-END:initComponents
145
private void jButtonConectarActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_jButtonConectarActionPerformed // TODO add your handling code here: byte [] dados = {0,1,2,3,4,5,6,7,8,9}; try { //aguarda contato do cliente DatagramSocket clienteSocket = new DatagramSocket(); jLabelMensagem.setText("Estabelecendo conexão com o servidor..."); byte[] numIP = new byte[4]; numIP[0] = (byte) Integer.parseInt(jSpinnerIp1.getModel().getValue().toString()); numIP[1] = (byte) Integer.parseInt(jSpinnerIp2.getModel().getValue().toString()); numIP[2] = (byte) Integer.parseInt(jSpinnerIp3.getModel().getValue().toString()); numIP[3] = (byte) Integer.parseInt(jSpinnerIp4.getModel().getValue().toString()); int porta = Integer.parseInt(jSpinnerPorta.getModel().getValue().toString()); InetAddress endereco = InetAddress.getByAddress(numIP); DatagramPacket pktEnv = new DatagramPacket(dados, dados.length,endereco,porta); clienteSocket.send(pktEnv); byte[] dadosRecv = new byte[500]; DatagramPacket pktRecv = new DatagramPacket(dadosRecv, dadosRecv.length); jProgressBarRecepcao.setMaximum(MAX_PACKET_RECV); int i = 0; jLabelMensagem.setText("Recebendo dados....."); while(i < MAX_PACKET_RECV) { clienteSocket.receive(pktRecv); i++; jProgressBarRecepcao.setValue(i); jLabelNumPacotes.setText(String.format("%d",i)); if (parar) break; } } catch(Exception e) { } jLabelMensagem.setText("Todos os pacotes foram recebidos com sucesso"); }//GEN-LAST:event_jButtonConectarActionPerformed private void jButtonPararActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_jButtonPararActionPerformed // TODO add your handling code here: parar = true; }//GEN-LAST:event_jButtonPararActionPerformed /** * @param args the command line arguments */ public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() {
146
public void run() { new UDPCliente().setVisible(true); } }); } // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton jButtonConectar; private javax.swing.JButton jButtonParar; private java.awt.Label jLabelMensagem; private java.awt.Label jLabelNumPacotes; private javax.swing.JProgressBar jProgressBarRecepcao; private javax.swing.JSpinner jSpinnerIp1; private javax.swing.JSpinner jSpinnerIp2; private javax.swing.JSpinner jSpinnerIp3; private javax.swing.JSpinner jSpinnerIp4; private javax.swing.JSpinner jSpinnerPorta; private java.awt.Label label2; private java.awt.Label label3; // End of variables declaration//GEN-END:variables }
147
Código fonte da aplicação ServidorUDP em Java:
/* * UdpServer.java * * Copyright © 1998-2010 Research In Motion Ltd. * * Note: For the sake of simplicity, this sample application may not leverage * resource bundles and resource strings. However, it is STRONGLY recommended * that application developers make use of the localization features available * within the BlackBerry development platform to ensure a seamless application * experience across a variety of languages and geographies. For more information * on localizing your application, please refer to the BlackBerry Java Development * Environment Development Guide associated with this release. */ package com.rim.samples.server.udpdemo; import java.io.*; import java.net.*; import java.util.Date; /** * This class represents the server in a client/server configuration */ public class UdpServer implements Runnable { final static int BROADCAST_PORT = 2010; /** * Entry point for application. */ public static void main(String args[]) { new UdpServer().run(); } public void run() { System.out.println(" -----------------UDP Demo Server-----------------" + "\n\n"); while(true) { try { // Create a new socket connection bound to the defined port DatagramSocket sock = new DatagramSocket(BROADCAST_PORT); System.out.println("Waiting for data on local port: " + sock.getLocalPort()); // Create a packet to contain incoming data byte[] buf = new byte[256];
148
DatagramPacket packet = new DatagramPacket(buf, buf.length); // Wait for incoming data (receive() is a blocking method) sock.receive(packet); // Retrieve data from packet and display String data = new String(packet.getData()); int endIndex = data.indexOf(0); data = data.substring(0, endIndex); int remotePort = packet.getPort(); System.out.println("Received data from remote port " + remotePort + ":\n" + data); // Determine origin of packet and display information InetAddress remoteAddress = packet.getAddress(); System.out.println("Sent from address: " + remoteAddress.getHostAddress()); // Send back an acknowledgment String ack = "RECEIVED " + new Date().toString(); sock.send(new DatagramPacket(ack.getBytes(), ack.length(), remoteAddress, remotePort)); sock.close(); } catch(IOException ioe) { System.out.println("Error: IOException - " + ioe.toString()); } } } }
149
Código fonte da variante TCP-UEM para o ns2 versão 2.34 (tcp-UEMNR.h)
#include "tcp.h" #define CLOSE_CWND_LOSS_RATE 0x00001000 struct loss_rate { int num_pkt_tx_; int num_pkt_loss_; }; class UemnrTcpAgent : public virtual RenoTcpAgent { public: UemnrTcpAgent(); virtual void recv(Packet* p, Handler*); virtual void timeout(int tno); virtual void dupack_action(); void partialnewack_helper(Packet* pkt); void slowdown(int how); protected: int max_cwnd_; //guarda o valor máximo da janela de congestionamento já alcançada durante a conexão. loss_rate lr; link_down_ lnk_down_; int new_dupack_; int new_dupack_factor_loss_; int new_dupack_factor_increment_; double loss_rate_monit_; int first_lost_; int newreno_changes_; /* 0 for fixing unnecessary fast retransmits */ /* 1 for additional code from Allman, */ /* to implement other algorithms from */ /* Hoe's paper, including sending a new */ /* packet for every two duplicate ACKs. */ /* The default is set to 0. */ int newreno_changes1_; /* Newreno_changes1_ set to 0 gives the */ /* Slow-but-Steady variant of NewReno from */ /* RFC 2582, with the retransmit timer reset */ /* after each partial new ack. */ /* Newreno_changes1_ set to 1 gives the */ /* Impatient variant of NewReno from */ /* RFC 2582, with the retransmit timer reset */ /* only for the first partial new ack. */ /* The default is set to 0 */ void partialnewack(Packet *pkt); int allow_fast_retransmit(int last_cwnd_action_); int acked_, new_ssthresh_; /* used if newreno_changes_ == 1 */ double ack2_, ack3_, basertt_; /* used if newreno_changes_ == 1 */ int firstpartial_; /* For the first partial ACK. */ int partial_window_deflation_; /* 0 if set cwnd to ssthresh upon */ /* partial new ack (default) */ /* 1 if deflate (cwnd + dupwnd) by */ /* amount of data acked */ /* "Partial window deflation" is */ /* discussed in RFC 2582. */ int exit_recovery_fix_; /* 0 for setting cwnd to ssthresh upon */ /* leaving fast recovery (default) */ /* 1 for setting cwnd to min(ssthresh, */ /* amnt. of data in network) when leaving */ };
150
Código fonte da variante TCP-UEM para o ns2 versão 2.34 (tcp-UEMNR.cc)
#include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <math.h> #include "packet.h" #include "ip.h" #include "flags.h" #include "tcp-UEMNR.h" static class UemnrTcpClass : public TclClass { public: UemnrTcpClass() : TclClass("Agent/TCP/UEMNR") {} TclObject* create(int, const char*const*) { return (new UemnrTcpAgent()); } } class_uemnrtcp; UemnrTcpAgent::UemnrTcpAgent() : TcpAgent() { newreno_changes_ = 0; newreno_changes1_ = 0; acked_ = 0; firstpartial_ = 0; partial_window_deflation_ = 0; exit_recovery_fix_ = 0; max_cwnd_ = 0; lnk_down_.valid_ACK_ = true; lnk_down_.is_link_down_ = false; lnk_down_.is_lost_sequential_ = false; lnk_down_.seqno_ = t_seqno_; lnk_down_.cwnd_ =cwnd_; lnk_down_.cont_timeout_ = 0; lnk_down_.ssthresh_ = ssthresh_; lnk_down_.num_pkt_loss_ = 1.0; lnk_down_.num_pkt_send_ = 1.0; new_dupack_ = 0; new_dupack_factor_increment_ = 3; new_dupack_factor_loss_ = 1.0; loss_rate_monit_ = 0; first_lost_ = 1; bind("num_pkt_loss_",&lnk_down_.num_pkt_loss_); bind("num_pkt_send_",&lnk_down_.num_pkt_send_); bind("cont_timeout_",&lnk_down_.cont_timeout_); bind("new_dupack_",&new_dupack_); bind("new_dupack_factor_loss_",&new_dupack_factor_loss_); bind("loss_rate_monit_",&loss_rate_monit_); bind("newreno_changes_", &newreno_changes_); bind("newreno_changes1_", &newreno_changes1_); bind("exit_recovery_fix_", &exit_recovery_fix_); bind("partial_window_deflation_", &partial_window_deflation_); bind("link_down_", &lnk_down_.is_link_down_); bind("max_cwnd_", &max_cwnd_); } /* * Process a packet that acks previously unacknowleges data, but * does not take us out of Fast Retransmit. */ void UemnrTcpAgent::partialnewack(Packet* pkt)
151
{ hdr_tcp *tcph = hdr_tcp::access(pkt); if (partial_window_deflation_) { // Do partial window deflation before resetting last_ack_ unsigned int deflate = 0; // Should initialize it?? - haoboy if (tcph->seqno() > last_ack_) // assertion deflate = tcph->seqno() - last_ack_; else printf("False call to partialnewack: deflate %u \ last_ack_ %d\n", deflate, last_ack_); if (dupwnd_ > deflate) dupwnd_ -= (deflate - 1); else { cwnd_ -= (deflate - dupwnd_); // Leave dupwnd_ > 0 to flag "fast recovery" phase dupwnd_ = 1; } if (cwnd_ < 1) {cwnd_ = 1;} } last_ack_ = tcph->seqno(); highest_ack_ = last_ack_; if (t_seqno_ < last_ack_ + 1) t_seqno_ = last_ack_ + 1; if (rtt_active_ && tcph->seqno() >= rtt_seq_) { rtt_active_ = 0; t_backoff_ = 1; } } void UemnrTcpAgent::partialnewack_helper(Packet* pkt) { if (!newreno_changes1_ || firstpartial_ == 0) { firstpartial_ = 1; /* For newreno_changes1_, * only reset the retransmit timer for the first * partial ACK, so that, in the worst case, we * don't have to wait for one packet retransmitted * per RTT. */ newtimer(pkt); } partialnewack(pkt); //output(last_ack_ + 1, 0); } int UemnrTcpAgent::allow_fast_retransmit(int /* last_cwnd_action_*/) { return 0; } void UemnrTcpAgent::dupack_action() { int recovered = (highest_ack_ > recover_); int recovered1 = (highest_ack_ == recover_); int allowFastRetransmit = allow_fast_retransmit(last_cwnd_action_); if (recovered || (!bug_fix_ && !ecn_) || allowFastRetransmit || (bugfix_ss_ && highest_ack_ == 0)) { // (highest_ack_ == 0) added to allow Fast Retransmit // when the first data packet is dropped. // Bug report from Mark Allman. goto reno_action;
152
} if (bug_fix_ && less_careful_ && recovered1) { /* * For the Less Careful variant, allow a Fast Retransmit * if highest_ack_ == recover. * RFC 2582 recommends the Careful variant, not the * Less Careful one. */ goto reno_action; } if (ecn_ && last_cwnd_action_ == CWND_ACTION_ECN) { last_cwnd_action_ = CWND_ACTION_DUPACK; /* * What if there is a DUPACK action followed closely by ECN * followed closely by a DUPACK action? * The optimal thing to do would be to remember all * congestion actions from the most recent window * of data. Otherwise "bugfix" might not prevent * all unnecessary Fast Retransmits. */ reset_rtx_timer(1,0); output(last_ack_ + 1, TCP_REASON_DUPACK); dupwnd_ = numdupacks_; return; } if (bug_fix_) { if (bugfix_ts_ && tss[highest_ack_ % tss_size_] == ts_echo_) goto reno_action; else if (bugfix_ack_ && cwnd_ > 1 && highest_ack_ - prev_highest_ack_ <= numdupacks_) goto reno_action; else /* * The line below, for "bug_fix_" true, avoids * problems with multiple fast retransmits in one * window of data. */ return; } reno_action: recover_ = maxseq_; reset_rtx_timer(1,0); if (!lossQuickStart()) { trace_event("UEMNR_FAST_RETX"); last_cwnd_action_ = CWND_ACTION_DUPACK; loss_rate_monit_ = (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_) * cwnd_; new_dupack_factor_loss_+= loss_rate_monit_; //aumenta a força do fator de perdas if ((max_cwnd_ < cwnd_) && (!first_lost_)) max_cwnd_ = cwnd_; //slowdown(CLOSE_CWND_LOSS_RATE); //slowdown(CLOSE_SSTHRESH_HALF|CLOSE_CWND_HALF); slowdown(CLOSE_CWND_LOSS_RATE_DUPACK); lnk_down_.num_pkt_loss_++; output(last_ack_ + 1, TCP_REASON_DUPACK); // from top dupwnd_ = numdupacks_; } return; }
153
void UemnrTcpAgent::recv(Packet *pkt, Handler*) { hdr_tcp *tcph = hdr_tcp::access(pkt); int valid_ack = 0; /* Use first packet to calculate the RTT --contributed by Allman */ if (qs_approved_ == 1 && tcph->seqno() > last_ack_) endQuickStart(); if (qs_requested_ == 1) processQuickStart(pkt); if (++acked_ == 1) basertt_ = Scheduler::instance().clock() - firstsent_; /* Estimate ssthresh based on the calculated RTT and the estimated bandwidth (using ACKs 2 and 3). */ else if (acked_ == 2) ack2_ = Scheduler::instance().clock(); else if (acked_ == 3) { ack3_ = Scheduler::instance().clock(); new_ssthresh_ = int((basertt_ * (size_ / (ack3_ - ack2_))) / size_); if (newreno_changes_ > 0 && new_ssthresh_ < ssthresh_) ssthresh_ = new_ssthresh_; } #ifdef notdef if (pkt->type_ != PT_ACK) { fprintf(stderr, "ns: confiuration error: tcp received non-ack\n"); exit(1); } #endif /* W.N.: check if this is from a previous incarnation */ if (tcph->ts() < lastreset_) { // Remove packet and do nothing Packet::free(pkt); return; } ++nackpack_; ts_peer_ = tcph->ts(); if (hdr_flags::access(pkt)->ecnecho() && ecn_) ecn(tcph->seqno()); recv_helper(pkt); recv_frto_helper(pkt); if (tcph->seqno() > last_ack_) { if (tcph->seqno() >= recover_ || (last_cwnd_action_ != CWND_ACTION_DUPACK)) { if (dupwnd_ > 0) { dupwnd_ = 0; if (last_cwnd_action_ == CWND_ACTION_DUPACK) last_cwnd_action_ = CWND_ACTION_EXITED; if (exit_recovery_fix_) { int outstanding = maxseq_ - tcph->seqno() + 1; if (ssthresh_ < outstanding) cwnd_ = ssthresh_; else cwnd_ = outstanding; }
154
} firstpartial_ = 0; recv_newack_helper(pkt); if (last_ack_ == 0 && delay_growth_) { cwnd_ = initial_window(); } } else { /* received new ack for a packet sent during Fast * Recovery, but sender stays in Fast Recovery */ if (partial_window_deflation_ == 0) dupwnd_ = 0; partialnewack_helper(pkt); } } else if (tcph->seqno() == last_ack_) { if (hdr_flags::access(pkt)->eln_ && eln_) { tcp_eln(pkt); return; } if (++dupacks_ == numdupacks_) { dupack_action(); if (!exitFastRetrans_) dupwnd_ = numdupacks_; } else if (dupacks_ > numdupacks_ && (!exitFastRetrans_ || last_cwnd_action_ == CWND_ACTION_DUPACK)) { trace_event("NEWRENO_FAST_RECOVERY"); ++dupwnd_; // fast recovery /* For every two duplicate ACKs we receive (in the * "fast retransmit phase"), send one entirely new * data packet "to keep the flywheel going". --Allman */ if (newreno_changes_ > 0 && (dupacks_ % 2) == 1) output (t_seqno_++,0); } else if (dupacks_ < numdupacks_ && singledup_ ) { send_one(); } } if (tcph->seqno() >= last_ack_) // Check if ACK is valid. Suggestion by Mark Allman. valid_ack = 1; Packet::free(pkt); #ifdef notyet if (trace_) plot(); #endif /* *Atualiza a estrutura link_down */ if (valid_ack) { new_dupack_++; //contador de acks sequenciais //diminui a força do fator de perdas new_dupack_factor_loss_-= loss_rate_monit_; if (new_dupack_factor_loss_ < 0) new_dupack_factor_loss_ = 1; lnk_down_.valid_ACK_ = true; if (lnk_down_.is_link_down_) { cwnd_ = lnk_down_.cwnd_; ssthresh_ = lnk_down_.ssthresh_; lnk_down_.num_pkt_send_ = 1.0; lnk_down_.num_pkt_loss_ = 1.0; } lnk_down_.is_link_down_ = false;
155
lnk_down_.is_lost_sequential_ = false; lnk_down_.seqno_ = highest_ack_ + 1; lnk_down_.cwnd_ = cwnd_; lnk_down_.ssthresh_ = ssthresh_; lnk_down_.cont_timeout_ = 1.0; lnk_down_.num_pkt_send_++; } else { lnk_down_.valid_ACK_ = false; new_dupack_=0; //contador de acks sequenciais } /* * Try to send more data */ if (valid_ack || aggressive_maxburst_) { if (dupacks_ == 0) /* * Maxburst is really only needed for the first * window of data on exiting Fast Recovery. */ send_much(0, 0, maxburst_); else if (dupacks_ > numdupacks_ - 1 && newreno_changes_ == 0) send_much(0, 0, 2); } } void UemnrTcpAgent::timeout(int tno) { new_dupack_ = 0; /* retransmit timer */ if (tno == TCP_TIMER_RTX) { // There has been a timeout - will trace this event trace_event("TIMEOUT"); frto_ = 0; // Set pipe_prev as per Eifel Response pipe_prev_ = (window() > ssthresh_) ? window() : (int)ssthresh_; //atualiza contador de timeouts if (lnk_down_.seqno_ == (highest_ack_ + 1)) lnk_down_.cont_timeout_++; lnk_down_.num_pkt_loss_++; //Se timeout > 0 e perda não é sequencial então a perda passa a ser sequencial if ((lnk_down_.cont_timeout_ >3) && !lnk_down_.is_lost_sequential_) lnk_down_.is_lost_sequential_ = true; //if ((lnk_down_.cont_timeout_ > (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_)) && lnk_down_.is_lost_sequential_ ) { if (((lnk_down_.cont_timeout_ / lnk_down_.cwnd_) > (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_)) && lnk_down_.is_lost_sequential_ ) { lnk_down_.is_link_down_ = true; }
156
if (lnk_down_.is_link_down_) { send_one(); set_rtx_timer(); reset_rtx_timer(0,0); return; } if (cwnd_ < 1) cwnd_ = 1; if (qs_approved_ == 1) qs_approved_ = 0; if (highest_ack_ == maxseq_ && !slow_start_restart_) { /* * TCP option: * If no outstanding data, then don't do anything. */ // Should this return be here? // What if CWND_ACTION_ECN and cwnd < 1? // return; } else { recover_ = maxseq_; if (highest_ack_ == -1 && wnd_init_option_ == 2) /* * First packet dropped, so don't use larger * initial windows. */ wnd_init_option_ = 1; else if ((highest_ack_ == -1) && (wnd_init_option_ == 1) && (wnd_init_ > 1) && bugfix_ss_) /* * First packet dropped, so don't use larger * initial windows. Bugfix from Mark Allman. */ wnd_init_ = 1; if (highest_ack_ == maxseq_ && restart_bugfix_) /* * if there is no outstanding data, don't cut * down ssthresh_. */ slowdown(CLOSE_CWND_ONE|NO_OUTSTANDING_DATA); else if (highest_ack_ < recover_ && last_cwnd_action_ == CWND_ACTION_ECN) { /* * if we are in recovery from a recent ECN, * don't cut down ssthresh_. */ slowdown(CLOSE_CWND_ONE); if (frto_enabled_ || sfrto_enabled_) { frto_ = 1; } } else { ++nrexmit_; last_cwnd_action_ = CWND_ACTION_TIMEOUT; if (first_lost_) { slowdown(CLOSE_SSTHRESH_HALF|CLOSE_CWND_ONE); first_lost_ = 0; } else {
157
slowdown(CLOSE_CWND_LOSS_RATE); } if (frto_enabled_ || sfrto_enabled_) { frto_ = 1; } } } /* if there is no outstanding data, don't back off rtx timer */ if (highest_ack_ == maxseq_ && restart_bugfix_) { reset_rtx_timer(0,0); } else { reset_rtx_timer(0,1); } last_cwnd_action_ = CWND_ACTION_TIMEOUT; send_much(0, TCP_REASON_TIMEOUT, maxburst_); } else { timeout_nonrtx(tno); } } void UemnrTcpAgent::slowdown(int how) { double decrease; /* added for highspeed - sylvia */ double win, halfwin, decreasewin; int slowstart = 0; ++ncwndcuts_; if (!(how & TCP_IDLE) && !(how & NO_OUTSTANDING_DATA)){ ++ncwndcuts1_; } // we are in slowstart for sure if cwnd < ssthresh if (cwnd_ < ssthresh_) slowstart = 1; if (precision_reduce_) { halfwin = windowd() / 2; if (wnd_option_ == 6) { /* binomial controls */ decreasewin = windowd() - (1.0-decrease_num_)*pow(windowd(),l_parameter_); } else if (wnd_option_ == 8 && (cwnd_ > low_window_)) { /* experimental highspeed TCP */ decrease = decrease_param(); //if (decrease < 0.1) // decrease = 0.1; decrease_num_ = decrease; decreasewin = windowd() - (decrease * windowd()); } else { decreasewin = decrease_num_ * windowd(); } win = windowd(); } else { int temp; temp = (int)(window() / 2); halfwin = (double) temp; if (wnd_option_ == 6) { /* binomial controls */ temp = (int)(window() - (1.0-decrease_num_)*pow(window(),l_parameter_)); } else if ((wnd_option_ == 8) && (cwnd_ > low_window_)) { /* experimental highspeed TCP */ decrease = decrease_param();
158
//if (decrease < 0.1) // decrease = 0.1; decrease_num_ = decrease; temp = (int)(windowd() - (decrease * windowd())); } else { temp = (int)(decrease_num_ * window()); } decreasewin = (double) temp; win = (double) window(); } if (how & CLOSE_SSTHRESH_HALF) // For the first decrease, decrease by half // even for non-standard values of decrease_num_. if (first_decrease_ == 1 || slowstart || last_cwnd_action_ == CWND_ACTION_TIMEOUT) { // Do we really want halfwin instead of decreasewin // after a timeout? ssthresh_ = (int) halfwin; } else { ssthresh_ = (int) decreasewin; } else if (how & THREE_QUARTER_SSTHRESH) if (ssthresh_ < 3*cwnd_/4) ssthresh_ = (int)(3*cwnd_/4); if (how & CLOSE_CWND_HALF) // For the first decrease, decrease by half // even for non-standard values of decrease_num_. if (first_decrease_ == 1 || slowstart || decrease_num_ == 0.5) { cwnd_ = halfwin; } else cwnd_ = decreasewin; else if (how & CWND_HALF_WITH_MIN) { // We have not thought about how non-standard TCPs, with // non-standard values of decrease_num_, should respond // after quiescent periods. cwnd_ = decreasewin; if (cwnd_ < 1) cwnd_ = 1; } else if (how & CLOSE_CWND_RESTART) cwnd_ = int(wnd_restart_); else if (how & CLOSE_CWND_INIT) cwnd_ = int(wnd_init_); else if (how & CLOSE_CWND_ONE) cwnd_ = 1; else if (how & CLOSE_CWND_HALF_WAY) { // cwnd_ = win - (win - W_used)/2 ; cwnd_ = W_used + decrease_num_ * (win - W_used); if (cwnd_ < 1) cwnd_ = 1; } else if (how & CLOSE_CWND_LOSS_RATE) { /*double loss_rate_ = (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_) * cwnd_;*/ double loss_rate_ = (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_) * cwnd_; ssthresh_ = cwnd_ + 1; loss_rate_ = loss_rate_ * new_dupack_factor_loss_; loss_rate_monit_ = loss_rate_; if (loss_rate_ < 1) loss_rate_ = 1.0;
159
/*cwnd_ = ssthresh_ - loss_rate_;*/ // diminui a janela com base na taxa de erro. double time = Scheduler::instance().clock(); int mediaSegTransPorSegundo = (lnk_down_.num_pkt_send_ * size_) / (time); //2º opção: ajusta a janela com base na taxa de transmissão (throgouput) ssthresh_ = mediaSegTransPorSegundo / size_; //cwnd_ = ssthresh_ -loss_rate_; cwnd_ = ssthresh_ - (ssthresh_ / t_rtt_); if (cwnd_ < 1) { cwnd_ = 1; } } else if (how & CLOSE_CWND_LOSS_RATE_DUPACK) { double loss_rate_ = (lnk_down_.num_pkt_loss_ / lnk_down_.num_pkt_send_) * cwnd_; ssthresh_ = cwnd_; //cwnd_ = 3 * ssthresh_ / 4; cwnd_ = 3 * max_cwnd_ / 4; if (cwnd_ < 1) { cwnd_ = 1; } } if (ssthresh_ < 2) ssthresh_ = 2; if (how & (CLOSE_CWND_HALF|CLOSE_CWND_RESTART|CLOSE_CWND_INIT|CLOSE_CWND_ONE)) cong_action_ = TRUE; fcnt_ = count_ = 0; if (first_decrease_ == 1) first_decrease_ = 0; // for event tracing slow start if (cwnd_ == 1 || slowstart) // Not sure if this is best way to capture slow_start // This is probably tracing a superset of slowdowns of // which all may not be slow_start's --Padma, 07/'01. trace_event("SLOW_START"); }