TCP em Redes de Elevado Débito: A abordagem EIC TCP

Instituto Politécnico de Leiria
Escola Superior de Tecnologia e Gestão
TCP em Redes de
Elevado Débito
David Luís Santos Serafim
Hugo Elias Nogueira
Leiria
Fevereiro de 2007

Instituto Politécnico de Leiria
Escola Superior de Tecnologia e Gestão
TCP em Redes de
Elevado Débito:
A abordagem EIC TCP
Autores:
David Luís Santos Serafim, n.º 9035
Hugo Elias Nogueira, n.º 9063
Orientador: Prof. Paulo Loureiro
Co-orientador: Prof. Paulo Cordeiro
Leiria
Fevereiro de 2007

Dedicatória
Dedicatória
Seguindo o carácter pessoal do nome de diversas versões TCP, a versão deste projecto será referenciada
como EIC TCP. A decisão tomada surge em forma de dedicatória ao curso EIC (Engenharia Informática e
Comunicações), principal responsável pela concretização de todo o projecto. Essa responsabilidade
provém do facto de ter fornecido todas as nossas capacidades técnicas, absolutamente necessárias a todo o
bom desenvolvimento do projecto. Devido ao facto de o curso terminar brevemente, a opção por este
nome, e não um nome técnico, veio a revelar-se como a decisão mais justa e correcta.
Obrigado a todos aqueles que contribuíram, directa e indirectamente, no pequeno ciclo de vida de EIC.
i

TCP em Redes de Elevado Débito
Agradecimentos
Ao orientador do projecto, Prof. Paulo Loureiro e Prof. Paulo Cordeiro, pela preciosa orientação e
incentivo.
A todos os que contribuíram, directa ou indirectamente, na comunidade de investigação TCP.
Ao pessoal de Projecto II de EIC.
David Serafim:
Ao David X. Wei pela disponibilidade imediata no esclarecimento de dúvidas e por toda a simpatia no
seu esclarecimento. Um agradecimento extra pela referência na página do seu projecto Linux TCP
Implementation.
À minha família pelo apoio incondicional.
À minha namorada Liliana, principalmente, pela paciência e compeensão nas horas extra dedicadas ao
projecto.
Hugo Elias Nogueira:
Agradeço à minha família pelo apoio moral e económico.
Aos meus amigos pelo apoio moral.
Ao meu colega David Serafim pela dedicação demonstrada ao longo do projecto.
ii

Resumo
Resumo
Através de uuma publicação recente foi verificado que o TCP não se encontra preparado para atingir os
níveis de eficiência habituais, se forem consideradas redes de alto débito e elevado atraso.
Devido a essa situação, a comunidade de investigação mobilizou-se, com o principal intuito de devolver
ao TCP toda a sua eficiência anteriormente estabelecida. Diversas alternativas às normais versões do TCP
foram surgindo, adaptando o TCP a este tipo de meio específico. Todas estas versões possuem diferentes
algoritmos, estabelecendo diversos padrões de comportamento por parte do débito da rede. Os algoritmos
têm como base alterações na rede que lhe sugiram situações de congestão, diferenciando-se na sua
abordagem.
O projecto desenvolvido tem como primeira fase um estudo alargado de todos os mecanismos e
algoritmos, que foram contribuindo para toda a instalação de eficiência e eficácia nas redes de dados
actuais. Numa segunda fase o estudo abrange as novas versões, principalmente as versões para o meio de
alto débito.
Após todo o estudo efectuado, serão efectuados testes, com o principal intuito de verificar a
disponibilidade de versões deste protocolo que se encontra implementadas. Os níveis de eficiência e
estabilidade encontrados para um meio de alto débito serão também analisados.
Quando as fases de introdução a todos os problemas, falhas e conceitos estiverem referenciadas, uma
nova abordagem ao normal TCP e às variadas versões específicas para alto débito é definida.
A versão estará sujeita, também, a variados testes, com o principal objectivo de verificação de falhas, para
posteriores melhoramentos no algoritmo implementado, ou comparações de eficiência com outras versões
do mesmo protocolo.
iii

Índice
Dedicatória ...............................................................................................................................................i
Agradecimentos.......................................................................................................................................ii
Resumo...................................................................................................................................................iii
Índice......................................................................................................................................................iv
Lista de Siglas e Acrónimos.................................................................................................................viii
Lista de Figuras ......................................................................................................................................xi
Lista de Tabelas....................................................................................................................................xvi
Lista e Definição de Palavras Chave...................................................................................................xvii
1. Introdução....................................................................................................................................... 1
2. Planeamento.................................................................................................................................... 2
2.1. Gestão do âmbito.......................................................................................................................... 2
2.1.1. Descrição do produto e serviços do projecto...................................................................... 2
2.1.2. Os objectivos do projecto................................................................................................... 2
2.1.3. As entregas ......................................................................................................................... 4
2.1.4. Restrições do projecto ........................................................................................................ 4
2.1.5. Definição do Âmbito.......................................................................................................... 5
2.1.6. O Software.......................................................................................................................... 8
2.1.7. O Hardware ........................................................................................................................ 9
2.2. Gestão de Tempo........................................................................................................................ 10
3. Enquadramento ao Protocolo........................................................................................................ 12
3.1. Necessidade e Motivação ........................................................................................................... 12
3.1.1. Lista de pressupostos........................................................................................................ 13
3.1.2. As redes de alto débito ..................................................................................................... 14
iv

Índice
3.2. O Desenvolvimento.....................................................................................................................19
3.2.1. Entidades e Pessoas...........................................................................................................21
3.3. TCP..............................................................................................................................................30
3.3.1. O cabeçalho.......................................................................................................................30
3.3.2. Os mecanismos..................................................................................................................34
3.3.3. Os algoritmos ....................................................................................................................52
3.3.4. Os mecanismos para alto débito........................................................................................54
3.4. Os limites teóricos.......................................................................................................................57
3.5. A Congestão e as versões TCP....................................................................................................59
3.5.1. TCP Tahoe ........................................................................................................................60
3.5.2. TCP Reno..........................................................................................................................68
3.5.3. TCP newReno ...................................................................................................................69
3.5.4. TCP Vegas ........................................................................................................................72
3.5.5. Outros meios, outras versões.............................................................................................78
3.5.6. DCA VS LCA ...................................................................................................................81
3.6. Versões TCP alto débito..............................................................................................................83
3.6.1. O problema com o alto débito...........................................................................................83
3.6.2. HighSpeed TCP.................................................................................................................85
3.6.3. Scalable TCP.....................................................................................................................87
3.6.4. BIC e CUBIC ....................................................................................................................88
3.6.5. H-TCP ...............................................................................................................................90
3.6.6. FAST TCP.........................................................................................................................90
3.6.7. Compound TCP.................................................................................................................92
3.6.8. Outros................................................................................................................................93
3.7. Ponto de Situação ........................................................................................................................94
4. Testes Práticos.............................................................................................................................. 96
4.1. Testes Linux ................................................................................................................................97
4.1.1. Planeamento dos testes......................................................................................................97
v

4.1.2. Problemas....................................................................................................................... 100
4.1.3. Resultados ...................................................................................................................... 107
4.1.4. Conclusões...................................................................................................................... 114
4.2. NS2........................................................................................................................................... 115
4.2.1. Classes TCP.................................................................................................................... 116
4.2.2. Outras implementações TCP.......................................................................................... 118
4.2.3. Cenários.......................................................................................................................... 119
5. EIC TCP...................................................................................................................................... 121
5.1. Motivação................................................................................................................................. 121
5.2. Especificação............................................................................................................................ 122
5.3. Implementação ......................................................................................................................... 125
5.4. Testes........................................................................................................................................ 129
5.4.1. Testes Lumbbell ............................................................................................................. 129
5.4.2. Testes Internet ................................................................................................................ 138
5.4.3. Conclusões...................................................................................................................... 145
5.5. Trabalho Futuro........................................................................................................................ 146
6. Conclusão ................................................................................................................................... 148
7. Bibliografia................................................................................................................................. 149
Anexos................................................................................................................................................. 156
A.1. Planeamento ............................................................................................................................. 156
A.1.1. Entregas.......................................................................................................................... 156
A.1.2. WBS ............................................................................................................................... 160
A.2. Novo Protocolo......................................................................................................................... 163
A.2.1. Ficheiro novo_protocolo.cc............................................................................................ 163
A.2.2. Ficheiro novo_protocolo.h ............................................................................................. 172
A.3. Scripts....................................................................................................................................... 175
A.3.1. Cenário Simples Linux NS2 Implementation................................................................. 175
A.3.2. Cenário Lumbbell........................................................................................................... 178
vi

Índice
A.3.3. Cenário Internet...............................................................................................................181
A.4. Código EIC TCP .......................................................................................................................204
A.4.1. Ficheiro eic-end.cc ..........................................................................................................205
A.4.2. Ficheiro eic-end.h............................................................................................................228
vii

Lista de Siglas e Acrónimos
Ack Acknowledgment
ACM Association for Computing Machinery
AIMD Additive Increase and Multiplicative Decrease
AQM Active Queue Management
BDP Bandwidth Delay Product
BIC Binary Increase Congestion Avoidance
BP Burst Probe
BS Burst Segments
BSD Berkeley Software Distribution
BWE Bandwidth Estimate
CRC Cyclic Reduncancy Check
CPU Central Prossecing Unit
CTCP Compound TCP
CUBIC Função Cúbica
CUTE Congestion Control Using Timeouts at the End-to-
End
CWND Congestion Window
CWR Congestion Window Reduced
DCA Delay Congestion Avoidance
DCCP Datagram Congestion Control Protocol
DEC Digital Equipment Corporation
DWND Delay Window
ECE ECN-Echo
viii

Lista de Siglas e Acrónimos
ECN Explicit Congestion Notification
EIC TCP Engenharia Informática e Comunicações TCP
EUA Estados Unidos da América
FACK Forward Acknowlegement
FIFO First In First Out
FIN Finalize
FTP File Transfer Protocol
H-TCP Hamilton TCP
HSTCP HighSpeed TCP
HTTP Hypertext Trasfer Protocol
ICIR Internet Center for Internet Research
ICSI International Computer Science Institute
IEE Institution of Electrical Engineers
IEEE Institute of Electrical & Electronical Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
IPFW IP Firewall
LAN Local Área Network
LCA Loss-Based Congestion Avoidance
LFN Long Fat Networks
LP Loose Probe
LS Loose Segments
MIT Massachutetts Institute of Technology
MSS Maximum Segment Size
MTU Maximum Transmit Unit
NAM Network Animator
NAT Network Adress Translation
NS2 Network Simulator 2
ix

