ads:
MINIST
´
ERIO DA DEFESA
EX
´
ERCITO BRASILEIRO
DEPARTAMENTO DE CI
ˆ
ENCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAC¸
˜
AO
MARCELO REIS DA SILVA
ADAPTAC¸
˜
AO DA CAMADA DE TRANSPORTE ATRAV
´
ES DA
CORRETA SELEC¸
˜
AO DE ALGORITMO DE CONTROLE DE
CONGESTIONAMENTO
Rio de Janeiro
26 de Janeiro de 2009
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
INSTITUTO MILITAR DE ENGENHARIA
MARCELO REIS DA SILVA
ADAPTAC¸
˜
AO DA CAMADA DE TRANSPORTE ATRAV
´
ES DA
CORRETA SELEC¸
˜
AO DE ALGORITMO DE CONTROLE DE
CONGESTIONAMENTO
Disserta¸c˜ao de Mestrado apresentada ao Curso de
Mestrado em Sistemas e Computa¸c˜ao do Instituto Mili-
tar de Engenharia, como requisito parcial para obten¸c˜ao
do t´ıtulo de Mestre em Sistemas e Computa¸c˜ao.
Orientador: Prof. Ronaldo Moreira Salles - Ph.D.
Rio de Janeiro
26 de Janeiro de 2009
ads:
c2009
INSTITUTO MILITAR DE ENGENHARIA
Pra¸ca General Tib´urcio, 80-Praia Vermelha
Rio de Janeiro-RJ CEP 22290-270
Este exemplar ´e de propriedade do Instituto Militar de Engenharia, que poder´a inclu´ı-
lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma
de arquivamento.
´
E permitida a men¸c˜ao, reprodu¸c˜ao parcial ou integral e a transmiss˜ao entre bibliotecas
deste trabalho, sem modifica¸c˜ao de seu texto, em qualquer meio que esteja ou venha a
ser fixado, para pesquisa acadˆemica, coment´arios e cita¸c˜oes, desde que sem finalidade
comercial e que seja feita a referˆencia bibliogr´afica completa.
Os conceitos expressos neste trabalho s˜ao de responsabilidade do autor e do orientador.
S586a Silva, M. R.
Adapta¸c˜ao da Camada de Transporte Atrav´es da
Correta Sele¸c˜ao de Algoritmo de Controle de Conges-
tionamento/ Marcelo Reis da Silva. – Rio de Janeiro:
Instituto Militar de Engenharia, 26 de Janeiro de 2009.
94 p.: il.
Disserta¸c˜ao (mestrado) – Instituto Militar de Enge-
nharia – Rio de Janeiro, 26 de Janeiro de 2009.
1. Redes de comunicao de dados. 2. Transporte
adaptativo. I. T´ıtulo. I I. Instituto Militar de Engenha-
ria.
CDD 004.06
2
INSTITUTO MILITAR DE ENGENHARIA
MARCELO REIS DA SILVA
ADAPTAC¸
˜
AO DA CAMADA DE TRANSPORTE ATRAV
´
ES DA
CORRETA SELEC¸
˜
AO DE ALGORITMO DE CONTROLE DE
CONGESTIONAMENTO
Disserta¸c˜ao de Mestrado apresentada ao Curso de Mestrado em Sistemas e Com-
puta¸c˜ao do Instituto Militar de Engenharia, como requisito parcial para obten¸c˜ao do
t´ıtulo de Mestre em Sistemas e Computa¸c˜ao.
Orientador: Prof. Ronaldo Moreira Salles - Ph.D.
Aprovada em 26 de Janeiro de 2009 pela seguinte Banca Examinadora:
Prof. Ronaldo Moreira Salles - Ph.D. do IME - Presidente
Prof. Magnos Martinello - Ph.D. da UFES
Prof. Sidney Cunha de Lucena - DSc. da UNIRIO
Prof. Raquel Coelho Gomes Pinto - D.Sc. do IME
Rio de Janeiro
26 de Janeiro de 2009
3
Dedico esta disserta¸c˜ao ao meu DEUS, o Pai das lu-
zes, de quem procede to da boa d´adiva e todo dom
perfeito, em quem n˜ao h´a mudan¸ca nem sombra de
varia¸c˜ao.
4
AGRADECIMENTOS
Agrade¸co, acima de tudo, a JESUS, que sustenta todas as coisas pela Palavra do seu
Poder.
`
As irm˜as de ora¸c˜ao da Assembl´eia de Deus em Parque Col´umbia, Pastoreada pelo
servo do SENHOR Artur Lu´ıs de Meireles, pela forma simples e fervorosa com que sempre
apresentavam minhas causas diante do SENHOR.
Ao meu Orientador, Major Salles, por sua paciˆencia, dedica¸c˜ao e pelos excelentes
conselhos.
A todos os meus familiares, em especial `a minha Esposa Beatriz, cujo ap oio n˜ao se
pode descrever com palavras e ao meu irm˜ao Luciano pelos equipamentos cedidos.
Agrade¸co a todas as pessoas que contribu´ıram com o desenvolvimento desta dis-
serta¸c˜ao de mestrado, tenha sido por meio de cr´ıticas, id´eias, apoio, incentivo ou qualquer
outra forma de aux´ılio.
Por fim, a todos os professores e funcion´arios do Departamento de Engenharia de
Sistemas (SE/8) do Instituto Militar de Engenharia.
Marcelo Reis da Silva
5
Se o degrau alcan¸cado n˜ao revelar um pouco mais da
minha pequenez, eu, na verdade, deslizei.
O AUTOR
6
SUM
´
ARIO
LISTA DE ILUSTRAC¸
˜
OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
LISTA DE ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 INTRODUC¸
˜
AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1 Abrangˆencia e complexidade das redes de comunica¸c˜ao . . . . . . . . . . . . . . . . . . . 18
1.2 Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1 Projeto C2 em Combate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2 Discrepˆancia nas liga¸c˜oes fim-a-fim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1 Particionando Conex˜oes TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.2 Enlaces com produto banda retardo elevado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.3 Transporte sobre UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.4 Redes Autonˆomicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4 Variando o Transporte nas Distribui¸c˜oes Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Organiza¸c˜ao da Disserta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 CONCEITOS B
´
ASICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Suite TCP: Uma vis˜ao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 An´alise da Camada de Transporte TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Intera¸c˜ao entre as camadas Aplica¸c˜ao e de Transporte : “Sockets”. . . . . . . . . 29
2.2.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Transporte TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 Controle de Congestionamento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.5 Intera¸c˜ao Entre as Camadas Transporte e Internet . . . . . . . . . . . . . . . . . . . . . . . 35
2.3 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 EVOLUC¸
˜
AO DO TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Vis˜ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Variantes TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7
3.2.1 BIC (XU, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 CUBIC (XU, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Fast TCP (JIN, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.4 High Speed TCP (HSTCP) (FLOYD, 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5 Scalable TCP (STCP) (KELLY, 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.6 TCP Hybla (CAINI, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.7 TCP-Illinois (LIU, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.8 TCP Vegas (BRAKMO, 1994) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.9 H-TCP (SHORTEN, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.10 Compound TCP (TAN, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.11 TCP Westwood (CASETTI, 2001) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.12 TCP Westwood+ (DELL’AERA, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.13 Resumo das Variantes TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 AN
´
ALISE DA VIABILIDADE E METODOLOGIA PARA CONS-
TRUC¸
˜
AO DE UMA CAMADA DE TRANSPORTE ADAPTATIVA 41
4.1 Viabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Considera¸c˜oes iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 DESEMPENHO DAS VARIANTES TCP . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1 Experimento com enlaces de 1200 bits por Segundo a 1 Megabit por
segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Experimento com enlace de 10 Megabits por segundo . . . . . . . . . . . . . . . . . . . . 48
5.3 Experimento com Enlace de 100 Megabits por segundo . . . . . . . . . . . . . . . . . . . 49
5.4 Experimento com Enlace de 1 Gigabit por segundo . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Paralelo com a Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 CRIT
´
ERIOS DE ADAPTAC¸
˜
AO ENTRE AS VARIANTES TCP . 55
6.1 An´alise dos Experimentos com enlaces de at´e 10Megabits por segundo . . . . . . 55
6.2 An´alise do Experimento com enlace de 100 Megabits por segundo . . . . . . . . . . 55
6.3 Enlace de 1 Gigabit por Segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Escolhendo a melhor abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8
7 ESTUDO DE CASOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1 Cen´ario Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Realiza¸c˜ao de Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8 ARQUITETURA E IMPLEMENTAC¸
˜
AO . . . . . . . . . . . . . . . . . . . . . . . . 61
8.1 Padr˜oes de Projeto: Vis˜ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.2 O Padr˜ao Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.3 Padr˜ao State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.4 Arquitetura da Camada de Transporte Adaptativa . . . . . . . . . . . . . . . . . . . . . . . 63
8.5 Implementa¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.5.1 Colhendo os Parˆametros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.5.1.1 RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.5.1.2 Banda Dispon´ıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.6 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9 ADAPTAC¸
˜
AO SOBRE UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.1 Preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2 An´alise do TCP e do UDP Em Enlaces Restritos . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.1 Ambiente de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.2 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3 Analisando os desempenhos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.3 Estruturando a Adapta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10 CONSIDERAC¸
˜
OES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.1 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
11 REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
12 AP
ˆ
ENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
12.1 Netem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.1.1 Vis˜ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.1.2 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.2 sysctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12.2.1 Vis˜ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9
12.2.2 Refinando os Parˆametros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12.3 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10
LISTA DE ILUSTRAC¸
˜
OES
FIG.1.1 Arquitetura Programa C2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
FIG.1.2 Estrutura da Rede Rio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
FIG.2.1 Analogia Camadas OSI X Camadas TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
FIG.2.2 O Papel dos Sockets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
FIG.2.3 Transporte UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
FIG.2.4 Conex˜ao TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
FIG.2.5 Multiplexa¸c˜ao/Demultiplexa¸c˜ao TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
FIG.2.6 Atualiza¸c˜ao da Janela de Congestionamneto TCP. . . . . . . . . . . . . . . . . . . . 34
FIG.2.7 Intera¸c˜ao Camadas Transporte e Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIG.5.1 Estrutura para Enlaces de 1200bps a 1Mbps. . . . . . . . . . . . . . . . . . . . . . . . 44
FIG.5.2 Desempenho dos Protocolos: 1200 bps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
FIG.5.3 Desempenho dos Protocolos: 56 Kbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
FIG.5.4 Desempenho dos Protocolos: 512 Kbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
FIG.5.5 Desempenho dos Protocolos: 1 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
FIG.5.6 Estrutura para Enlace de 10 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
FIG.5.7 Desempenho dos Protocolos: 10 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
FIG.5.8 Desempenho dos Protocolos: 100 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
FIG.5.9 Estrutura para Enlace 1 Gbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
FIG.5.10 Desempenho dos Protocolos: 1 Gbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
FIG.8.1 Padr˜ao Observer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
FIG.8.2 Padr˜ao State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
FIG.8.3 Transporte adaptativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
FIG.8.4 Transporte adaptativo: Vis˜ao Detalhada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
FIG.8.5 Arquitetura da Camada de Transporte Adaptativa. . . . . . . . . . . . . . . . . . . 64
FIG.8.6 T´ecnica de medi¸c˜ao de banda par de pacote. . . . . . . . . . . . . . . . . . . . . . . . . 66
FIG.8.7 Implementa¸c˜ao de uma Camada de Transporte Adaptativa. . . . . . . . . . . . 67
FIG.9.1 Ambiente de testes - TCP X UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
FIG.9.2 TCP X UDP 10%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
FIG.9.3 TCP X UDP 25%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
11
FIG.9.4 TCP X UDP 50%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
FIG.9.5 Adapta¸c˜ao Sobre UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
FIG.12.1 Disciplina de Fila e o Netem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12
LISTA DE TABELAS
TAB.1.1 Computa¸c˜ao “Tradiconal” X Autonˆomica. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
TAB.3.1 Variantes TCP e suas indica¸c˜oes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
TAB.6.1 Ganhos Percentuais do CUBIC em Rela¸c˜ao ao Reno - Enlace de
100 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
TAB.6.2 Ganhos Percentuais do BIC em Rela¸c˜ao ao Reno - Enlace de 1
Gbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
TAB.6.3 Condi¸c˜oes de emprego dos protocolos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
TAB.7.1 Desempenho esperado dos protocolos CUBIC e Reno em enlaces
Ethernet e sat´elite (GEO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
TAB.7.2 Dura¸c˜ao do processo de backup com uso exclusivo do Reno. . . . . . . . . . . . 59
TAB.7.3 Dura¸c˜ao do processo de backup com uso exclusivo do CUBIC. . . . . . . . . . 59
TAB.7.4 Dura¸c˜ao do processo de backup com adapta¸c˜ao entre o Reno e o
CUBIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
TAB.8.1 Principais ferramentas de medi¸c˜ao da banda fim-a-fim. . . . . . . . . . . . . . . . 67
TAB.12.1 Vari´aveis que devem ser ajustadas para enlaces de alta velocidade. . . . . 87
13
LISTA DE ABREVIATURAS
C2 - Comando e Controle
ACK - Acknowledge
AIMD - Additive Increase Multiplicative Decrease
BDP - Bandwidth delay product
BIC - Binary Increase Congestion
COTER - Comando de Opera¸c˜oes Terrestres
cwnd - congestion window
DNS - Domain Name System
DSL - Digital Subscriber Line
ERE - Eligible Rate Estimation
FDT - Fio Duplo Telefˆonico
FTP - File Transfer Protocol
GEO - Geo-estacion´ario
HF - High frequency
HSTCP - HighSpeed TCP
HTTP - Hypertext Transfer Protocol
IME - Instituto Militar de Engenharia
med - M´edio
min - M´ınimo
MSS - Maximum segment size
MTU - Maximum transmit unit
Netem - Network Emulation
OSI - Open Systems Interconnection
PER - Packet Error Rate
RTT - Round-trip time
SISCOMIS - Sistema de Comunica¸c˜oes Militares por Sat´elite
SNT - Sistema Nacional de Telecomunica¸c˜oes
ssthresh - Slow Start threshold
STCP - Scalable TCP
14
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
VHF - Very High Frequency
WAN - Wide Area Network
15
RESUMO
Hoje em dia, as transmiss˜oes sem fio, junto com a r´apida expans˜ao de redes de alta
velocidade, imp˜oem novos desafios aos protocolos de transporte de dados. Dentre estes
desafios, destacam-se as conex˜oes de longo round trip time (RTTs), as conex˜oes com ta-
xas de erros de pacotes (PER) n˜ao desprez´ıveis (HF, por exemplo), e grandes largura de
banda. Para superar estes desafios, um grande n´umero de variantes TCP ´e apresentado na
literatura com finalidades e prop´ositos diferentes. Entretanto, como a maioria das propos-
tas s˜ao desenvolvidas para solucionar problemas diferentes, elas representam otimiza¸c˜oes
para redes espec´ıficas. Conseq¨uentemente, dado o n´ıvel crescente de heterogeneidade das
redes atuais e futuras, a escolha da melhor abordagem de transporte parece um problema
em aberto. Este trabalho prop˜oe uma metodologia para a sele¸c˜ao de diferentes vers˜oes
de protocolos de transporte caracterizando uma camada de transporte adaptativa. A
proposta ´e simples, de baixo custo e baseada em experimentos reais. Alguns crit´erios,
a serem adotados para a sele¸c˜ao do transporte de dados, s˜ao discutidos. S˜ao fornecidos
resultados relativos a topologias de rede reais, escolhidas para ilustrar as vantagens de
uma camada de transporte adaptativa. Tais resultados s˜ao extremamente encorajadores
e justificam as observa¸c˜oes que se seguem sobre a viabilidade e implementa¸c˜ao de uma
camada deste tipo.
16
ABSTRACT
Nowadays, the wireless transmissions, together with the rapid growth of high speed
networks, pose new challenges to the data transport protocols. Among them, the most
prominent are long round trip times (RTTs), not negligible (HF, for instance) packet
error rates (PER), and very large bandwidths. To overcome them, a wide variety of TCP
enhancements has been presented in the literature with different purposes and capabilities.
However, as most prop osals aim to address specific impairments, they are optimizations
for specific network environments. Therefore, given the increasing level of heterogeneity of
present and future networks, the choice of the best transport enhancement seems a quite
open problem. This work proposes a selection methodology among different transport
protocol versions, characterizing an adaptive transport layer. Such proposal is simple, low
cost and built from real experiments. Some criteria, to be adopted for the data transport
selection, are discussed. Results, referring to real network topologies, chosen to ilustrate
the adaptive transport layer advantages, are provided. They are quite encouraging and
justify the following remarks about viability and such a layer implementation.
17
1 INTRODUC¸
˜
AO
1.1 ABRANG
ˆ
ENCIA E COMPLEXIDADE DAS REDES DE COMUNICAC¸
˜
AO
Ao considerar-se as redes de comunica¸c˜ao, ´e f´acil observar que elas tˆem permeado
praticamente todas as ´areas da atividade humana. Seja na calmaria do campo, seja no
agito das grandes cidades, quer no lazer ou nas atividades profissionais, na guerra ou
na paz, as conex˜oes de dados tornam as distˆancias entre os diversos ambientes cada vez
menor. A expans˜ao das redes de dados ´e, portanto, algo inevit´avel em uma sociedade
que, p or diversos fatores, principalmente econˆomicos, busca cada vez mais a globaliza¸c˜ao.
T˜ao diversas quantas as situa¸c˜oes permeadas pelas redes de comunica¸c˜ao s˜ao as carac-
ter´ısticas dos componentes da sua malha. Essa heterogeneidade exige a adapta¸c˜ao das
camadas sup eriores para que haja comunica¸c˜ao entre quaisquer dois pontos desta rede.
A configura¸c˜ao das redes est´a cada vez mais complexa, como resultado da combina¸c˜ao de
diferentes:
• Plataformas
No mundo das plataformas, entidades agregadoras dos componentes de hardware
utilizados nas redes de comunica¸c˜ao, h´a varia¸c˜oes em praticamente todos os as-
pectos: tamanho, capacidade de processamento, capacidade de armazenamento,
arquitetura, etc.
• Aplica¸c˜oes
Diversas s˜ao as aplica¸c˜oes clientes das redes de dados, cada qual com seus requi-
sitos e exigˆencias sobre o desempenho das mesmas para atingirem seus prop´ositos.
Aplica¸c˜oes em tempo real , por exemplo, requerem que novos dados sejam entregues
a todo instante e no tempo correto; aplica¸c˜oes el´asticas devem primar pela corre¸c˜ao e
recupera¸c˜ao dos dados trocados; j´a as aplica¸c˜oes multim´ıdias exigem pequeno jitter,
e assim por diante.
• Tecnologias de transmiss˜ao
Interligando as plataformas existem diversos tipos de enlaces diferentes com carac-
ter´ısticas pr´oprias quanto `a taxa de transmiss˜ao, largura de banda, sensibilidade `a
18
interferˆencia, latˆencia, grau de mobilidade, etc.
A diversifica¸c˜ao das tecnologias envolvidas na comunica¸c˜ao digital tem influenciado de
forma decisiva os requisitos dos projetos, inclusive aqueles de cunho b´elico. No Ex´ercito
Brasileiro esta influˆencia pode ser comprovada pelas caracter´ısticas do projeto C2 (Co-
mando e Controle) em Combate.
1.2 MOTIVAC¸
˜
AO
1.2.1 PROJETO C2 EM COMBATE
Para auxiliar as atividades de comando e controle do Ex´ercito Brasileiro, foi criado,
atrav´es da portaria n´umero 102 - Comando da For¸ca, de 18 de mar¸co de 2003, o projeto
C2 em combate (COTER, 2002), composto por dois grandes vetores: O Programa C2
em Combate e o M´odulo de Telem´atica. O M´odulo de Telem´atica provˆe diversas tecnolo-
gias de enlace atrav´es das quais o Programa C2 em Combate trafegar´a suas informa¸c˜oes
(FIG. 1.1). Sendo assim, um dos principais requisitos do programa C2 em combate ´e
a capacidade de trocar seus dados independente da tecnologia de enlace disponibilizada
pelo m´odulo de telem´atica em um dado momento. Dentre os enlaces poss´ıveis de serem
FIG. 1.1: Arquitetura Programa C2.
escolhidos est˜ao: r´adio (HF, VHF), sat´elite (SISCOMIS), ethernet, DSL (FDT), etc . Cer-
tamente a manuten¸c˜ao de um mesmo algoritmo de transporte quando do chaveamento
entre uma liga¸c˜ao DSL (velocidades da ordem de centenas de kilobits ou at´e Megabits
por segundo) (KESSLER, 1992) e uma em HF (no m´aximo 1200 bps, com taxa de erro
m´edia de 50% (JOHNSON, 1995)), poderia comprometer a troca de informa¸c˜oes.
19
1.2.2 DISCREP
ˆ
ANCIA NAS LIGAC¸
˜
OES FIM-A-FIM
Um fato observado nas grandes redes de computadores (WAN´s, por exemplo) ´e que as
liga¸c˜oes entre os clientes de um servidor s˜ao as mais diversas, sofrendo varia¸c˜oes principal-
mente na capacidade fim-a-fim dos enlaces. Para exemplificar, consideremos a topologia
da rede rio (FIG 1.2)
FIG. 1.2: Estrutura da Rede Rio.
Nesta rede imaginemos que dois clientes, um na OI e outro no HEMORIO estejam
conectados a um servidor do CBPF. Na ausˆencia de sobrecarga, o protocolo de transporte
que rege a conex˜ao entre este servidor e o terminal localizado na OI pode ser bem mais
agressivo do que aquele presente na conex˜ao estabelecida entre o CBPF e o HEMORIO,
pois no primeiro caso disp˜oe-se de um enlace de capacidade maior ou igual a 1 Gbps,
enquanto que no segundo a velocidade da conex˜ao n˜ao chega a 100 Mbps.
Muitos trabalhos refletem a preocupa¸c˜ao dos pesquisadores com a diversidade das redes
de comunica¸c˜ao, introduzindo conceitos que representam a flexibiliza¸c˜ao dos mecanismos
envolvidos na liga¸c˜ao entre dois terminais. Alguns destes trabalhos foram estudados
durante a revis˜ao bibliogr´afica. O resultado desta revis˜ao comp˜oe o conte´udo da se¸c˜ao a
seguir.
20
1.3 TRABALHOS RELACIONADOS
1.3.1 PARTICIONANDO CONEX
˜
OES TCP
Devido `as diferen¸cas significativas que os enlaces componentes de uma liga¸c˜ao fim-a-fim
podem apresentar entre si (fibra ´otica, ethernet, 802.11, R´adio, etc), estudos (REZENDE,
2008) est˜ao propondo uma adapta¸c˜ao da camada de transporte atrav´es da cria¸c˜ao de
sess˜oes TCP entre pares de n´os que interconectam as m´aquinas transmissora e receptora.
Estas sess˜oes TCP objetivam emular uma conex˜ao fim-a-fim mais eficiente. Os n´os inter-
medi´arios servem como comutadores da camada de transporte numa abordagem conhecida
com “split approach” (LEE, 2008). O presente trabalho, por´em, concentra seus esfor¸cos
sob uma abordagem fim-a-fim, que trata a comunica¸c˜ao entre o receptor e o transmissor
sem levar em considera¸c˜ao os n´os intermedi´arios entre eles.
1.3.2 ENLACES COM PRODUTO BANDA RETARDO ELEVADO
´
E ineg´avel que a atual Internet tornou-se funcional com o uso dos algoritmos de con-
gestionamento presentes nas vers˜oes tradicionais do TCP (Tahoe, Reno, New Reno). En-
tretanto, o TCP se mostra pouco escal´avel em redes com produto banda retardo (BDP)
elevado, tamb´em chamadas de fast long-distance networks, isto ´e, elevada velocidade e
longo RTT. Tanto o emprego cada vez maior dos enlaces com velocidade na ordem de
Gigabits por segundo, quanto a utiliza¸c˜ao de liga¸c˜oes de alta latˆencia (sat´elites, por exem-
plo), s˜ao suficientes para elevar o produto banda retardo a n´ıveis nos quais o throghput
alcan¸cado pelas vers˜oes tradicionais do TCP ser´a bem aqu´em da capacidade real do en-
lace. Para amenizar este problema, diversos autores tˆem proposto novas fun¸c˜oes para
atualiza¸c˜ao da janela de congestionamento, apresentando assim diversas variantes TCP
para redes de alto BDP, tais como BIC TCP (XU, 2004), CUBIC (XU, 2005), Fast TCP
(JIN, 2004), H-TCP (SHORTEN, 2004), High Speed TCP (FLOYD, 2003), abordadas
com maiores detalhes no decorrer deste trabalho.
Infelizmente, a maioria dos trabalhos realizados para confrontar o desempenho das
novas vers˜oes TCP s˜ao baseados em simula¸c˜oes, onde h´a maior chance de a influˆencia de
fatores importantes relacionados `a transmiss˜ao de dados em ambientes reais ser tratada
de maneira inadequada. Neste trabalho, adota-se uma abordagem pr´atica, atrav´es de
experimentos em laborat´orio, para avali¸c˜ao da escalabilidade de algumas destas vers˜oes.
Este trabalho n˜ao visa propor uma nova abordagem, mas fornecer crit´erios para es-
21
colher, entre as op¸c˜oes de transporte de dados hoje disponibilizadas, aquela que melhor
se adequada ao estado momentˆaneo da rede.
1.3.3 TRANSPORTE SOBRE UDP
No outro extremo dos enlaces de grande capacidade, est˜ao aqueles que oferecem peque-
nas taxas de transmiss˜ao da ordem de centenas de bits por segundo associada a elevada
taxa de erros. Os enlaces r´adio de alta freq¨uˆencia (HF), enquadram-se nesta categoria.
Por associar alta mobilidade a um custo relativamente baixo, a comunica¸c˜ao baseada em
HF continuar´a exercendo por muito tempo ainda um importante papel nos sistemas de
comunica¸c˜ao, principalmente em contextos operacionais. S´o para ilustrar, podemos citar
o que aconteceu durante as opera¸c˜oes de salvamento ap´os o ataque de 11 de setembro
em Nova Iorque (JODALEN, 2004), onde a falta de energia el´etrica, a destrui¸c˜ao parcial
das redes e o congestionamento causado p or milhares de chamadas simultˆaneas produzi-
ram um colapso na infra-estrutura de telecomunica¸c˜oes. Durante o resgate das v´ıtimas, a
Guarda Nacional Americana dispunha apenas das redes HF para conduzir as opera¸c˜oes.
O emprego de protocolos de transporte baseados em UDP em redes HF, com esquemas
espec´ıficos para trabalhar sobre enlaces com quase nenhum feed-back, no lugar de proto-
colos de transportes reativos (TCP), pode reduzir o tempo de download de um arquivo
de dezenas de horas para dezenas de minutos (ASENSTORFER, 1997).
Por este motivo, o trabalho tamb´em traz uma an´alise a respeito dos ganhos reais que
o UDP pode trazer em rela¸c˜ao ao TCP quando os dados s˜ao transmitidos por enlaces que
se aproximem das caracter´ısticas proporcionadas pelas transmiss˜oes digitais em HF.
Ser˜ao realizadas portanto, considera¸c˜oes a respeito de uma camada de transporte
adaptativa sobre UDP. Estas considera¸c˜oes s˜ao para emprego em projetos especiais tais
como o Projeto C2 em Combate, que prevˆe a possibilidade de se trabalhar com os mais
diversos tipos de enlaces, incluindo o HF.
H´a, al´em daquelas situa¸c˜oes em que se empregam enlaces de baixa capacidade e ele-
vadas taxas de erro, ocasi˜oes em que n˜ao ´e interessante para as aplica¸c˜oes todos os servi¸cos
oferecidos por uma camada de transporte reativa. Dentre elas, destacam-se:
• Aplica¸c˜oes de tempo real: Para este tipo de aplica¸c˜ao n˜ao vale a pena perder tempo
com o reenvio de pacotes perdidos em detrimento daqueles que est˜ao sendo gerados
durante suas atividades.
22
• Aplica¸c˜oes com necessidade de resposta r´apida: O TCP, por exemplo, perde muito
tempo com a abertura de conex˜ao antes da troca efetiva de dados. Aplica¸c˜oes como
DNS, no entanto, precisam de respostas r´apidas `as suas requisi¸c˜oes, sem perder
tempo com as preliminares pr´oprias do TCP.
• Clientes leves: O transporte orientado a conex˜ao requer o armazenamento de in´u-
meras vari´aveis de estado para viabiliza¸c˜ao das suas atividades. Com UDP, por´em,
o estado das conex˜oes ´e ignorado, aumentando significativamente, assim, o n´umero
m´aximo de requisi¸c˜oes que podem ser atendidas por um servidor ao mesmo tempo.
1.3.4 REDES AUTON
ˆ
OMICAS
Existe uma forte tendˆencia, devido ao grande n´umero de usu´arios alcan¸cados pelas
redes de comunica¸c˜ao, em tornar esta rede cada vez mais independente do usu´ario final,
ou seja, os sistemas computacionais devem interligar-se de forma auto configur´avel, en-
carregando os administradores das tarefas de elevada complexidade. As redes baseadas
nesta filosofia s˜ao denominadas autonˆomicas (KEPHART, 2003). Uma das caracter´ısticas
das redes autonˆomicas ´e a capacidade de gerenciar seus n´os e conex˜oes sem a interven¸c˜ao
humana, “aprendendo” a modificar seu comportamento atrav´es da an´alise de eventos que
ocorrem na rede. A tabela 1.1 re´une os principais vetores da computa¸c˜ao autonˆomica e
seus objetivos em rela¸c˜ao `as tecnologias tradicionais.
Como j´a foi dito, as redes atuais s˜ao extremamente complexas. Portanto, a existˆencia
de um mecanismo de transporte de dados que possa, em fun¸c˜ao das condi¸c˜oes da rede,
escolher a melhor fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento de forma im-
percept´ıvel para os usu´arios finais vai ao encontro dos objetivos perseguidos pela Auto
configura¸c˜ao e Auto-otimiza¸c˜ao pregadas na computa¸c˜ao autonˆomica.
1.4 VARIANDO O TRANSPORTE NAS DISTRIBUIC¸
˜
OES LINUX
A necessidade da adapta¸c˜ao da camada de transporte ´e t˜ao evidente que, a partir do
kernel 2.6.7, algumas distribui¸c˜oes linux j´a trazem a op¸c˜ao de carregamento de outros algo-
ritmos de controle de congestionamento em tempo de execu¸c˜ao atrav´es do comando sysctl
(Cap. 12.2). A ativa¸c˜ao dos m´odulos, entretanto, depende da interven¸c˜ao do usu´ario, que
deve carreg´a-los atrav´es da linha de comando. Al´em disso, dificilmente os usu´arios finais,
interessados em uma computa¸c˜ao cada vez mais autonˆomica, ter˜ao discernimento a ponto
23
Vetores da Computa¸c˜ao Autonˆomica
Conceito Computa¸c˜ao “Tradicional” Computa¸c˜ao Autonˆomica
Auto configura¸c˜ao A instala¸c˜ao, configura¸c˜ao
e interliga¸c˜ao entre sistemas
consome tempo e ´e alta-
mente suscet´ıvel a erros.
Configura¸c˜ao dos sistemas
em alto n´ıvel. Os outros
ajustes s˜ao feitos de forma
autom´atica e transparente
pelo pr´oprio sistema.
Auto-otimiza¸c˜ao Os sistemas possuem cente-
nas de parˆametros, dificil-
mente ajustados de forma
´otima. Esses parˆametros
crescem a cada nova dis-
tribui¸c˜ao.
Os componentes do sis-
tema procuram continua-
mente oportunidades para
melhorar seu desempenho e
eficiˆencia.
Auto diagn´ostico A identifica¸c˜ao de um pro-
blema em um sistema com-
plexo pode consumir v´arias
semanas da equipe de pro-
gramadores.
O sistema automatica-
mente detecta, diagnostica
e repara problemas lo-
calizados de hardware e
software
Auto prote¸c˜ao A detec¸c˜ao e recupera¸c˜ao de
ataques ou falhas em cadeia
´e manual.
O sistema automatica-
mente se defende contra
ataques maliciosos e usa um
hist´orico para se antecipar
e prever falhas que compro-
metam o sistema como um
todo.
TAB. 1.1: Computa¸c˜ao “Tradiconal” X Autonˆomica.
24
de escolherem a melhor abordagem de transporte para uma determinada rede. Outro
ponto que deve ser destacado ´e que, ap´os a mudan¸ca do algoritmo de transporte, somente
as novas conex˜oes seguir˜ao as novas regras, ou seja, aquelas previamente estabelecidas
continuar˜ao regidas pelo m´odulo em vigor durante o seu in´ıcio (SILVA, 2006).
Um kernel da fam´ılia 2.6.7, dotado da possibilidade de alterar o “tipo” de TCP em
tempo de execu¸c˜ao, serviu de base para realiza¸c˜ao dos experimentos deste trabalho, cuja
proposta visa o levantamneto de dados em topologias de redes reais.
1.5 OBJETIVO
Apesar de v´arios estudos estarem sendo realizados com o objetivo de tornar o trans-
porte mais escal´avel poss´ıvel, pouco se discute a respeito de uma camada adaptativa,
isto ´e, um esquema de transporte que pudesse agregar v´arias maneiras de realizar a co-
munica¸c˜ao fim-a-fim e escolher uma delas dinamicamente, de acordo com as condi¸c˜oes
impostas pela rede, ou seja, uma camada de transporte conforme a camada de rede. Este
trabalho visa a flexibiliza¸c˜ao da camada de transporte, adaptando-a convenientemente
`a diversidade pr´opria das redes de comunica¸c˜ao hodiernas. Para isso, vamos estudar
as vantagens de uma camada de transporte adaptativa e propor uma arquitetura para
implementa¸c˜ao de uma camada desse tipo.
Esta arquitetura ´e apresentada visando a constru¸c˜ao de camadas de transporte adap-
tativas capazes de suportar ajustes em seus mecanismos, mesmo durante a troca de da-
dos. Ou seja, ainda que uma determinada conex˜ao j´a tenha sido estabelecida, a proposta
deste trabalho visa dar a esta conex˜ao a possibilidade de adequar-se aos novos valores
dos parˆametros da rede, os quais, em geral, podem a qualquer momento assumir valores
praticamente imprevis´ıveis.
O trabalho faz uma investiga¸c˜ao da viabilidade de uma camada de transporte adapta-
tiva e levanta, de forma pr´atica, alguns crit´erios para defini¸c˜ao da escolha entre aborda-
gens de transporte diferentes. Para isso, uma tabela relacionar´a o protocolo de transporte
(vers˜ao TCP), mais indicado para os valores do RTT e velocidade apresentados por uma
liga¸c˜ao fim-a-fim. Esta tabela servir´a de base para as camadas de transporte adaptativas
adequarem suas atividades `as condi¸c˜oes impostas pela rede em um dado momento.
Visando atender situa¸c˜oes mais espec´ıficas, avalia-se, atrav´es de cen´arios reais, os ga-
nhos que o emprego de um transporte sem conex˜ao pode produzir em rela¸c˜ao a protocolos
de transporte reativos em enlaces que se aproximem das caracter´ısticas pr´oprias da trans-
25
miss˜ao de dados em HF.
`
A luz destes resultados, s˜ao feitas considera¸c˜oes de como se
implementaria uma camada de transporte que precisasse alternar entre uma abordagem
de transporte espec´ıfica sobre UDP para uma filosofia mais tradicional.
1.6 ORGANIZAC¸
˜
AO DA DISSERTAC¸
˜
AO
O trabalho est´a dividido em 10 cap´ıtulos. No Cap´ıtulo 2 ser˜ao apresentados os con-
ceitos b´asicos da comunica¸c˜ao digital, necess´arios aos estudos realizados neste trabalho.
O Cap´ıtulo 3 traz um hist´orico da evolu¸c˜ao do protocolo TCP desde suas vers˜oes mais
remotas at´e aquelas projetadas em fun¸c˜ao das tecnologias de transmiss˜ao atuais.
Do cap´ıtulo 4 ao cap´ıtulo 8 tratam-se quest˜oes relativas a uma camada de transporte
que ajuste suas atividades dentro das variantes TCP.
O cap´ıtulo 4 analisa viabilidade de uma camada de transporte que seja capaz de
agregar diversas vers˜oes TCP e faz uma descri¸c˜ao da metodologia adotada pelo trabalho.
No cap´ıtulo 5, levantam-se os dados que v˜ao servir de crit´erio para sele¸c˜ao do controle
de congestionamento mais adequado dentre as vers˜oes TCP.
No Cap´ıtulo 6, ´e feita uma an´alise geral dos resultados obtidos no cap´ıtulo 5, an´alise
esta que serve de base para a determina¸c˜ao dos crit´erios de chaveamento entre as variantes
TCP de melhor desempenho.
O cap´ıtulo 7 apresenta alguns estudos de casos, para destacar-se as vantagens que
podem advir de uma camada de transporte flex´ıvel.
O cap´ıtulo 8 detalha a arquitetura para implementa¸c˜ao de uma camada de transporte
adaptativa entre as variantes TCP. Ainda neste cap´ıtulo, s˜ao feitas considera¸c˜oes sobre
ferramentas que podem auxiliar o processo de desenvolvimento de uma camada TCP
adaptativa.
O cap´ıtulo 9 agrupa a segunda fase do trabalho. S˜ao feitas considera¸c˜oes sobre as
vantagens do UDP em rela¸c˜ao ao TCP em enlaces com elevada taxa de erro e baixa
velocidade. Al´em disso, ´e apresentado um modelo de transporte adaptativo sobre UDP.
Por fim, o cap´ıtulo 10 destaca as principais conclus˜oes e algumas propostas para
trabalhos futuros.
26
2 CONCEITOS B
´
ASICOS
2.1 SUITE TCP: UMA VIS
˜
AO GERAL
Todo e qualquer tipo de comunica¸c˜ao requer um conjunto m´ınimo de servi¸cos que a
torne poss´ıvel. Nas comunica¸c˜oes digitais n˜ao ´e diferente; as mesmas precisam de canal,
controle de erros, roteamento, controle de fluxo, controle de congestionamento, etc. A fim
de facilitar o projeto e organiza¸c˜ao das redes de dados, a International Organization for
Standardization desenvolveu o modelo de referˆencia OSI (Open System Interconnection),
que define como os v´arios servi¸cos envolvidos numa comunica¸c˜ao digital devem intera-
gir entre si. Estes servi¸cos foram hierarquizados (STALLING, 1994) em sete camadas:
aplica¸c˜ao, apresenta¸c˜ao, sess˜ao, transporte, rede, enlace e f´ısica. Cada camada se uti-
liza das tarefas das camadas adjacentes, sem acesso aos detalhes de implementa¸c˜ao das
mesmas.
O TCP/IP ´e uma suite de protocolos padronizada utilizada para conectar diferentes
dispositivos de uma rede. Pode-se dizer que o TCP ´e uma simplifica¸c˜ao do modelo OSI
(FIG. 2.1). No topo da pilha TCP/IP encontramos a camada de aplica¸c˜ao que agrega
FIG. 2.1: Analogia Camadas OSI X Camadas TCP.
protocolos de alto n´ıvel tais como FTP, HTTP, SMTP, Telnet, DNS, etc.
A camada de transporte foi projetada para gerenciar a comunica¸c˜ao entre processos
27
instanciados nos terminais de uma rede. Dois mecanismos de transportes foram definidos
nesta camada, o TCP (Transmission Control Protocol) e o UDP (User Datagram Proto-
col), que ser˜ao estudados com maiores detalhes na sess˜ao a seguir. A camada Internet
define um formato padronizado de pacotes chamado IP (Internet Protocol), e ´e encar-
regada da transferˆencia de dados entre dispositivos associados a endere¸cos IP distintos.
Os dados oriundos da camada de transporte s˜ao, na camada Internet, distribu´ıdos em um
ou mais p eda¸cos menores, cada qual com seu cabe¸calho IP, e com seu pr´oprio conjunto
de bytes detetores de erros; a camada de transporte instanciada no computador remoto,
ao receber os dados da camada Internet, checa a integridade deles; uma vez que n˜ao haja
erros, eles s˜ao remontados e encaminhados ao programa que os espera.
A camada rede terminal n˜ao possui protocolos bem definidos por esta arquitetura,
devendo entretanto ser capaz de encaminhar os pacotes IP que a sensibilizem.
Como este trabalho visa propor uma modifica¸c˜ao na camada de transporte sobre IP, ´e
feita a seguir uma investiga¸c˜ao mais detalhada da camada de transporte na pilha TCP/IP
e da sua intera¸c˜ao com as camadas aplica¸c˜ao e Internet.
2.2 AN
´
ALISE DA CAMADA DE TRANSPORTE TCP/IP
A camada de transporte TCP/IP (TANENBAUM, 2003) (KUROSE, 2008) tem por
finalidade promover a comunica¸c˜ao entre processos remotos de forma transparente, ou
seja, se um pro cesso gera uma mensagem para um outro, ele simplesmente entrega esta
mensagem para a camada de transporte, que, com o aux´ılio das camadas inferiores, se en-
carregar´a de dar `a mensagem o devido destino. A camada de transporte realiza, portanto,
algumas atividades chaves, dentre as quais destacam-se:
• Garantia da confiabilidade: Os dados devem chegar ao destino da maneira como
foram gerados pelo transmissor;
• Multiplexa¸c˜ao: V´arios processos podem estar injetando dados na camada de trans-
porte ao mesmo tempo, o que exige que esta camada seja capaz agregar a comu-
nica¸c˜ao ente diversos processos diferentes;
• Demultiplexa¸c˜ao: Os dados oriundos das camadas inferiores devem ser despachados
para os respectivos processos destino;
28
• Controle de Congestionamento: A camada de transporte deve ser capaz de aproveitar
ao m´aximo a capacidade de escoamento de dados da rede sem sobrecarreg´a-la;
• Controle de Fluxo: A taxa com que os dados s˜ao transportados deve respeitar a
capacidade de tratamento destes dados por parte do receptor.
2.2.1 INTERAC¸
˜
AO ENTRE AS CAMADAS APLICAC¸
˜
AO E DE TRANSPORTE :
“SOCKETS”
Tanto o TCP quanto o UDP utilizam como interface com a aplica¸c˜ao os sockets. Cada
processo na m´aquina que deseja utilizar os servi¸cos da camada de transporte da pilha IP
deve estar associado a um socket que se encarrega de intermediar a troca de dados entre
cada processo e a camada de transporte (FIG. 2.2).
FIG. 2.2: O Papel dos Sockets.
2.2.2 UDP
Nesta modalidade de transporte (POSTEL, 1980), n˜ao h´a implementa¸c˜ao de controle
de congestionamento, a confiabilidade resume-se a verificar se os segmentos recebidos est˜ao
´ıntegros, sem se preocupar com a p ossibilidade de perda ou desordena¸c˜ao dos mesmos. A
multiplexa¸c˜ao/demultiplexa¸c˜ao ´e feita principalmente atrav´es da porta destino, ou seja,
pelo valor da porta destino o transporte UDP despacha os segmentos para o processo
29
ligado ao socket associado `aquela porta, de forma que dois processos remotos podem
atingir o mesmo socket desde que eles enviem para a mesma porta destino (FIG. 2.3).
FIG. 2.3: Transporte UDP.
2.2.3 TRANSPORTE TCP
O transporte TCP trata a confiabilidade de forma muito mais ampla quando com-
parado ao UDP, j´a que o TCP, al´em de verificar a integridade dos segmentos, tamb´em
realiza a recupera¸c˜ao de segmentos eventualmente perdidos bem como reordena os data-
gramas caso os mesmos cheguem fora de ordem. As conex˜oes s˜ao estabelecidas da seguinte
forma: h´a no servidor um socket encarregado de receber novas conex˜oes; quando um socket
no cliente informa a este socket o desejo de abrir uma conex˜ao com o servidor, estes dois
sockets realizam o famoso three-way handshaking (KUROSE, 2008); uma vez aceita a
conex˜ao, instancia-se um novo socket no servidor, agora respons´avel pela troca de dados
efetivos entre este servidor e o cliente (FIG. 2.4).
Na multiplexa¸c˜ao/demultiplexa¸c˜ao utilizam-se as portas associadas aos processos in-
terligados pela rede; cada par ordenado de n´umero de portas identifica um determinado
socket, como ilustrado na Figura 2.5.
30
FIG. 2.4: Conex˜ao TCP.
FIG. 2.5: Multiplexa¸c˜ao/Demultiplexa¸c˜ao TCP.
31
Quando os dados s˜ao recebidos pela camada de transporte eles s˜ao agrupados em
segmentos, cujo tamanho deve variar de acordo com as caracter´ısticas do enlace (MTU).
O controle de congestionamento pode ser resumidamente descrito como sendo o n´umero
m´aximo de segmentos que a camada de transporte passa `as camadas inferiores a cada
transmiss˜ao. Esta quantidade ´e influenciada por dois fatores: a capacidade do receptor
(controle de fluxo), e a capacidade da rede (controle de congestionamento). O transmis-
sor guarda consigo dois valores, o n´umero m´aximo de bytes que podem ser tratados pelo
receptor (janela de fluxo), e o n´umero estimado de bytes que podem ser lan¸cados na infra-
estrutura da rede sem congestion´a-la (janela de congestionamento), denotada por cwnd.
O menor entre estes dois valores ser´a a quantidade de dados que a camada de transporte
ir´a despejar na rede a cada tentativa de transmiss˜ao. Na pr´oxima sess˜ao analisaremos
com mais detalhes as vari´aveis envolvidas no controle de congestionamneto TCP.
2.2.4 CONTROLE DE CONGESTIONAMENTO TCP
Durante o estabelecimento de uma conex˜ao TCP o transmissor e o receptor negociam
o valor inicial da janela de congestionamento (cwnd), chamado de Maximum Segment
Size (MSS). Durante a transmiss˜ao a janela de congestionamento nas diversas variantes
TCP tem seu valor, dado em MSS’s, ditado por uma fun¸c˜ao cujos valores das vari´aveis de
dom´ınio s˜ao determinados de acordo com o n´umero de segmentos que tiveram seu rece-
bimento confimado pelo receptor. A confima¸c˜ao de cada por¸c˜ao transmitida ´e realizada
atrav´es de pacotes ACK’s durante toda a transmiss˜ao. Dependendo do perfil de chegada
dos pacotes ACK’s, o transporte TCP assume algum dos estados abaixo relacionados:
a) Slow Start
Inicialmente, a fonte TCP n˜ao possui qualquer informa¸c˜ao atinente ao estado da
rede. Em raz˜ao disso, o algoritmo Slow Start inicia a conex˜ao com uma janela de con-
gestionamento de 1 MSS, sendo aumentada exponencialmente no decorrer da trans-
miss˜ao. O TCP utiliza o Slow Start no in´ıcio de cada conex˜ao ou no caso de timeout
(tempo m´aximo de espera por uma confirma¸c˜ao). O algoritmo ´e resumido a seguir:
1. In´ıcio da conex˜ao ou ap´os o timeout −→ cwnd = 1;
2. Cada recebimento de ACK −→ cwnd = cwnd + 1.
32
A ocorrˆencia de timeout ´e interpretada pelo TCP como um ind´ıcio de alto grau de
congestionamento da rede. Desta forma, o algoritmo reduz bruscamente a janela de
congestionamento e, conseq¨uentemente, a taxa de envio dos pacotes.
b) Congestion Avoidance
Ap´os a ocorrˆencia do primeiro timeout, o algoritmo Congestion Avoidance ´e acionado,
visando incrementar a cwnd de maneira mais conservadora, aumentada de 1 MSS
cada vez que todos os segmentos da janela atual s˜ao entregues com sucesso. J´a o
decremento da cwnd ´e mais agressivo, reduzida `a metade caso algum segmento se
perca durante uma rodada de transmiss˜ao. Esta filosofia de funcionamneto, que
adota incremento aditivos (neste caso, 1 MSS a cada vez que todos os segmentos da
cwnd s˜ao entregues com sucesso), e decr´escimos multiplicativos (o valor da cwnd ´e
aqui reduzido `a metade), ´e conhecido como AIMD (Additive Increase/Multiplicative-
Decrease). O Congestion Avoidance ´e apresentado a seguir:
1. Cada recebimento de ACK −→ cwnd = cwnd +
1
cwnd
Na realidade, os algoritmos Slow Start e Congestion Avoidance s˜ao implementa-
dos em conjunto, sob o controle de uma vari´avel denominada ssthresh (Slow Start
threshold) da seguinte maneira:
1. In´ıcio da conex˜ao −→ cwnd = 1 e ssthresh = 0 : Slow Start;
2. Ocorreu timeout −→ ssthresh =
cwnd
2
;
3. Se cwnd = 1 : reinicia Slow Start;
4. Se cwnd < ssthresh −→ cwnd manipulada por Slow Start;
5. Se cwnd > ssthresh −→ cwnd manipulada por Congestion Avoidance;
A Figura abaixo mostra o Slow Start atuando em conjunto com o Congestion Avoid-
ance
33
FIG. 2.6: Atualiza¸c˜ao da Janela de Congestionamneto TCP.
c) Fast Retransmit
A finalidade do Fast Retransmit ´e tornar mais eficiente o processo de retransmiss˜ao
de pacotes. Este algoritmo estabelece que o recebimento de 3 (trˆes) ACKs duplicados
indica uma perda de pacote, devendo a fonte retransmiti-lo imediatamente. Desta
forma, evita-se a longa espera pelo estouro do temporizador (timeout), agilizando a
retransmiss˜ao.
d) Fast Recovery
O Fast Recovery ´e implementado em conjunto com o Fast Retransmit, visando a
manipula¸c˜ao da cwnd em caso de congestionamento moderado. A descri¸c˜ao do al-
goritmo ´e resumida a seguir:
1. Ao receber 3 ACKs duplicados consecutivos ou ocorrer timeout −→ ssthresh
=
cwnd
2
;
2. Retransmite o pacote supostamente perdido: Fast Retransmit;
3. cwnd = ssthresh + 3;
4. A cada ACK duplicado recebido −→ cwnd = cwnd + 1;
5. Ao receber o novo ACK do pacote retransmitido −→ cwnd = ssthresh.
34
2.2.5 INTERAC¸
˜
AO ENTRE AS CAMADAS TRANSPORTE E INTERNET
A intera¸c˜ao entre as camadas de transporte e Internet pode ser assim resumida:
Quando a camada de transporte recebe um conjunto de dados da aplica¸c˜ao (mensagem),
ela o particiona em segmentos. Cada segmento tem no m´aximo 64 Kbytes, mas, em geral,
ele n˜ao chega a 1500 bytes (tamanho do quadro Ethernet). Na camada Internet, cada
segmento entregue ´e ent˜ao encapsulado em um ou mais datagramas IP. Na camada In-
ternet da m´aquina destino o segmento original ´e remontado e entregue aos cuidados da
respectiva camada de transporte, como ilustrado na Figura 2.7.
FIG. 2.7: Intera¸c˜ao Camadas Transporte e Internet.
2.3 RESUMO
O controle de congestionamento TCP fica, como pˆode ser observado, completamente
transparente tanto para a aplica¸c˜ao, que utiliza como portal de acesso para as camadas
inferiores os sockets, quanto para as atividades inerentes `a camada Internet; ´e plena-
mente poss´ıvel interferir de forma exclusiva no controle de congestionamento, mantendo
as demais caracter´ısticas da pilha TCP/IP constantes.
35
3 EVOLUC¸
˜
AO DO TCP
3.1 VIS
˜
AO GERAL
O TCP ´e um dos principais protocolos de transporte devido a sua predominˆancia no
conjunto de protocolos da Internet. A evolu¸c˜ao do TCP perseguiu a maior escalabilidade
deste protocolo. Para isso, as modifica¸c˜oes propostas ao longo dos anos focaram o controle
de congestionamento. Nas implementa¸c˜oes mais antigas do TCP (POSTEL, 1981b), o
emissor repassava para o canal de comunica¸c˜ao m´ultiplos segmentos at´e o limite da janela
de fluxo anunciada p elo receptor. Posteriormente, surgiram trˆes novas vers˜oes do TCP:
TCP Tahoe (JACOBSON, 1988), dotado do Congestion Avoidance e Slow Start, o TCP
Reno (JACOBSON, 1990), que trouxe o Fast Retransmit e introduziu o Fast Recovery no
Congestion Avoidance, e o TCP New Reno (FLOYD, 2004), propondo uma otimiza¸c˜ao
no Fast Recovery. Apesar de toda contribui¸c˜ao e utilidade das vers˜oes tradicionais do
TCP, estudos comprovam (REZENDE, 2005) que o mesmo apresenta um desempenho
muito restrito em redes de alta velocidade, nas quais o produto banda retardo (BDP) seja
elevado, bem como em redes sem fio. Com o objetivo de aproveitar melhor os recursos
destas redes, diversas variantes do TCP foram propostas. A se¸c˜ao a seguir apresenta um
resumo dos principais representantes das varia¸c˜oes TCP.
3.2 VARIANTES TCP
3.2.1 BIC (XU, 2004)
A id´eia central do controle de congestionamento desta variante do TCP ´e a utiliza¸c˜ao
do valor m´edio entre a janela de congestionamento imediatamente antes e depois de uma
perda (w). Quando a “distˆancia” da janela de congestionamento (cwnd) de w ´e maior
do que um determinado valor, o incremento de cwnd ´e mais agressivo; quando cwnd est´a
“perto” de w este incremento passa a ser mais suave. Al´em disso, para redes subuti-
lizadas, onde o crescimento da janela de congestionamento passa a ser sistem´atico, esta
variante implementa um algoritmo que aumenta esta janela mais agressivamente (expo-
nencialmente).
36
3.2.2 CUBIC (XU, 2005)
Uma caracter´ıstica marcante nesta variante ´e a atualiza¸c˜ao da sua janela de conges-
tionamento levando-se em considera¸c˜ao o tempo decorrido desde o ´ultimo evento de perda,
n˜ao privilegiando, assim, fluxos com RTT’s maior ou menor. Sua fun¸c˜ao de crescimento
da janela de congestionamento ´e semelhante a do BIC, possuindo, por´em, um formato
mais simples e maior cautela antes de tornar o incremento agressivo.
3.2.3 FAST TCP (JIN, 2004)
Utiliza uma sistem´atica baseada em quatro componentes: controle de estimativa,
que fornece as informa¸c˜oes necess´arias `as demais componentes (por exemplo, estima o
RTTmin e RTTmed, integrantes da fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento,
calculada pela componente controle de janela); controle de dados, que seleciona
quais segmentos, dentre os ainda n˜ao reconhecidamente transmitidos, devem ser envia-
dos, e controle de rajada que regula a quantidades de dados a serem transmitidos a
fim de evitar grandes rajadas de dados, as quais podem criar longas filas e aumentar a
probabilidade de erros em massa.
3.2.4 HIGH SPEED TCP (HSTCP) (FLOYD, 2003)
Para altas taxas de perdas de pacotes, este protocolo se comporta de forma idˆentica
ao TCP-Reno; uma vez que os congestionamentos ocorram com menor freq¨uˆencia, por´em,
a atualiza¸c˜ao do valor da janela de congestionamento passa a ser mais agressiva. Em
suma, pode-se dizer que na fase de congestion avoidance (quando cwnd > ssthresh), o
algoritmo AIMD ´e modificado de tal forma que o incremento e o decremento da janela de
congestionamento variem de acordo com o tamanho da mesma.
3.2.5 SCALABLE TCP (STCP) (KELLY, 2003)
Seu mecanismo permite que a atualiza¸c˜ao da janela de congestionamento esteja em
fun¸c˜ao apenas do RTT da conex˜ao, sem levar em considera¸c˜ao o tamanho desta janela no
momento da perda.
37
3.2.6 TCP HYBLA (CAINI, 2004)
Baseia o controle da janela de congestionamento em um RTT referˆencia para conex˜ao,
eliminando a dependˆencia entre o n´umero de segmentos presentes nesta janela e o RTT
real do enlace. Este protocolo simula conex˜oes TCP em RTT´s pequenos.
3.2.7 TCP-ILLINOIS (LIU, 2006)
Todas as caracter´ısticas do TCP New Reno s˜ao mantidas com exce¸c˜ao do AIMD, ou
seja, no congestion avoidance, o acr´escimo na janela de congestionamento ser´a tanto maior
quanto menor for o atraso estimado na fila dos roteadores, enquanto que o decr´escimo
ser´a tanto mais agressivo quanto maior for este atraso.
3.2.8 TCP VEGAS (BRAKMO, 1994)
A id´eia b´asica deste algoritmo ´e a utiliza¸c˜ao do RTT como indicador da iminˆencia ou
n˜ao de um evento de perda de pacotes. Quanto maior o RTT, maior ´e, em princ´ıpio, a
carga nos roteadores, o que requer adapta¸c˜oes na atualiza¸c˜ao da janela de congestiona-
mento. O HSTCP ´e considerado uma evolu¸c˜ao deste algoritmo.
3.2.9 H-TCP (SHORTEN, 2004)
A janela de congestionamento deste algoritmo sofre influˆencia tanto do n´umero de
perdas de pacotes ocorridas quanto do tempo decorrido desde o ´ultimo evento de conges-
tionamento. Sendo assim, quanto melhor for a resposta da rede ao fluxo de dados ( longo
per´ıodo sem perdas), mais agressivo ser´a o aumento da janela de congestionamento.
3.2.10 COMPOUND TCP (TAN, 2006)
Incorpora ao incremento do congestion avoidance do TCP tradicional uma componente
baseada no atraso (RTT). Desta forma, agrega as vantagens dos algoritmos baseados em
atraso (agressividade em redes subutilizadas) junto com aquelas inerentes aos baseados
em perdas, apropriados para redes congestionadas.
3.2.11 TCP WESTWOOD (CASETTI, 2001)
Monitora continuamente os pacotes ACK´s para estimar o ERE (Eligible Rate Es-
timation), fundamental na atualiza¸c˜ao da janela de congestionamento e cuja t´ecnica de
38
estima¸c˜ao est´a em aberto. Como ele usa a taxa estimada para atualizar a janela de con-
gestionamento, este proto colo se mostra extremamente eficiente em redes wireless, onde
perdas de pacotes, geralmente causadas por ru´ıdos, requerem, na maioria das vezes, um
aumento na quantidade de retransmiss˜ao e n˜ao uma redu¸c˜ao do n´umero de segmentos
inseridos no meio.
3.2.12 TCP WESTWOOD+ (DELL’AERA, 2004)
Difere do Anterior, principalmente, por basear a realiza¸c˜ao de novas estimativas da
ERE a cada RTT e n˜ao em recebimento de pacotes ACK´s apenas.
3.2.13 RESUMO DAS VARIANTES TCP
Segue abaixo uma tabela com as situa¸c˜oes mais indicadas para aplica¸c˜ao de cada um
destes protocolos e uma breve explica¸c˜ao de por que se espera uma boa resposta destes
protocolos nestas situa¸c˜oes:
39
Protocolo Indica¸c˜ao Explica¸c˜ao
BIC TCP Fluxos com RTT´s diferen-
tes e n˜ao TCP.
Atualiza¸c˜ao da janela de conges-
tionamento baseada no tamanho
da mesma. Agressivo com fluxos
TCP.
CUBIC Fluxos com longos RTT´s e
diferentes entre si.
Janela atualizada conforme o
tempo desde o ´ultimo evento de
perda.
Fast TCP Redes com RTT’s est´aveis. Fluxos com RTT’s muito vari´avel
dificultam as estimativas pr´oprias
deste protocolo.
H-TCP Redes n˜ao congestionadas Se h´a muitas perdas, este pro-
tocolo se comporta conforme o
TCP.
High Speed TCP Fluxos com RTT’s pr´oximos Os fluxos com RTT’s mais curtos
s˜ao privilegiados, deixando p ouca
banda para os de RTT’s mais lon-
gos
Scalable TCP Conex˜oes com RTT ho-
mogˆeneo.
O tamanho da janela depende da
frequˆencia com que chegam os
ACK’s.
TCP Hybla Pr´oprio para enlaces de
longo RTT.
A atualiza¸c˜ao independe do RTT.
TCP-Illinois Redes de pequeno jitter. Facilita a estimativa do atraso nos
roteadores.
TCP Vegas Redes de pequeno jitter. Grandes oscila¸c˜oes do RTT difi-
cultam a detec¸c˜ao da iminˆencia
de um congestionamento.
Compound TCP Conex˜oes com RTT’s dife-
rentes.
Insere uma componente de atraso
no aumento da janela de conges-
tionamento.
Westwood
Westwood+
Redes wireless. Pouco agressivo na redu¸c˜ao da
janela de congestionamento
TAB. 3.1: Variantes TCP e suas indica¸c˜oes.
40
4 AN
´
ALISE DA VIABILIDADE E METODOLOGIA PARA
CONSTRUC¸
˜
AO DE UMA CAMADA DE TRANSPORTE ADAPTATIVA
4.1 VIABILIDADE
4.1.1 CONSIDERAC¸
˜
OES INICIAIS
Como j´a foi mencionado acima, a pr´opria evolu¸c˜ao da camada de transporte TCP
buscou adaptar-se (infelizmente de maneira isolada), `as novas demandas da rede. Antes
de propor como seria uma camada de transporte adaptativa dentro das variantes TCP,
analisemos mais uma vez a fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento do TCP
Reno (FIG.2.6): O gr´afico desta fun¸c˜ao ´e linear acima da threshold e exponencial abaixo
dela. Esta varia¸c˜ao na forma da fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento, ou
seja, linear acima da threshold e exponencial abaixo dela, forma a base para o estudo da
viabilidade de uma camada de transporte adaptativa entre as variantes TCP.
Como pˆode ser observado, a fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento do
TCP Reno pressup˜oe uma adapta¸c˜ao da mesma de acordo com o feedback que a rede lhe
proporciona. Do acima exposto, podemos concluir que o chaveamento entre fun¸c˜oes de
atualiza¸c˜ao da janela de congestionamento ´e algo inerente `as vers˜oes tradicionais do TCP.
Al´em disso, v´arios dos algoritmos que procuraram dar ao TCP uma maior escalabilidade
concentram seus esfor¸cos na forma de atualiza¸c˜ao da janela de congestionamento; e n˜ao
poderia ser diferente, pois ´e esta a fun¸c˜ao que vai determinar a quantidade de datagramas
inseridos a cada rodada de transmiss˜ao na rede.
Fica claro, portanto, que podemos disponibilizar na camada de transporte um conjunto
de fun¸c˜oes que possam ser, de acordo com as condi¸c˜oes pontuais da rede, escolhidas
durante a troca de dados. Sendo assim, para uma camada de transporte TCP adaptativa,
precisar´ıamos apenas trabalhar no controle de congestionamento da camada em quest˜ao.
Em suma, a altera¸c˜ao mais significativa para que as camadas de transporte tradicionais
se tornem adaptativas est´a basicamente vinculada ao controle de congestionamento, to-
talmente transparente para as aplica¸c˜oes, o que torna poss´ıveis implementa¸c˜oes (veja
detalhes no cap´ıtulo 8) do transporte adaptativo plenamente amig´aveis `as aplica¸c˜oes hoje
existentes.
41
4.2 METODOLOGIA
Como foi visto, a crescente diversidade nas redes de comunica¸c˜ao requer protocolos
distintos para melhor se realizar a troca de informa¸c˜oes. Neste contexto, cabe um estudo
para se verificar a viabilidade e as vantagens de uma camada de transporte adaptativa,
capaz de adaptar-se `as varia¸c˜oes que podem ocorrer na rede durante a troca de dados.
Este estudo ser´a dividido em duas fases distintas: adapta¸c˜ao entre as variantes TCP e a
adapta¸c˜ao quando da necessidade de emprego de um protocolo de transporte baseado em
UDP.
A adapta¸c˜ao entre as variantes TCP ´e vista como uma op¸c˜ao muito mais abrangente,
pois a varia¸c˜ao do protocolo de transporte dentro das vers˜oes TCP n˜ao requer modi-
fica¸c˜ao alguma nos aplicativos, para os quais as atividades relativas ao transporte das
mensagens continuar´a transparente. Testes pr´aticos envolvendo diferentes algoritmos de
transporte ser˜ao realizados para avalia¸c˜ao das vantagens de um algoritmo de transporte
para outro, bem como para especifica¸c˜ao de crit´erios que justifiquem o chaveamento entre
estes algoritmos. Para ressaltar as vantagens de uma camada de transporte adaptativa,
s˜ao apresentados alguns estudos de casos, nos quais utilizam-se as conclus˜oes extra´ıdas
dos experimentos. Diante das vantagens apontadas pelos experimentos, apresentam-se os
elementos necess´arios `a implementa¸c˜ao de uma camada de transporte que possa variar
entre as variantes TCP.
Na segunda fase do trabalho, trata-se a adapta¸c˜ao do transporte baseada em UDP
objetivando contemplar projetos espec´ıficos, em cuja gˆenese j´a haja a preocupa¸c˜ao com
a possibilidade de se trabalhar com protocolos de transporte otimizados para situa¸c˜oes
especiais (ex. Programa C2 em combate).
Os testes pr´aticos se limitar˜ao aos algoritmos de transporte presentes no 2.6.25 do
linux, no qual est˜ao dispon´ıveis algumas das variante apresentadas na se¸c˜ao 3.2 (Reno,
BIC, CUBIC, STCP, HSTCP , HTCP, VEGAS e WESTWOOD+); como o HSTCP ´e
considerado uma evolu¸c˜ao do VEGAS e o WESTWOOD+ ´e indicado para redes wireless,
os testes englobar˜ao apenas as vers˜oes Reno, BIC, CUBIC, STCP, HSTCP , HTCP do
TCP. No kernel em quest˜ao o TCP Reno ´e na verdade uma implementa¸c˜ao do New Reno.
Daqui em diante, a menos que haja alguma ressalva, todas as vezes que nos referirmos ao
TCP Reno estaremos nos reportando ao TCP New Reno.
42
5 DESEMPENHO DAS VARIANTES TCP
Para uma avalia¸c˜ao pr´atica das vers˜oes TCP de alta velocidade foram realizados down-
loads de arquivos, cujos tamanhos produzem um tempo de transferˆencia de quatro a seis
minutos atrav´es do TCP Reno, variando-se o protocolo de transporte e a capacidade do
enlace. Para cada clock rate ajustado, acrescentou-se, atrav´es do Netem (Apˆendice 1),
atrasos (200, 400, 600, 800 e 1000 ms), ao RTT. Fixados o RTT e o protocolo de trans-
porte (Reno, BIC, CUBIC, STCP, HSTCP e HTCP), mediu-se o tempo de download.
O download foi realizado de um servidor apache vers˜ao 2.0, utilizando-se como cliente o
FireFox 3.0.1. A partir destes testes podemos escolher qual dos protocolos se comportou
melhor, isto ´e, proporcionou menor tempo de download. Os testes foram realizados no
laborat´orio de redes do IME. As m´aquinas utilizadas seguem a seguinte configura¸c˜ao:
• Hardware: Intel(R) Pentium(R) 4 HT 3.00 GHz;
• SO: Suse 11, kernel 2.6.25.11-0.1-pae;
• Mem´oria: 512 MB;
• Placa de Rede: ASUSTeK 82540EM Gigabit Ethernet;
• HD: Samsung(R) SP 0802N 7200 rpm IDE ATA 133;
• Parti¸c˜ao de Swap: 1 Gb.
Alguns outros parˆametros foram alterados atrav´es do comando sysctl (Apˆendice 2), de
acordo com (MICHEL, 2008).
5.1 EXPERIMENTO COM ENLACES DE 1200 BITS POR SEGUNDO A 1 MEGABIT
POR SEGUNDO
A flexibilidade na velocidade do enlace foi garantida pela infra-estrutura da Figura
5.1: Duas m´aquinas, grecia01, na rede 4 e grecia11, na rede 6, se comunicavam, de forma
exclusiva, atrav´es de um enlace serial, que fazia a ponte entre os roteadores Mykonos
(Cisco(R)2611) e Santorini (Cisco(R)2621), e cuja velocidade foi configurada para os
valores 1.2, 56, 512 e 1000 Kbps.
43
FIG. 5.1: Estrutura para Enlaces de 1200bps a 1Mbps.
• Enlace de 1200 bps
Com a velocidade do enlace serial ajustada para 1200 bps, foi levantado o tempo
m´edio entre trˆes downloads de um arquivo de 40 Kbytes para cada um dos acr´escimos
no RTT considerados, chegando-se ao gr´afico da Figura 5.2. Como se pode observar,
nestas condi¸c˜oes o TCP Reno se comportou de forma extremamente satisfat´oria,
conseguindo em alguns casos um comportamento melhor do que as outras abor-
dagens. Para o menor RTT (1290 ms), o Reno alcan¸cou um tempo de download
menor do que aquele obtido com os outros protocolos, principalmente em rela¸c˜ao
ao CUBIC. Conforme aumentamos o RTT, os protocolos, com exce¸c˜ao do HTCP,
praticamente se igualaram durante os testes, com ligeira vantagem para o Reno. O
HTCP come¸ca a se destacar negativamente de um RTT de 2090 ms em diante.
• Enlace de 56 Kbps
Agora os downloads realizados transferiram um arquivo de 2.7 Mbytes. Os tempos
de download para cada RTT est˜ao sumarizados no gr´afico da Figura 5.3. Mais uma
vez o TCP Reno se mostra uma excelente escolha para este tipo de configura¸c˜ao. At´e
44
FIG. 5.2: Desempenho dos Protocolos: 1200 bps.
45
FIG. 5.3: Desempenho dos Protocolos: 56 Kbps.
46
o RTT de 627 ms os protocolos se equivalem; a partir da´ı, observa-se uma grande
vantagem dos protocolos BIC, HSTCP e Reno em rela¸c˜ao aos protocolos STCP,
HTCP e CUBIC estes dois ´ultimos com desempenhos semelhantes, fornecendo os
maiores tempos de download. O desempenho global mostra ligeira vantagem para o
Reno nesta fase dos testes.
• Enlace de 512 Kbps
O tamanho de arquivo considerado nesta rodada de teste foi de 17 MB, o que re-
sultou no gr´afico da Figura 5.4. Novamente destaque positivo para o desempenho
FIG. 5.4: Desempenho dos Protocolos: 512 Kbps.
do TCP Reno. Para esta fase dos testes o HTCP impˆos um tempo de download
muito acima dos outros. Os protocolos de melhor comportamento (praticamente
idˆenticos) s˜ao o Reno e o HSTCP. Os demais protocolos podem ser ordenados de
forma crescente em rela¸c˜ao ao tempo de download para cada um dos valores de RTT
considerados da seguinte forma: BIC, STCP e CUBIC.
47
• Enlace de 1 Mbps
Para um arquivo de 30 MB, chega-se ao gr´afico da Figura 5.5. Outra vez o TCP Reno
FIG. 5.5: Desempenho dos Protocolos: 1 Mbps.
constitui uma excelente op¸c˜ao. Como no caso anterior, o HTCP atinge os maiores
tempos de download; em seguida vem o CUBIC, mas com tempos de transferˆencia
bem menores. Os protocolos Reno, STCP, HSTCP e BIC tiveram desempenhos
muito semelhantes, proporcionando os menores tempos de download.
5.2 EXPERIMENTO COM ENLACE DE 10 MEGABITS POR SEGUNDO
Para ligar duas m´aquinas a 10 Mbps, utilizou-se a configura¸c˜ao ilustrada na Figura 5.6.
Como pode-se observar nesta figura, as redes 3 e 6 se interligam por interfaces Ethernet
48
FIG. 5.6: Estrutura para Enlace de 10 Mbps.
(velocidade de 10 Mbps) do roteador Mykonos, dedicado ao experimento. Durante esta
fase um arquivo de 300 MB foi transferido da m´aquina grecia01, na rede 6, `a m´aquina
grecia11, na rede 3, para o levantamento dos pontos do gr´afico da Figura 5.7. Como
vemos, o TCP Reno continua entre os protocolos de melhor desempenho. Mais uma vez o
HTCP ´e o destaque negativo nesta configura¸c˜ao, seguido pelo CUBIC que, apesar disto,
mostra-se bem mais eficiente do que o HTCP. Os protocolos STCP e BIC demonstram um
comportamento intermedi´ario entre os protocolos considerados. Os menores tempos de
download est˜ao associados aos protocolos Reno e HSTCP, os quais mantˆem suas respostas
praticamente idˆenticas durante todas as situa¸c˜oes consideradas nesta fase.
5.3 EXPERIMENTO COM ENLACE DE 100 MEGABITS POR SEGUNDO
Como estamos trabalhando com placas FastEthernet concentradas em um switch Cata-
lyst(R) 2950, atrav´es de cabos par tran¸cado da categoria 5e, colocamos duas m´aquinas
em uma mesma sub-rede para alcan¸carmos a velocidade de 100Mbps. Um arquivo de 1
GB, trocado entre as m´aquinas grecia01 e grecia 11, ambas na rede 6, serviu de base para
a constru¸c˜ao do gr´afico da Figura 5.8. N˜ao se pode deixar de destacar que, nesse enlace,
a partir de um acr´escimo de 600 ms no RTT, o TCP Reno passa a ter um desempenho
abaixo de todas as outras variantes TCP consideradas. Destaque positivo para o CUBIC-
TCP. At´e o RTT de 400ms os desempenhos dos protocolos s˜ao idˆenticos, mas, para RTT´s
acima deste valor o Reno ´e apontado pelos testes como a pior op¸c˜ao, seguido pelo HSTCP.
Agora o HTCP, junto com o CUBIC e o BIC, constituem as melhores op¸c˜oes, seguidos
49
FIG. 5.7: Desempenho dos Protocolos: 10 Mbps.
50
FIG. 5.8: Desempenho dos Protocolos: 100 Mbps.
51
de perto pelo STCP. Entretanto, o CUBIC obtem uma ligeira vantagem m´edia quando
considerados todos os pontos.
5.4 EXPERIMENTO COM ENLACE DE 1 GIGABIT POR SEGUNDO
As m´aquinas grecia01 e grecia11 foram diretamente ligadas por um cabo par tran¸cado
da categoria 5e, pois duas placas FastEthernet conectadas por um cabo desse tipo tra-
balham a uma velocidade de 1 Gbps (FIG.5.9). Um arquivo de 5 GB foi transportado
FIG. 5.9: Estrutura para Enlace 1 Gbps.
por cada um dos protocolos a cada acr´escimo no RTT, de acordo com o gr´afico da Figura
5.10. A partir de um acr´escimo de 400 ms no RTT, o desempenho do TCP Reno come¸ca a
se degradar. Destaque positivo para o BIC TCP nesta configura¸c˜ao. Os menores tempos
de downloads nesta configura¸c˜ao est˜ao associados ao BIC e ao STCP, com o BIC con-
seguindo alcan¸car tempos um pouco menores. Entre 400 e 800 ms os protocolos em ordem
decrescente em rela¸c˜ao ao tempo de download s˜ao Reno, HTCP, HSTCP e CUBIC. Em
1000ms, por´em, a ordem passa a ser HTCP, CUBIC, Reno e HSTCP.
5.5 PARALELO COM A LITERATURA
Verdadeiramente, a ado¸c˜ao de um protocolo de transporte preparado para redes de alto
produto banda retardo pode aproveitar melhor a capacidade fornecida pelo enlace. Entre-
tanto, n˜ao h´a um consenso entre os estudiosos sobre qual seria a abordagem de transporte
52
FIG. 5.10: Desempenho dos Protocolos: 1 Gbps.
53
mais escal´avel no que diz respeito ao aproveitamento do enlace. Em (MICHEL, 2007),
por exemplo, o HTCP ´e tido como protocolo altamente escal´avel; o CUBIC e o STCP
s˜ao destacados negativamente sob este aspecto no referido trabalho. J´a o Advanced Com-
puting for Science Department (MICHEL, 2008) sugere o HTCP e o CUBIC como as
melhores op¸c˜oes em redes com BDP elevado. Na pr´atica, por´em, para um enlace de 1
Gbps, o HTCP demonstrou um desempenho muito aqu´em de algumas outras variantes,
inclusive do pr´oprio CUBIC, cuja performance est´a abaixo do BIC e do STCP, por exem-
plo, estes dois ´ultimos apontados como protocolos de excelente escalabilidade por (XU,
2004), fato comprovado pelos experimentos.
54
6 CRIT
´
ERIOS DE ADAPTAC¸
˜
AO ENTRE AS VARIANTES TCP
Neste cap´ıtulo ´e feita uma an´alise mais detalhada dos dados obtidos nos experimentos.
Baseados nesta an´alise, apresenta-se de forma mais concreta a sistem´atica de adapta¸c˜ao
entre as variantes TCP, baseando nossas decis˜oes no RTT e velocidade do enlace.
6.1 AN
´
ALISE DOS EXPERIMENTOS COM ENLACES DE AT
´
E 10MEGABITS POR
SEGUNDO
Os dados extra´ıdos dos experimentos deixam claro que, para enlaces de velocidade
at´e 10 Mbps, a vers˜ao Reno constitui uma excelente op¸c˜ao, independente do RTT. Esta
conclus˜ao era esperada, pois os enlaces em quest˜ao constituem o “nicho” do Reno, ou seja,
estamos nos enlaces em fun¸c˜ao dos quais o Reno baseou toda sua evolu¸c˜ao; a utiliza¸c˜ao
de uma outra abordagem nestes casos pode, inclusive, comprometer o desempenho da
transmiss˜ao, basta observarmos o desempenho do HTCP nos gr´aficos correspondentes.
Como segunda op¸c˜ao em termos de desempenho, temos o BIC TCP que, em geral, se
comportou melhor do que as outras abordagens estando, por´em, abaixo do TCP-Reno.
6.2 AN
´
ALISE DO EXPERIMENTO COM ENLACE DE 100 MEGABITS POR SE-
GUNDO
Para enlaces de velocidade de 100 Mbps o Reno manteve-se entre as abordagens de
melhor desempenho at´e um acr´escimo de 600 ms no RTT, a partir do qual o CUBIC-
TCP e o STCP passaram a ser os protocolos de transporte mais indicados, com ligeira
vantagem para o CUBIC, quando considerados todos os demais pontos at´e 1000 ms. Os
gr´aficos mostram que o tempo de download pode ser reduzido em at´e 46,7%, escolhendo-
se o protocolo de transporte adequado (CUBIC em vez do Reno). Na Tabela 6.2 os
diversos ganhos percentuais proporcionados pelo protocolo CUBIC em rela¸c˜ao ao Reno
(
(T
Reno
− T
CU BI C
) ∗ 100
T
Reno
), onde T
X
representa o tempo de download utilizando-se o pro-
tocolo X durante os experimentos para o enlace em quest˜ao), s˜ao sumarizados a seguir:
55
RTT(ms) Ganho Percentual (CUBIC sobre Reno)
600 27,7
800 46,0
1000 46,7
TAB. 6.1: Ganhos Percentuais do CUBIC em Rela¸c˜ao ao Reno - Enlace de 100 Mbps.
6.3 ENLACE DE 1 GIGABIT POR SEGUNDO
Agora, a partir de um acr´escimo de 400 ms o Reno ´e superado pelos protocolos BIC e
STCP. Um fato interessante neste tipo de enlace ´e que o Reno conseguiu um desempenho
melhor ou igual ao de algumas variantes (CUBIC, HTCP e HSTCP) que, teoricamente,
deveriam super´a-lo neste tipo de cen´ario. Como o BIC se destacou nesta fase, vamos
sumarizar os ganhos percentuais que ele proporcionou em rela¸c˜ao ao Reno na Tabela 6.3
RTT(ms) Ganho Percentual (BIC sobre Reno)
400 27,5
600 34,6
800 24,4
1000 17,3
TAB. 6.2: Ganhos Percentuais do BIC em Rela¸c˜ao ao Reno - Enlace de 1 Gbps.
6.4 ESCOLHENDO A MELHOR ABORDAGEM
Sendo assim, baseados nos nossos testes, apresentamos a Tabela 6.3, que sintetiza de
forma pr´atica e objetiva a an´alise dos dados levantados nos testes. Esta tabela serve de
parˆametro para o chaveamento da melhor fun¸c˜ao de atualiza¸c˜ao da janela de conges-
tionamento durante as atividades de uma camada de transporte TCP adaptativa.
Velocidade do Enlace RTT Protocolo Indicado
At´e 10 Mbps Qualquer Reno
100 Mbps ≤ 400 ms Reno
> 400 ms CUBIC
1Gbps ≤ 200 ms Reno
> 200 ms BIC
TAB. 6.3: Condi¸c˜oes de emprego dos protocolos.
56
7 ESTUDO DE CASOS
Agora, para avaliarmos de forma mais precisa as vantagens de uma camada de trans-
porte adaptativa vamos montar cen´arios (baseado em situa¸c˜oes reais), nos quais podere-
mos ver de forma mais n´ıtida os benef´ıcios que um transporte adaptativo pode nos trazer
na pr´atica.
7.1 CEN
´
ARIO OPERACIONAL
Suponha que durante uma opera¸c˜ao militar, onde o M´odulo de Telem´atica est´a sendo
empregado, o sistema “olhos da ´aguia” (sistema de reconhecimento a´ereo com captura
de imagem), gere um filme (3,3 GB) que retrate a situa¸c˜ao de uma determinada ´area de
interesse. H´a uma solicita¸c˜ao de que o tal filme seja transmitido do local da opera¸c˜ao
(suponhamos Manaus) para Bras´ılia (Comando Geral das Opera¸c˜oes). Existem duas pos-
sibilidades de enlace entre Manaus e Bras´ılia: um limitado por um cabo Ethernet (banda
10 Mbps e RTT de 30 ms) e outro estabelecido por um sat´elite GEO (AI3, 2009) (banda
da ordem de 100 Mbps e RTT de 600 ms), extremamente inst´aveis devido `as dificuldades
impostas pela natureza da opera¸c˜ao. Sendo assim, quanto mais r´apida uma informa¸c˜ao
for transmitida melhor, pois a qualquer momento pode-se perder a liga¸c˜ao entre os p ostos
considerados. Como foi visto nos testes anteriores, uma das melhores op¸c˜oes de protocolo
de transporte para o enlace Ethernet ´e o Reno. J´a para um enlace de 100 Mbps com RTT
da ordem de 600 ms, os mesmos experimentos revelaram que o CUBIC ´e a melhor op¸c˜ao.
Para obten¸c˜ao de dados mais concretos foram feitos, no laborat´orio de redes do IME,
downloads de dois arquivos, um de 300 MB e outro de de 3 GB variando-se os enlaces
(ora Ethernet com 30 ms de RTT, ora FastEthernet com 600 ms de RTT), chegando-se
ent˜ao `a Tabela 7.1. Suponhamos ainda que o comportamento dos protocolos nos enlaces
de sat´elite ser´a semelhante ao que eles apresentaram no FastEthernet (100 Mbps/RTT de
600 ms), j´a que os sat´elites GEO tamb´em possuem velocidade de transmiss˜ao da ordem
de 100 Mbps e RTT’s de 600 ms. Assumiremos que, logo ap´os a central de comando em
Bras´ılia receber os primeiros 300 MB do arquivo solicitado pela liga¸c˜ao Ethernet, o enlace
por sat´elite torna-se, por acaso, dispon´ıvel e que, ap´os 10 minutos do in´ıcio do download,
ambos os enlaces saem do ar.
57
Enlace Tamanho do Arquivo Protocolo Tempo(s)
Ethernet 300 MB Reno 300
(10 Mbps/RTT 30 ms) CUBIC 329
FastEthernet 3 GB Reno 346
(100 Mbps/RTT 600 ms) CUBIC 277
TAB. 7.1: Desempenho esperado dos protocolos CUBIC e Reno em enlaces Ethernet e
sat´elite (GEO).
Vamos analisar o download dos 3,3 GB caso fosse feito com o protocolo de transporte
est´atico e caso houvesse possibilidade de adapta¸c˜ao:
• Somente Reno
Pelos dados da tabela, o download duraria 646 segundos (300 segundos para os 300
MB e 346 segundos para os 3 GB restantes), isto ´e, 10 minutos e 46 segundos de
download. A miss˜ao, portanto, n˜ao teria sido cumprida.
• Somente CUBIC
Da mesma forma, mantendo-se o CUBIC TCP, o download levaria 606 segundos
(329 segundos mais 277 segundos), isto ´e, 10 minutos e 6 segundos. Novamente o
objetivo n˜ao teria sido atingido.
• Chaveando entre Reno e CUBIC
Agora vamos supor que durante os 300 MB iniciais tenhamos utilizado o Reno e
que a camada de transporte alinhe seu controle de congestionamento com o CUBIC
quando o enlace por sat´elite torna-se dispon´ıvel. Nesse caso, o arquivo seria entregue
em 577 segundos (300 mais 277 segundos), que equivalem a 9 minutos e 37 segundos,
garantindo assim o ˆexito da miss˜ao.
7.2 REALIZAC¸
˜
AO DE BACKUPS
Vamos imaginar agora uma grande multinacional, localizada em Bel´em do Par´a que
realize espelhamento de toda a sua massa de dados (3 GB), para uma m´aquina localizada
em seu pa´ıs sede (backup completo), por um enlace sat´elite com as mesmas caracter´ısticas
mencionadas anteriormente. Para outra m´aquina localizada em S˜ao Paulo, cujo enlace
58
´e limitado por uma liga¸c˜ao 10BaseT com RTT m´edio de 30 ms, deve ser realizado um
backup parcial, ou seja, procede-se o espelhamento dos arquivos modificados nas ´ultimas
duas semanas (em m´edia 300 MB). Dez backup de cada tipo devem ser realizados por
dia.
´
E desej´avel que as opera¸c˜oes de backup sejam realizadas o mais r´apido poss´ıvel, pois
as mesmas consomem grande parte dos recursos da rede em detrimento das atividades
pr´oprias do neg´ocio da empresa. Segundo os experimentos, para os backups completos o
CUBIC seria a melhor op¸c˜ao de transporte, j´a os arquivos modificados durante as duas
´ultimas semanas devem ser transportados para S˜ao Paulo pelo Reno. Vamos analisar de
forma pr´atica os ganhos, caso a esta¸c˜ao respons´avel pelo espelhamento pudesse adaptar
seu modo de transportar os dados; para isso, tomaremos por base os mesmos dados da
tabela 7.1.
• Somente Reno
A tabela 7.2 nos d´a uma perspectiva do tempo total que seria gasto para atender
os 20 backups Verifica-se que o tempo total para realizar-se os espelhamentos seria
Tipo de backup Tamanho do Arquivo Dura¸c˜ao (s)
10 parciais 300 MB 3000
10 completos 3 GB 3460
Total 6460
TAB. 7.2: Dura¸c˜ao do processo de backup com uso exclusivo do Reno.
de 6460 segundos, que totalizam 1 hora 47 minutos e 40 segundos.
• Somente CUBIC
Tomando o mesmo procedimento para o CUBIC chegamos a Tabela 7.3: Sendo
Tipo de backup Tamanho do Arquivo Dura¸c˜ao(s)
10 parciais 300 MB 3290
10 completos 3 GB 2770
Total 6060
TAB. 7.3: Dura¸c˜ao do processo de backup com uso exclusivo do CUBIC.
assim, mantendo-se o protocolo CUBIC est´atico, o tempo gasto ´e de 1 hora e 41
minutos.
59
• Chaveamento entre Reno e CUBIC
Se nas duplica¸c˜oes de dados parciais o protocolo utilizado fosse o Reno e nas comple-
tas o CUBIC, os tempos de atendimento seriam conforme os constantes da Tabela
7.4: Perfazendo um tempo de 1 hora 36 minutos e 10 segundos. Como podemos
Tipo de backup Tamanho do Arquivo Dura¸c˜ao(s)
10 parciais 300 MB 3000
10 completos 3 GB 2770
Total 5770
TAB. 7.4: Dura¸c˜ao do processo de backup com adapta¸c˜ao entre o Reno e o CUBIC.
observar, com o transporte adaptativo ter´ıamos os recursos da rede totalmente dedi-
cados aos neg´ocios da empresa durante praticamente 5 minutos a mais (temp o sufi-
ciente para atender um backup completo), em rela¸c˜ao a um protocolo de transporte
que se mantivesse apenas no CUBIC TCP. Este tempo livre ´e ainda mais expressivo
(praticamente 11 minutos!), quando tomado em rela¸c˜ao a um transporte de dados
que insistisse no Reno. Portanto, a cada processo di´ario de backup, economiza-se
5 minutos em rela¸c˜ao a um protocolo de transporte est´atico no CUBIC. Em uma
semana as atividades pr´oprias do neg´ocio da empresa teriam 35 minutos de exclu-
sividade na sua infra-estrutura de dados. Em um mˆes esse tempo saltaria para 2
horas e 30 minutos. Durante um ano de exerc´ıcio, 1 dia 6 horas e 25 minutos! Em
rela¸c˜ao a uma camada de transporte TCP Reno os valores seriam: 11 minutos a
mais para cada processo di´ario de backup; 1 hora e 17 minutos a cada semana; 5
horas e 30 minutos a cada mˆes e 2 dias e 18 horas e 55 minutos por ano! Este ´ultimo
estudo de casos chama aten¸c˜ao tamb´em em rela¸c˜ao ao processamento das m´aquinas
transmissoras, pois as mesmas tarefas podem ser realizadas com uma consider´avel
economia de tempo, prop orcionando uma menor sobrecarga nas esta¸c˜oes, as quais
podem alocar seu poder de processamento para outras tarefas quando do t´ermino
das transmiss˜oes.
60
8 ARQUITETURA E IMPLEMENTAC¸
˜
AO
Agora que os testes revelaram que podemos obter grandes vantagens com o emprego de
uma camada de transporte adaptativa, modelaremos uma camada de transporte com um
m´odulo respons´avel pelo chaveamento entre as abordagens TCP. Estudaremos o padr˜ao
observer e state (GAMMA, 1995) e qual a utilidade destes para o referido m´odulo. Apre-
sentaremos tamb´em uma implementa¸c˜ao externa, atrav´es de script, da camada de trans-
porte adaptativa que serve de modelo conceitual para a compila¸c˜ao de sistemas opera-
cionais que desejem disponibilizar no seu kernel uma camada deste tipo.
8.1 PADR
˜
OES DE PROJETO: VIS
˜
AO GERAL
Um Padr˜ao de projeto ´e uma forma de solu¸c˜ao que permite aos programadores re-
solverem problemas semelhantes. A pr´atica de se documentar padr˜oes para resolu¸c˜ao de
problemas de mesma natureza ´e muito comum, principalmente nas atividades de engenha-
ria. No desenvolvimento de softwares n˜ao ´e diferente; nele encontramos a todo instante
problemas, cujas caracter´ısticas s˜ao comuns a algum outro previamente solucionado. O
emprego de solu¸c˜oes padronizadas d´a maior velocidade ao desenvolvimento, favorece o
reuso e facilita a comunica¸c˜ao entre os profissionais da ´area. Este trabalho n˜ao tem por
objetivo fazer uma an´alise aprofundada dos padr˜oes de projeto j´a catalogados, caso o
leitor queira tais informa¸c˜oes, poder´a encontr´a-las em (GAMMA, 1995).
8.2 O PADR
˜
AO OBSERVER
O prop´osito deste padr˜ao ´e definir uma dependˆencia um-para-muitos entre objetos
para, quando um objeto mudar de estado, todos os seus dependentes sejam notificados e
atualizados automaticamente. A estrutura de classes deste padr˜ao ´e ilustrada pela Figura
8.1. Tanto o sujeito como os objetos est˜ao associados a uma interface. A interface do
sujeito informa, atrav´es do m´etodo Notificar, as mudan¸cas nas vari´aveis de estado contidas
no Sujeito Concreto. Acionados pela notifica¸c˜ao, os observadores atualizam seus estados
(m´etodo Atualizar), de acordo com os novos valores dos atributos do Sujeito Concreto,
obtidos pelo m´etodo ObterEstado.
61
FIG. 8.1: Padr˜ao Observer.
8.3 PADR
˜
AO STATE
Quando desejamos que um objeto altere o seu comportamento, a partir da mudan¸ca
nos valores dos seus atributos, devemos empregar o padr˜ao state. O objetivo deste padr˜ao
compreende a utiliza¸c˜ao de objetos para representarem estados e polimorfismo para tornar
transparente a execu¸c˜ao de tarefas dependentes destes estados, como sugere a estrutura
da Figura 8.2:
FIG. 8.2: Padr˜ao State.
O objeto Contexto possui uma classe abstrata Estado que ´e concretizada em algum
dos estados (Estado ConcretoA, Estado ConcretoB, Estado ConcretoC, etc). De acordo
com a situa¸c˜ao, isto ´e, quando h´a uma mudan¸ca na situa¸c˜ao de interesse, o objeto Con-
texto seleciona uma das implementa¸c˜oes da classe Estado preparada para esta situa¸c˜ao
espec´ıfica. Sendo assim, cada vez que o objeto contexto ´e acionado, ele reage com o m´etodo
Requisi¸c˜ao, que invoca o m´etodo Tratamento, do Estado concretizado pelo pr´oprio Con-
texto.
62
8.4 ARQUITETURA DA CAMADA DE TRANSPORTE ADAPTATIVA
Basicamente, esta camada deve manter a mesma interface com a aplica¸c˜ao (socket no
caso da pilha IP); por esta interface os dados seriam, como normalmente se faz, “bufferi-
zados”, aguardando a sua inclus˜ao na janela de congestionamento para transmiss˜ao. Exa-
tamente neste ponto, ou seja, na fun¸c˜ao que define a quantidade de segmentos que devem
compor a janela de congestionamento, deve haver um conjunto de abordagem que estar˜ao
`a disp osi¸c˜ao da camada de transporte para serem utilizadas no controle de congestiona-
mento (FIG. 8.3).
FIG. 8.3: Transporte adaptativo.
Uma vis˜ao mais detalhada do funcionamento desta camada ´e ilustrado na Figura 8.4.
FIG. 8.4: Transporte adaptativo: Vis˜ao Detalhada.
O Observador deve se inteirar dos parˆametros de interesse da rede e informar ao
Avaliador de contexto sempre que ocorrer uma mudan¸ca em algum desses parˆametros. O
63
Avaliador de contexto, a partir das notifica¸c˜oes emitidas pelo Observador, avalia qual a
variante TCP indicada, em fun¸c˜ao dos novos valores dos parˆametros levantados pelo ob-
servador. Com o intuito de embasar futuras implementa¸c˜oes de uma camada como esta,
vamos modelar seus componentes utilizando os padr˜oes state e observer. O observador
da figura 8.4 ser´a implementado por um padr˜ao observer, pois no mesmo deve haver uma
classe capaz de encapsular os parˆametros da rede e notificar ao avaliador de contexto
sempre que houver uma mudan¸ca em alguma vari´avel de interesse (banda, retardo, jitter,
etc). J´a no m´odulo avaliador, empregaremos o padr˜ao state: uma vez notificado pelo ob-
servador, o avaliador deve perceber o contexto vivido pela rede naquele momento e alinhar
a fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento de acordo com este contexto. A
Figura 8.5 apresenta o detalhamento da arquitetura para implementa¸c˜ao de uma camada
de transporte adaptativa.
FIG. 8.5: Arquitetura da Camada de Transporte Adaptativa.
Supondo que as vari´aveis de interesse para a adapta¸c˜ao do transporte sejam apenas o
RTT e a banda dispon´ıvel, cada vez que os m´etodos AjustarBanda ou AjustarRTT forem
acionados a classe abstrata Rede acionar´a o Seletor atrav´es do m´etodo Notificar, no qual
haver´a uma chamada para o m´etodo Atualizar VarianteTCP(), concretizado neste Sele-
tor. O Seletor, por sua vez, requisitar´a o RTT e a banda atrav´es dos m´etodos ObterRTT
e ObterBanda, respectivamente. A partir destes valores, o Seletor concretizar´a a classe
abstrata VarianteTCP de acordo com a melhor abordagem (BIC,CUBIC ou RENO) para
64
o momento vivido pela rede. O m´etodo Atualizar CWND do Seletor chama o m´etodo
virtual CWND, concretizado nas classes filhas de VarianteTCP, garantindo assim que a
janela de congestionamento seja atualizada de acordo com a fun¸c˜ao de interesse. Ressalta-
mos ainda que esta arquitetura pode ser facilmente estendida para trabalhar-se com mais
parˆametros ou mais variantes TCP.
8.5 IMPLEMENTAC¸
˜
AO
8.5.1 COLHENDO OS PAR
ˆ
AMETROS
Todo esfor¸co envolvendo as propostas de variantes TCP baseia-se fundamentalmente
nos parˆametros banda e retardo, como j´a foi discutido anteriormente. Para implementa¸c˜ao
de uma camada de transporte adaptativa faz-se necess´ario, portanto, algumas observa¸c˜oes
a respeito de como esses parˆametros ser˜ao levantados. As t´ecnicas de medi¸c˜oes em redes
podem ser classificadas em ativas, em que h´a inser¸c˜ao de pacotes que visam ´unica e
exclusivamente levantar dados a respeito da conex˜ao, ou passivas, em que um ou mais
pontos da rede s˜ao encarregados da coleta de informa¸c˜oes a repeito da malha da qual
fazem parte. As medi¸c˜oes passivas requerem, para sua maior eficiˆencia, equipamentos
dedicados e ´e indicada quando deseja-se observar com precis˜ao uma grande quantidade de
vari´aveis da rede como um todo. Como o foco do presente trabalho baseia-se no estudo
das conex˜oes fim-a-fim, apresentaremos t´ecnicas ativas para medi¸c˜ao dos parˆametros de
interesse (apenas dois: banda e retardo), j´a que as mesmas s˜ao mais simples e, de acordo
com a Tabela 6.3, n˜ao precisamos de medidas extremamente precisas para selecionarmos
a melhor abordagem no transporte de dados.
8.5.1.1 RTT
O RTT (Round Trip Time) ´e o tempo de ida e volta da fonte ao destino.
´
E quase
imposs´ıvel dissociar a medida do RTT da mais popular das ferramentas de medi¸c˜ao: o ping
(POSTEL, 1981a), baseado em troca de mensagens ICMP peri´odicas. Esta ferramenta na
grande maioria dos casos (redes que n˜ao apresentam comportamento peri´odico (PAXSON,
1997)), se mostra eficiente na obten¸c˜ao do RTT fim-a-fim.
65
8.5.1.2 BANDA DISPON
´
IVEL
As principais t´ecnicas para medi¸c˜ao de capacidade de enlace s˜ao: sondagem de pa-
cotes de tamanho vari´avel (JACOBSON, 1997), que determina a capacidade dos enlaces
individualmente, e dispers˜ao de par de pacotes (SAROIU, 2002), que mede a capaci-
dade fim-a-fim. A dispers˜ao de par de pacotes se baseia no fato de que, caso n˜ao haja
tr´afego concorrente, ap´os um par de pacotes atravessar o “gargalo” de uma liga¸c˜ao, o
intervalo entre os recebimentos do primeiro e segundo pacotes ´e proporcional `a largura
de banda deste “gargalo” (FIG. 8.6). Para que essa t´ecnica funcione, o tamanho dos
FIG. 8.6: T´ecnica de medi¸c˜ao de banda par de pacote.
pacotes deve ser suficientemente grande para causar um enfileiramento no menor “gar-
galo”. Infelizmente, para a maioria das situa¸c˜oes h´a presen¸ca de tr´afego concorrente du-
rante as medi¸c˜oes. Para contornar este problema, diversos trabalhos (DOVROLIS, 2001),
(CARTER, 1996), (DOVROLIS, 2004), foram desenvolvidos, dentre os quais destacamos
(DOVROLIS, 2004), que, para o c´alculo da banda dispon´ıvel, prop˜oe um tratamento es-
tat´ıstico dos dados colhidos a partir do envio de m´ultiplos pares de pacotes durante as
medi¸c˜oes. Na tabela 8.1 as principais ferramentas de medi¸c˜ao da banda fim-a-fim e suas
respectivas referˆencias, que podem ser utilizadas para alimentar a camada de transporte
adaptativa com os parˆametros necess´arios ao seu funcionamento, ou mesmo servir de base
para implementa¸c˜ao de um novo coletor de parˆametros.
66
Aplicativo Referˆencia
bprobe (CARTER, 1996)
nettimer (LAI, 2000)
pathrate (DOVROLIS, 2004)
sprobe (SAROIU, 2002)
TAB. 8.1: Principais ferramentas de medi¸c˜ao da banda fim-a-fim.
8.6 PROGRAMA
Como j´a foi dito, o pathrate ´e um aplicativo para estimar a capacidade do canal
fim-a-fim. Resumidamente, este aplicativo avalia a capacidade do canal entre dois en-
dere¸cos IP e produz um arquivo no qual encontramos o RTT entre as m´aquinas e um
intervalo de velocidades estimado para capacidade do enlace entre eles. Maiores detalhes
a respeito da instala¸c˜ao, forma de funcionamento e emprego do pathrate se encontram
em (PATHRATE, 2008). O programa, desenvolvido para adaptar a camada de trans-
porte, cria, atrav´es do comando fork, um processo para executar o pathrate. Ap´os a
execu¸c˜ao do pathrate, o referido programa lˆe o arquivo de sa´ıda para extrair a velocidade
e o RTT. De posse destes dados, o programa, baseado na Tabela 6.3, utiliza o comando
sysctl para ativar a variante TCP de melhor desempenho para o RTT e banda estimados
(FIG.8.7). O c´odigo do programa se encontra no Apˆendice 3. Destacamos ainda que um
FIG. 8.7: Implementa¸c˜ao de uma Camada de Transporte Adaptativa.
administrador pode de tempos em tempos, atrav´es do crontab, por exemplo, chamar o
programa desenvolvido para adaptar seu transporte `as condi¸c˜oes da rede.
67
9 ADAPTAC¸
˜
AO SOBRE UDP
9.1 PRELIMINARES
Esta ´e a segunda fase do trabalho, cuja finalidade ´e mostrar como deve ser uma camada
de transporte adaptativa que tamb´em tenha de operar com protocolos desenvolvidos para
redes com caracter´ısticas incomuns. Lembramos que no m´odulo de telem´atica, por exem-
plo, pode haver chaveamento de uma conex˜ao “boa” (baixas taxas de erro e velocidades
da ordem de Mbps, ex.: Ethernet, fibra optica), para um enlace HF. Em (ISODE, 2008)
encontramos alguns motivos pelos quais os mecanismos TCP n˜ao s˜ao aconselhados no
caso de utiliza¸c˜ao de enlaces HF, dentre as quais destacam-se o fato de as vers˜oes TCP
terem sido projetadas para redes com velocidades muito acima daquelas proporcionadas
pelos enlaces HF e o grande n´umero de retransmiss˜oes desnecess´arias produzidas pelos
mecanismos TCP enquanto este protocolo n˜ao “descobrir” o RTT do enlace. A camada
de transporte deve, portanto, adequar-se a tais condi¸c˜oes.
Visando esta adequa¸c˜ao, faz-se uma an´alise do desempenho do TCP e do UDP em
enlaces restritos com o objetivo de dar uma vis˜ao mais concreta a respeito dos ganhos que
podem ser alcan¸cados pelo UDP em rela¸c˜ao ao TCP em enlaces com baixa velocidade e
elevada taxa de erro.
Posteriormente, ´e apresentado um esquema de adapta¸c˜ao quando da necessicade de
empregar-se ora protocolos especiais, otimizados para situa¸c˜oes espec´ıficas (geralmente
baseados em UDP), ora protocolos alinhados com esquemas mais tradicionais.
9.2 AN
´
ALISE DO TCP E DO UDP EM ENLACES RESTRITOS
9.2.1 AMBIENTE DE TESTE
Os testes foram realizados no laborat´orio de redes do IME. As m´aquinas utilizadas
seguem a configura¸c˜ao apresentada nao cap´ıtulo 5. Para avaliarmos a eficiˆencia entre o
transporte TCP e UDP, foram realizados transferˆencias de dados na estrutura ilustrada
pela Figura 9.1.
68
FIG. 9.1: Ambiente de testes - TCP X UDP.
9.2.2 EXPERIMENTOS
Como sugere a Figura 9.1, as m´aquinas Grecia21 e Grecia715 se interligam por dois
roteadores: CRETA (CISCO(R) 2611) e CYPRUS (CISCO(R) 1750), que se conectam
diretamente por um enlace serial. Na m´aquina Grecia21, um programa desenvolvido
enviava dados (500 Bytes a cada 0.5 segundos), durante um determinado intervalo de
tempo (15, 30, 60 e 120 segundos), para a m´aquina Grecia715 utilizando o enlace serial
(s0-s0/1), ajustado a velocidade de 1200 bps, ora atrav´es do UDP, ora atrav´es do TCP. A
taxa de erro a cada rodada de teste foi repectivamente 10, 25 e 50 %; estas taxas foram
emuladas pelo Netem (Apˆendice 1). O goodput proporcionado por ambos os protocolos
para as taxas de erro utilizadas est˜ao condensadas nos gr´aficos das Figuras 9.2, 9.3 e 9.4
9.2.3 ANALISANDO OS DESEMPENHOS
Como pode ser observado, o UDP proporciona uma transferˆencia bruta de dados
cada vez maior `a medida que se aumenta a taxa de erros. Um coment´ario especial cabe
na situa¸c˜ao na qual a taxa de erros foi ajustada para 50% (configura¸c˜ao esta que traduz
enlaces HF). Os resultados confirmam que a manuten¸c˜ao de protocolos alinhados `a filosofia
TCP podem comprometer as atividades de comunica¸c˜ao quando elas utilizam enlaces
cujas caracter´ısticas se aproximam daquelas proporcionadas pelas transmiss˜oes de dados
69
FIG. 9.2: TCP X UDP 10%.
70
FIG. 9.3: TCP X UDP 25%.
71
FIG. 9.4: TCP X UDP 50%.
72
em HF.
Os experimentos podem ser utilizados para avalia¸c˜ao de qu˜ao promissor pode ser o
investimento em mecanismos confi´aveis para transmiss˜ao de dados sobre UDP. No caso das
transferˆencias realizadas com um canal de taxa de erro em 50%, o goodput do UDP chega
a ser praticamnete 700% maior do que aquele alcan¸cado pelo TCP. Sendo assim, mesmo
que a garantia da confiabilidade durante a transmiss˜ao UDP no terceiro experimento
representasse uma redu¸c˜ao de quase 75% no goodput do tr´afego UDP, ele ainda seria o
dobro do alcan¸cado pelo TCP.
9.3 ESTRUTURANDO A ADAPTAC¸
˜
AO
Infelizmente a multiplexa¸c˜ao/demultiplexa¸c˜ao do UDP e do TCP seguem, como foi
visto anteriormente, padr˜oes distintos: o UDP utiliza somente a porta destino para al-
can¸car o processo destinat´ario das informa¸c˜oes enquanto que o TCP utiliza o par de portas
para despachar os dados encaminhados. Sendo assim, passar do UDP para o TCP, ou
vice-versa. requer uma estrutura mais elaborada do que aquela sugerida na adapta¸c˜ao
entre as variantes TCP.
Uma forma de possibilitar a adapta¸c˜ao entre um protocolo de transporte espec´ıfico
sobre o UDP e o TCP seria acumular as atividades de transporte na aplica¸c˜ao. Quando
em enlaces HF, por exemplo, o m´odulo da aplica¸c˜ao respons´avel pelo transporte de dados
passaria a trabalhar de forma otimizada para o enlace em quest˜ao, como em (KENNING-
TON, 1997). Caso um enlace reconhecidamente amig´avel ao TCP passe a reger a conex˜ao,
o TCP seria ent˜ao emulado sobre o UDP (FIG.9.5). A emula¸c˜ao do TCP sobre o UDP
j´a ´e adotada em diversas aplica¸c˜oes pr´aticas, principalmente naquelas que realizam trans-
miss˜ao de dados em enlaces r´adio. O programa C2 em combate ´e um exemplo de sucesso
desta abordagem (RONDON, 2006). Outro exemplo de projeto que segue esta filosofia ´e
o RakNet (RAKNET, 2008).
´
E importante ressaltar ainda que todas as considera¸c˜oes feitas sobre o projeto de
camada de transporte adaptativa para o chaveamento entre as variante TCP valem para
a implementa¸c˜ao de um transporte adaptativo na aplica¸c˜ao sobre o UDP. Obviamente,
neste caso, haver´a necessidade de se implementar cada fun¸c˜ao de atualiza¸c˜ao da janela
de congestionamento (Reno, BIC, etc), que sirva de op¸c˜ao para a camada de transporte
adaptativa sobre o UDP.
73
FIG. 9.5: Adapta¸c˜ao Sobre UDP.
74
10 CONSIDERAC¸
˜
OES FINAIS
10.1 CONCLUS
˜
OES
No desenvolvimento deste trabalho, ficou provada a importˆancia de uma camada de
transporte adaptativa para o sucesso das comunica¸c˜oes digitais, principalmente devido
`a imprevisibilidade das redes de comunica¸c˜oes atuais. Os resultados comprovaram que
uma grande economia, tanto de tempo quanto de recursos, pode ser atingida quando
o transporte se adequa ao momento vivido pela infra-estrutura de comunica¸c˜ao. Feliz-
mente, para uma boa escolha no que diz respeito `a fun¸c˜ao de atualiza¸c˜ao da janela de
congestionamento, n˜ao precisamos de medidas extremamente precisas, o que torna as
implementa¸c˜oes de camadas de transporte adaptativas independentes de sondagens ex-
tremamente eficientes, as quais tornariam tais implementa¸c˜oes bem mais dif´ıceis de serem
concretizadas.
Quanto `a viabilidade de uma camada de transporte flex´ıvel, vimos que a adapta¸c˜ao
na fun¸c˜ao de atualiza¸c˜ao da janela de congestionamento ´e algo inerente `as mais remotas
vers˜oes do TCP e que bastaria disponibilizarmos outras fun¸c˜oes de atualiza¸c˜ao (CUBIC,
BIC, etc), que seriam selecionadas de acordo com os parˆametros levantados nos experi-
mentos.
A arquitetura da camada de transporte adaptativa apresentada refor¸ca ainda mais a
aplicabilidade desta nova filosofia, pois esta arquitetura e os padr˜oes de projetos a partir
dos quais a mesma foi estruturada, s˜ao amplamente conhecidos e representam de forma
simples e precisa toda a documenta¸c˜ao necess´aria aos poss´ıveis desenvolvedores desta
camada.
Mesmo que os sistemas operacionais n˜ao sejam dotados de uma camada de transporte
adaptativa, ´e poss´ıvel emularmos um transporte adaptativo como ilustrado na imple-
menta¸c˜ao (se¸c˜ao 8.6), feita utilizando-se o comando sysctl e os m´odulos dispon´ıveis nas
vers˜oes mais modernas de kernel. Al´em disso, ainda que n˜ao haja no kernel os referidos
m´odulos, o transporte de dados pode ter sua flexibiliza¸c˜ao garantida caso as aplica¸c˜oes,
associadas a sockets UDP, se encarreguem das atividades de atualiza¸c˜ao da cwnd, como
ilustrado no cap´ıtulo 9 na adapta¸c˜ao sobre o UDP.
75
Outro fato bem interessante ´e o bom desempenho do TCP Reno, como op¸c˜ao de
transporte de dados para um grande n´umero de situa¸c˜oes, principalmente naquelas mais
tradicionais (velocidades at´e 10 Mbps), e at´e em alguns enlaces mais robustos, como
observado nos enlaces de 100 Mbps, para RTT’s abaixo de 400 ms e liga¸c˜oes de 1 GB com
RTT inferior a 200 ms.
Deve-se destacar tamb´em que a vantagem do emprego do UDP em rela¸c˜ao ao TCP
em canais HF est´a intimamente relacionada com a taxa de erros e nem tanto com a
velocidade do enlace. Os experimentos apresentados no cap´ıtulo 9 mostram que, para
uma taxa de erros de 10%, a diferen¸ca entre as quantidades de dados transportados pelas
duas abordagens n˜ao ´e t˜ao expressiva. Esta diferen¸ca poderia at´e ser tolerada diante
da confiabilidade oferecida pelo TCP. Contudo, conforme se intensificavam as perdas no
canal, o desempenho do UDP se mantinha est´avel enquanto que o TCP diminu´ıa de forma
dr´astica a quantidade de dados transportados a cada rodada de testes. Nestas situa¸c˜oes
´e interessante o investimento em mecanismos eficientes, a serem implementados sobre o
UDP, para garantia da confiabilidade na troca de informa¸c˜oes.
10.2 TRABALHOS FUTUROS
Outras quest˜oes podem ser exploradas no contexto deste trabalho, dentre as quais
destacamos:
• Latˆencia
Durante todo o trabalho, baseamos nossas conclus˜oes, como geralmente ´e feito em
trabalhos cient´ıficos, em um modelo simplificado, isto ´e, assumimos que a camada
de transporte adaptativa ´e capaz de chavear entre as abordagens dispon´ıveis de
forma instantˆanea, sem fazermos qualquer considera¸c˜ao sobre a latˆencia que pode
existir durante este chaveamento, principalmente no que diz respeito ao ajuste das
vari´aveis de contexto para realiza¸c˜ao das atividades da camada de transporte e como
aproveitarmos as informa¸c˜oes presentes nestas vari´aveis para alimentarmos aquelas
requeridas pela nova abordagem de transporte ora instanciada.
Deve ser levantado se ´e poss´ıvel ou n˜ao a implementa¸c˜ao de uma camada de trans-
porte adaptativa com tempo de chaveamento desprez´ıvel entre os algoritmos de
atualiza¸c˜ao da janela de congestionamento. Caso esta latˆencia n˜ao seja desprez´ıvel,
´e preciso medir quais os impactos desta latˆencia nos resultados ora apresentados.
76
• Outras Vari´aveis
Como a maioria dos trabalhos na literatura justifica as propostas de novas vers˜oes
TCP levando-se em considera¸c˜ao o BDP, no caso dos enlaces confi´aveis, e na taxa
de erros, no caso dos enlaces suscet´ıveis a interferˆencias, este trabalho concentrou
seus esfor¸cos nestes parˆametros. Entretanto, existem outros fatores que podem ser
considerados como importantes na hora de se optar por esta ou aquela abordagem
de transporte. S´o para ilustrar, o desempenho do TCP tradicional ´e reconhecida-
mente prejudicado em redes de grande jitter. At´e que ponto este jitter realmente
degrada as mais novas vers˜oes do TCP e suas variantes, bem como se os valores deste
jitter representam alguma situa¸c˜ao pr´atica, deve ser objeto de investiga¸c˜ao para o
aperfei¸coamento das implementa¸c˜oes das camadas de transporte adaptativas.
• Dura¸c˜ao da Conex˜ao
Um outro fator que deve ser estudado ´e qual dura¸c˜ao m´ınima uma conex˜ao deve ter
para ser contemplada com a possibilidade de adaptar seu mecanismo de transporte.
Obviamente, para conex˜oes muito curtas n˜ao valeria a pena dotar a camada de
transporte com a flexibilidade proposta por este trabalho.
77
11 REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS
AI3. Asian Internet Interconnection Initiatives, 2009. URL
http://ai3.asti.dost.gov.ph/sat/chara.html. Visitado em visitado em
29/01/2009.
ASENSTORFER, P. e SCHOLZ, J. B. Longfish - a hf radio network testbed. 7th Int.
Conf. on HF Radio Systems and Techniques , 1997.
BRAKMO, L., O’MALLEY, S. e PETERSON, L. Tcp vegas: New techniques for conges-
tion detection and avoidance. SIGCOMM 94 Symposium, 1994.
CAINI, C. e FIRRINCIELI, R. Tcp hybla: a tcp enhancement for heterogeneous networks.
Int. J. Satellite Commun. Netw., 2004.
CARTER, R. L. e CROVELLA, M. E. Measuring bottleneck link speed in packet-switched
networks. Technical report, Department of Computer Science, Boston Univer-
sity, http://www.cs.bu.edu/faculty/crovella/papers.html, 1996.
CASETTI, C., GERLA, M., MASCOLO, S., SANADIDI, M. Y. e WANG, R. Tcp west-
wood: Bandwidth estimation for enhanced transport over wireless links. ACM Mo-
bicom 2001, 2001.
COTER. Principais aspectos do sistema de comando e controle do ex´ercito e da for¸ca
terrestre. Minist´erio da Defesa - Ex´ercito Brasileiro - Comando de Opera¸c˜oes
Terrestres, 2002.
DELL’AERA, A., GRIECO, L. A. e MASCOLO, S. Linux 2.4 implementation of west-
wood+ tcp with rate-halving: A performance evaluation over the internet. IEEE In-
ternational conference on Communication (ICC 2004), June 2004, Paris,
2004.
DOVROLIS, C., RAMANATHAN, P. e MOORE, D. What do packet dispersion tech-
niques measure? IEEE INFOCOM’2001, Anchorage, AK, EUA., 2001.
DOVROLIS, C., RAMANATHAN, P. e MOORE, D. Packet dispersion techniques and
a capacity estimation methodology. IEEE/ACM Transactions on Networking,
2004.
FLOYD, S. Highspeed tcp for large congestion windows - rfc 3649. Experimental, 2003.
URL http://www.icir.org/floyd/hstcp.html.
FLOYD, S., HENDERSON, T. e GURTOV, A. The newreno modification to tcp’s fast
recovery algorithm - rfc 2582. IETF, 2004.
78
GAMMA, E., HELM, R., JOHNSON, R. e VLISSIDES, J. M. Design Patterns: Elements
of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series).
Addison-Wesley, 1995.
HEMMINGER, S. Network emulation with netem. In Proceedings of LCA, 2005.
ISODE. Why ip over hf radio should be avoided. Isode’s whitepapers, 2008.
JACOBSON, V. Congestion avoidance and control. SIGCOMM ’88 Conf., ACM,
1988.
JACOBSON, V. Berkeley tcp evolution from 4.3-tahoe to 4.3-reno. Eighteenth Internet
Engineering Task Force - University of British Columbia, Vancouver,B.C,
1990.
JACOBSON, V. Pathchar: A tool to infer characteristics of internet paths. Presented
at the Mathematical Sciences Research Institute (MSRI),April 1997., 1997.
URL http://www.caida.org/tools/utilities/others/pathchar/.
JIN, C., WEI, D. X. e LOW, S. H. Fast tcp: Motivation, architecture, algorithms, perfor-
mance. Em IEEE INFOCOM, 2004.
JODALEN, V., EGGEN, A., SOLBERG, B. e GRONNERUD, O. Military messaging in
ip networks using hf links. Communications Magazine, IEEE, 2004.
JOHNSON, E. E. Hf radio in the international information infrastructure. Em Nordic
Shortwave Conference , HF95, Faro, Sweden, 1995.
KELLY, T. Scalable tcp: Improving performance in high-speed widearea networks. ACM
SIGCOMM Computer Communication Review, 2003.
KENNINGTON, A. The fitfeel transmission protocol. Int. Conf. on Telecommuni-
cations (ICT97), Melbourne, Australia., 1997.
KEPHART, J. e CHESS, D. The vision of autonomic computing. IEEE Computer,
2003.
KESSLER, G. C. e TRAIN, D. A. Metropolitan Area Networks - Concepts, Standards and
Services. McGraw-Hill Inc , 1992. ISBN: 0070342431.
KUROSE, J. F. e ROSS, K. Computer Networking: A Top-Down Approach, 4/E.
Addison-Wesley, 2008. ISBN: 0321497708.
LAI, K. e BAKER, M. Measuring link bandwidths using a deterministic model of packet
delay. ACM SIGCOMM’2000, Estocolmo, Su´ecia, 2000.
LEE, C., LEE, D., KOO, J., BANERJEE, S. e CHUNG, J. Cli-based tcp: an end-to-end
proactive approach robust to trafic load. Elsevier, 2008.
79
LIU, S., BASAR, T. e SRIKANT, R. Tcp illinois: A loss and delay-based congestion
control algorithm for high-speed networks. 1
st
Int. Conf. on Performance Eval-
uation Methodologies and Tools, 2006.
MICHEL, N. F. e FONSECA, N. L. S. Uma investiga¸c˜ao sobre a escalabilidade de variantes
do protocolo tcp para redes de alta velocidade. Wperformance, 2007.
MICHEL, N. F. e FONSECA, N. L. S. Tcp tunning guide. Advanced Computing for
Science, 2008.
PATHRATE. 2008. URL http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/
pathrate tutorial.html. Visitado em visitado em 29/01/2009.
PAXSON, V. Measurement and analysis of end-to-end internet dynamics. University
of California, Berkeley, 1997.
POSTEL, J. User datagram proto col, rfc 768. 7th Int. Conf. on HF Radio Systems
and Techniques, 1980.
POSTEL, J. Internet control message protocol. rfc 792. Internet Engineering Task
Force (IETF) , 1981a.
POSTEL, J. Internet protocol, std 5, rfc 791. USC/Information Sciences Institute ,
1981b.
RAKNET. 2008. URL http://www.jenkinssoftware.com/raknet/manual/reliabilitytypes.html.
Visitado em visitado em 29/01/2009.
REZENDE, J. F., COSTA, L. H. M. K. e RUBINSTEIN, M. G. Avalia¸c˜ao experimen-
tal e simula¸c˜ao do protocolo tcp em redes de alta velocidade. XXII SIMP
´
OSIO
BRASILEIRO DE TELECOMUNICAC¸
˜
OES - SBrT’05, 2005.
REZENDE, J. F., DA SILVA, M. W. R., CARDOSO, K. V., MENDES, A. C., GUEDES,
R. M. e AUGUSTO, C. H. P. Segmenta¸c˜ao de conex˜oes tcp para a transferˆencia fim-a-
fim em alta velocidade. SBC, 2008.
RONDON. Programa c2 em combate “mecanismo de replica¸c˜ao e difus˜ao de objetos
nodais(rondon). Technical report, Minist´erio da Defesa - Ex´ercito Brasileiro -
Departamneto de Ciˆencia e Tecnologia - Centro Integrado de de Guerra
Eletrˆonica (CIGE), 2006.
SAROIU, S., GUMMADI, P. e GRIBBLE, S. Sprobe: A fast technique for measuring
bottleneck bandwidth in uncooperative environments. IEEE INFOCOM, 2002.
SHORTEN, R. e LEITH, D. H-tcp: Tcp for high-speed and longdistance networks. Sec-
ond International Workshop on Protocols for Fast Long-Distance Net-
works, February 16-17, 2004, Argonne, Illinois USA, 2004.
SILVA, L. A. F. An´alise de desempenho de proto colos de transporte para redes de alta
velocidade. Disserta¸c˜ao de Mestrado, COPPE/UFRJ, M.Sc.,Engenharia El´etrica
- Universidade Federal do Rio de Janeiro, 2006.
80
STALLING, W. Data and Computer Communications. Macmilan Publishing Com-
pany, 1994. ISBN-0070342431.
TAN, K., SONG, J., ZHANG, Q. e SRIDHARAN, M. Compound tcp: A scalable and
tcp-friendly congestion control for high-speed networks. PFLDnet, 2006.
TANENBAUM, A. S. Computer Networks - Fourth Edition. Prentice Hall, 2003. ISBN:
0130661023.
XU, L., HARFOUSH, K. e RHEE, I. Binary increase congestion control (bic) for fast
long-distance networks. IEEE INFOCOM, 2004.
XU, L. e RHEE, I. Cubic: A new tcp-friendly high-speed tcp variant. Workshop on
Protocols for Fast Long Distance Networks, 2005.
81
12 AP
ˆ
ENDICES
82
12.1 NETEM
12.1.1 VIS
˜
AO GERAL
O m´odulo Netem (Network Emulation) ´e um recurso recentemente agregado `as vers˜oes
Linux, cujas funcionalidades permitem alterar as propriedades de uma conex˜ao fim-a-fim.
As vers˜oes atuais alteram os atrasos (jitter e RTT), perda, duplica¸c˜ao e reordena¸c˜ao de
pacotes. V´arios trabalhos (REZENDE, 2008) (HEMMINGER, 2005) atestam a eficiˆencia
desta ferramenta na avalia¸c˜ao de protocolos de transmiss˜ao. Nas distribui¸c˜oes 2.6 Fe-
dora, OpenSuse, Gentoo, Debian, Mandriva, Ubuntu, este m´odulo j´a faz parte do kernel.
O Netem ´e acionado pelo comando “tc” (trafic control), empregado para controlar os
parˆametros utilizados no controle de tr´afego no Linux. Um exemplo destes parˆametros
´e a disciplina de fila (qdisc), que regula o envio de pacotes de acordo com as suas con-
figura¸c˜oes; sendo assim, sempre que um pacote deve ser enviado por uma interface, ele
´e primeiro tratado pela qdisc associada a ela (FIG. 12.1). O Netem atua alternando a
disciplina associada `a fila de uma interface, como veremos nos exemplos a seguir.
FIG. 12.1: Disciplina de Fila e o Netem.
12.1.2 EXEMPLOS
• Alterando Atrasos
O comando a seguir adiciona um atraso fixo em todos os pacotes despachados pela
interface eth0:
83
#tc qdisc add dev eth0 root netem delay 100ms
Este comando pode ser traduzido da seguinte forma: “Alerte ao controle de tr´afego
que antes de um pacote sair da fila associada `a intervace eth0 (disciplina da fila -
qdisc), ele deve esperar 100 ms”. As altera¸c˜oes produzidas por este comando podem
ser verificadas por simples testes, at´e mesmo atrav´es do comando ping.
´
E poss´ıvel
acrescentarmos varia¸c˜oes no atraso (jitter) da seguinte forma:
# tc qdisc change dev eth0 root netem delay 100ms 10ms
Observe que agora foi utilizado o parˆametro change, que simplesmente muda a dis-
ciplina da fila sem precisarmos recarreg´a-la. Este comando faz com que o atraso
seja de 100±10ms. Se n˜ao estivermos interessados em uma varia¸c˜ao puramente
randˆomica (distribu´ıda uniformemente) deste jitter devemos inserir o comando com
o formato:
# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
que produz um delay de 100± 10ms com o pr´oximo elemento randˆomico depen-
dendo 25% do anterior. Obviamente estes c´alculos s˜ao resultados de aproxima¸c˜oes
estat´ısticas. Tipicamente, a distribui¸c˜ao do jitter n˜ao ´e uniforme, por isso podemos
associar a varia¸c˜ao do atraso a uma distribui¸c˜ao normal:
# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
A princ´ıpio, qualquer distribui¸c˜ao pode ser utilizada, basta gerar o arquivo .dist cor-
respondente e copi´a-lo para /usr/lib/tc. As distribui¸c˜oes normal, pareto e paretonor-
mal j´a est˜ao dispon´ıveis.
• Perda de Pacotes
A perda de pacotes pode ser especificada atrav´es do comando tc de acordo com o
exemplo a seguir:
# tc qdisc change dev eth0 root netem loss 0.1%
este comando causa uma perda randˆomica de 1 pacote a cada 1000. Existe a pos-
sibilidade de se tornar as perdas menos randˆomicas se utilizarmos o comando da
seguinte maneira:
# tc qdisc change dev eth0 root netem loss 0.3% 25%
Assim, haver´a 0,3% de perdas e cada probabilidade sucessiva depende de um quarto
da anterior, como sugere a seguinte equa¸c˜ao:
P
n
= 0.25 ∗ P
n−1
+ 0.75random.
84
• Duplica¸c˜ao de Pacotes
A duplica¸c˜ao de pacotes ´e especificada da mesma forma empregada na Perda de
pacotes
# tc qdisc change dev eth0 root netem duplicate 1%
• Corrup¸c˜ao de Pacotes
Para emularmos a corrup¸c˜ao de pacotes basta executarmos o seguinte comando:
# tc qdisc change dev eth0 root netem corrupt 0.1%
1 a cada 1000 pacotes ter˜ao um dos seus bits corrompidos.
• Reordena¸c˜ao de Pacotes
Existem duas formas de proceder a reordena¸c˜ao de pacotes: O m´etodo gap e o
reorder. No gap, uma seq¨uˆencia l´ogica de reordena¸c˜ao ´e estabelecida, por exemplo
# tc qdisc change dev eth0 root netem gap 5 delay 10ms
Este comando produz o envio autom´atico de todos os pacotes m´ultiplos de 5 (quinto,
d´ecimo, d´ecimo quinto...) e mant´em os demais pacotes na fila por 10ms. Para
exemplificar, suponha que depois de executada a linha de comando anterior, 10
pacotes cheguem na fila: o pacote 1 no tempo t
1
, o 2 em t
2
e assim sucessivamente
at´e o d´ecimo pacote no tempo t
10
. Nestas condi¸c˜oes, os pacotes 5 e 10 ser˜ao enviados
em t
5
e t
10
respectivamente, enquanto que os demais pacotes seguir˜ao a seguinte
regra: o pacote 1 ser´a despachado em t
1
+ 10 ms, o 2 em t
2
+ 10 ms, o 3 em t
3
+ 10
ms e assim por diante at´e o nono em t
9
+ 10 ms.
Com o parˆametro reorder, produzimos uma reordena¸c˜ao de uma determinada por-
centagem de pacotes:
# tc qdisc change dev eth0 root netem delay 10ms reorder 25% 50%
Neste exemplo, 25% dos pacotes com uma correla¸c˜ao de 50% (P
n
= 0.50 ∗ P
n−1
+
0.50random), ser˜ao enviados imediatamente, os outros permanecer˜ao na fila por
10ms. Existe ainda uma forma indireta de se produzir a reordena¸c˜ao, atrav´es da
varia¸c˜ao do jitter :
# tc qdisc change dev eth0 root netem delay 100ms 75ms
Se ao primeiro pacote ´e associado um atraso de 100 ms e ao segundo pacote um
85
atraso de 50 ms (100 ms - 50 ms), o segundo pacote ser´a enviado antes do primeiro;
isto porque os pacotes na fila s˜ao dispostos segundo o momento de envio.
Existem ainda outras formas de se combinar o Netem com outros recursos para al-
can¸carmos outros parˆametros da rede. H´a tamb´em uma lista de discuss˜ao para que os
usu´arios desta ferramenta possam sanar suas d´uvidas em
http://www.linuxfoundation.org/en/Net:Netem
12.2 SYSCTL
12.2.1 VIS
˜
AO GERAL
O comando sysctl (System Control), permite configurar parˆametros do kernel em
tempo de execu¸c˜ao. O arquivo de configura¸c˜ao do sysctl ´e o /etc/sysctl.conf. Seguem
alguns exemplos de comandos sysctl b´asicos:
• sysctl -a: exibe todos os valores de todos os parˆametros.
• sysctl -w variavel=valor: ajusta o parˆametro vari´avel para valor
• sysctl -p: carrega as configua¸c˜oes do arquivo /etc/sysctl.conf
12.2.2 REFINANDO OS PAR
ˆ
AMETROS
Segundo (MICHEL, 2008), deve-se fazer as seguintes altera¸c˜oes para incrementar o
desempenho do TCP em redes de alta velocidade:
net.core.rmem max = 16777216
1
net.core.wmem max = 16777216
net.ipv4.tcp rmem = 4096 87380 16777216
net.ipv4.tcp wmem = 4096 65536 16777216
Caso utilizemos o comando sysctl -p para ajustarmos estes parˆametros, devemos acres-
centar estas linhas no arquivo /etc/sysctl.conf e ent˜ao executarmos o comando sysctl -p
Se utilizarmos o sysctl -w para cada parˆametro devemos fazer:
sysctl -w net.core.rmem max = 16777216
sysctl -w net.core.wmem max= 16777216
1
Os valores representam quantidades em bytes
86
net.core.rmem max Ajusta o valor, do buffer recep¸c˜ao m´aximo para cada
conex˜ao.
net.core.wmem max Ajusta o buffer de envio m´aximo para cada conex˜ao
net.ipv4.tcp rmem O primeiro valor especifica a quantidade m´ınima de
mem´oria para o buffer de recep¸c˜ao que o kernel alo-
car´a para cada conex˜ao TCP, mesmo em situa¸c˜oes de
sobrecarga do sistema. O segundo representa o valor
default para o referido buffer. O terceiro valor especi-
fica o tamanho m´aximo do buffer de recep¸c˜ao para cada
conex˜ao TCP.
net.ipv4.tcp wmem An´alogo ao anterior, atuando agora sobre o buffer de
envio de cada conex˜ao TCP.
TAB. 12.1: Vari´aveis que devem ser ajustadas para enlaces de alta velocidade.
sysctl -w net.ipv4.tcp rmem = 4096 87380 16777216
sysctl -w net.ipv4.tcp wmem = 4096 65536 16777216
Segue abaixo uma tabela contendo o significado pr´atico de cada um dos parˆametros
mencionados:
´
E poss´ıvel alterarmos tamb´em o protocolo de transporte utilizado pelo kernel da
seguinte maneira:
sysctl -w net.ipv4.tcp congestion control=bic
As possibilidades de valores para net.ipv4.tcp congestion control se encontram, no caso do
SUSE11, 2.6.25.11-0.1-pae, em /lib/modules/2.6.25.11-0.1-pae/kernel/net/ipv4. Neste di-
ret´orio h´a arquivos cujos nomes come¸cam por tcp . Os valores poss´ıveis para net.ipv4.tcp
congestion control correspondem ao nome dos arquivos sem o tcp e sem a extens˜ao; por
exemplo, se quisermos ajustar o transporte para TCP CUBIC, basta verificarmos que
no diret´orio /lib/modules/2.6.25.11-0.1-pae/kernel/net/ipv4 h´a o arquivo “tcp cubic.ko”.
Retirando-se o tcp e a extens˜ao do nome do respectivo arquivo teremos o parˆametro
esperado; basta ent˜ao executarmos o comando:
sysctl -w net.ipv4.tcp congestion control=cubic
Destacamos ainda que, ap´os a mudan¸ca no protocolo de transporte, somente as novas
conex˜oes passar˜ao a ser regidas pelo m´odulo carregado. As conex˜oes anteriores per-
manecem no protocolo configurado quando do seu estabelecimento.
Existe uma enorme gama de parˆametros que podem ser dinamicamente configurados
87
pelo sysctl, e a tendˆencia natural ´e que esta lista cres¸ca cada vez mais, pois a cada nova
vers˜ao de kernel mais parˆametros passam a estar sob a possibilidade de altera¸c˜ao em
tempo de execu¸c˜ao.
12.3 PROGRAMA
#include < s t d i o . h>
#include <s ys / t ypes . h>
#include <s ys / s o cket . h>
#include < n e t i n e t / i n . h>
5 #include <netdb . h>
#include < s t d l i b . h>
#include < s t r i n g . h>
#include <time . h>
10
void e r r o r ( char ∗ ) ;
void e s p e r e ( int ) ;
in t E xt r ai rV a lo ( char ∗ parStr , i nt ∗ parValo r ) ;
15 i nt EstimarBandaRTT ( int ∗parBanda , in t ∗parRTT , char ∗parUnidade ) ;
in t main ( in t argc , char ∗ argv [ ] )
{
in t pi d ;
20 in t banda , RTT;
char unidade ;
i f ( a r gc != 2) {
f p r i n t f ( s t d e r r , " Usar: servidor \n" ) ;
25 e x i t ( 0 ) ;
}
in t s t a t u s ;
char se n de r Pa t h r at e [ 3 0 ] ;
30 st r c p y ( sen d e r P athrate , "-s" ) ;
s t r c p y ( s en d er P at h r a te +2, argv [ 1 ] ) ;
char outPathRate [ 3 0 ] ;
s t r c p y ( outPathRate , "-oteste .out" ) ;
88
p r i n t f ( "%s" , se n de r Pa t hr a te ) ;
35 pi d = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
{
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "./ pathrate_rcv " , "" , s e nderPath r a t e , "-v" , outPathRate ,NULL ) ;
40 e x i t ( 0 ) ;
}
e l s e /∗ pa r e nt p r o c e s s ∗/
{
wait(& s t a t u s ) ;
45 p r i n t f ( "\n I’m the parent !" ) ;
p r i n t f ( "\n Child returned: %d\n" , s t a t u s ) ;
EstimarBandaRTT(&banda ,&RTT,& unidade ) ;
i f ( unidade == ’M’ )
{
50 i f ( abs ( banda −1000) < abs ( banda −100)) // caso Giga
{
i f (RTT > 200)
{
pid = f o r k ( ) ;
55 i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
{
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin/sh" , "" , "./ bic.sc" ,NULL) ;
e x i t ( 0 ) ;
60 }
e l s e /∗ pa r ent p r o c e s s ∗/
wait(& s t a t u s ) ;
}
65 el s e
{
pid = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
{
70 p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin/sh" , "" , "./ reno.sc" ,NULL) ;
e x i t ( 0 ) ;
}
89
e l s e /∗ pa r ent p r o c e s s ∗/
75 wait(& s t a t u s ) ;
}
}
e l s e i f ( abs ( banda −10) > abs ( banda −100)) // caso 100M
80 {
i f (RTT > 400)
{
pid = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
85 {
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin/sh" , "" , "./ cubic .sc" ,NULL ) ;
e x i t ( 0 ) ;
}
90 e l s e /∗ pa r ent p r o c e s s ∗/
wait(& s t a t u s ) ;
}
e l s e
95 {
pid = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
{
p r i n t f ( "\n I’m the child!" ) ;
100 e x e c l ( "/bin/sh" , "" , "./ reno.sc" ,NULL) ;
e x i t ( 0 ) ;
}
e l s e /∗ pa r ent p r o c e s s ∗/
wait(& s t a t u s ) ;
105
}
}
110
e l s e // cas o 10M
{
pid = f o r k ( ) ;
90
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
115 {
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin /sh" , "" , "./ reno.sc" ,NULL ) ;
e x i t ( 0 ) ;
}
120 e l s e /∗ pa r e nt p r o c e s s ∗/
wait(& s t a t u s ) ;
}
125
}
e l s e i f ( unidade == ’G’ )
{
130 i f (RTT > 200)
{
pid = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
{
135 p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin /sh" , "" , "./ bic.sc" ,NULL) ;
e x i t ( 0 ) ;
}
e l s e /∗ pa r e nt p r o c e s s ∗/
140 wait(& s t a t u s ) ;
}
e l s e
{
pid = f o r k ( ) ;
145 i f ( p id == 0) /∗ c h i l d p r o c e s s ∗/
{
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin /sh" , "" , "./ reno.sc" ,NULL ) ;
e x i t ( 0 ) ;
150 }
e l s e /∗ pa r ent p r o c e s s ∗/
wait(& s t a t u s ) ;
91
}
155 }
e l s e // d e f a u l t
{
pid = f o r k ( ) ;
i f ( pid == 0) /∗ c h i l d pr o c e s s ∗/
160 {
p r i n t f ( "\n I’m the child!" ) ;
e x e c l ( "/bin/sh" , "" , "./ reno.sc" ,NULL) ;
e x i t ( 0 ) ;
}
165 e l s e /∗ pa r ent p r o c e s s ∗/
wait(& s t a t u s ) ;
}
170 }
return 0 ;
}
175 i nt EstimarBandaRTT ( int ∗parBanda , i nt ∗parRTT , char ∗ parUnidade )
{
FILE ∗ f= fopen ( "./ teste .out" , "r" ) ;
s i z e t l e n= 2 0 0 ; // v a l o r a r b i t r a r i o
char ∗ l i n h a= malloc ( l e n ) ;
180 in t i =0;
i f ( ! f )
{
p e r r o r ( "./ teste .out" ) ;
e x i t ( 1 ) ;
185 }
while ( g e t l i n e (& l in ha , &len , f ) > 0)
{
p r i n t f ( "%s" , l i n h a ) ;
i ++;
190
i f ( s t r s t r ( li n ha , " --> Average round -trip time:" ) )
{
Ex t r a i r V a l o r ( lin ha , parRTT ) ;
92
}
195 e l s e i f ( s t r s t r ( li n ha , " Final capacity estimate :" ) )
{
Ex t r a i r V a l o r ( lin ha , parBanda ) ;
i f ( s t r s t r ( li n ha , " Mbps " ) )
200 ∗ parUnidade = ’M’ ;
e l s e i f ( s t r s t r ( l i n ha , " Gbps" ) )
∗ parUnidade = ’G’ ;
e l s e
∗ parUnidade = ’k’ ;
205
}
}
210 i f ( l i n h a )
f r e e ( l i n h a ) ;
f c l o s e ( f ) ;
p r i n t f ( "RTT: %d\nBanda: %d%cbps\n" , ∗parRTT , ∗ parBanda , ∗ parUnidade ) ;
return 0 ;
215
}
in t E x t r a i r V a l o r ( char ∗ parS tr , i nt ∗ parVa lor )
220 {
in t i , j ;
in t done =0;
∗ parVal or = 0 ;
225 i = s t r l e n ( pa r St r ) ;
fo r ( j =0; j < i && ! done ; j ++)
{
i f ( p ar S tr [ j ] >=’0’&& pa r Str [ j ] <=’9’ )
{
230 p r i n t f ( "%c\n" , par S tr [ j ] ) ;
while ( pa r St r [ j ] >=’0’&& p a rS t r [ j ] <=’9’ )
{
∗ parVal or=∗parValor ∗10+( p a rS t r [ j ]−’0’ ) ;
93
j ++;
235 p r i n t f ( "%d\n" ,∗ parVal or ) ;
}
done =1;
}
}
240 return 0 ;
}
94
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
