TCP-UEM: uma abordagem para controle de congestionamento …mestrado/diss/2012/goncalves.pdf · 2013-02-21 · tentam tratar o problema na camada de transporte. Outras soluções

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


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.


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.


• 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.


• 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.


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.


• 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.


• 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.


• 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).


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










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


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




UDPServer



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


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 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




UDPServer



1 1000 1000 Misto de Cabo e

Rádio


Rádio


Rádio


Rádio


Rádio


55

Rádio


Rádio


Rádio


Rádio


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


Enlace 1 1 ms Cabo

Enlace 2 12 ms Cabo

Enlace 3 23 ms Cabo


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.




UDPServer




Rádio


Rádio


Rádio


Rádio


Rádio


56

Rádio


Rádio


Rádio


Rádio


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)




UDPServer



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)




UDPServer



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)




UDPServer



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.


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.


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.


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:

107

Máquina de estado finito 1 - TCP-UEM

108


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


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 now [$ns now]

set acumulado1 [expr $acumulado1 + [expr $bandaNode1/$time*8/100000]]




#registra a média do uso da largura de banda percebida pelo destinatário

116

puts $traceBWNode1 “$now [expr $acumulado1 / contador]




$sinkNode1 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


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.


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"); }

Documents

TCP-UEM: uma abordagem para controle de congestionamento …mestrado/diss/2012/goncalves.pdf · 2013-02-21 · tentam tratar o problema na camada de transporte. Outras soluções