PARC Paco Alto Reseaarch Center
PAWS Protection Against Wrapped Sequence
PC Personal Computer
PFLDnet Protocols for Fast Long Distance Networks
PSH Push
RAM Random Access Memory
RFC Request for Comments
RED Random Early Detect
REM Random Exponencial Marking
RST Reset
RTO Retransmission Timeout Value
RTT Round Trip Time
SACK Selective Acklowledgement
SIG Special Interest Groups
SO Sistema Operativo
SWP Sliding Window Protocol
SYN Syncronization
TCP Trasmission Control Protocol
TOE TCP Offload Engine
TRPR Tcpdump Rate Plot Real-Time
TS Timestamp
US United States (United States of America)
URG Urgent
WAN Wide Area Network
WBS Work Breakdown Structure
WIN Window
XCP Explicit Congestion Protocol
x

Lista de Figuras
Lista de Figuras
Figura 2.1 – Esquema resumido do processo de conhecimento para a nova versão do protocolo................3
Figura 2.2 – Intercepção da nova versão com a inovação e a precaução necessárias. ..................................5
Figura 2.3 – Representação da matéria que envolve o âmbito......................................................................6
Figura 2.4 – Representação do âmbito, considerando as várias interfaces do TCP. .....................................7
Figura 2.5 – Representação dos tipos de reacção e controlo.........................................................................8
Figura 2.6 – Localização do âmbito através de uma comunicação entre emissor, receptor e rede. ..............8
Figura 2.7 – Representação do WBS...........................................................................................................10
Figura 2.8 – Gráfico de Gantt, representativo da sequência e relacionamento entre actividade.................11
Figura 3.1 – Esquema representativo da relação entre o TCP e os custos económicos. .............................13
Figura 3.2 – Crescimento da largura de banda disponibilizada (Fonte: [67]). ............................................16
Figura 3.3 – Mapa representativo das diversas ligações de alto débito entre continentes (Fonte:
Telegeography Research)............................................................................................................................17
Figura 3.4 – Mapa representativo de toda a disponibilização de largura de banda para Internet nos
diversos continentes (Fonte: Telegeography Research)..............................................................................17
Figura 3.5 – Relação ano, largura de banda teórica disponibilizada e ligações intercontinentais (Fonte:
Telegeography Research)............................................................................................................................18
Figura 3.6 – Tráfego médio, gerado pelas diversas ligações intercontinentais (Fonte: Telegeography
Research).....................................................................................................................................................18
Figura 3.7 – Timeline de desenvolvimento TCP.........................................................................................20
Figura 3.8 – Representação da analogia entre uma região e as versões TCP..............................................23
Figura 3.9 – O Cabeçalho TCP. ..................................................................................................................31
Figura 3.10 – Primeiro segmento TCP de uma sessão de dados.................................................................34
Figura 3.11 – Primeiro segmento TCP, após estabelecimento da sessão....................................................34
Figura 3.12 – Exemplo de troca de dados 1. ...............................................................................................36
xi

Figura 3.13 – Exemplo de troca de dados 2. .............................................................................................. 37
Figura 3.14 – O mecanismo de Piggybacking (Fonte: Washinton University).......................................... 38
Figura 3.15 – Representação do mecanismo Sliding Window................................................................... 39
Figura 3.16 – Representação das várias movimentações ao longo das trocas de segmentos TCP............. 39
Figura 3.17 – Movimentos do Sliding Window. ........................................................................................ 40
Figura 3.18 – Relação Window/Buffer....................................................................................................... 40
Figura 3.19 – Relação RTT/segmentos TCP.............................................................................................. 42
Figura 3.20 – Relação RTT/Janela. ............................................................................................................ 42
Figura 3.21 – Relação largura de banda/segmentos TCP........................................................................... 43
Figura 3.22 – Problema da janela com ligação de alto débito.................................................................... 43
Figura 3.23 – Reprentação do Silly Window Syndrome (Fonte: [3])......................................................... 44
Figura 3.24 – Cálculo do RTT medido por analisador de tráfego, comparado com o calculado TCP
(Fonte: [1]). ................................................................................................................................................ 47
Figura 3.25 – Representação da técnica exponential backoff..................................................................... 49
Figura 3.26 – Processo de activação do Persist Timer. .............................................................................. 50
Figura 3.27 – Exemplo de funcionamento do protocolo Sack.................................................................... 51
Figura 3.28 – Representação dos blocos da Sack Option........................................................................... 52
Figura 3.29 – Representação do retransmission ambiguity problem.......................................................... 54
Figura 3.30 – Representação dos campos do Timestamp Option............................................................... 55
Figura 3.31 – Análise do tráfego automóvel e populacional (Fonte: Universidade Técnica de Dresden e
Crowd Dynamics)....................................................................................................................................... 59
Figura 3.32 – Exemplo hidráulico de uma situação de congestão (Fonte: [3]). ......................................... 60
Figura 3.33 – Funcionamento da janela de receptor/janela congestão. ...................................................... 61
Figura 3.34 – Representação do estado de equilíbrio (Fonte: [13]). .......................................................... 62
Figura 3.35 – Representação do comportamento do Slow Start (Fonte: [13]). .......................................... 62
Figura 3.36 – Representação da perfomance de uma implementação 4.3BSD (Fonte: [13])..................... 63
Figura 3.37 – Representação da perfomance de uma implementação 4.3 BSD+ (Fonte [13])................... 64
Figura 3.38 – Representação gráfica da relação Slow Start/Congestion Avoidance (Fonte: [1]). ............. 66
Figura 3.39 – Probabilidade de existir perda de segmento......................................................................... 67
xii

Lista de Figuras
Figura 3.40 – Representação dos algoritmos de congestão em funcionamento (Fonte: [6]).......................69
Figura 3.41 – Representação do padrão problemático Fast Retransmit/Fast Recovery. .............................70
Figura 3.42 – Resumo de todas as operações e algoritmos de congestão, proporcionados pelas versões
TCP Tahoe, Reno e newReno. ....................................................................................................................72
Figura 3.43 – Relação throughput/velocidade transmissão [Fonte: [15]]. ..................................................76
Figura 3.44 – Gráfico característico do TCP Vegas....................................................................................77
Figura 3.45 – Comportamento do TCP Reno numa LFN de 10Gbit/s (Fonte: [9]).....................................84
Figura 3.46 – Representação do padrão gráfico do normal TCP (TCP Reno), MulTCP(N=10) e
HighSpeed TCP, numa LFN de 10Gbit/s (Fonte: [9]). ...............................................................................87
Figura 3.47 – Representação das modificações na janela de congestão efectuadas pelo TCP Scalable
(Fonte: [25]). ...............................................................................................................................................88
Figura 3.48 - Representação do padrão gráfico do normal TCP (TCP Reno), MulTCP(N=10) e Scalable
TCP (a=0.01, b=0.125) numa LFN 10Gbit/s (Fonte: [9])...........................................................................88
Figura 3.49 – Representação do algoritmo Binary Search Increase............................................................89
Figura 3.50 – Funções de crescimento BIC e CUBIC (Fonte: [27]). ..........................................................90
Figura 3.51 – Arquitectura FAST TCP (adaptado de [30] )........................................................................91
Figura 3.52 – Representação do funcionamento das janelas de congestão e atraso Compound TCP.........93
Figura 4.1 – Cenário Simulado Inicial. .......................................................................................................97
Figura 4.2 – Cenário Final...........................................................................................................................98
Figura 4.3 – CPU a utilizar 100% da capacidade de processamento ........................................................100
Figura 4.4 – Largura de banda ocupada com velocidade de 1Gbit/s, sem qualquer tipo de atraso...........101
Figura 4.5 – Simulação com atraso de 1000ms e 100Mbit/s (dummynet)................................................102
Figura 4.6 – Simulação com buffer de 16MB e buffer de 67MB (DummyNet). ......................................103
Figura 4.7 – Simulação com buffer máximo de 67MB e atraso de 1000ms (Netem) ...............................104
Figura 4.8 – Simulação com buffer de 16MB e buffer de 67MB, ambos com atraso de 50ms. ...............105
Figura 4.9 – Simulação com atraso configurado a 350ms, 300ms e 250ms..............................................105
Figura 4.10 – Simulação com a versão newReno (amostragem 10s)........................................................107
Figura 4.11 – Simulação com a versão TCP Vegas (amostragem 10s).....................................................108
Figura 4.12 – Simulação com a versão TCP Hybla (amostragem 10s).....................................................108
xiii

Figura 4.13 – Simulação com a versão Westwood+ (Amostragem 10s).................................................. 109
Figura 4.14 – Simulação com a versão Veno (amostragem 10s). ............................................................ 110
Figura 4.15 – Simulação com a versão Low Priority TCP (amostragem 10s). ........................................ 110
Figura 4.16 – Simulação com a versão HighSpeed TCP (amostragem 10s). ........................................... 111
Figura 4.17 – Simulação com a versão Scalable TCP (amostragem 10s). ............................................... 112
Figura 4.18 - Simulação com a versão BIC (amostragem 10s). ............................................................... 112
Figura 4.19 – Simulação com a versão CUBIC (amostragem 10s).......................................................... 113
Figura 4.20 – Simulação com a versão H-TCP (amostragem a 10s)........................................................ 114
Figura 4.21 – Simulação com a versão H-TCP (amostragem a 5s)......................................................... 114
Figura 4.22 – Simulação com todas as versões testadas........................................................................... 115
Figura 4.23 – Arquitectura NS (Fonte: [106]).......................................................................................... 116
Figura 4.24 – Cenário Lumbbell em NS2................................................................................................. 120
Figura 4.25 – Cenário Internet.................................................................................................................. 120
Figura 5.1 – Técnica de atenuação de Ack Compression......................................................................... 123
Figura 5.2 – Adaptabilidade da versão EIC TCP. .................................................................................... 124
Figura 5.3 – Arquitectura EIC TCP.......................................................................................................... 125
Figura 5.4 – Diagrama de Classes EIC TCP. ........................................................................................... 126
Figura 5.5 – Diagrama de fluxo da recepção de segmentos do EIC TCP................................................. 126
Figura 5.6 – Fluxograma de envio de segmentos do EIC TCP. ............................................................... 127
Figura 5.7 – Algoritmo da abertura de janela do EIC TCP ...................................................................... 128
Figura 5.8 – Simulação com a versão newReno Vs. EIC TCP e somatório das duas. ............................. 130
Figura 5.9 – Simulação com a versão TCP Vegas Vs. EIC TCP e somatório das duas........................... 131
Figura 5.10 - Simulação com a versão TCP Hybla Vs. EIC TCP e somatório das duas.......................... 131
Figura 5.11 – Simulação com a versão TCP Westwood+ Vs. EIC TCP e somatório das duas................ 132
Figura 5.12 – Simulação com a versão TCP Veno Vs. EIC TCP e somatório das duas. ......................... 132
Figura 5.13 – Simulação com a versão TCP Low Priority Vs. EIC TCP e somatório das duas............... 133
Figura 5.14 – Simulação com a versão HighSpeed Vs. EIC TCP e somatório das duas.......................... 134
Figura 5.15 – Simulação com a versão Scalable Vs. EIC TCP e somatório das duas.............................. 134
xiv

Lista de Figuras
Figura 5.16 – Simulação com a versão BIC Vs. EIC TCP e somatório das duas......................................135
Figura 5.17 – Simulação com a versão CUBIC Vs. EIC TCP e somatório das duas................................136
Figura 5.18 – Simulação com a versão H-TCP Vs. EIC TCP e somatório das duas.................................136
Figura 5.19 - Simulação com a versão Compound TCP Vs. EIC TCP e somatório das duas...................137
Figura 5.20 – Simulação com a versão EIC TCP VS EIC TCP e somatório das duas..............................138
Figura 5.21 – Simulação na Internet com TCP newReno (25 segmentos e 200 segmentos de média).....139
Figura 5.22 – Simulação na Internet com TCP Vegas (25 e 200 segmentos de média)............................140
Figura 5.23 – Simulação na Internet com TCP Hybla (25 e 200 segmentos de média)...........................140
Figura 5.24 – Simulação na Internet com TCP Westwood+ (25 e 200 segmentos de média). ................141
Figura 5.25 – Simulação na Internet com TCP Veno (25 e 200 segmentos de média).............................141
Figura 5.26 – Simulação na Internet com HighSpeed TCP (25 e 200 segmentos de média)....................142
Figura 5.27 – Simulação na Internet com Scalable TCP (25 e 200 segmentos de média). .......................142
Figura 5.28 - Simulação na Internet com BIC (25 e 200 segmentos de média)........................................143
Figura 5.29 – Simulação na Internet com CUBIC (25 e 200 segmentos de média)..................................144
Figura 5.30 – Simulação na Internet com H-TCP (25 e 200 segmentos de média). .................................144
Figura 5.31 – Simulação na Internet com Compound TCP (25 e 200 segmentos de média)....................145
Figura 5.32 – Futura arquitectura EIC TCP. .............................................................................................146
xv

Lista de Tabelas
Tabela 3.1 – Valores da Window Scale Option.......................................................................................... 56
Tabela 3.2 – Tamanho do segmento que circula numa rede ethernet TCP/IP............................................ 58
Tabela 3.3 – Tabela com valores de tempo de resposta conforme tipo de ligação (Fonte: [62]). .............. 85
Tabela 3.4 – Valores de percentagem de utilização do TCP Tahoe, Reno e newReno.............................. 95
Tabela 4.1 – Especificações de Hardware e SO usado por PC................................................................... 98
Tabela 4.2 – Definição dos Agentes Emissores TCP. .............................................................................. 117
Tabela 4.3 – Definição dos Agentes Receptores TCP.............................................................................. 118
xvi

Lista e Definição de Palavras Chave
Lista e Definição de Palavras Chave
Algoritmo – Um algorimto no âmbito TCP é, geralmente, caracterizado por poucas linhas de código que
alteram de forma muito significativa o desempenho da rede.
Alto Débito, LFN – Termos associados, mas com diferentes significados. Uma LFN pode ser
considerada ser de alto débito, uma ligação de alto débito não deve ser considerada uma LFN. Ao longo
do relatório serão referidas como LFN ligações a partir de 100Mbit/s com elevado atraso. Serão
consideradas de alto débito ligações a partir de 1Gbit/s, independentemente do atraso.
Eficiência, Eficácia, Aproveitamento da Largura de Banda – Todos os termos estão relacionados e
são bastante utilizados ao longo do relatório. Dizem respeito à melhor forma de utilizar a largura de banda
nas redes de dados.
Extremo, Extremo a Extremo – São considerados extremos como entidades emissor e receptor.
Extremo a Extremo diz respeito a uma abstração da ligação que não considera dispositivos intermédio.
Mecanismo – A principal diferença entre um típico algoritmo TCP são muitas linhas de código com o
objectivo de garantir toda a base estável TCP.
Mecanismo Genérico – Mecanismo partilhado por qualquer versão TCP.
Segmento TCP, Pacote TCP – Nas comunidades de investigação surgem os dois termos. Neste relatório
é considerado apenas o termo Segmento TCP, com o obejctivo de diferenciar dos pacotes da camada IP.
Propriedade – Dada por determinado algoritmo ou mecanismo, é especialmente caracterizada por fazer
surgir diversos comportamentos.
Segmentos Enviados, Segmentos Injectados – Neste relatório serão utilizados os termos segmentos
enviados quando já foram notificadas a sua correcta recepção, segmento injectado será utilizado quando
apenas foram transmitidos.
Sliding Window, Window – Por vezes em diversa documentação o mecanismo Sliding Window é
referenciado como a própria janela, neste documento específico optou-se pela distinção.
Taxa de transmissão – A taxa em que os segmentos TCP são enviados. Importante não confundir com
throughput.
Técnica – Da “família” do algoritmo e mecanismo. Caracterizada por poucas linhas de código e pouca
alteração no funcionamento geral do protocolo.
xvii

TCP Genérico, Normal TCP, Vanilla TCP – Todos estes termos se referem à versão Reno TCP com
todos os mecanismos genéricos.
Throughtput – O termo throughtput poder ser utilizado com diversos significado. Ao longo deste
relatório o throughput irá sempre referir a actual carga de tráfego por segundo.
xviii

1. Introdução
1.Introdução
Ao contrário de muitos protocolos que pouco mudaram desde a sua especificação, o TCP (Transmission
Control Protocol) mudou bastante.
O Protocolo TCP foi especificado em 1981, na altura, não foi especificado qualquer algoritmo de
congestão, mas sim especificado a necessidade de um qualquer mecanismo de congestão. Esse
mecanismo que viria salvar a Internet de vários colapsos, apenas foi correctamente implementado em
1988. Na altura, achou-se que o algoritmo estava preparado para grandes larguras de banda, mas,
infelizmente a noção de “grande largura de banda” existente em 1988 é logicamente distorcida
comparando com a actualidade. O algoritmo, actualmente, tem algumas falhas quando funciona nesse tipo
de meios, sendo necessários novos algoritmos de congestão, para que se possa usufruir ao máximo de
toda a banda existente.
O estudo “Experimental Evaluation of TCP Protocols for High-Speed Networks” prova toda esta falta de
eficácia e eficiência na ocupação de largura de banda disponível. Assim sendo, o TCP está de novo
sujeito a nova fase de constantes modificações nos seus algoritmos. Diversas versões surgiram e surgem,
com o principal objectivo de atingir a taxa máxima de largura de banda disponibilizada. Vários conceitos
inovadores surgiram também, todos eles trazendo diversas vantagens e desvantagens.
Esta é provavelmente a fase mais “movimentada” deste protocolo, que vê os seus normais mecanismos
postos em causa devido à falta de eficiência demonstrada. O alto débito veio revolucionar toda a
informação digital e trouxe ao TCP o seu maior desafio.
1

2.Planeamento
2.1. Gestão do âmbito
O Protocolo de comunicações em estudo é um dos protocolos de rede mais estudados. Esse facto verifica-
se tanto pela sua importância, como pelas suas diversas áreas de abrangência. Um grande risco que se
corre quando se estuda este protocolo é divergir desnecessariamente para outros campos de pesquisa. Essa
divergência acontece devido à constante procura de respostas, junto com ambiguidade dos campos de
estudo que estão por vezes bastante interligados. Devido a essa razão, uma correcta planificação do
âmbito é bastante importante, permitindo uma menor distanciação em relação ao principal objecto de
estudo deste projecto.
2.1.1. Descrição do produto e serviços do projecto
O Projecto pretende a criação de um novo algoritmo de controlo de congestão relativo ao protocolo de
comunicações TCP (Transmission Control Protocol). O novo algoritmo deverá ser adaptado a um meio
que disponibiliza larguras de banda de alto débito e elevadas latências. De forma complementar, deverão
efectuar-se testes reais/simulados aos protocolos TCP existentes, bem como à versão de protocolo criada.
Será elaborado em paralelo documentação com explicação teórica dos vários mecanismos TCP, testes
práticos/simulados efectuados e definição da nova versão/algoritmo criado.
2.1.2. Os objectivos do projecto
Os objectivos prendem-se principalmente com a observação de falhas nos protocolos existentes e
posterior inovação na definição de uma nova versão. Dividem-se em três objectivos principais:
• Uma observação detalhada das falhas existentes através de testes práticos nos algoritmos de
congestão do TCP, e abordando, principalmente, as versões que não estão preparadas para redes
de altos débitos e elevadas latências;
2

2. Planeamento
• Um ponto de situação de todas as versões existentes preparadas para alto débito. O objectivo é
verificar o que já foi desenvolvido, de forma a não desenvolver nada anteriormente
implementado, podendo efectuar melhoramentos em alguns conceitos;
A Figura 2.1 representa o esquema de estudo, na tentativa de obter uma nova versão.
Figura 2.1 – Esquema resumido do processo de conhecimento para a nova versão do protocolo.
• Uma nova versão do TCP, em que a posterior implementação acrescentará uma componente de
inovação aos normais mecanismos de congestão do TCP, sendo especificamente preparada para
altos débitos e latências.
A criação desta nova versão é o objectivo mais importante de todo o projecto. O algoritmo de congestão
terá de reunir uma série de condições, para que o objectivo principal deste trabalho seja cumprido da
melhor forma. Algumas condições da nova versão do protocolo são:
• Usar a largura de banda da rede da forma eficiente;
• Minimização do número de retransmissões;
• Maximização da taxa de transmissão efectiva.
3

2.1.3. As entregas
As principais entregas do projecto, na sua maioria, iniciam ou terminam uma fase importante do mesmo.
Algumas fases serão avaliadas frequentemente, outras devido a sua menor complexidade/importância são
avaliadas em menor frequência. Existem também comunicações únicas, igualmente importantes na
medida em que geralmente iniciam tarefas mais demoradas, e bem definidas, podem minimizar o tempo
das diversas tarefas. A forma como as entregas são feitas, na sua maior parte a melhor opção passa por
uma reunião, porém, nas entregas múltiplas e de controlo o envio por e-mail poderá também ser uma boa
opção. Este tipo de decisão deverá ter como base a importância e dificuldades inerentes da entrega. As
entregas encontram-se definidas em Anexo (ver A.1.1).
Os objectivos do projecto também deverão passar por uma concretização a mais correcta possível destas
várias entregas inerentes ao projecto. Se todas elas forem bem efectuadas, automaticamente todos os
objectivos deste projecto deverão ser cumpridos.
2.1.4. Restrições do projecto
Existem dois tipos de restrições a que este projecto está inerente: as restrições do próprio projecto, e as
restrições da nova versão TCP a implementar. As restrições são os principais obstáculos deste projecto.
Restrições do Projecto
• Os testes práticos estão sempre restringidos a qualquer componente de simulação. Simuladores de
atrasos e de perdas serão os mais utilizados. A situação ideal seria utilizar ligações transatlânticas
de alto débito, com os seus conhecidos atrasos e perdas;
• O tempo do projecto é bastante restrito, considerando um tipo de projecto como este (onde se
pretende fazer algo de novo). Esta situação poderá limitar principalmente a implementação,
levando a escolher caminhos mais fáceis e com menor risco;
• A Gestão do tempo do projecto (ver Cap. 2.2) nunca poderá ficar totalmente definida desde
início. Esta situação, deve-se ao problema inicial de existir uma ideia muito pouca madura do que
irá ser a especificação da nova versão do protocolo. Por essa razão, é bastante complicado definir
o tempo de especificação e implementação do mesmo.
4

2. Planeamento
Restrições da nova versão TCP
• O TCP tem resultado bastante bem em termos de perfomance, eficiência global e justiça na
atribuição de recursos porque todos utilizam praticamente as mesmas formas de TCP, com
respostas bastante similares. O protocolo implementado não pode ser radicalmente diferente de
todas as versões já existentes.
• Apesar da nova versão do protocolo estar especificamente ligado a um meio de elevado débito e
latência, ele terá que obrigatoriamente funcionar de forma adequada em todos os outros meios.
• Terá de, necessariamente, existir justiça na atribuição de recursos. Pretende-se utilizar a máxima
largura de banda do canal, mas sempre nos limites da nossa atribuição, e em cooperação com
outros possíveis protocolos a funcionar na camada de transporte.
• O Protocolo original já foi especificado à 17 anos. Torna-se claro que no mundo da tecnologia
este tempo é demasiado. Assim sendo, durante os anos foram feitas diversas correcções ao
especificado, tudo a favor da inovação. Porém, em todos os protocolos já implementados, existe
sempre uma margem limite de distanciação da especificação original. É essa a margem de
distanciação a que estamos restringidos. A mudança no TCP será sempre um balanço entre a
inovação e a precaução pelas características anteriormente especificadas. A Figura 2.2 representa
esta situação.
Figura 2.2 – Intercepção da nova versão com a inovação e a precaução necessárias.
2.1.5. Definição do Âmbito
A definição do âmbito é especialmente importante durante as entregas da fase de estudo e durante a
especificação do novo protocolo. No que diz respeito à implementação, o controlo do âmbito será mais
facilitado devido à existência de uma especificação, que se for correctamente definida, definirá
claramente o caminho e as metas a atingir.
5

2.1.5.1. O Protocolo
O Protocolo TCP tem diversas áreas de estudo. É crucial o rigor em relação a área que o projecto se
insere, sendo que uma expansão demasiada nas restantes áreas deve ser evitada. As áreas de estudo são as
seguintes:
• Transferência de Dados;
• Confiabilidade;
• Controlo de Fluxo;
• Controlo de Congestão;
• Multiplexação;
• Conexões;
• Precedências;
• Segurança;
A principal área onde irá incidir o estudo é o controlo de fluxo e o controlo de congestão. Existe também
uma sub área que também se poderá revelar importante: a transferência dos dados. Informação mais
detalhada sobre o que abrange cada uma das áreas que não se inserem directamente no âmbito deste
projecto poderá ser importante, pois poderá transmitir uma melhor noção acerca do desvio de matéria.
Essa informação poderá ser encontrada principalmente na especificação do protocolo [38]. A Figura 2.3 é
uma representação das áreas em termos de importância para o âmbito.
Figura 2.3 – Representação da matéria que envolve o âmbito.
6

2. Planeamento
Em relação a todas as áreas envolvidas no âmbito, a matéria abordada dividem-se da seguinte forma:
• Transferência de dados
A forma que o TCP gera pacotes na rede. Poderá gerar de forma mais contínua, ou de forma mais
espaçada, conforme a situação que supõe estar a rede.
• Controlo de fluxo
A forma com que o receptor e emissor controlam os dados que vão trocando ao longo da ligação. Este
controlo é conseguido, principalmente, através de um conjunto de mecanismos que interligados entre si
são os responsáveis pela estabilidade da rede.
• Controlo de congestão
Uma área a quem não foi dada a devida importância aquando da especificação do protocolo. Diz respeito
à forma como o emissor consegue evitar, analisar e tratar situações de congestão na rede.
Outra forma que também poder-se-á revelar importante na definição do âmbito de estudo, é a parte
específica de interacções que o TCP tem com outras entidades. Não será considerada qualquer tipo de
aplicação específica, para além de um normal gerador de tráfego. De igual forma, não será dado ênfase a
outras camadas, nomeadamente o IP (Internet Protocol), que por diversas vezes surge ligado ao TCP. A
Figura 2.4 exemplifica o foco do âmbito no protocolo TCP, bem como as áreas referidas anteriormente.
Figura 2.4 – Representação do âmbito, considerando as várias interfaces do TCP.
2.1.5.2. O controlo de congestão
Pormenorizando mais a definição, na parte específica do controlo de congestão existe diversas áreas de
abordagem divididas principalmente, entre tipo de reacção à congestão e o tipo de controlo.
O tipo de reacção divide-se entre o controlo de congestão e prevenção de congestão. Ambos os tipos são
extremamente importantes ao âmbito deste trabalho, não fazendo sentido cuidar da congestão de rede sem
ter a preocupação de evitá-la.
7

No que diz respeito ao controlo, ele divide-se em controlo implícito e controlo explícito. O controlo
implícito implica uma adivinhação da existência de congestão na rede. No controlo explícito existe uma
notificação ao emissor, por parte do dispositivo congestionado. O controlo explícito é uma área pouco
influente no âmbito. A Figura 2.5 representa a divisão das áreas existentes na congestão, bem como os
níveis de importância associados a este projecto.
Figura 2.5 – Representação dos tipos de reacção e controlo.
O facto de a nova versão pretender ser compatível para qualquer possível receptor e dispositivo de rede,
sem que qualquer tipo de modificação necessite de ser efectuada nos mesmos, é a razão principal para a
pouca importância dada ao controlo explícito. A Figura 2.6 demonstra a localização do tipo de controlo
inserido no âmbito deste projecto.
Figura 2.6 – Localização do âmbito através de uma comunicação entre emissor, receptor e rede.
2.1.6. O Software
O Software irá ser utilizado na parte de testes e em toda a parte de implementação. Na fase de testes
inicial, irá ser utilizado o sistema operativo Linux na sua distribuição Kubuntu [87](versão mais recente
8

2. Planeamento
estável). Irão também ser utilizadas as aplicações necessárias para geração e monitorização de tráfego da
plataforma Linux, bem como aplicações com intuito estatístico e geradores de atraso. As aplicações que
serão utilizadas durante os testes serão: Xgraph [88], Gnuplot [89], Tcpdump [90], Iperf [91], Dummynet
[92], Netem [93], Trpr [94].
No caso da implementação irá ser utilizado software de simulação, mais propriamente o NS2 [103]
(Network Simulator, versão mais recente estável) para sistema operativo Linux. Poderão também ser
necessárias aplicações para criação de estatísticas geradas por este simulador. Essas aplicações poderão
ser o Xgraph ou o Gnuplot, já utilizados anteriormente.
2.1.7. O Hardware
O Hardware especificamente necessário neste projecto será 3 computadores pessoais com placas de rede
que suportem velocidades de 1Gbps. Adicionalmente será usado um switch de monitores. Este hardware
apenas é necessário para a fase inicial de testes. O caso ideal não é minimamente possível de realizar,
pelo que grande parte dos testes irão recorrer a simulações.
2.1.7.1. A Documentação
Num trabalho de investigação, toda a fase de documentação assume um carácter extra de importância,
i.e., todo o estudo efectuado deve ser correctamente estruturado e descrito em relatório, sob pena de toda
a parte prática de testes não ter a base teórica necessária ao leitor, que, ao contrário dos participantes do
projecto, não esteve presente em toda a investigação. Outra forma de abordar a importância da
documentação neste tipo de projectos, é o facto de um dos seus objectivos ser servir de referência a novos
projectos de investigação da mesma área.
No que diz respeito a toda a parte prática, os caminhos até chegar aos diversos cenários e testes devem ser
documentados, também com o propósito de poder servir de referência a projectos de características
semelhantes.
Os documentos devem também conter referências a diversas fontes informativas, com o intuito de
direccionar quem necessite de abordar um assunto específico mais detalhadamente. Estando o projecto
directamente ligado com a Internet, assim estarão as suas referências principais.
9

2.1.7.2. Organograma técnico
Figura 2.7 – Representação do WBS.
A descrição dos pacotes de trabalho do WBS (Work Breakdown Structure) encontra-se em Anexo (ver
A.1.2)
2.2. Gestão de Tempo
A Gestão de tempo num projecto de investigação é talvez o tipo de gestão mais difícil de definir. As
dificuldades prendem-se principalmente com a definição do tempo de estudo e definição do tempo de
implementação da nova versão. Provavelmente, o tempo de implementação terá de ser redefinido aquando
da especificação da mesma; nessa altura será mais clara a correcta noção do que será implementado. Em
relação ao problema do estudo será sempre um risco inerente.
As actividades deste projecto são em tempo e tipo bastante diversificadas. Existem actividades que podem
funcionar em regime de paralelismo com outra actividade, outras que são absolutamente necessárias a
todo o posterior desenvolvimento do projecto e outras que se não conseguirem ser cumpridas
correctamente, não alteram em muito toda a boa concretização do projecto.
A Sequência das actividades começa com todo o planeamento de actividades inerentes ao projecto.
Seguidamente existirá uma fase de estudo, bem como uma fase de testes práticos. No final a especificação
e implementação da nova versão.
Na estimativa da duração das actividades representada na Figura 2.8 houve alguns factores a ter
em conta:
• O prazo limite imposto para o projecto;
• Os recursos disponíveis;
• A experiência e número dos recursos humanos.
10

2. Planeamento
Figura 2.8 – Gráfico de Gantt, representativo da sequência e relacionamento entre actividade.
11

3.Enquadramento ao Protocolo
Como já foi referido anteriormente (ver Cap. 2.1), o protocolo TCP tem diversas áreas de estudo que se
dividem por toda a comunidade de investigação. A principal área de estudo abordada neste projecto teve
um desenvolvimento que originou diversos algoritmos próprios, mas continua a utilizar os mecanismos
essenciais do TCP genérico, para todo o correcto funcionamento do protocolo.
No que diz respeito aos diversos mecanismos de funcionamento, uma correcta explicação de todo o
estudo é essencial para os objectivos posteriores de testes e implementações, pois será a base de toda a
análise. O tipo de funcionamento poderá ser genérico, ou específico ao meio de transmissão de alto
débito.
Neste enquadramento, irão ser analisadas as razões que levaram às modificações do protocolo para que se
verificasse um melhor desempenho; primeiro considerando um meio genérico de transmissão; depois a
verificação de falta de eficiência em certos meios, desenvolvendo soluções; finalmente o meio de alto
débito. Irá também ser analisada toda a evolução no que diz respeito aos desenvolvimentos TCP por parte
de entidades e pessoas.
3.1. Necessidade e Motivação
Num mundo onde a capacidade das infra-estruturas de rede e a sua complexidade estão relacionadas
directamente com o débito na rede, e paralelamente, a entrega dos dados relacionada com o lucro
proporcionado pela infra-estrutura; o TCP assume um papel de importância crítica [9]. Essa importância
crítica, resulta do facto do protocolo ser o responsável pelo transporte fiável e eficiente dos dados. Assim
sendo, quanto melhor for a implementação do protocolo, melhor será a forma de entrega dos dados, e
consequentemente maior será a poupança de custos. Uma representação do tipo de interacções existentes
entre complexidade/capacidade da rede, o seu débito, e posterior entrega dos dados e lucro é representada
na Figura 3.1.
12

3. Enquadramento ao Protocolo
Figura 3.1 – Esquema representativo da relação entre o TCP e os custos económicos.
Todos os protocolos de rede estiveram atentos a toda a evolução das redes dados, e todos tiveram e
continuam a ter como objectivo principal a satisfação de qualquer necessidade proveniente quer dos
utilizadores, quer das próprias redes. O Protocolo TCP não foge à regra, e a lista actual de necessidades
deste protocolo é agora bastante vasta, sendo a necessidade de adaptação a ligações de alto débito apenas
uma delas. As necessidades surgiram através da verificação de diversos problemas no protocolo. Esses
problemas estão associados, na sua maioria, aos pressupostos assumidos pelas versões iniciais (ver Cap.
3.1.1).
3.1.1. Lista de pressupostos
Surgiram diversos problemas devido aos pressupostos das versões genéricas do TCP, alguns deles são:
• O meio é sempre uma rede de cabos, nunca uma rede wireless;
Os sistemas wireless têm uma taxa de erros elevada proporcionada pelo próprio meio físico. O TCP
assume que na sua grande maioria essa perca se deve a congestão na rede e não a erros do meio, tal como
acontece em redes com cabos.
• Existe sempre só um melhor caminho para chegar ao destino;
O TCP considera que a reordenação dos pacotes é bastante minoritária comparada com os variados
acontecimentos na rede. Devido a esse facto relega a escolha de melhor caminho para camadas abaixo.
Quando existe reordenação dos segmentos, os caminhos seleccionados serão o caminho dos antigos
segmentos, porém esse poderá na ocasião não ser o melhor.
• A largura de banda de uma determinada rede nunca tem oscilações;
13

O controlo de congestão é feito também através da análise dos atrasos, se existir oscilações rápidas na
largura de banda o atraso aumenta e o TCP torna-se bastante conservativo, principalmente, no que diz
respeito a injecção de pacotes na rede.
• A largura de banda de uma determinada rede é igual nos seus dois sentidos;
O emissor tem de guardar uma cópia do segmento enviado na rede, até que o receptor o notifique que o
recebeu. Se a largura de banda for bastante menor para enviar notificação, o tempo que a cópia fica no
emissor aumenta bastante, apesar de o receptor já ter recebido o segmento.
• Os buffers dos dispositivos da rede são sempre FIFO1
(Firt In First Out);
São assumidas algumas arquitecturas sobre os dispositivos de rede, para outras arquitecturas a eficiência
poderá não ser a mesma
• Existe um determinado padrão sobre o tipo de aplicação;
São assumidas também algumas considerações sobre a natureza das aplicações. O TCP considera que
uma aplicação irá usar uma sessão por um determinado tempo, existindo diversos envios de segmentos só
para estabelecimento de parâmetros, que provavelmente a aplicação nem irá usar.
• Os outros fluxos existentes na rede são sempre sessões TCP;
O protocolo foi apenas preparado para interagir com sessões paralelas dele próprio, se tiver em paralelo
outros protocolos, que também tenham mecanismos de controlo de fluxo, a situação poderá ser
problemática na atribuição de recursos.
• Foram assumidas redes com largura de banda de banda de aproximadamente 10Mbit/s e baixos
níveis de latência;
A eficiência na ocupação da largura de banda é aceitável, ainda, para larguras de banda na ordem dos
100Mbit/s. Porém chegando a larguras de banda aproximadas do 1Gbit/s, existe um decréscimo
preocupante na eficiência, que vai piorando à medida que a largura de banda aumenta. Em largas
distâncias, as velocidades usadas são de níveis bastante altos, assim como os níveis da latência. É nesse
tipo de ligações que os problemas se verificam mais críticos.
3.1.2. As redes de alto débito
Os problemas que se desencadearam pelo último pressuposto referenciado no capítulo acima são,
provavelmente, os maiores alvos actuais de toda a comunidade de investigação ligada ao TCP. Procuram-
1
Tipo de fila onde o primeiro segmento a entrar é o primeiro segmento a sair.
14

se assim, variadas formas de os eliminar ou minimizar. Este tipo de problemas vai ser focado em todo
este relatório.
A razão do interesse é óbvia: as larguras de banda utilizadas actualmente são de um índice completamente
diferente, comparando com as larguras de banda utilizada na criação dos normais algoritmos de congestão
(Cap. 3.5). Assim sendo, de que vale ter meios de transmissão bastante rápidos, se não existe quem os
consiga utilizar da melhor forma? Este tipo de perguntas foi o principal incentivo à investigação
desenvolvida sobre o protocolo TCP em meios de alto débito.
O limite da largura de banda existente tem vindo a subir de forma cada vez mais abrupta. As razões são
muitas: aumento da procura dos consumidores, aumento dos consumidores, mudança de conteúdos na
Internet, mais comunidades de investigação, etc. Na Figura 3.2 poderá verificar-se a azul o crescimento
verificado e esperado no que diz respeito aos limites máximos de largura de banda; a linha vermelha
corrige para o que se verificou na actualidade mais recente. Através da análise da Figura chegou-se
também a diversas conclusões:
• A largura de banda teve uma fase estática no seu crescimento, de 1980 a 1990. Essa fase deve-se
à prioridade dada a outros parâmetros, para que a criação de uma rede global de computadores
pudesse ser criada e mantida (Internet). Os principais parâmetros foram especificados no
protocolo TCP em 1981 [38];
• A largura de banda inicia o seu crescimento por volta do ano 1990, muito devido à chegada do
Cabo UTP. Os parâmetros para uma rede global estavam estabelecidos, procurava-se agora maior
adesão;
• Em 1995 surge o cabo UTP com capacidade para 100Mbit/s. As velocidades de fibra óptica
acompanhavam as do cabo, mas permitiam maiores distâncias, sendo por isso utilizadas no
backbone da Internet. A Internet é um sucesso, assim como as redes locais;
• A partir de 1995 o crescimento torna-se ainda mais exponencial, sendo alcançadas em 1998
velocidades de 1Gbit/s, tanto por parte do cabo UTP, como da fibra óptica. A velocidade de
1Gbit/s é um ponto crucial para o TCP, pois é a partir desta largura de banda que se começaram a
verificar os variados problemas;
• O crescimento continua passando pelos 10Gbit/s em 1999 [65], chegando a 100Gbit/s em 2005.
Porém estes valores só foram conseguidos através de fibra óptica. Verificam-se neste caso, cada
vez mais, uma perda de eficiência por parte do TCP;
• Esperava-se que por volta de 2010 se atingisse velocidades de 1Tbit/s, porém um recente recorde
de 14Tbit/s foi conseguido [66]. Espera-se então um grande desafio ao TCP.
15

Figura 3.2 – Crescimento da largura de banda disponibilizada (Fonte: [67]).
Por outro lado, no que diz respeito à largura de banda disponibilizada ao utilizador final, esta tem seguido
quase à regra a lei de Nielsen2
. Utilizando essa mesma regra, e considerando 4Mbit/s (velocidade média
de Internet disponibilizada actualmente ao normal utilizador), estima-se que apenas por volta do ano 2019
a barreira do 1Gbit/s será ultrapassada.
Desta forma, a preocupação com a eficiência do TCP em meios de altos débitos para os utilizadores finais
não é prioritária. A preocupação é totalmente direccionada para as ligações de todo o backbone da
Internet e ligações WAN, principalmente as ligações entre continentes, devido à sua elevada latência. Este
tipo de redes é conhecido como LFN (Long Fat Networks).
Na Figura 3.3 estão dispostas as diversas ligações entre continentes. Essas ligações são as que se sujeitam
mais aos diversos problemas do TCP, considerando as suas versões mais genéricas. Estas ligações variam
na sua maioria de 10Gbit/s a 500Gbit/s, existindo algumas ligações que poderão ultrapassar o limite de
500Gbit/s. As suas latências, geralmente, estão relacionadas com a distância, porém, o próprio meio físico
poderá também estar relacionado. A maioria de todas estas ligações é transatlântica, existindo um número
também significativo na ligação entre a América do Norte e o Japão. O protocolo de transporte utilizado
nestas redes é o TCP em, aproximadamente, 90% das ligações estabelecidas.
2
A Lei de Nielsen é bastante similar à mais popular lei de Moore, a lei defende que considerando o utilizador final, a largura de
banda disponibilizada cresce 50% a cada ano.
16

Figura 3.3 – Mapa representativo das diversas ligações de alto débito entre continentes (Fonte: Telegeography Research).
Estas ligações servem para disponibilizar largura de banda pelos diversos continentes, pelo que quanto
maior a velocidade e a eficiência destas ligações, maior poderá ser a velocidade disponibilizada ao
utilizador final. O utilizador final é assim também afectado, então, pelos problemas do TCP. A Figura 3.4
não é difícil de adivinhar, tendo sido analisada a Figura 3.3, sendo o principal tráfego dividido entre
América do Norte, Europa e Japão.
Figura 3.4 – Mapa representativo de toda a disponibilização de largura de banda para Internet nos diversos continentes (Fonte:
Telegeography Research).
A largura de banda disponibilizada para os diversos continentes é assim bastante diversificado. Essa
diversificação pode ser analisada com maior detalhe na Figura 3.5. Nas ligações transatlânticas verifica-se
uma disponibilização de cerca de 3.0Tbit/s; o dobro da disponibilização entre América e Ásia, que usufrui
de cerca de 1.5Tbit/s. Os valores intra Ásia, e entre Estados Unidos e América do Sul são extremamente
próximos, não chegando a velocidades de 1Tbit/s.
17

Figura 3.5 – Relação ano, largura de banda teórica disponibilizada e ligações intercontinentais (Fonte: Telegeography Research).
Apesar de toda esta disponibilização, o tráfego usado nas diversas ligações é bem diferente do que o que
poderia ser proporcionado por elas. Essa situação pode facilmente ser analisada na Figura 3.6. Os valores
dos diversos tráfegos são extremamente baixos, considerando a quantidade de suporte da própria ligação.
O valor de 3.5Tbit/s para a ligação transatlântica é aproveitado numa média de 668,757 Mbit/s, o que
significa cerca de 20% do poder de disponibilização. O aproveitamento melhora, substancialmente, nas
menores larguras de banda, disponibilizadas pelas outras ligações intercontinentais.
Figura 3.6 – Tráfego médio, gerado pelas diversas ligações intercontinentais (Fonte: Telegeography Research).
Existem duas razões principais para esta falta de aproveitamento da largura de banda disponibilizada:
• Razões económicas e de mercado;
18

Planeamentos de grande procura de largura de banda no futuro e lucro a longo prazo, considerando a
implementação do meio físico apenas numa fase, etc.
• Mecanismos de controlo de congestão, falhas de eficiência a nível do protocolo de transporte, o
TCP.
As razões económicas e de mercado são as maiores responsáveis pela queda acentuada entre tráfego
utilizado e largura de banda disponibilizada. Apesar desse facto, o TCP não está isento de
responsabilidades. O TCP demora bastante a atingir a capacidade máxima da rede, e quando a adquire
existem problemas na sua manutenção (ver Cap. 3.6.1). As redes intercontinentais actuais são, na sua
maioria, construídas usando diversas ligações LFN com routers de alta capacidade. O TCP actual tem de
estar preparado para este tipo de cenário.
As necessidades e motivações aos melhoramentos no protocolo TCP são diversificadas, tais como os seus
variados problemas. Mesmo com todas as limitações, o TCP comportasse até bastante bem na maioria dos
ambientes de rede [9]. Porém, melhorá-lo especificamente para ligações de alto débito poderá trazer
diversas vantagens. Vantagens no campo económico, benefícios ao utilizador doméstico e,
principalmente, o aproveitamento da tecnologia que hoje dispõe são algumas delas.
3.2. O Desenvolvimento
Ao longo do tempo o TCP foi evoluindo de diversas formas, até se tornar no protocolo consistente e
eficaz que hoje é. Como qualquer protocolo, a sua fase inicial diz respeito a todos os mecanismos básicos,
existindo nas fases posteriores um esforço para a sua estabilização e a adição de diversos melhoramentos.
Foram efectuadas diversas melhorias e desenvolvidas várias implementações para aumentar o seu
desempenho, particularmente no caso da rede estar congestionada. O TCP não é desenhado para
funcionar em qualquer tipo de velocidade particular, mas tem o objectivo de usar a banda que lhe
pertence da forma mais eficiente. Essa eficiência foi sempre um ponto crucial, desde a sua especificação
às suas variadas implementações e versões. A Figura 3.7 efectua uma comparação entre a escala temporal
e a largura de banda máxima disponibilizada, representando todos os grandes acontecimentos que
sucederam a este protocolo, com especial ênfase no controlo de congestão do mesmo.
19

Figura 3.7 – Timeline de desenvolvimento TCP.
Todo o teor dos acontecimentos, irá ser explicado ao longo do relatório. Cada acontecimento teve a sua
própria importância, e todos têm em comum o protocolo TCP, divergindo no objectivo. Diversos
parâmetros são necessários para a estabilização e aderência a um protocolo global, e cada acontecimento
foi responsável pela adição de um deles.
20

O desenvolvimento foi dividido em três ciclos, bastante fáceis de distinguir devido à divergência de
objectivos.
1ºCiclo – A Especificação
O ciclo inicial que representa todo o nascimento deste protocolo. As primeiras necessidades para a
criação do protocolo, todas as noções teóricas iniciais, os mecanismos básicos para funcionamento
prático, a primeira implementação num sistema operativo, o primeiro algoritmo com o objectivo de
melhorar a eficiência; todos estes são acontecimentos da fase mais imatura deste protocolo.
2º Ciclo – A Congestão
O acontecimento que marca a passagem do 1º para o 2ºciclo é a observação dos colapsos existentes nas
redes de computadores, devido à existência um deficiente controlo de congestão. Foi o 1º grande desafio a
este protocolo. A partir do desenvolvimento do primeiro algoritmo de controlo de congestão, verificou-se
a importância extrema deste tipo de controlo, para toda a eficiência do protocolo. Foram ainda efectuados
ainda outros melhoramentos como o ECN [49] ou o Sack [43].
3ºCiclo – A Congestão em alto débito
Ao contrário do que se passou na passagem do 1º para o 2ºciclo, não existe um acontecimento marcante.
O 3ºciclo começa quando a largura de banda disponibilizada assume valores, aos quais os normais
algoritmos de controlo de congestão e outros mecanismos, não se conseguem adaptar devidamente.
Verifica-se novamente uma perda de eficiência e um novo desafio ao TCP, criando a comunidade de
investigação diversas modificações ao protocolo, com vista a melhorar o seu desempenho em redes de
alto débito.
3.2.1. Entidades e Pessoas
O TCP em todo o seu desenvolvimento esteve ligado a diversas entidades e diversas pessoas. Tal como
qualquer outro protocolo de redes, a entidade principal no que diz respeito à obtenção de standards é o
IETF. Por outro lado, existe um conjunto de entidades e pessoas que são responsáveis pela “alimentação”
de ideias ao IETF, sendo sempre esta a entidade que monitoriza a coerência e efectua a aprovação das
mesmas.
As versões e alguns mecanismos do TCP, ao contrário de muitas modificações em outros protocolos,
estão muito associadas às pessoas responsáveis pelo seu desenvolvimento. Esse facto acontece devido ao
21

grande esforço individual, desenvolvido pelas mesmas na sua modificação ao protocolo. Um bom
exemplo é o nome dos diversos algoritmos utilizados pelo TCP (ver Cap. 3.3.3).
O esforço dispendido divide-se principalmente em três componentes, que estão também bastante
relacionados com os ciclos de desenvolvimento (ver Cap. 3.2):
• Melhoramentos nos mecanismos genéricos;
• Melhoramentos no controlo de congestão;
• Melhoramentos no controlo de congestão para alto débito.
3.2.1.1. Mecanismos genéricos
Os mecanismos genéricos foram especificados principalmente dentro dos próprios grupo de trabalho da
IETF, sendo ainda hoje esta entidade, a principal responsável pelos melhoramentos e adições deste tipo de
mecanismos. Os dois grupos da IETF relacionados com o TCP actualmente são: TCP Maintenance and
Minor Extensions [68] e Transport Area Working Group [69]. Estes dois grupos são bastante recentes
(2004 e 2001), pelo que na fase inicial do TCP, o grupo responsável por este tipo de mecanismos foi o
Networking Workgroup. Este grupo que na altura incluía tudo o que dizia respeito a redes de
computadores.
O Grupo TCP Maintenance and Minor Extensions é, actualmente, o grupo responsável pelo tipo de
mecanismos genéricos do TCP. É um grupo específico ao protocolo TCP que diz respeito ao
desenvolvimento do que se tratam como pequenos melhoramentos ao protocolo. Para modificações de
maior nível ao protocolo, existe o Transport Area Working Group. Por vezes a dimensão do
melhoramento pode tornar-se complicada de analisar, por essa mesma razão os dois grupos cooperam
bastante entre si, de forma a controlarem os seus âmbitos e objectivos.
A adição ou melhoramento de algum mecanismo genérico, não transforma o TCP numa nova versão, i.e.,
considera-se uma nova versão quando se verifica a existência de melhoramentos ou adições na parte do
algoritmo de congestão AIMD, Slow Start, Fast Recovery, etc. (ver Cap. 3.5). Assim sendo, considera-se
então uma nova versão, quando existe uma modificação significativa na forma de funcionamento do
protocolo, logo os mecanismos/algoritmos de congestão, elaborados pelo IETF e propostos ao IETF,
fazem na sua grande maioria, parte do Transport Area Working Group.
O desenvolvimento de mecanismos genéricos funciona, ainda, em paralelo com todos os melhoramentos
que dizem respeito à congestão, apesar de se ter verificado mais activo no 1ºciclo (especificação do
protocolo) de desenvolvimento.
22

3.2.1.2. Melhoramentos controlo de congestão
Em relação ao desenvolvimento dos mecanismos de controlo de congestão, de forma curiosa ele começou
de uma forma quase local, sendo ainda hoje visíveis esses traços no nome das diversas versões (TCP
Tahoe, TCP Reno, TCP newReno, TCP Vegas). A Figura 3.8 demonstra em melhor detalhe a analogia
entre as versões e a região do Nevada.
Figura 3.8 – Representação da analogia entre uma região e as versões TCP.
Apesar deste relacionamento da Figura, as versões não foram desenvolvidas nas cidades que lhes deram o
nome, mas sim em universidades dos estados vizinhos.
No que diz respeito às versões de alto débito, já não se verifica de forma tão acentuada este tipo de
analogia. Esse facto pode estar relacionado com a total globalização da Internet, ou poderá apenas ser
uma mera opção dos criadores, de forma a relacionar o título com o funcionamento da sua versão. No
desenvolvimento dos mecanismos/algoritmos de congestão começaram a surgir diversas pessoas e
instituições com trabalho paralelo ao IETF que desenvolveram diversos princípios, ainda hoje
especificados em qualquer implementação TCP. Algumas dessas pessoas e instituições foram:
• Van Jacobson
Van Jacobson é principalmente conhecido por ter sido aquele que evitou o colapso da Internet em 1988,
devido, principalmente, aos algoritmos de congestão por si especificados e implementados. Dele surgiram
as primeiras versões deste protocolo: TCP Tahoe (ver Cap. 3.5.1) e TCP Reno (ver Cap. 3.5.2), assim
como os diversos algoritmos associados às versões. A sua versão TCP Reno é hoje considerada a versão
23

mais genérica de qualquer implementação TCP, i.e., quando se fala em TCP, normalmente refere-se ao
TCP na sua versão Reno. Para além de ser a versão mais conhecida do TCP, é também a que serve de
base à maioria de todas as outras, principalmente as versões de alto débito (Cap. 3.6).
Para além da extrema importância dos algoritmos desenvolvidos, Van Jacobson deu o primeiro passo para
um largo conjunto de versões e algoritmos específicos para os problemas de congestão de rede. As
comunidades de investigação repararam na extrema importância do problema congestão, e o que ela
implicava na estabilidade e eficiência da Internet. Essa estabilidade e eficiência, proporcionada pelos
diversos melhoramentos feitos vieram impulsionar imenso todo o estudo sobre o TCP.
Van Jacobson contribuiu ainda para diversos mecanismos genéricos do TCP e diversos analisadores de
rede. Na altura do desenvolvimento do TCP Tahoe e Reno, Jabobson investigava no Lawrence Berkeley
Laboratory [70] da Universidade da California, tendo sido contratado com o objectivo urgente de resolver
os colapsos da Internet devido a situações congestão.
Actualmente é investigador na PARC (Paco Alto Research Center) [71]. Recebeu diversos prémios
devido à importância de todo o seu desenvolvimento, entre eles, o ACM SIGCOMM Award 2001e o Koji
Kobayashi Computers and Communications Award por parte da IEEE.
Mais informação: ver http://en.wikipedia.org/wiki/Van_Jacobson
• Lawrence Brakmo
Após o impulso dado pelo TCP Reno ao controlo de congestão, Brakmo especificou e implementou um
algoritmo com o mesmo objectivo do Reno, mas com um funcionamento totalmente diferente. À versão
implementada foi dado o nome de TCP Vegas (ver Cap. 3.5.4), devido principalmente às divergências de
características com o Reno (Vegas é a concorrente do Reno, no que diz respeito à maior cidade de
entretenimento do estado do Nevada, EUA). As versões do TCP para alto débito são sempre baseadas ou
no Reno, ou no Vegas, pelo que a importância da versão de Brakmo passa principalmente pela adição de
uma alternativa aos algoritmos do Reno.
Brakmo investigava no Laboratory of Computer Science da Universidade do Arizona na altura do
desenvolvimento da sua versão.
Mais informação: ver http://www.brakmo.org/lawrence/
24

• Janey Hoe
Janey Hoe foi a responsável por um melhoramento do protocolo TCP na sua versão Reno. O
melhoramento foi de tal forma importante que modificou o nome da versão, sendo a versão com o
melhoramento efectuado chamada de newReno. A versão newReno encerrou um ciclo de melhoramentos
relacionados com o controlo de congestão, sendo que a sua versão (a mais comum, ver Cap. 3.7),
funciona, apesar das suas limitações, bastante bem na maioria dos meios.
Por vezes nas implementações, não existe distinção entre a versão Reno e newReno, sendo apenas
apresentada a versão Reno, que na realidade é newReno. Hoe investigava no Laboratory for Computer
Science do MIT (Massachutetts Institute of Technology), quando desenvolveu a versão newReno.
Depois do newReno, não é conhecido qualquer desenvolvimento no protocolo TCP por parte de Janey
Hoe. Terminou assim, tanto uma fase de desenvolvimento TCP na área da congestão, como o seu próprio
contributo ao protocolo.
Como já foi referido acima, as versões do protocolo ganham por vezes um carácter muito pessoal. De tal
forma acontece essa situação, que na fase inicial quando apenas a ideia estava especificada, se referia às
versões do TCP como a versão do Jacobson, a versão de Brakmo, ou a versão do Hoe. Apesar desta
situação, existia obviamente um grupo de trabalho mais vasto a trabalhar nas diversas versões. A
importância da própria universidade ao direccionar muita da sua investigação para à área de congestão do
TCP, também não deve ser desvalorizada.
Uma entidade também bastante importante, principalmente no que diz respeito a troca de ideias no meio
académico foi a ACM (Association for Computing Machinery).
ACM/SIGCOMM
Fundado em 1947, teve um papel preponderante na área das telecomunicações, funcionando variadas
vezes quase em regime competitivo com o IEEE (Institute of Electrical & Electronics Engineers) [72].
Apesar da competitividade, as direcções tomadas eram bastante diferentes. O IEEE baseava-se
principalmente na parte da elaboração de standards e hardware; abordando a ACM a parte mais teórica
25

das redes de telecomunicações, e as relações específicas entre utilizadores e rede. A ACM tinha também
melhor definido o seu principal objectivo: a inovação.
Analisado o âmbito da ACM, não é complicado adivinhar que os algoritmos de congestão do TCP seriam
abordados. Em 1969 foi criado o SIGCOMM dedicada exclusivamente às redes de comunicação. Os SIGs
(Special Interest Groups) [73] são grupos de estudo específico que incluem diversos grupos de
investigação académicos, e que têm associados a distribuição de jornais e conferências sobre a matéria em
questão. O jornal saiu pela primeira vez em 1970, tendo sido organizada a primeira conferência
SIGCOMM em 1986. A conferência anual da SIGCOMM atraiu os melhores artigos e debates sobre rede
de computadores, abordando tanto a parte teórica, como diversos testes práticos.
Alguns desses artigos e debates revelaram-se completamente revolucionários e marcantes. Sendo 1986 (o
mesmo ano da primeira SIGCOMM), o ano em que se começam a verificar os primeiros colapsos na rede
devido a congestão, o TCP teve nas diversas SIGCOMMs, artigos e debates de extrema importância. A
título de exemplo o TCP na sua versão Tahoe foi apresentado na SIGCOMM88, o Reno na
SIGCOMM99, o TCP Vegas na SIGCOMM94 e o TCP newReno na SIGCOMM96 [74]. A SIGCOMM
ainda existe actualmente, mas ao contrário do que aconteceu nas conferências passadas já não é
apresentada investigação absolutamente inovadora, tendo sido o seu prestígio afectado.
Mais informações: ver http://www.acm.org e http:// www.sigcomm.org
3.2.1.3. Melhoramentos controlo de congestão para alto débito
O 2ºCiclo no desenvolvimento do controlo de congestão é marcado pela série de versões do protocolo
TCP na tentativa de o adaptar a diversos meios específicos, principalmente os meios de alto débito. A
abordagem para aumentar a eficiência do TCP foi-se multiplicando pelas comunidades de investigação,
existindo agora métodos implícitos e explícitos (ver Cap. 2.1.5.2) para controlo de congestão que se
foram desenvolvendo após a fase Reno. Existe também um conhecimento bem mais vasto sobre o TCP e
o seu controlo de congestão, o que não se verificava na altura do Reno. Devido a esse conhecimento
formou-se um núcleo bem mais completo na investigação, implementação e documentação de tudo o que
é controlo de congestão. O desafio para o TCP usando banda larga nunca foi tão grande, mas a
comunidade de investigação também nunca esteve tão bem preparada, não existindo maior prova do que a
quantidade de versões existentes.
Novas comunidades deram origem a algumas novas instituições, com pessoas que se notabilizaram pela
eficiência das suas versões e seu empenho no desenvolvimento específico para alto débito.
26

• ICIR
Em 1999 foi formado o ICIR (Internet Center for Internet Research), pertencente ao ICSI (International
Computer Science Institute) [75]. O ICSI é afiliado com a Universidade da Califórnia, que como foi
referido (ver Cap. 3.2.1.2), tem grande história na investigação sobre controlo de congestão no TCP.
Além disso, surgiu exactamente na altura dessa investigação (1988, TCP Tahoe), muito devido às
limitações dos ambientes de investigação académicos proporcionados pelos laboratórios da universidade.
O ICSI continua a ser uma instituição sem fins lucrativos, mas é bastante mais ligado ao mundo
empresarial e a todo o resto do globo. O ICIR é um grupo de trabalho do ICSI completamente
direccionado para a estabilidade das redes e Internet. Existindo no controlo de congestão uma relação
directa com toda a estabilidade das redes, este grupo foca-se essencialmente neste tipo de controlo.
Mais informações: ver http://www.icir.org/
• Sally Floyd
Sally ingressou no ICIR aquando da criação da entidade. A quantidade de projectos em que se envolveu e
está envolvida é imensa, sendo a principal impulsionadora do desenvolvimento do controlo de congestão
para alto débito e elevadas latências. A sua versão HighSpeed TCP (ver Cap. 3.6.2) é a versão específica
para alto débito mais amadurecida, considerando implementação e testes práticos reais; sendo a versão
mais próxima de se tornar standard para alto débito. Apesar da importância da sua versão, é também a
responsável por mecanismos de congestão explícitos (ver Cap. 2.1.5.2), tais como o QuickStart [54] e o
ECN [49], ou ainda mecanismos de controlo de filas como o RED (Random Early Detection) [76].
A preocupação no desenvolvimento de aplicações simuladoras de variados ambientes de rede é também
uma constante, estando envolvida em diversos projectos do tipo com vista a facilitar cada vez mais
desenvolvimentos na área.
Elaborou diversas RFCs da IETF, mesmo antes de entrar no ICIR, uma delas foi toda a especificação [52]
do algoritmo de congestão de Janey Hoe. Sally continua a investigar no ICIR, sendo a sua página pessoal
um bom ponto de partida para qualquer investigação na área de congestão do TCP para alto débito.
Mais informações: http://www.icir.org/floyd
27

• PFLDnet
A importância que a PFLDnet (Protocols for fast long distance networks) tem em relação aos
melhoramentos no controlo de congestão para alto débito é muito similar à importância da SIGCOMM
para os normais algoritmos de congestão.
A PFLDnet nasce por diversos motivos: perda de prestígio por parte da SIGCOMM, necessidade de
conferências mais especializadas, a imensa investigação sobre redes de alto débito e seus protocolos.
Devido a todas essas razões, em 2003 surge a primeira conferência, dando origem a apresentações e
debates sobre a globalidade dos assuntos deste tipo de redes. Obviamente os protocolos de transporte
específicos para alto débito foram o assunto principal. Os pontos de destaque em relação ao controlo de
congestão, considerando todas as conferências até agora realizadas, foram:
PFLDnet2003 – HighSpeed TCP (ver Cap. 3.6.2); QuickStart; DCCP (Datagram Congestion Control
Protocol, ver RFC 4340); Scalable TCP (ver Cap. 3.6.3); testes de prova da falta de eficiência; buffers e
sistemas operativos. [77]
PFLDnet2004 – Ponto de situação após primeira PFLDnet; Normalização dos testes; LCA (Loss-Based
Congestion Avoidance) VS DCA (Delay-Based Congestion Avoidance) (ver Cap. 3.5.6); HighSpeed TCP
LP; XCP (eXplicit Control Protocol, ver); Hamilton TCP (ver Cap. 3.6.5); variados testes aos novos
protocolos. [78]
PFLDnet2005 – CUBIC (Versão melhorada do Binary Increase Congestion Control, ver); testes de
atribuição de recursos (fairness); Layering TCP (LTCP); TCP Africa. [79]
PFLDnet2006 – Debates sobre o estado dos variados protocolos; Compound TCP (ver Cap. 3.6.7);
continuação dos testes. [80]
Os assuntos dividem-se entre novos algoritmos de congestão (Highspeed TCP, Scalable TCP, CUBIC,
etc.), mecanismos de congestão explícitos (QuickStart, DCCP, XCP), testes e debates sobre os resultados.
O protocolo de transporte TCP não é o único abordado nestas conferências, existindo também outros
protocolos da mesma camada e investigações em outras camadas. Estar com atenção a tudo o que se passa
nestas conferências é um passo extremamente importante na actualização de todo o desenvolvimento em
28

redes de alto débito. Actualmente é ela a principal “foz3
” de toda a comunidade de investigação do TCP
para alto débito.
• Internet2 e Land Speed Record
A Internet2 é uma entidade sem fins lucrativos que desenvolve, implementa e difunde inovação em
termos de redes avançadas, nas quais se inclui o alto débito, i.e., cumpre objectivos do ICIR juntamente
com o da PFLDnet. Apesar desse facto, a Internet2 não é tão importante no desenvolvimento do TCP para
alto débito como são as duas outras entidades. Isso acontece, principalmente, devido ao carácter bastante
alargado de temas abordados, tanto na investigação, como nas conferências organizadas por esta entidade.
Directamente ligado aos mecanismos de congestão para alto débito está o Land Speed Record4
. Este
recorde gerido pela Internet2, tem como principal objectivo o incentivo à investigação na eficiência das
redes de computadores. Esse incentivo traz algo de novo a toda a comunidade de investigação, que vê
assim recompensado tanto monetariamente, como socialmente todo o seu esforço. Tal como todos os
recordes, tem varias restrições associadas que devem ser cumpridas, sendo que estabelecer um novo
recorde, automaticamente, garante a publicidade à entidade que o estabeleceu. Actualmente o recorde está
estabelecido em 7.61Gbit/s, considerando IPv4; 6.96Gbit/s, considerando IPv6. Os valores são médios
por determinado espaço de tempo, verificando-se então a discrepância entre o actual recorde de largura de
banda máximo (14Tbit/s, ver Cap. 3.1.2) e a média que se consegue atingir.
Mais informações: http://www.internet2.edu/ e http://www.internet2.edu/lsr/
Fazer parte da comunidade de investigação dos algoritmos de congestão do TCP é hoje bem mais simples
do que por exemplo há dez anos atrás. Diversos artigos foram sendo publicados, existindo agora
documentação explicativa acerca do funcionamento de cada algoritmo e mecanismo, que melhore
qualquer parâmetro de eficiência. O problema da falta de hardware que permita efectuar testes em meios
de alto débito também é facilmente ultrapassado com as plataformas de simulação que actualmente
existem. É de referir também, que praticamente todas as principais entidades de investigação são sem fins
lucrativos, o que significa que a partilha de informação e a cooperação com outras entidades é quase uma
norma. O desenvolvimento a nível comercial é ainda muito pouco, existindo apenas devido à publicidade
inerente de um qualquer recorde no negócio das tecnologias.
3
“foz” como ponto de encontro de todas as ideias inovadoras.
4
Muitas vezes referenciado apenas como LSR.
29

3.3. TCP
O principal protocolo da camada de transporte é composto talvez pela maior quantidade de mecanismos
de todos os protocolos de redes. Esse facto acontece devido a interligação do protocolo com variados
meios e tecnologias, obrigando o TCP a estar constantemente a adaptar-se. Todos os mecanismos aqui
referenciados têm uma relação directa com a eficiência nas redes de computadores. Para além desses,
existem outros mecanismos que não serão abordados, por não terem qualquer relação com o âmbito deste
projecto.
Para além dos mecanismos, variados algoritmos foram também desenvolvidos, sendo que o cabeçalho
necessita igualmente apresentação devido à sua importância. A própria apresentação do cabeçalho origina
a posterior apresentação de alguns aspectos diferenciadores deste protocolo de transporte orientado à
ligação5
e Full-Duplex6
.
3.3.1. O cabeçalho
O cabeçalho TCP é o responsável por toda a comunicação entre emissor e receptor. Foi especificado
juntamente com a especificação do protocolo [38], tendo sido alvo, ao longo do tempo, de algumas
modificações, devido principalmente ao seu carácter adaptativo com as diversas tecnologias que vão
emergindo. As modificações passaram essencialmente pela adição de novos campos. O cabeçalho TCP,
sem opções, ocupa exactamente o mesmo tamanho do cabeçalho IPv4 (Internet Protocol Version 4), i.e.,
20 bytes.
Os campos apresentados na Figura 3.9 já incluem os campos adicionados recentemente, sendo que pode
ser encontrado em diversa documentação versões do cabeçalho mais antigas. A vermelho estão os campos
relacionados com o controlo de congestão, os dados estão representados a verde.
5
Existe sempre uma negociação emissor/receptor acerca do estabelecimento de uma sessão de dados.
6
Permite o envio e recepção de ambos os extremos no contexto de apenas existir uma sessão estabelecida.
30

Figura 3.9 – O Cabeçalho TCP.
• Source Port
Campo identificativo do porto origem.
• Destination Port
Campo identificativo do porto destino.
Estes dois campos servem essencialmente para estabelecimento de conexões, não tendo qualquer relação
com o controlo de congestão.
• Sequence Number
O campo Sequence Number tem dois modos de funcionamento:
- Se a flag SYN estiver activa então a sequência será gerada por uma fórmula que lhe garantirá unicidade
naquela espaço de tempo, perante outras ligações estabelecidas;
- Se a flag SYN não estiver activa, então o primeiro byte de dados é o número da 1ª sequência, sendo as
sequências dos segmentos posteriores o tamanho dos segmentos anteriores enviados.
• Acknowledgement Number
Se a ack flag estiver activada, então este valor é o número de sequência do próximo segmento que o
receptor espera receber. Por ser um protocolo Full-Duplex esta flag estará sempre activa.
• Data Offset
O endereço de ínicio do cabeçalho TCP.
• Reserved
Para uso futuro, principalmente de novas flags (não tem qualquer utilidade neste momento).
31

• Flags
Existem duas flags directamente ligadas ao controlo de congestão explícito (ver Cap. 2.1.5.2) adicionadas
mais recentemente (ano de 2001) [81].
- A flag ECE tem o objectivo de negociar o mecanismo de ECN entre dispositivos;
- A flag CWR (Congestion Window Reduced) é activada depois da negociação, sendo um pedido explícito
para reduzir a taxa de transmissão do emissor;
Todas as outras flags não estão relacionadas com mecanismos de congestão, servindo como bits de
controlo de variadas situações.
- A flag URG activa o campo Urgent Pointer fazendo com que o pacote seja marcado como urgente. O
que fazer com pacotes deste tipo depende das aplicações;
- PHS é a abreviação para Push. Quando esta flag está activa, o receptor notifica o emissor para que que
envie todos os dados que tem, sem que seja considerado o campo Window. Esta flag não é praticamente
utilizada, pelo que as implementações não costumam fornecer, sequer, forma de a activar;
- As flags RST, SYN e FIN servem para controlo das sessões de dados. RST abrevia Reset, requisitando
uma paragem brusca na sessão de dados. A SYN notifica o estabelecimento de uma sessão TCP (SYN é a
abreviatura de Syncronization). FYN abrevia Finalize, terminando a sessão de dados normalmente.
• Window
O número de bytes que o receptor está preparado para receber.
• Checksum
Para detecção de erros do cabeçalho e dos dados.
• Urgent Pointer
Se a flag URG estiver activada, então este campo representa o endereço do último segmento TCP urgente.
• Options
O campo Options é responsável por toda a parte opcional do cabeçalho TCP, permitindo assim ao
cabeçalho uma maior capacidade de adaptação às diversas situações a que está sujeito. A única opção
definida na primeira especificação do cabeçalho foi a opção MSS (Maximum Segment Size). Actualmente
existem diversas opções [82] tendo sido os meios de alto débito, um dos principais responsáveis [RFC
1323] pelo aumento das mesmas. Devido à abundância desses meios, actualmente, essas opções
tornaram-se as mais utilizadas.
As opções mais importantes estão todas relacionadas com a requisição de eficiência por partes da rede,
algumas delas são: MSS, Timestamp, Window Scale, Sack Permitted e Sack.
32

- O MSS permite a um extremo da rede notificar o outro acerca do tamanho máximo do segmento TCP
que poderá enviar. Esta função, combinada com o facto de o próprio emissor poder também limitar os
segmentos que envia através do MTU (Maximum Trasmit Unit), evita que o segmento TCP seja
fragmentado em caminhos com MTU pequeno. A opção MSS armazena o valor máximo do segmento
TCP;
- A Timestamp Option foi das primeiras opções a ser criada devido ao aparecimento das redes de alto
débito. O seu objectivo principal é uma medição mais precisa do RTT (Round Trip Time, ver Cap.
3.3.2.3). Este mecanismo será explicado em maior detalhe no 3.3.4.1.
- A Window Scale Option foi também criada principalmente devido às redes de alto débito. O objectivo é
aumentar o número de bits que o normal campo Window permite, sendo este campo um valor escalar que
multiplica o valor existente pelo campo Window inicial. O mecanismo que utiliza esta opção será também
explicado em maior detalhe no Cap. 3.3.4.2.
- Sack Permitted e Sack são duas opções que pertencem ao mecanismo Sack (Selective Acknowledgment,
ver Subsecção). Uma delas é responsável pela negociação emissora/receptor sobre a utilização do Sack
durante a ligação. Se o Sack for activado na ligação, a opção Sack será a responsável pelos blocos de
segmentos já recebidos pelo receptor.
Todas estas opções são negociadas durante o estabelecimento da sessão dados, i.e., em pacotes com a flag
SYN activa. É pois necessário que emissor e receptor permitam o uso da respectiva opção.
As seguintes figuras são parte de uma normal conexão em HTTP (hypertext transfer protocol) à Internet.
Foram capturadas pelo analisador de tráfego Ethereal [83]. Nas duas figuras são visíveis os estados de
todos os campos do cabeçalho perante diferentes situações.
A Figura 3.10 é o primeiro segmento TCP, sendo responsável pelo estabelecimento da sessão. O número
de sequência é mostrado como “relative sequence numbers”, sendo representado por “0”. Esta situação
acontece na maioria dos analisadores de tráfego, com o intuito de facilitar resoluções de problemas no
estabelecimento da ligação. O número de sequência real, neste caso, será um número completamente
aleatório, sendo os segmentos TCP seguintes até ao estabelecimento da ligação esse número mais um,
consecutivamente (no analisador as sequências são representadas por 1, 2, 3, 4, etc.).
Nas flags verifica-se que o SYN está activo, sinal que está a ser estabelecida uma ligação. Os próximos
pacotes até ao final do estabelecimento também terão a flag SYN activada.
O tamanho da Window que é notificado é o tamanho máximo do campo Window (o campo window tem
16 bits, 65535). Para mais do que 65535 bytes é necessário usar a Window Scale Option (ver ).=16
2
33

TCP em Redes de Elevado Débito: A abordagem EIC TCP

TCP em Redes de Elevado Débito: A abordagem EIC TCP

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a TCP em Redes de Elevado Débito: A abordagem EIC TCP

Semelhante a TCP em Redes de Elevado Débito: A abordagem EIC TCP (20)

TCP em Redes de Elevado Débito: A abordagem EIC TCP