Baixar para ler offline
![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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-15-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-16-320.jpg)
![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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-17-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-18-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-20-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-28-320.jpg)
![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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-31-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-34-320.jpg)
![3. Enquadramento ao Protocolo
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-37-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-38-320.jpg)
![3. Enquadramento ao Protocolo
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-41-320.jpg)
![3. Enquadramento ao Protocolo
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-43-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-44-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-46-320.jpg)
![3. Enquadramento ao Protocolo
• 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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-47-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-48-320.jpg)
![3. Enquadramento ao Protocolo
• 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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-49-320.jpg)
![TCP em Redes de Elevado Débito
• 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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-50-320.jpg)
![TCP em Redes de Elevado Débito
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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-52-320.jpg)
![TCP em Redes de Elevado Débito
• 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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-54-320.jpg)
![3. Enquadramento ao Protocolo
- 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](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-55-320.jpg)
![3. Enquadramento ao Protocolo
segmento volta a ser retransmitido. Para este procedimento o emissor guarda uma cópia do
segmento transmitido, pronta a ser retransmitida;
• Quando o TCP recebe os segmentos de dados do receptor ele envia uma notificação ao emissor,
essa notificação é chamada de acknowledgement, ou abreviando, ack;
• TCP mantém um checksum no seu cabeçalho. O checksum é extremo-a-estremo, com o objectivo
de detectar qualquer modificação dos dados na rede. Se um segmento chegar ao receptor com o
checksum inválido o TCP automaticamente o descarta, não transmitindo qualquer ack de
recepção.
• Os segmentos TCP são transmitidos em pacotes IP, podendo chegar fora de ordem ao receptor
por diversas razões, algumas delas de encaminhamento. Devido a essa razão, o receptor TCP
consegue voltar a sequenciar os dados se necessário, passando os dados de forma correcta para a
aplicação;
• Os dados podem também chegar em duplicado, nesse caso o receptor TCP descarta os pacotes
redundantes;
• Cada extremo de uma conexão TCP tem um tamanho de buffer finito. O receptor TCP só permite
ao outro extremo lhe enviar dados para os quais o seu buffer está preparado. [1]
Todos estes funcionamentos são conseguidos através de mecanismos interligados, sendo a base de todo o
protocolo. Para qualquer posterior desenvolvimento a nível de congestão no TCP é necessária a
aprendizagem de alguns deles, principalmente aqueles directamente ligados à eficiência.
3.3.2.1. Acks e Piggybacking
Os acks são uma presença constante em todos os protocolos orientados à ligação, esta situação não foge a
regra no protocolo TCP. Numa sessão de dados os acks servem, essencialmente, para existir notificação
de recebimento por parte de determinada entidade receptora, a partir daí a entidade emissora descarta toda
a responsabilidade no envio do segmento TCP a que foi notificada a recepção. A entidade receptora será
agora a responsável por todo o posterior tratamento ao segmento, sendo o seu normal destino os buffers
do processo aplicacional. Outro procedimento que irá acontecer no receptor é o descarte da cópia
guardada do segmento a que foi notificada a recepção, o que irá disponibilizar mais espaço no buffer
emissor.
Cada ack preenche o campo number acknowledgement com o próximo número de sequência que pretenda
receber. Se entretanto o segmento TCP que se pretenda não chegue ao receptor, o ack enviado para cada
segmento TCP recebido (que não seja o pretendido), é o ack com o pacote pretendido.
35](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-57-320.jpg)
![TCP em Redes de Elevado Débito
• A janela abre quando o limite direito avança para a direita, permitindo a mais dados serem
enviados. Esta situação acontece quando o processo aplicacional receptor liberta dados no buffer,
sendo posteriormente aumentado o valor da janela oferecida;
• A janela encolhe quando o limite direito se movimenta para o lado esquerdo. Esta situação
acontece quando o valor da janela oferecida é diminuído. Esta situação não é aconselhada
[RFC1222].
Estes três movimentos estão representados sucintamente na Figura 3.17.
Figura 3.17 – Movimentos do Sliding Window.
Com Sliding Window, para cada segmento recebido não é necessário uma notificação imediata do ack,
sendo o ack enviado posteriormente, utilizando a propriedade cumulativa. Além disso, devido ao facto do
Sliding Window manter a rede completamente saturada com segmentos, consegue um melhor throughput
do que um protocolo apenas com o simples mecanismo de acks [2].
O Tamanho da janela (buffer)
O processo aplicacional a usufruir largura de banda de rede é, geralmente, o principal responsável pelas
respectivas mudanças no tamanho da janela disponível. A Figura 3.18 exemplifica todo o funcionamento
de libertação do buffer, e posterior aviso da janela. O pacote IP é entregue pela camada de rede e é
processado pelo TCP até entrar para o processo aplicacional; quanto mais rápido for o processo a tratar os
dados, mais vazio ficará o buffer, sendo posteriormente maior o valor da janela oferecida.
Figura 3.18 – Relação Window/Buffer.
40](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-62-320.jpg)
![3. Enquadramento ao Protocolo
O tamanho da janela8
é um aspecto que afecta directamente a perfomance do TCP. O tamanho da janela
deve ser adaptado à disponibilidade da largura de banda e ao atraso da ligação em questão. Maiores
larguras de banda e maiores atrasos implicam sempre maiores janelas.
Alguns sistemas operativos limitam também a perfomance TCP por não terem o tamanho de janela
adequada às ligações de que usufruem, um desses casos é o Windows XP. O sistema operativo mais
usado nos dias de hoje utiliza para ethernet uma janela de 17520KBytes, i.e., utiliza aproximadamente
metade do valor máximo da janela, podendo piorar se o outro extremo utilizar Options como Sack ou
Timestamp. Em ligações ethernet que suportem 1Gbit/s, a largura de banda nunca consegue ser
correctamente aproveitada com uma janela deste tamanho [84], mesmo com atrasos na ordem dos 0.1ms.
A janela pode ser aumentada no sistema operativo [85] melhorando a perfomance, mas o aproveitamento
total da largura de banda nunca é conseguido. É de referir que a versão de TCP (TCP Reno) utilizada no
Windows também prejudica a perfomance, considerando ligações de alto débito (ver Cap. 3.6.1).
No Linux o tamanho da janela vem por omissão o máximo (64K), sendo a perfomance a mesma que nos
sistemas Windows, se for considerada a mesma versão de protocolo e o mesmo atraso.
O tamanho da janela TCP de forma a utilizar a largura de banda de forma eficiente pode ser calculado
utilizando a seguinte fórmula:
(sec)*sec)/(arg)( RTTbitsbandadeuraLBDPCapacidade =
Esta fórmula permite-nos obter a capacidade da rede, também chamado de BDP (Bandwidth Delay
Product). Este valor pode variar, tal como foi dito anteriormente, conforme os valores de largura de banda
e RTT. O valor da janela para aproveitar a largura de banda de forma eficiente é igual ao valor do BDP. O
valor recomendado é duas vezes o BDP.
Existem também algumas recomendações acerca do valor inicial da janela por parte da IETF [50].
A Relação com o RTT
Podemos comparar o RTT com o comprimento de um canal de dados. Se o comprimento do canal de
dados é maior, então existirá consequentemente uma maior capacidade da rede (BDP) no transporte dos
dados. Existindo mais capacidade, significa automaticamente, mais segmentos TCP a circular na rede. A
Figura 3.19 exemplifica a relação entre segmentos e RTT; o dobro do RTT, o dobro dos segmentos.
8
Janela neste caso é o equivalente a dizer “buffer”. Existe também a definição de “window” como buffer disponível, como é o
caso da Figura 3.17. A razão é esse ser o nome do campo do cabeçalho TCP.
41](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-63-320.jpg)
![TCP em Redes de Elevado Débito
janelas nos próprios sistemas operativos, ou utilizando a Window Scale Option (ver Cap. 3.3.4.2). Novos
problemas a que estão inerentes as ligações de alto débito irão sendo explicados.
Silly Window Syndrome
A condição Silly Window Syndrome10
pode acontecer em qualquer implementação que possua
mecanismos de janela. Foi verificada pela primeira vez formalmente em 1982 [39]. O que se verifica,
quando esta situação ocorre, são pequenas trocas de segmentos TCP em vez dos segmentos completos.
A causa é muitos simples, o receptor está constantemente a oferecer pequenas janelas, em vez de esperar
por maiores janelas. Do outro lado, o emissor está constantemente a enviar pequenos segmentos de dados
em vez de esperar por dados adicionais. A Figura 3.23 representa todo o processo de ocorrência do Silly
Window Syndrome. A janela (buffer) do receptor está cheia sendo que a aplicação lê apenas um byte da
janela, libertando 1 byte na respectiva janela; o byte livre é então notificado ao emissor; o emissor
transmitirá então um segmento com 1 byte, enchendo de novo a janela.
Figura 3.23 – Reprentação do Silly Window Syndrome (Fonte: [3]).
As soluções passam por modificações por parte de emissor e receptor. Em relação ao receptor a solução é
clara: o emissor não deve oferecer pequenas janelas. A janela só deve então aumentar perante duas
situações:
• A janela pode ser aumentada até ao valor de um segmento TCP (utilizando o valor MSS
negociado);
• A janela pode ser aumentada, apenas, até ao valor da sua metade.
10
Por vezes também referenciado como SWS. Devido ao facto de não ser um protocolo ou mecanismo optou-se pela definição
extensa.
44](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-66-320.jpg)
![3. Enquadramento ao Protocolo
No extremo responsável pela emissão as seguintes opções devem ser tomadas, bastando uma ser
verdadeira para se poder executar o envio:
• Enviar apenas quando um segmento TCP tem o seu valor máximo (utilizando o valor MSS
negociado);
• Enviar apenas quando o segmento é, pelo menos, metade da maior janela alguma vez oferecida
pelo receptor;
• Enviar todos os dados em buffer caso existam dados por confirmar (à espera de ack) não estando
o algorirmo de Nagle (ver Cap. 3.3.3.1) activo.
A situação de Silly Window Syndrome está directamente relacionada com o persist timer (ver Cap.
3.3.2.4) e com o algoritmo de Nagle. As ligações mais sujeitas a esta situação são claramente ligações
com emissores rápidos e receptores lentos.
3.3.2.3. Estimação do RTT
“Um bom estimador de RTT, o núcleo do temporizador de retransmissão, é a mais importante
característica para a implementação de um protocolo que pretende suportar grandes cargas”. [13]
A medição do RTT tem sido alvo de preocupação desde a inicial especificação do TCP [38], tendo
sofrido duas importantes modificações. O RTT reflecte o estado da rede, sendo, tal como o desempenho
das ligações, bastante variável ao longo do tempo da sessão de dados. A estimação correcta de toda essa
variância é o objectivo de toda a estimação do RTT.
A primeira medida que o TCP efectua é o cálculo em relação a um segmento TCP e respectivo ack,
garantindo a receptividade desse segmento. É de realçar de novo a propriedade cumulativa, que neste caso
é o principal problema de medição RTT, na medida em que não existe uma relação de um para um entre
segmento TCP e respectivo ack.
A especificação inicial calculava o RTT através de uma relação ponderada entre o RTT medido11
e o
antigo RTT. A relação é dada pela seguinte fórmula:
MRR )1( αα −+←
RTTEstimadorR =
11
Sempre que se falar de RTT medido, está-se a referir à medição entre segmento TCP e qualquer ack que notifique a sua
receptividade.
45](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-67-320.jpg)
![TCP em Redes de Elevado Débito
medidoValorM =
9.0== entoarredondamdefactorα
Sendo o factor de arredondamento aconselhado igual a 0.9, 90% do valor calculado (R) irá ter como base
o antigo valor, e 10% do valor calculado irá ter como base o novo valor medido. A passagem de RTT
para o temporizador, também conhecido como RTO (Retransmission Timeout Value) é feita com recurso
a outra fórmula:
βRRTO =
2== atrasodoriaçãovadefactorβ
O factor de variação do atraso é recomendado na especificação ser igual a 2. Este factor de variação pode
ser optimizado à ligação conforme os seus atrasos inerentes.
Van Jacobson (ver Cap. 3.2.1.2) detalhou os problemas desta fórmula [13] na estimação dos RTT,
nomeadamente o facto da variação do atraso ser um parâmetro difícil e pouco coerente de escolher,
obrigando muitas vezes a retransmissões desnecessárias. Foram então definidas novas fórmulas que
estimam o RTT com base na média e variância:
AMErr −=
médiaA =
medidoValorM =
Esta primeira fórmula é também responsável pelo cálculo da média de todos os RTT calculados. Err é a
diferença entre o valor RTT medido é a média. A média e o desvio são calculados da seguinte forma:
)|(| DErrhDD −+←
gErrAA +←
DesvioD =
4
1
== desviodoganhoh
8
1
== médiadaganhog
A média tem um valor ponderado g que é recomendado de valor 0.125. De igual forma existe um ganho h
para o desvio com recomendação de 0.25. Ao ser aumentado o ganho do desvio, significa que o RTO terá
um aumento mais acentuado. O RTO é dado por:
46](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-68-320.jpg)
![3. Enquadramento ao Protocolo
DARTO 4+=
Existem porém uma modificação para a situação inicial na troca de dados:
DARTO 2+=
Esta última fórmula faz com que o RTO não seja tão elevado na sua fase inicial. A Figura 3.24 representa
uma comparação do valor estimado com o valor real fornecido por um analisador de tráfego; o eixo dos
xx é o valor RTT/RTO, o eixo dos yy o tempo em segundos; no início o valor calculado (calculated RTO)
começa por ser alto, tornando-se a estimação ao longo do tempo de transmissão bem mais perfeita.
Figura 3.24 – Cálculo do RTT medido por analisador de tráfego, comparado com o calculado TCP (Fonte: [1]).
A segunda modificação, a adição de um campo timestamp option já teve a sua introdução anteriormente
(ver Cap. 3.3.1) e vai ser explicada em maior detalhe na (ver Cap. 3.3.4.1).
A implementação das formas de estimar o RTT varia imenso. Existem pequenas modificações nas
fórmulas, medições feitas apenas por janela, etc. Essencialmente é o tipo de ligações que define as
implementações; por exemplo, no caso de existir apenas uma medição do RTT por janela, essa situação
funciona bastante bem para baixas larguras de banda, mas levanta diversos problemas para alto débito,
onde uma estimação detalhada do RTT se revela crucial.
A estimação do RTT está directamente associada a um temporizador de retransmissão, porém esta
associação verifica-se apenas para a primeira retransmissão. Existem também algumas situações onde o
RTT não deve ser medido (ver Cap. 3.3.3.2). O funcionamento dos temporizadores após a primeira
retransmissão vai ser explicada seguidamente.
47](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-69-320.jpg)
![TCP em Redes de Elevado Débito
3.3.2.4. Os Temporizadores
“Um elemento crítico de qualquer implementação é a estratégia timeout/retransmissão”. [1]
Os temporizadores são essenciais a toda a eficiência da rede, na medida em que mal configurados podem
significar desnecessárias transmissões/retransmissões. As retransmissões são iniciadas por dois tipos de
eventos: timeouts e acks duplicados; as retransmissões devido a acks duplicados são explicadas no Cap.
3.5.1.1.
Retransmit timer
A implementação/configuração do retrasmit timer12
pode por vezes se tornar complicada. Algumas
complicações surgem perante as seguintes situações:
• Timeout um pouco maior que o RTT;
Esta situação é a mais comum. Se tudo estivesse em equilíbrio então a situação ideal seria o temporizador
igual ao RTT, porém os atrasos vão variando ao longo de toda a ligação e têm que ser definidas margens
de aceitação para certos atrasos. A solução neste caso prende-se essencialmente com uma correcta
estimação do RTT, e um bom conhecimento da rede em questão, principalmente os atrasos a que pode
estar inerente.
• Timeout demasiado pequeno;
Esta situação pode ocorrer, geralmente, quando a rede está sujeita a muitas perdas e tem poucos atrasos,
nesse caso são usados temporizadores pequenos pois o grau de desconfiança na rede é elevado.
Temporizadores pequenos em redes com algum atraso e perdas pouco relevantes significam, geralmente,
retransmissões desnecessárias.
• Timeout demasiado longo;
Situação ocorrente quando existe um grau de confiança elevado na rede (em relação às perdas), ou o
atraso da rede é elevada. Numa rede que não reúna essas características irá ser verificado uma reacção
bastante lenta aquando da perca de um qualquer segmento TCP.
Quando ocorre um timeout são executadas duas operações: retransmissão do segmento TCP que causou o
timeout e o reiniciar do temporizador. O temporizador altera também o seu tempo conforme o número de
12
Termo mais usado, que corresponde a temporizador de retransmissão.
48](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-70-320.jpg)
![3. Enquadramento ao Protocolo
Delayed Ack Timer
Na parte do receptor existe o delayed ack timer. Este temporizador define o tempo que o receptor deve
esperar, entre o correcto receber do segmento e o envio do respectivo ack. A espera é útil para
optimização da largura de banda, notificando vários segmentos num só ack (propriedade cumulativa),
sendo também útil para o mecanismo de piggybacking (ver Cap. 3.3.2.1). Os valores de timeout deste
temporizador variam bastante de implementação para implementação, sendo o valor mais usado 200ms.
3.3.2.5. Sack
O Sack é um protocolo especificado formalmente em 1996 [43] com o objectivo de melhorar todo o
mecanismo de acknowledgment. Os mecanismos de acknowledgment (ver Cap 3.3.2.1) devido à
propriedade cumulativa têm algumas vantagens e desvantagens, o Sack fixou-se em todas a desvantagens
desta propriedade. As desvantagens são:
• A recepção de segmentos fora de sequência nunca tem associado um ack;
• O receptor manda acks duplicados;
• O emissor apenas pode receber uma notificação de segmento recebido (ack) por RTT.
Este protocolo usa as opções do TCP Sack Permitted e Sack (ver Cap. 3.3.2.5). A opção Sack armazena os
blocos de dados que já foram recebidos, permitindo ao protocolo TCP, além da notificação do normal
ack, a notificação de diversos blocos de dados já recebidos. A Figura 3.27 exemplifica o funcionamento
do Sack; São enviados 5 blocos de dados (100, 200, 300, 400 e 500), 2 deles (200 e 400) são perdidos;
após o esgotar do delay ack timer é enviado o normal ack 200, mas com a notificação de que os blocos
500-600 e 300-400 já foram recebidos, ajudando assim o emissor a melhor decidir o que transmitir.
Figura 3.27 – Exemplo de funcionamento do protocolo Sack.
51](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-73-320.jpg)
![TCP em Redes de Elevado Débito
A Sack Option é de comprimento variável, com limite para quatro blocos, sendo composta da forma
representado na Figura 3.28. O limite direito representa o primeiro número de sequência desse bloco, o
limite esquerdo é o número a seguir ao último número de sequência do bloco.
Figura 3.28 – Representação dos blocos da Sack Option.
Existe uma extensão feita a este protocolo a que foi dado o nome de D-Sack [47] . Esta opção pretende
utilizar o primeiro bloco Sack para notificação de segmentos duplicados. O objectivo principal é notificar
ao emissor que foram efectuadas retransmissões desnecessárias. Desta forma, o emissor poderá reagir,
anulando por exemplo os algoritmos de controlo de congestão. Esta extensão ainda possui poucas
implementações e quando existe implementação não se verifica por omissão.
3.3.3. Os algoritmos
Existem vários tipos de algoritmos no TCP. Um algoritmo no TCP caracteriza-se por poucas linhas de
código, aquando das implementações. Geralmente alteram também de forma muito significativa o
desempenho da rede. Os algoritmos surgem, também geralmente, associados ao seu criador dividindo-se
em três tipos:
• Algoritmos de controlo de congestão;
Algoritmos que previnem o emissor de não congestionar toda a rede.
• Algoritmos de controlo de erros;
Algoritmos de recuperação para situações de perdas de segmentos.
• Algoritmos de controlo de fluxo.
Algoritmos que previnem o emissor de não sobrecarregar o receptor com informação, tentando que o
mesmo envie os dados de forma adequada à largura de banda.
O objectivo de cada tipo de algoritmo é diferente, mas toda a implementação é feita de forma combinada,
fazendo com que uma correcta separação entre eles não se verifique simples de efectuar.
52](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-74-320.jpg)
![3. Enquadramento ao Protocolo
Os algoritmos de congestão e de controlo de erros vão ser analisados mais à frente (ver Cap. 3.6), sendo
agora analisados dois algoritmos, correspondentes ao controlo de fluxo.
3.3.3.1. Algoritmo de Nagle
O primeiro algoritmo, definido para optimizar a ocupação da rede por parte do TCP, foi especificado em
1984 [40]. O nome atribuído foi o nome do seu criador (John Nagle), tendo sido um algoritmo criado na
fase inicial dos colapsos da Internet (ver Cap. 3.2) e por isso considerado, por vezes, o primeiro algoritmo
de congestão. Porém, geralmente são referidos como algoritmos congestão outro tipo de algoritmos,
criados um pouco mais tarde (ver Cap. 3.6).
O algoritmo especifica que quando uma ligação TCP tem segmentos que ainda não foram confirmados da
recepção, pequenos segmentos não podem ser enviados, até que os acks sejam recebidos. Em vez dessa
situação, pequenas quantidades de dados da aplicação vão sendo somadas, sendo posteriormente enviadas
apenas num segmento TCP quando todos os ack chegarem. O algoritmo é extremamente simples e de
uma tremenda utilidade, pois em situações de congestão, se existirem aplicações interactivas16
na rede o
desempenho da rede aumenta exponencialmente. Além disso, não precisa de qualquer tipo de
sincronização adicional, pois à medida que a rede vai ficando descongestionada (acks a chegar) mais
rápida será a transmissão dos dados.
3.3.3.2. Algoritmo de Karn
Especificado em 1987 [10], este algoritmo está directamente ligado à estimação de RTT (ver Cap.
3.3.2.3). Phil Karn reparou num problema de ambiguidade durante as retransmissões a que foi dado o
nome de retransmission ambiguity problem.
Um segmento é transmitido e para esse segmento o retransmission timer esgota, enviando um novo
segmento; de seguida é recebido um ack do segmento retransmitido. A pergunta que agora se faz é se este
ack é do segmento transmitido atrasado ou do segmento restransmitido? A resposta seria fácil se existisse
forma de saber que o primeiro segmento tinha sido perdido, porém não existe nenhum mecanismo que
permita essa verificação. De qualquer forma, se ele for correctamente recebido não há forma alguma de
saber a que segmento se refere o ack. A Figura 3.29 representa a situação de ambiguidade atrás explicada.
16
Este tipo de aplicações tem a característica de enviar uma grande quantidade de pequenos segmentos de dados para a rede.
53](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-75-320.jpg)
![3. Enquadramento ao Protocolo
problemática surge quando os números de sequência esgotam antes do tempo deste temporizador,
fazendo com que os números de sequência se possam repetir na mesma ligação.
Para a solução destes três problemas foram criados três mecanismos especificados em 1992 [42],
juntamente com as alterações ao cabeçalho.
3.3.4.1. Timestamp Option
A timestamp option foi a última modificação mais relevante, aplicada aos estimadores de RTT. O
conceito é a adição de uma nova marcação de tempo em cada segmento TCP. A essa marcação, o receptor
responderá na forma de um echo reply17
. A forma como essa opção está estruturada é representada na
Figura 3.30. O primeiro campo (TS Value) é preenchido pelo emissor, o segundo campo (Tsecr) é
preenchido pelo receptor.
Figura 3.30 – Representação dos campos do Timestamp Option.
Existem várias considerações a ter nesta troca de valores. O facto de o preenchimento ser um echo reply
traz consigo duas vantagens: não é necessário qualquer tipo de sincronização (para além da já existente
nos normais mecanismos TCP), não é necessário o receptor saber como está estruturada a informação no
campo preenchido pelo receptor. O valor do TS Value é um valor fornecido pelo relógio do sistema.
Também devido ao echo reply por parte do receptor foi necessário a criação de duas formas de
funcionamento:
• Se um ack estiver a utilizar a propriedade cumulativa a notificar o emissor, o valor do Timestamp
Option será sempre o do primeiro segmento que for recebido;
• Se um segmento estiver fora de sequência, implicando que um antigo segmento foi perdido,
quando esse segmento é recebido, o valor da Timestamp Option será o do segmento perdido.
Através destes mecanismos, esta opção permite saber para além do RTT do último segmento a ser
recebido, o do primeiro. Desta forma o RTT terá uma melhor estimação, ganhado o TCP uma melhor
preparação para redes de alto débito.
17
O emitido pelo emissor será igual ao preenchido pelo receptor.
55](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-77-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.32 – Exemplo hidráulico de uma situação de congestão (Fonte: [3]).
Devido ao facto de as redes de computadores, principalmente a Internet, não terem a mesma capacidade
ao longo da ligação, entende-se facilmente a razão dos colapsos. Assim sendo, a solução foi abordar os
problemas de duas formas: o controlo da capacidade da rede e o controlo da capacidade do receptor.
As soluções vieram em forma de versões TCP com os seus algoritmos de congestão que se vieram a
verificar de extrema importância.
3.5.1. TCP Tahoe
“Os caminhos óbvios para implementar um protocolo de transporte baseado em janela, pode resultar,
exactamente, no comportamento errado no que diz respeito à congestão da rede”. [13]
O TCP Tahoe é especificado em 1988 [13], num paper que se viria a tornar um clássico23
no ramo das
redes de computadores. O nome “Tahoe” não surgiu aquando da sua especificação, sendo o nome
atribuído, posteriormente, após implementação dos algoritmos e mecanismos de congestão em BSD
(Berkeley Software Distribution). A versão é caracterizada essencialmente pela adição de uma nova
janela (janela de congestão), e os algoritmos de congestão Slow Start e Fast Retrasmit.
23
Definição usada para referir algo que, actualmente, ainda se verifique uma grande referência.
60](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-82-320.jpg)
![3. Enquadramento ao Protocolo
3.5.1.1. Janela de Congestão
A janela de congestão24
é uma segunda janela, com o intuito de solucionar a situação de congestão na
rede (a congestão no receptor é já solucionada pela janela referida anteriormente). A janela de congestão
não tem qualquer tipo de relação com o receptor, funcionando como uma forma de controlo de fluxo por
parte do emissor. O papel do emissor será transmitir o mínimo destas duas janelas; o receptor pode
oferecer assim determinada janela, mas o emissor através da sua janela de congestão poderá saber que ao
injectar segmentos até aquele limite irá congestionar a rede. A Figura 3.33 exemplifica a relação entre as
duas janelas. A janela irá oferecer 8Kb ao emissor para enviar, por outro lado a sua janela de congestão só
lhe permite 4Kb; finalmente serão enviados os 4Kb.
Figura 3.33 – Funcionamento da janela de receptor/janela congestão.
A janela de congestão irá funcionar em conjunto com os algoritmos de congestão, variando o seu valor
conforme os acontecimentos da rede. É de referir também que o valor da janela é medido em bytes e não
em segmentos.
3.5.1.2. Slow Start
“Um novo pacote não pode ser colocado na rede até que um velho pacote saia. A física do fluxo prevê
que os sistemas com esta propriedade deve ser robustos em relação à congestão“. [13]
O mecanismo de acks (ver Cap. 3.3.2.1) funciona basicamente como o relógio do TCP. Essa situação
permite ao TCP adquirir outra propriedade: self-clocking25
. Esta propriedade permite ao TCP adquirir um
determinado ritmo, onde os acks conseguem ser gerados à mesma velocidade dos segmentos. Desta forma
é atingido o estado de equilíbrio representado na Figura 3.34, onde os variados tempos de transmissão são
sempre mantidos.
24
Muitas vezes referenciado como congestion window ou cwnd.
25
Termo mais usado, correspondente a auto sincronização.
61](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-83-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.34 – Representação do estado de equilíbrio (Fonte: [13]).
O objectivo será, então, conseguir manter este estado de equilíbrio na rede. O problema principal é iniciar
esse mesmo estado de equilíbrio, sendo o Slow Start, o responsável por essa mesma inicialização.
O processo de funcionamento do Slow Start é observar a velocidade a que devem ser injectados os
segmentos na rede, através da velocidade a que os acks são devolvidos por parte do receptor.
O valor inicial da janela de congestão representa o primeiro segmento que será enviado, esse valor será o
MSS negociado, aquando do estabelecimento da ligação. A partir do primeiro segmento enviado, para
cada ack recebido (do segmento enviado), a janela de congestão será incrementada em mais um
segmento.
A Figura 3.35 demonstra este comportamento. O emissor começa por transmitir um segmento e espera
pelo seu ack; quando o ack é recebido a janela de congestão é aumentada de 1 (1) para 2 (2, 3) segmentos;
quando cada ack desses segmentos chega ao emissor, a janela de congestão é aumentada para 4
segmentos (4, 5, 6, 7); após os acks, a janela aumenta para 8 segmentos (8, 9, 10, 11, 12, 13, 14, 15); a
multiplicação continua a subir exponencialmente até ocorrer alguma situação que active outro algoritmo.
Figura 3.35 – Representação do comportamento do Slow Start (Fonte: [13]).
62](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-84-320.jpg)
![3. Enquadramento ao Protocolo
Como já foi anteriormente referido (ver Cap. 3.2), as primeiras implementação foram feitas em BSD que
na altura ia na sua versão 4.3. Uma exemplo de uma rede com essa implementação é representado na
Figura 3.36. A rede em questão é uma rede ethernet de 10Mbit/s característica da altura, com ligação
backbone de 230.4Kbit/s; o eixo dos xx representa o tempo, o yy representa o número de sequência dos
segmentos, a linha a tracejado representa a largura de banda disponibilizada; para aproveitar ao máximo
os segmentos deviam seguir a linha a tracejado, porém, esse comportamento não se verifica, sendo o
tráfego caracterizado por constantes retransmissões que pioram ao longo do tempo, existindo até
segmentos retransmitidos 4 e 5 vezes. O aproveitamento da largura de banda por parte desta rede, não
surpreendentemente, será cerca de 35%.
Figura 3.36 – Representação da perfomance de uma implementação 4.3BSD (Fonte: [13]).
A mesma rede, com exactamente as mesmas configurações da representada na Figura 3.35, sendo alterado
apenas a implementação para BSD 4.3+, é agora representada na Figura 3.36. Esta implementação foi
uma versão intermédia entre a versão BSD 4.3 e a BSD 4.3 Tahoe, que apenas implementava o algorimo
Slow Start. Os melhoramentos verificados são: excepto até ao 16º segmento, os segmentos seguem
exactamente a linha da largura de banda disponibilizada; são correctamente26
enviados cerca de 155
segmentos, ao longo de aproximadamente 9 segundos (para o mesmo tempo, a antiga implementação
enviava correctamente cerca de 65). Não existe qualquer retransmissão, limitando os “tempos mortos” do
emissor ao tempo de chegada dos acks.
26
Correctamente neste caso implica o envio sem descarte e com ack (excepto nos segmentos finais que poderão ainda não ter
sido notificados).
63](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-85-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.37 – Representação da perfomance de uma implementação 4.3 BSD+ (Fonte [13]).
A única desvantagem que se retira deste algoritmo são os 2 segundos iniciais em que se afasta um pouco
da largura de banda disponibilizada, após os 2 segundos o termo “slow” 27
perde todo o seu sentido,
superando em velocidade de pacotes enviados correctamente qualquer outra implementação feita.
A melhoria de perfomance proporcionada por este algoritmo em relação aos normais mecanismos
implementados não deixou qualquer dúvida às comunidades de investigação, passando rapidamente a ser
adoptado em qualquer rede de computadores e principalmente na Internet.
O slow start, tal como os algoritmos que irão posteriormente ser explicados, teve origem em algoritmos
implementados anteriormente pela DEC (Digital Equipment Corportaion) [86], nomeadamente o CUTE
(Congestion Control Using Timeouts at the End-to-End) [11]. Especificados em 1986, dois anos antes do
TCP Tahoe, estes algoritmos deram origem ao termo “Linear Decrease and Sudden Decrease”, que viria
a ser adaptado pelas versões TCP como AIMD (Additive Increase and Multiplicate Decrease). Os
algoritmos AIMD são caracterizados pela aplicação de multiplicações, adições e divisões na janela de
congestão conforme a correspondente situação da rede.
O Slow Start é especialmente importante na medida em que a maioria das ligações TCP não dura muito
tempo, assim sendo, muitas das vezes apenas este algoritmo é invocado.
27
O inglês “slow” significa lento.
64](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-86-320.jpg)
![TCP em Redes de Elevado Débito
Para esta relação é necessário o uso de duas simples variáveis: cwnd29
, responsável pelo tamanho actual
da janela de congestão; ssthresh, o threshold30
do Slow Start onde poderá ocorrer congestão.
O relacionamento entre Slow Start e Congestion Avoidance baseia-se essencialmente nos seguintes
pontos:
• Quando a congestão ocorre, verificada pelas possíveis indicações, metade do valor da janela de
congestão ficará guardado na variável ssthresh, ficando esse o limite da zona de congestão;
• Se existir um timeout, adicionalmente a variável cwnd baixa para o valor MSS inicial;
• Quando é notificada a recepção de novos segmentos, a forma como a janela é aumentada depende
da situação que o emissor pensa estar a rede. Se ssthreshcwnd ≤ não se passou o limite de
congestão, sendo usado o normal crescimento Slow Start; se pelo contrário ,
então passou-se o limite de congestão, sendo usado o incremento Congestion Avoidance.
ssthreshcwnd ≥
A Figura 3.38 demonstra como os algoritmos e respectivas variáveis se relacionam. O eixo dos xx
representa os RTT, o eixo dos yy representa o valor da cwnd em segmentos. Pressupõe-se nesta
representação que uma anterior situação de congestão já sucedeu aquando do segmento 32, sendo
verificado um timeout; por essa mesma razão o ssthresh ficou armazenado com o valor 16; de seguida o
Slow Start começa novamente a partir do 1º segmento até ao 16º segmento (valor do ssthresh); após
ultrapassar o valor do ssthresh entrou-se na zona de possível congestão, diminuindo assim a velocidade
de envio.
Figura 3.38 – Representação gráfica da relação Slow Start/Congestion Avoidance (Fonte: [1]).
29
Por vezes utilizada para referenciar a própria janela de congestão, neste caso referenciada como uma variável.
30
O inglês “threshold” significa ponto inicial, neste caso referenciado como ponto inicial de congestão.
66](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-88-320.jpg)
![TCP em Redes de Elevado Débito
3.5.2. TCP Reno
Em 1990 Van Jacobson (ver Cap. 3.2.1.2), continuando a precisa análise de eficiência das redes de
computadores efectua modificações ao algoritmo Congestion Avoidance [14]. O algoritmo principal desta
nova versão é o Fast Recovery.
3.5.2.1. Fast Recovery
Fast Recovery permite uma recuperação mais rápida, enviando menos. As modificações efectuadas
devem-se em grande parte a uma situação verificada: apesar de um ack duplicado poder indicar
congestão, significa também que um segmento chegou bem ao receptor e saiu da rede. Foram
especificadas as seguintes situações:
• Por cada vez que cada ack duplicado chegar ao emissor, em vez de usar a normal forma de
incrementação Congestion Avoidance, incrementa-se a cwnd no valor de um segmento;
• Quando o segmento é retransmitido devido ao algoritmo Fast retransmit, a cwnd assume o valor
do ssthresh mais três segmentos. Desta forma é feito directamente Congestion Avoidance em vez
de iniciar Slow Start, o valor dos três segmentos é devido ao facto de 3 acks duplicados
significarem que 3 segmentos saíram da rede;
• Transmite um segmento se for permitido pela cwnd e pela janela do receptor;
• Quando tudo voltar ao normal e novos segmentos notificados ao emissor, a cwnd toma o valor do
ssthresh, de forma a ser feita a normal incrementação Congestion Avoidance em vez do Slow
Start.
A Figura 3.40 exemplifica uma situação com todos os algoritmos de congestão em funcionamento (Slow
Start, Congestion Avoidance, Fast Retransmit e Fast Recovery). O eixo dos xx representa o tempo, o eixo
dos yy a janela de congestão; o valor máximo do yy é o valor do ssthresh, que será por sua vez o tamanho
máximo da janela do receptor (64KB). O algoritmo inicial é o Slow Start que é automaticamente
invocado; passado algum tempo um timeout ocorre e o ssthresh toma metade do valor da cwnd; o Slow
Start inicia outra vez, mas agora, quando atinge o valor do ssthresh o limite de congestão é atingido e o
Congestion Avoidance invocado com a sua incrementação 1/cwnd; o próximo acontecimento é uma perda
detectada pelo 3º ack duplicado, sendo então invocado o Fast Retransmit que rapidamente transmite o
segmento, sem que exista tempo morto por parte do emissor; por fim é invocado o Fast Recovery ficando
a cwnd com o valor de ssthresh mais a adição de 3 segmentos, entrando directamente em Congestion
Avoidance. Continuando, ainda são invocados mais duas vezes o Fast Retransmit, Fast Recovery e
Congestion Avoidance sucessivamente.
68](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-90-320.jpg)
![3. Enquadramento ao Protocolo
Figura 3.40 – Representação dos algoritmos de congestão em funcionamento (Fonte: [6]).
Van Jacobson acabava aqui o seu ciclo de algoritmos, porém um melhoramento final aos seus algoritmos
ia ainda ser efectuado. Todos os algoritmos de congestão anteriormente referenciados ficaram
referenciados em RFC [45].
3.5.3. TCP newReno
Janey Hoe (ver Cap. 3.2.1.2 ) iria desenvolver o último algoritmo deste ciclo. Especificado numa primeira
vez em 1996 [19] e finalmente em RFC em 1999 [46] e 2004 [52], este foi talvez o algoritmo que mais
demorou a ser adoptado. Essa tardia adopção deveu-se provavelmente ao facto de as melhorias não se
verificarem tão grandes, quanto as verificadas aquando da criação dos anteriores algoritmos.
O newReno foca, essencialmente, a fraca capacidade do Reno em recuperar de uma múltipla perda de
segmentos. Verificou-se que para uma única perda de segmento a recuperação é bastante boa, mas que
passando esse limite a perfomance torna-se bastante reduzida.
O problema acontece aquando da activação do algoritmo Fast Retransmit. Como foi referenciado
anteriormente, o algoritmo Fast Retransmit é activado sempre que o emissor recebe um terceiro ack
duplicado, sendo que o segmento é rapidamente retransmitido. A situação problemática surge quando
para a mesma janela mais de um segmento se perdeu, sendo necessário mais do que uma transmissão.
Imaginando que o 3ºack duplicado é o 1, ao retransmitir é recebido o ack do 2; a situação não é normal,
pois até receber o 3ºack duplicado foram pelo menos enviados 3 segmentos e no funcionamento normal
existe um ack de n segmentos. Assim sendo, existe uma alta probabilidade de o 3 estar perdido que não
foi considerada nos algoritmos anteriores.
69](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-91-320.jpg)
![3. Enquadramento ao Protocolo
o Se o 3ºack duplicado for menor que a variável recover então estamos perante um Partial
Ack, i.e., não foram recebidos todos os segmentos;
Neste caso não são efectuado nem Fast Retransmit nem Fast Recovery. O valor ssthresh não vai
ser afectado nem a cwnd, porém será enviado um segmento por RTT. Esse envio acontece pois
cada vez que um ack duplicado chegue ao emissor a janela do receptor irá permitir mais um
envio, como a janela de congestão como não foi diminuída irá permiti-lo, até todos os segmentos
da janela serem retransmitidos.
o Se o 3ºack duplicado for maior que a variável recover então todos os segmentos foram
correctamente recebidos.
Funcionamento normal31
por parte do Fast Retransmit e Fast Recovery.
As semelhanças nas preocupações entre TCP newReno e Sack (ver Cap. 3.3.2.5) são bem notórias: ambos
se preocupam com a optimização na retransmissão de segmentos. Apesar dessa situação o TCP newReno
com Sack supera em perfomance o normal Reno com Sack. Existe porém um cenário onde o Reno tem
melhor perfomance: sem perdas, mas com suficiente reordenamento para o emissor receber 3ºack e ser
“enganado” por não se tratar de uma perda. Com Reno apenas um segmento seria transmitido, com
newReno o “engano” dá origem a uma sucessão de retransmissões.
O newReno após algum tempo foi totalmente adoptado em todas as implementações. Muitas
implementações actuais não diferenciam Reno e newReno, considerando o primeiro como o segundo, e
nunca o segundo como o primeiro.
A recuperação de perdas é ainda actualmente um problema muito debatido e nada simples de resolver, foi
especificada uma RFC específica para esse procedimento [48].
A Figura 3.42 é um resumo de todas as versões TCP até agora explicadas. Todos são implementados em
conjunto, pelo que é normal existir dificuldade em definir o âmbito de cada um. O Fast Retransmit perde
todo o seu objectivo sem Fast Recovery, o Congestion Avoidance perde o objectivo se for retirado o Slow
Start.
31
Normal neste caso significa o funcionamento da versão anterior (TCP Reno).
71](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-93-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.42 – Resumo de todas as operações e algoritmos de congestão, proporcionados pelas versões TCP Tahoe, Reno e
newReno.
Ao longo do desenvolvimento notou-se também, cada vez mais, uma análise mais pormenorizada da
perfomance. A versão newReno foi detectada por variados testes e uma análise pormenorizada detectou
um padrão de menor perfomance. Esta seria a forma com que actualmente se desenvolvem as novas
versões: análise de perfomance, análise de padrões de menor perfomance, verificação da existência de
problemas, implementação da solução.
3.5.4. TCP Vegas
“O principal resultado que se verifica neste paper é o facto do Vegas conseguir atingir entre 40 a 70%
melhor throughput que o Reno”. [15]
O TCP Vegas foi especificado por Lawrence Brakmo (ver Cap. 3.2.1.2) em 1994 [15]. O seu objectivo foi
providenciar novos horizontes a todo controlo de congestão, propondo modificações para que o TCP
pudesse explorar esses mesmos horizontes.
Essas modificações dividem-se em sete melhoramentos, com o principal objectivo de aumentar o
throughput da rede e diminuir as perdas. Os melhoramentos são:
1. Melhoria significativa nos mecanismos de estimação RTT;
2. Melhor retransmissão de segmentos;
3. Melhor retransmissão, considerando múltiplas perdas;
4. Ajustamento à forma como é estabelecido o redimensionamento da janela de congestão no
Reno;
5. Melhor espaçamento entre os segmentos;
72](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-94-320.jpg)
![TCP em Redes de Elevado Débito
Melhoria para melhor espaçamento entre os segmentos
Verificou-se que no Reno grande parte das perdas é devido a bursts32
de segmentos. A razão dos bursts é
principalmente falhas nos mecanismos responsáveis pelo self-clocking. As duas razões para isso acontecer
são:
• Acks largamente cumulativos;
Geralmente esta situação acontece quando o receptor acumula bastantes notificações de segmentos para
poder fazer piggybacking (ver Cap. 3.3.2.1).
• Ack Compression.
Este mecanismo foi descrito pela primeira vez em 1992 [12]. A razão prende-se com o facto de os buffers
acumularem diversos segmentos nas suas filas de espera33
e quando geralmente a aplicação os retira,
retira-os bruscamente dando origem a acks muito poucos espaçados.
O TCP Reno não controla a forma como o espaçamento entre segmentos é efectuado. A janela de
congestão apenas limita a quantidade de segmentos a enviar, não implementando qualquer mecanismo de
controlo de espaçamento. Desta forma, a probabilidade das filas encherem é bastante grande.
O valor ideal de espaçamento é dado pela seguinte fórmula:
)(
cwnd
MaxSegment
RTTSeqSpacing =
Esta fórmula é utilizada pelo TCP Vegas no mecanismo Spike Supression. Este mecanismo consiste em
permitir apenas um envio de 2 vezes o MaxSegment por cada intervalo SegSpacing. O total de bytes que
se poderá transmitir continua limitado pela janela de congestão, porém, desta forma é apenas permitido
transmitir 2 vezes o número ideal de bytes por SegSpacing.
Outra forma de tratar a congestão
Como já foi visto anteriormente, o TCP Reno utiliza a perda de segmentos como sinal de congestão. Não
existe qualquer mecanismo no TCP Reno que permite detectar estados antecipados de congestão, desta
forma o TCP não previne mas apenas reage. O TCP Reno é assim considerado um protocolo reactivo e
não proactivo.
O TCP Vegas traz como principal novidade a sua proactividade (ver Cap. 2.1.5.2) já referida
anteriormente para tratar a congestão. Assim sendo, as abordagens para tratar a congestão poderão agora
ser divididas por:
32
O inglês “burst” significa rajada, neste caso referenciado a segmentos em rajada.
33
Filas de espera neste caso têm um significado genérico, não estando presente qualquer mecanismo específico.
74](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-96-320.jpg)
![TCP em Redes de Elevado Débito
As decisões referentes ao redimensionamento da janela de congestão são:
• Se α<Diff então a janela de congestão irá aumentar linearmente no valor de 1/cwnd;
• Se β>Diff então a janela de congestão irá diminuir no valor de 1/cwnd;
• Se βα << Diff então a janela será mantida.
A Figura 3.43 representa o funcionamento do TCP Vegas, considerando a relação entre a velocidade de
transmissão e a diferença de throughput verificada. Quanto maior o throughput actual, maior será a
velocidade de envio (aumento da janela); quanto menor o throughput actual, menor será a velocidade de
envio (diminuição da janela); a fase ideal é um intermédio das duas anteriores, não sendo alterada a
velocidade de transmissão.
Figura 3.43 – Relação throughput/velocidade transmissão [Fonte: [15]].
O algoritmo anterior explicado não é directamente aplicado na fase de Slow Start, tendo esse algoritmo
sido alvo de uma modificação.
Modificação no Slow Start
O Slow Start é um algoritmo bastante “caro36
” a nível de perdas, se o buffer do emissor não for limitado.
Quando o Slow Start começa a sobrecarregar a rede já podem existir perdas na ordem de metade da janela
de congestão. O TCP Vegas podia começar a usar de início o seu algoritmo de prevenção, mas a falta de
aproveitamento de largura de banda seria enorme. A solução encontrada foi um intermédio entre a
abordagem Reno e a abordagem Vegas. O Reno aumenta exponencialmente a janela de congestão por
cada RTT, o Vegas aumenta exponencialmente uma vez por RTT e no próximo previne com o seu
algoritmo. Também neste caso é definido um thresholdγ com objectivos idênticos aos outros dois
thresholds, mas para definir especificamente a “agressividade” do algoritmo Slow Start.
36
Caro em relação a que para ter elevado débito implica outras desvantagens.
76](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-98-320.jpg)
![3. Enquadramento ao Protocolo
A Figura 3.44 representa um gráfico característico da versão TCP Vegas. Ao contrário da versão Reno
não se verificam grandes oscilações; o gráfico é caracterizado por um uma janela de congestão que lhe
garante uma transmissão bastante constante ao longo do tempo; os thresholds β e α definem todo o
controlo de transmissão; verifica-se também que só existe Slow Start e Congestion Avoidance ao longo do
tempo.
Figura 3.44 – Gráfico característico do TCP Vegas.
Apesar deste ser um gráfico aproximado do que costumam ser as transmissões com TCP Vegas, todos os
algoritmos do Reno estão presentes. A principal vantagem do Vegas é que como tem uma taxa de 2 a 5
vezes menos perdas que o Reno, raramente os invoca.
A seguir à sua inicial especificação foram efectuados alguns melhoramentos [16][17]. Os principais
foram uma redução para ¼ da janela (no Reno era ½) aquando da verificação de congestão, e um valor
inicial da janela de 2 MSS (no Reno era 1 MSS).
Após toda a fase de especificação variados testes foram feitos. Provavelmente TCP Reno e TCP Vegas
foram as versões a que mais testes tiveram sujeitas, principalmente testes de comparação entre os dois. A
inicial especificação definia o TCP Vegas como garantia de mais 40% a 70% throughput que o Reno, mas
essa garantia não é assim tão simples e directa. Praticamente todos os estudos deram melhor perfomance
para o Vegas em situações com diferentes RTT, baixos atrasos e poucas retransmissões [16][17][18].
Apesar desta situação, ligações com altos atrasos têm melhor perfomance usando Reno [18]. Existe
também um problema a que o TCP Vegas está inerente: o facto de poderem existir mudanças de rotas ao
longo do percurso, alterando bruscamente o RTT; estando o TCP Vegas tão depende do RTT para as suas
decisões, o resultado são baixas perfomances. Outros problemas prendem-se principalmente com
fairness37
; a principal razão prende-se outra vez com o RTT: o primeiro fluxo que usar a rede terá sempre
um menor RTT mínimo do que o segundo fluxo, dessa forma terá sempre a sua janela maior, transferindo
posteriormente mais dados.
37
O inglês “fairness” significa justiça, neste caso justiça na atribuição de recursos.
77](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-99-320.jpg)
![TCP em Redes de Elevado Débito
Os testes verificam principalmente uma nova situação: a existência de duas versões, cada uma
funcionando melhor com certas condições de rede. Era dado aqui o primeiro passo para uma série de
versões cada vez mais específicas.
3.5.5. Outros meios, outras versões
Foi evidenciado no Cap. 3.1.1 que o desenvolvimento a partir de determinados pressupostos. Apesar desta
situação, as versões anteriormente referenciadas são eficientes para a maioria dos meios, não implicando
claro que sejam altamente eficientes em cada meio específico. As novas versões que surgiram abordam
esta situação, tentando atingir níveis de alta eficiência em meios específicos. A maior quantidade de
versões existentes tem como meio específico o alto débito (ver Cap. 3.6). Apesar disso, existem outros
meios igualmente importantes, com abordagens diferentes aos normais algoritmos de congestão.
3.5.5.1. Comunicações Satélite
As comunicações de Satélite são caracterizadas principalmente por: altos atrasos, erros nas transmissões,
perda de conectividade e altas larguras de banda assimétricas. Apesar de todos estes parâmetros afectarem
directamente a aquisição de eficiência por parte do TCP, o mais crítico são os altos atrasos, na ordem dos
480ms a 560ms.
A preocupação evidenciada pelas comunidades de investigação na obtenção da máxima eficiência deste
tipo de meios, deu origem a uma RFC [44] que fornece recomendações acerca dos algoritmos de
congestão a usar, aumento do tamanho da janela de recepção e outros melhoramentos.
Mais tarde iria surgir uma nova versão TCP, especificamente, direccionada para este tipo de meios: o
TCP Hybla.
TCP Hybla
O TCP Hybla, especificado em 2004 [20] tem como principal objectivo quebrar a relação entre RTT e
janela de congestão. Devido aos altos atrasos inerentes às comunicações satélites, os valores do RTT irão
ser de índice bastante superior a qualquer outro meio.
A forma como os normais algoritmos do Reno e Vegas decidem sobre a transmissão, ou não, de mais
segmentos por parte do emissor é feita a cada RTT. Desta forma, é fácil perceber que a forma instantânea
com que os antigos protocolos transmitiam para a rede, não se revela assim tão instantânea considerando
altos RTT.
78](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-100-320.jpg)
![3. Enquadramento ao Protocolo
O Hybla tenta devolver a instantaneidade em falta no que diz respeito à transmissão de segmentos. A
solução encontrada foi tornar as regras de aumento de congestão independentes do RTT, através de uma
mudança de escala temporal no envio de segmentos.
3.5.5.2. Comunicações Wireless
As redes wireless, apesar da tecnologia não ser recente, tornaram-se bastante comuns actualmente.
Quando esta tecnologia surgiu, exigiu novos requerimentos que resultaram em diversos protocolos e
mecanismos de rede específicos. O TCP na altura do surgimento desta tecnologia não foi sujeito a
qualquer modificação ou melhoramento. Essa situação, ocorreu muito por culpa da eficiência e
compatibilidade proporcionada pelos normais mecanismos e algoritmos de congestão deste protocolo. Só
mais tarde, após o surgimento das diversas versões TCP adaptadas a meios específicos, o TCP iria ser
melhorado para este tipo de meio tão peculiar.
Os meios wireless são caracterizados por: baixas larguras de banda e muitos erros de transmissão. A
característica mais crítica são os erros de transmissão que por vezes podem ultrapassar a barreira do 1%
(considerando bits/s). Estes erros geralmente quando ocorrem, ocorrem em burst.
Foi referido, anteriormente nos algoritmos de congestão (ver Cap. 3.5), que existem dois tipos de perdas e
que um desses tipos era desprezado (os erros do meio de transmissão). Neste tipo de meios essa situação
não pode acontecer, sob pena de ser perdida toda a eficiência na ocupação de largura de banda disponível.
Distinguir entre perdas devido a congestão e perdas devido ao meio de transmissão, assim como
providenciar formas de medição para a sua diferenciação é um problema fundamental para o TCP em
meios wireless e a sua solução não se revela fácil de adquirir.
Existem duas versões principais, especialmente, concebidas para este tipo de meio: o TCP Westwood e o
TCP Veno.
TCP Westwood
O TCP Westwood [29] foi a primeira versão a surgir. É um protocolo bastante estável utilizado por
omissão em diversas distribuições Linux. Apesar de ser concebido especificamente para redes wireless,
adapta-se bastante bem a todos os outros meios. Em todos os meios revela um aproveitamento de largura
de banda bastante superior ao TCP Reno e Vegas. As redes de alto débito não são excepção, apesar de os
meios sem fios não serem meios caracterizados por altas larguras de banda.
O conceito mais inovador do TCP Westwood é uma contínua estimação do débito da rede, monitorizando
toda a chegada dos respectivos acks. Todo este débito estimado é depois usado para alterações na forma
como é alterada a janela de congestão e o ssthresh. O objectivo será então uma maior dinâmica às perdas,
79](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-101-320.jpg)
![TCP em Redes de Elevado Débito
não exagerando nas descidas da janela de congestão. O algoritmo dinâmico de recuperação é referenciado
como “Faster Recovery38
”, o algoritmo de medição é referenciado como BWE (Bandwidth Estimate).
Estes dois algoritmos são as principais novidades desta versão, apesar disso, o RTT também é utilizado
para definir a taxa de transmissão. Assim, o RTT mínimo servirá para verificar o estado da rede, enquanto
o BWE servirá para saber o débito fluxo-a-fluxo, eliminando situações de monopolização da largura de
banda conhecidas dos algoritmos DCA (Delay Congestion Avoidance, ver Cap. 3.5.6).
Imaginando uma situação prática com perda por erro de transmissão, o TCP Westwood não o detecta;
mas, ao efectuar a recuperação, verificará o BWE que provavelmente estará com um bom débito para que
não ocorra congestão; então, vai verificar o RTT vendo que ele era o mínimo da transmissão (indicação
que a rede estava de “boa saúde” no que diz respeito a congestão); finalmente, perante estas situações a
janela de congestão não vai descer e o débito será mantido, sendo a perda praticamente ignorada.
Existe também um melhoramento a este algoritmo que permite uma melhor perfomance mesmo com ack
compression [12]. Essa versão é referenciada como Westwood+ [29].
TCP Veno
O TCP Veno [21] surgiu um pouco mais tarde do que o TCP Westwood trazendo uma menor componente
de inovação. O próprio nome “Veno” é uma analogia à junção dos mecanismos do Reno e Vegas. O TCP
Veno efectua a decisão que não é directamente tomada pelo TCP Westwood. Para efectuar essa decisão
utiliza todo o algoritmo de estimação RTT do TCP Vegas. O conceito é simples: se o RTT estimado for
muito elevado em relação ao mínimo, então poderá estar a ocorrer congestão e, posteriormente, se ocorrer
perda foi devido a congestão, invocando assim os normais algoritmos do Reno; caso contrário, a perda é
devido a erros de transmissão e a janela deve descer apenas 1/5, utilizando também os normais algoritmos
do Reno.
Para além destas versões, existem mais de 200. Apesar desse facto, 90% das versões são ainda
experimentais, estando em constante desenvolvimento e em constantes testes comparativos. As versões
anteriores referenciadas encontram-se já com um desenvolvimento bastante estável.
38
O nome tem uma razão comparativa com o anterior algoritmo do Reno “Fast Recovery”, significando maior rapidez (Faster).
80](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-102-320.jpg)
![3. Enquadramento ao Protocolo
3.5.5.3. TCP de baixa prioridade
Se até aqui se tem falado de eficiência e máxima ocupação da largura de banda disponível, o que dizer de
uma versão que apenas aproveita os “restos39
” da largura de banda de uma ligação? A resposta é simples:
se existirem ficheiros em que a o tempo da sua transferência não seja importante, não se revela necessário
requisitar largura de banda de outros fluxos.
Para redes com débitos bastante reduzidos este tipo de versões providencia o algoritmo para que os outros
fluxos consigam ter elevados tempos de resposta em aplicações interactivas, sendo simultaneamente
transferidos ficheiros, para os quais o tempo de resposta não é importante.
A versão mais conhecida que aborda este conceito é o TCP Low Priority40
[22], sendo o seu objectivo
usar a largura de banda não utilizada pelos outros fluxos de uma forma não intrusiva, i.e., transparente aos
outros fluxos.
3.5.6. DCA VS LCA
Durante o desenvolvimento de novas versões, mais se reparou nas vantagens e desvantagens entre as
implementações usando a base do TCP Reno e a base do TCP Vegas. Estas abordagens são referenciadas
como Loss-Based Congestion Avoidance (LCA), caso do TCP Reno e Delay Congestion Avoidance
(DCA), caso do TCP Vegas.
O primeiro passo na especificação de uma nova versão é ter a correcta noção do que induz cada uma
destas abordagens. As duas adequam-se mais a certos meios, as duas incorrem em alguma falta de
eficiência em certas situações, e as duas são absolutamente necessárias para a existência de versões
adaptadas, específicas a meios de transmissão.
Muitas das vantagens foram sendo explicadas anteriormente, será dado agora maior ênfase às diversas
desvantagens. As desvantagens da abordagem LCA são:
• Throughtput será sempre obrigatoriamente menor do que a largura de banda disponibilizada;
Sendo uma abordagem que testa a rede até ao limite, fácil será perceber que a rede acabaria por ceder,
descartando segmentos.
• Muitas perdas;
Testar a rede até ao limite traz também esta desvantagem. O primeiro teste será onde ocorrerá maiores
perdas (Slow Start). O objectivo é estudar a rede para perder menos;
39
Referindo a disponibilidade de largura de banda que não é ocupada.
40
Também referenciado como TCP-LP
81](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-103-320.jpg)
![TCP em Redes de Elevado Débito
• Altas variações nos atrasos;
Geralmente neste caso, ou os atrasos são pequenos, ou os atrasos são muito grande estando já a ocorrer
congestão.
• Alto requerimento de buffers por parte dos routers;
Sendo esta uma forma um pouco agressiva de tratar a rede (testando até existir perdas), os routers têm de
estar melhor preparados.
• Risco de diminuição da janela de congestão de forma exagerada;
Tendo apenas um nível de congestão (ou existe ou não existe), é complicado tomar uma decisão eficiente
no que diz respeito ao decréscimo da janela.
• Mais problemático quando existe perdas devido ao meio de transmissão;
Devido ao facto de existirem mais oscilações, quando existe perdas que não são devido a congestão é
perdida mais eficiência.
A comunidade de investigação geralmente atribui a abordagem DCA como menos arriscada, traduzindo
esse facto menos desvantagens. Apesar dessa situação existem também algumas:
• Pequenas variações no RTT não são valorizadas;
Em casos de bottleneck41
muito pequenos existirá variações RTT que o estimador RTT não irá notar
devido a amostragem do tempo, desvalorizando assim a possível ocorrência de congestão.
• Problema de fluxos serem monopolizados por outros;
Se existir um fluxo na ligação que esteja a manipular todo o bottleneck, os RTT indicarão congestão
baixando assim a taxa de transmissão, porém esses RTT são controlados pelo outro fluxo.
• Falta de justiça na atribuição de recursos aquando uma situação de congestão.
Numa situação de congestão, os algoritmos DCA não descem como os LCA. Desta forma toda a justiça
na atribuição de recursos (fairness) é perdida.
• Problemas entre a relação RTT e a congestão;
Existem variados estudos [23] que estabelecem uma fraca relação entre o aumento da janela de congestão
e o RTT.
41
O ingês “bottleneck” significa pescoço de garrafa, numa analogia a estreitamento do caminho, ou neste caso, a ligação mais
lenta.
82](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-104-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.45 – Comportamento do TCP Reno numa LFN de 10Gbit/s (Fonte: [9]).
A forma de cálculo deste tempo de recuperação por parte do algoritmo Congestion Avoidance (na versão
Reno) é fornecida pela seguinte fórmula, permitindo calcular o tempo de resposta (responsivness):
MSS
RTTC
2
)( 2
=∂
respostadetempo=∂
rededaCapacidadeC =
Alguns valores fornecidos por esta fórmula estão expressos na Tabela 3.3. Verifica-se uma subida
acentuada do tempo de resposta em relação ao aumento da capacidade da rede, ou em relação ao seu
atraso (RTT). É de realçar também que ao aumentar o tamanho do segmento, este tempo diminui bastante
(última ligação WAN Futura), para isso serão necessários buffers enormes por parte dos routers.
Ligação Capacidade RTT (ms) MSS (Byte) Valores de tempo
de resposta
LAN típica em 1988 10 Mb/s [ 2 ; 20 ] 1460 [ 1.7 ms ; 171 ms ]
Típica LAN actualmente 1 Gb/s 2
(pior caso)
1460 96 ms
Futura LAN 10 Gb/s 2
(pior caso)
1460 1.7s
WAN 1 Gb/s 120 1460 10 min
WAN 1 Gb/s 180 1460 23 min
84](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-106-320.jpg)
![3. Enquadramento ao Protocolo
WAN 1 Gb/s 300 1460 1 h 04 min
WAN 2.5 Gb/s 180 1460 58 min
WAN Futura 10 Gb/s 120 1460 1 h 32 min
WAN Futura 10 Gb/s 120 8960
(Jumbo Frame)
15 min
Tabela 3.3 – Tabela com valores de tempo de resposta conforme tipo de ligação (Fonte: [62]).
O objectivo das novas versões para alto débito é principalmente baixar este tempo de resposta, com o
intuito de aumentar o débito médio da rede.
As versões abaixo referenciadas são aquelas em que o desenvolvimento se encontra mais estável,
assumindo um elevado grau de importância devido aos novos conceitos adicionados.
3.6.2. HighSpeed TCP
“Uma forma de olhar a proposta HighSpeed TCP é que ela opera da mesma forma que um turbo de um
motor; quanto mais rápido o motor está, mais rápido o turbo opera até que o motor funcione na sua
normal velocidade”. [9]
O HighSpeed TCP é de todas as versões de alto débito aqui referenciadas a versão que se encontra mais
avançada em termos de desenvolvimento e adopção. É a única versão TCP para alto débito especificada
em RFC [51], tendo sido desenvolvida por Sally Floyd (ver Cap. 3.2.1.3).
O HighSpeed TCP surgiu com base num conceito de uma versão TCP para alto débito bastante simples: o
MulTCP [24].
MulTCP
Tal como foi referido anteriormente, o principal problema está no Congestion Avoidance (ver), devendo
as mudanças essenciais serem efectuadas nesse algoritmo (responsável pela reacção às perdas). O
MulTCP quando invoca o Congestion Avoidance incrementa a sua janela de congestão em N segmentos
por RTT, em vez do normal incremento 1/cwnd; após uma perda reduz a sua janela de congestão em
cwnd/(2N), em vez do normal cwnd/2. É também utilizada uma versão alterada do SlowStart, onde a
janela de congestão aumenta 3 segmentos em vez dos normais 2.
85](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-107-320.jpg)
![3. Enquadramento ao Protocolo
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]).
O aumento de perfomance é imenso, sendo traduzidos os cerca de 8 segundos de recuperação, em pelo
menos, velocidades médias de ligação de 9Gbit/s.
3.6.3. Scalable TCP
O Scalable TCP [Scalable] foi desenvolvido ainda antes do HighSpeed TCP, tendo como principal
objectivo quebrar o relacionamento entre as modificações na janela de congestão e o RTT. Os
desenvolvimentos efectuados no TCP Scalable são a substituição da normal função aditiva do Congestion
Avoidance, pela adição de um valor constante a , e a redução da janela por uma fracção de b. A
característica principal é o uso de um aumento multiplicativo à janela de congestão em vez do normal
aumento linear, aumentando assim a frequência de oscilação. Esta versão é bastante oscilante,
contrastando por exemplo com o TCP Vegas (o menos oscilante).
Na Figura 3.47 estão representadas as modificações efectuadas à janela de congestão, aquando da
situação de congestão; a fórmula para cálculo do intervalo de oscilação está também presente, bem como
todo o padrão de oscilação.
87](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-109-320.jpg)
![TCP em Redes de Elevado Débito
Figura 3.47 – Representação das modificações na janela de congestão efectuadas pelo TCP Scalable (Fonte: [25]).
O Scalable TCP possui semelhanças com o MulTCP na medida em que é escalável43
, apesar disso, ao
contrário do MulTCP, os valores aconselhados e quase sempre usados para qualquer largura de banda são
. A125.0,01.0 == ba Figura 3.48 demonstra o comportamento destas duas variações TCP (Scalable
TCP e MulTCP) e o normal TCP, na mesma ligação de 10Gbit/s da Figura. Verifica-se novamente o
carácter oscilante do Scalable TCP.
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]).
3.6.4. BIC e CUBIC
O BIC (Binary Increase Congestion Avoidance) [26] e o CUBIC [27] são duas versões que abordam
todas estas formas de incrementos na janela de congestão de uma forma totalmente inovadora. O conceito
43
O inglês “Scalable” significa escalável.
88](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-110-320.jpg)
![TCP em Redes de Elevado Débito
bastante mais “arredondado”, sendo sempre usado o algoritmo Binary Search Increase, mas sempre
recorrendo a uma função polinomial atenuando todas as alterações bruscas.
Figura 3.50 – Funções de crescimento BIC e CUBIC (Fonte: [27]).
É de referir que o BIC se encontra como a versão TCP por omissão na maioria das distribuições Linux.
3.6.5. H-TCP
O H-TCP (Hamilton TCP) [55] não traz propriamente qualquer inovação, funcionando como uma junção
evolucionária do HighSpeed TCP, TCP Scalable e TCP Westwood. Do Highspeed TCP foi adoptado a sua
aumento adaptativo na janela de congestão através das perdas; do TCP Westwood foi adoptado sua
moderação, aquando do decréscimo da janela de congestão; em relação ao Scalable TCP foi retirada toda
a sua oscilação, que o torna independente do RTT.
Esta versão do protocolo veio adoptar todos os algoritmos mais interessantes das versões anteriores. Essa
adopção permitiu diversos melhoramentos. Por exemplo: um dos problemas do TCP Westwood é que
apesar de ter um grande controlo nas descidas das suas janelas de congestão, não tem qualquer algoritmo
específico para incrementação; com a adição do algoritmo do TCP HighSpeed esta situação é eliminada.
O Scalable TCP não tem qualquer tipo de controlo adaptativo da sua janela; o algoritmo TCP Westwood
permite agora esse tipo de controlo.
3.6.6. FAST TCP
O FAST TCP é o único descendente do TCP Vegas (ver Cap. 3.5.4), considerando todas as versões de
alto débito analisadas. Quando especificado [30], foi especialmente tido em conta a vantagem do TCP
Vegas em relação ao TCP Reno nos meios de alto débito. A vantagem do TCP Vegas utilizando pouca
largura de banda revela-se mínima, porém, quando se trata de alto débito verifica-se decisiva. O objectivo
foi criar uma versão melhorada do TCP Vegas, especifica ao esse meio de transmissão de alto débito.
90](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-112-320.jpg)
![3. Enquadramento ao Protocolo
Foi referido anteriormente (ver Capítulo) que a incrementação e diminuição da janela de congestão do
TCP Vegas é sempre correspondente a 1/cwnd. Esta forma de decrescimento e crescimento leva a que o
TCP Vegas demore bastante a atingir a sua fase de equilíbrio. A principal modificação do FAST TCP diz
respeito a uma alteração nesta forma de incremento/decremento.
No FAST TCP a forma como são efectuadas modificações à janela por RTT depende de dois factores:
• A variação do RTT;
• O valor da janela de congestão corrente.
Com base nestes dois parâmetros, a fórmula de crescimento/decrescimento será igual a:
α+×= )/( RTTRTTbaseWW
O valor baseRTT continua a representar o RTT mínimo da ligação, representado o RTT o seu valor
corrente. Oα foi já referenciado anteriormente no TCP Vegas (ver).
Através deste tipo de incremento a janela será ajustada rapidamente até ao seu estado de equilíbrio; à
medida que a janela cresce, maior será o incremento; aumentando o RTT, o crescimento será bastante
atenuado.
O FAST TCP considera assim quatro componentes de controlo de congestão:
• Controlo de Dados;
Escolhe que tipo de segmentos transmitir (apenas utilizado para a estimação);
• Controlo de Janela;
Escolhe a quantidade de dados a transmitir;
• Controlo de Burst.
Escolhe o tempo que os irá transmitir, ligado aos tempos RTT que verificam o estado dos buffers.
A Figura 3.51 representa toda a arquitectura FAST TCP. Os campos a vermelho representam os campos
directamente relacionados; o controlo de janela afecta a estimação, a estimação afecta o controlo de
janela; o mesmo acontece com o controlo de burst; em relação ao controlo de dados, irá afectar a
estimação, mas a estimação não tem qualquer controlo sobre ele.
Figura 3.51 – Arquitectura FAST TCP (adaptado de [30] ).
91](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-113-320.jpg)
![TCP em Redes de Elevado Débito
3.6.7. Compound TCP
O Compound TCP [31] é especialmente importante por ser a versão usada pelo Windows Vista®, tendo
sido desenvolvida pela Microsoft®. As principais preocupações do Compound TCP são três:
• Eficiência em redes de alto débito;
• RTT fairness;
Tem obrigatoriamente de existir uma justiça na atribuição de recursos entre protocolos, especialmente
quando diferentes fluxos têm diferentes RTT.
• TCP fairness;
Não deve ser reduzida a perfomance de outros fluxos regulares a competir na mesma ligação, i.e., os
protocolos para alto débito devem usar a largura de banda disponível e não roubá-la de outros fluxos.
A ênfase dada nesta versão à forma como os fluxos TCP interagem é muito maior do que em todas as
versões anteriores.
Uma forma de ver esta versão é considerá-la uma junção entre a versão TCP Reno e TCP Vegas, este tipo
de versão já tinha sido verificado anteriormente com o TCP Veno (ver Cap. 3.5.5.1). Porém, o TCP
Compound é bem mais que uma simples junção, existindo algoritmos específicos para que as melhores
características de cada abordagem sejam realçadas.
A principal inovação nesta versão é a adição de uma 3ºjanela de congestão (após janela de receptor e
janela de congestão), a janela de atraso. A janela será responsável por cuidar de todas as alterações delay
based
44
. Algumas alterações efectuadas no normal incremento TCP foram:
),min( rwndlwndcwndwin +=
Com a adição da janela lwnd, o máximo de segmentos que é permitido ao emissor enviar será o mínimo
entre a janela de recepção, e a soma da janela de congestão com a janela de atraso
)(1 dwndcwndlcwndcwnd ++=
O incremento será também feito recorrendo à janela de atraso.
Não é efectuado nenhuma alteração à forma como é incrementada a normal janela de congestão. No que
diz respeito à janela de atraso, existe uma correspondência com a forma que o TCP Vegas decidia acerca
da mudança da janela de congestão; apesar dessa situação, a forma de diminuir e aumentar a dwnd já não
44
Variações no RTT ao longo do tempo de ligação.
92](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-114-320.jpg)
![3. Enquadramento ao Protocolo
é o normal incremento TCP, sendo utilizadas funções polinomiais que lhe permitem uma maior dinâmica
no crescimento.
A Figura 3.52 demonstra toda a dinâmica do uso destas duas janelas, sendo os pontos D, E, F, G os
pontos mais críticos de mudança. O TCP representa todo o normal crescimento da janela de congestão; o
DWND representa a janela de atraso; o CTCP referencia o funcionamento Compound TCP usando ambas
as janelas. As janelas são incrementadas até ao ponto E, a partir daí a janela de congestão (Janela Reno)
indica a continuação do aumento de envio de segmentos; por outro lado, a janela de atraso (janela Vegas)
indica que a rede está próxima da congestão, sendo necessário baixar o ritmo; a soma das duas janelas
revela a decisão tomada para o correcto funcionamento da rede.
Figura 3.52 – Representação do funcionamento das janelas de congestão e atraso Compound TCP.
3.6.8. Outros
As versões específicas para alto débito dividem-se, essencialmente, entre abordagens LCA ou DCA, ou
ambas; com maior justiça na atribuição de recursos, ou mais “agressivas”.
Para além das versões anteriores, existem variadas versões: TCP Africa, TCP Libra, TCP Paris, TCP
Rome, etc. Algumas destas versões utilizam também uma divisão em fluxos paralelos de dados para
alcançar maior eficiência na rede.
Outra forma de abordar a requisição de eficiência por parte da rede é utilizar a assistência dos próprios
routers utilizando mecanismos de congestão explícita (ver Cap. 2.1.5.2). Um importante protocolo para
essa operação é o XCP [32]. Esta forma de controlo de congestão foi primeiro explorada no conceito
ECN, sendo mais tarde generalizada no XCP.
93](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-115-320.jpg)
![TCP em Redes de Elevado Débito
No XCP o feedback45
acerca da carga existente na rede é baseado em sinal explícitos, providenciando aos
routers notificarem individualmente o seu estado de congestão.
As desvantagens desta abordagem são principalmente o facto de não ser respeitado o conceito extremo-a-
extremo da camada de transporte e ser necessário a alteração dos dispositivos de redes intermédios.
Apesar disso, também ainda não foi provado que este tipo de protocolo atinge maior perfomance que os
normais algoritmos de congestão implícita para alto débito [9].
3.7. Ponto de Situação
No que diz respeito a qual é a melhor versão para alto débito, a questão não se revela nada simples de
responder. Cada versão aborda o alto débito de diferente forma, existindo sempre condições da própria
rede, utilizadas para maximizar a eficiência dos seus testes. Porém, recorrendo à IETF como entidade
reguladora de todo o desenvolvimento de redes, o HighSpeed TCP será a versão que mais eficiência traz
ao alto débito, estando proposto para standard; seguidamente surge o Scalable TCP ainda em estado de
draft46
.
Apesar das normas recomendadas pela IETF, a situação em relação à adopção do Highspeed TCP não é
elevada, muito por culpa de não ser a versão por omissão de nenhum sistema operativo.
De uma forma simples poderemos definir a percentagem de utilização de uma versão pela percentagem de
utilização de um sistema operativo. Por exemplo: o TCP newReno sendo a única versão permitida ao
utilizador Windows® será utilizado em cerca de 90%, pois 90% é a percentagem aproximada de utilização
deste sistema operativo. O BIC e o Westwood são as versões por omissão do Linux (conforme a
distribuição), sendo então utilizadas cerca de 8%; apesar dessa situação é bastante simples alterar a versão
TCP no sistema operativo Linux.
Apesar desta simples relação são necessários estudos de maior grau de detalhe e complexidade. Esses
estudos para além das versões TCP devem também verificar a utilização de todos os diversos
mecanismos. O último desses estudos foi efectuado em Fevereiro de 2004 [33].
O estudo revelou-se bastante importante, na medida em que revelou todo o estado do TCP na Internet.
Baseou-se em testes a servidores Web induzindo diversas situações de perdas, re-ordenações, erros, etc.
com o objectivo principal de verificar os algoritmos de controlo de congestão dos servidores e seus
diversos mecanismos TCP. De igual forma, foram também testados os dispositivos intermédios
(Firewalls, NAT, proxies, etc) que prejudicam por vezes as comunicações extremo-a-extremo.
45
Notificação ao emissor.
46
Referência IETF a uma especificação ainda em estado de desenvolvimento.
94](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-116-320.jpg)
![3. Enquadramento ao Protocolo
O estudo revelou situações bastante surpreendentes: em relação às firewalls foi verificado que algumas
identificam a negociação de ECN como uma aplicação port-scanner47
, quebrando de imediato a ligação;
em relação aos servidores foram verificadas versões sem Fast Retransmit (sendo a única explicação
implementações defeituosas de um qualquer sistema operativo), e versões que não respeitavam as normas
dos números de sequência através de um mecanismo intitulado TCP/IP fingerprint scrubbers [34] para
protecção a ataques de hacking.
Neste teste não foram verificadas as versões para alto débito, tendo sido apenas efectuadas formas de
induzir mecanismos das versões newReno, Reno, ou Tahoe, principalmente a forma como reagiam a uma
simples perdas e a múltiplas perdas (diferença entre newReno e Reno). Os testes efectuados em 84394
servidores revelaram-se esclarecedores, estando representados na Tabela 3.4. A adopção do newReno
verifica-se bastante elevada, seguida do Reno (15%), existindo ainda a versão Tahoe (4%) em alguns
servidores.
Versão Percentagem de uso
newReno 76%
Reno 15%
Tahoe 4%
Outro 1%
Tabela 3.4 – Valores de percentagem de utilização do TCP Tahoe, Reno e newReno.
Como apenas foram testados alguns mecanismos, dentro da abrangência newReno poderão existir
algumas versões alto débito (baseados em LCA). É de referir também que 68% dos servidores efectua
correctamente a negociação para Sack, e 93% não permite negociação ECN. São agora necessários novos
estudos, de forma a ser verificado, detalhadamente, todo o processo de adopção das versões TCP para alto
débito.
47
O inglês “port scanner” significa escutador de portos, sendo uma aplicação muito utilizada para efeitos maliciosos.
95](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-117-320.jpg)
![TCP em Redes de Elevado Débito
4.Testes Práticos
Não é pretendido nos testes deste capítulo uma verificação exaustiva das várias implementações
existentes. Cada implementação foi já sujeita a diversos testes de perfomance, tendo como cenário
ambientes completamente reais48
[35]. O objectivo principal dos testes é verificar quais as versões TCP
disponíveis para o normal utilizador poder adquirir um maior grau de eficiência, principalmente,
considerando as redes de alto débito e grandes atrasos.
Ao longo deste capítulo existem considerações a ter em conta que não pertencem ao âmbito do TCP,
sendo igualmente importantes nos testes, algumas delas são:
• A velocidade da rede não pode ser mais rápida do que a velocidade da sua ligação mais lenta;
• A rede não pode ser mais rápida que a capacidade de memória da máquina mais lenta;
• A rede não pode ser mais rápida que o tamanho de janela oferecido pelo receptor sobre o RTT.
Esta fórmula é feita substituindo o tamanho da janela pelo BDP (ver Cap. 3.3.2.2), na fórmula
utilizada para calcular a capacidade da rede. A fórmula ficará a seguinte:
RTT
Janela
Throughput =
• Ter a certeza de que a amostra de tempo retirada permite verificar todas as condições, eliminando
qualquer incerteza na medição;
• Conhecimento de todas as interfaces utilizadas durante os testes: aplicações, buffers das
aplicações, placas de rede, buffers da rede, rede, etc.
• As componentes de simulação por vezes não têm resultados tão próximos da realidade;
• É bastante simples adquirir mais largura de banda (apenas com a desvantagem dos custos), sendo
bastante mais complicado adquirir menos atraso (implica modificações nos protocolos, sistema
operativo, interfaces de rede, etc.).
Os testes TCP de diversas publicações por vezes não se revelam também muito coerentes, tornando a sua
análise bastante difícil. Este facto prende-se, principalmente, com a dispersão de parâmetros que existem,
48
Sem recorrer a qualquer componente de simulação.
96](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-118-320.jpg)
![4. Testes Práticos
aquando a configuração dos cenários. Quase todos os testes efectuados às diversas versões são efectuados
com diferentes parâmetros, tornando bastante difícil uma correcta comparação entre eles. Provavelmente,
esse facto prende-se com razões de maximização de eficiência por parte de cada versão, funcionando
então os testes como uma prova de às comunidades de investigação, de todas as máximas potencialidades
da respectiva versão.
Cada vez mais se exigem correctas comparações, pelo que existem tentativas de tornar os cenários cada
vez mais genéricos entre as versões [36].
4.1. Testes Linux
O surgimento deste projecto teve como base os resultados apresentados no documento “Experimental
Evaluation of TCP Protocolos for High-Speed Networks” [5]. Neste artigo é mencionado o facto da
versão normal do TCP, newReno, não aproveitar convenientemente os recursos que as ligações
proporcionam em ambientes LFN. Como tal, antes de iniciar o desenvolvimento de uma nova versão,
realizaram-se testes num cenário bastante simples, tentando simular ao máximo as condições descritas no
documento, de modo a averiguar a validade das conclusões.
No capítulo seguinte são referenciadas todas as configurações, necessárias para a simulação do ambiente
de testes do artigo.
4.1.1. Planeamento dos testes
No artigo é relatado que o teste foi realizado numa ligação transatlântica entre Dublin e Chicago a 1Gbit/s
e atraso de propagação de 100ms. Para simular este cenário utilizaram-se 3 PCs, dois extremos para
enviar e receber os dados e um PC (Personal Computer) a ligar os outros dois; este último PC introduz
atraso aos segmentos. O esquema de configuração do cenário inicial encontra-se na Figura 4.1.
Figura 4.1 – Cenário Simulado Inicial.
97](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-119-320.jpg)
![TCP em Redes de Elevado Débito
A Tabela 4.1 representa as especificações dos PC utilizados, verificando-se uma máquina bastante
actualizada em termos de hardware e duas já com um hardware um pouco antigo.
PC CPU RAM Placa de Rede SO
Emissor 3GHz 512Mbytes Intel PRO/1000 CT Kubuntu 06.10
Receptor 1.1GHz 354Mbytes SMC Networks SMC9452TX-1 EZ
Card 1000
Kubuntu 06.10
Intermédia 1.1GHz 512Mbytes 2 x SMC Networks SMC9452TX EZ
Card 1000
FreeBSD 6.1
Tabela 4.1 – Especificações de Hardware e SO usado por PC.
As máquinas emissora e receptora utilizam o sistema operativo Linux, por ser o sistema operativo em que
primeiro se implementam todas as novas versão TCP, verificando-se também uma maior gama na escolha
das versões.
A distribuição escolhida foi o Kubuntu por ser actualmente dos mais utilizados e ter um grande apoio
técnico por parte das suas comunidade. A aplicação utilizada para gerar tráfego foi o Iperf [91]; a escolha
deste programa, deve-se ao facto desta aplicação ter sido usada para bater o recorde actual [95] do
máximo de largura de banda utilizada por um único fluxo TCP. Para a captura de segmentos utilizou-se o
Tcpdump [90] por ser a aplicação mais poderosa, superando o Wireshark [97]. Na descodificação dos
ficheiros gerados pelo Tcpdump utilizou-se o TRPR [94]. No PC intermédio que interliga o emissor e o
receptor foi utilizado o sistema operativo FreeBSD [96], com a aplicação Dummynet [92] para introduzir
atraso na ligação. Desta forma é simulada uma ligação transatlântica.
Devido a vários problemas encontrados, na tentativa de simular as características da rede mencionadas no
artigo, foi impossível verificar de forma coerente as conclusões do documento. O cenário que, devido a
todas as restrições encontradas, foi possível testar e que pretende simular um ambiente LFN, encontra-se
na Figura 4.2.
Figura 4.2 – Cenário Final.
98](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-120-320.jpg)
![4. Testes Práticos
sem ter a simulação do atraso configurada. Mesmo com a introdução de atraso esperam-se os mesmos os
resultados, diferindo apenas no facto de demorar mais tempo a verificar-se o congestionamento, pois a
aceleração do troughput depende inversamente do atraso. O eixo dos xx representa os segundos, o eixo
dos yy o débito alcançado, esta definição é valida para todos os testes deste capítulo.
Figura 4.4 – Largura de banda ocupada com velocidade de 1Gbit/s, sem qualquer tipo de atraso.
A resolução deste problema passaria pela utilização de hardware com maior capacidade de
processamento [98]. A Tecnologia TOE (TCP Offload Engine) [99] também poderá ser utilizada,
retirando assim bastante carga de processamento ao CPU nas operações de rede.
Configuração 100Mbit/s e atraso de 1000ms
Perante esta situação problemática, alterou-se a velocidade para 100Mbit/s e aumentou-se o atraso, de
modo a que o produto troughput/atraso se mantenha. A fórmula seguinte foi já anteriormente referenciada
(ver Cap. 3.3.2.2). Para a relação entre a velocidade e o atraso se manter o BDP será igual, logo, sabendo
a velocidade que é 100Mbit/s pode-se determinar que o atraso é de 1000ms.
atrasoMbitBDP
mssMbitBDP
×=
×=
100
100/1000
msatraso
ms
sMbit
sMbit
atraso
mssMbitsMbitatraso
1000
100
/100
/1000
100/1000/100
=
×=
×=×
Iniciou-se então a reconfiguração de todo o cenário.
Mesmo ao diminuir a largura de banda e aumentar o atraso proporcionalmente, não foi possível realizar o
teste proposto, pois com esta configuração o troughput ainda não atinge o valor desejado, atingindo cerca
de 35Mbit/s como se pode verificar pela Figura 4.5.
101](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-123-320.jpg)
![TCP em Redes de Elevado Débito
Figura 4.5 – Simulação com atraso de 1000ms e 100Mbit/s (dummynet)
Para tentar resolver este novo problema decidiu-se alterar os valores dos buffers do TCP para verificar se
o problema seria desta configuração. Inicialmente os buffers encontravam-se configurados da seguinte
forma:
net.ipv4.tcp_rmem=4096 87380 174760
net.ipv4.tcp_wmem=4096 16384 131072
net.ipv4.tcp_mem=4096 65536 98304
net.core.rmem_max=105472
net.core.wmem_max=105472
O valor máximo dos buffers foram alterados com o comando sysctl no valor de aproximadamente 16KB e
67MB, usando os valores recomendandos por um manual para gigabit em Linux [100] (sendo o máximo
um múltiplo de 2).
O primeiro passo, usando os buffers de 16KB:
sysctl –w net.ipv4.tcp_rmem=4096 87380 16777216
sysctl –w net.ipv4.tcp_wmem=4096 16384 16777216
sysctl –w net.ipv4.tcp_mem=4096 65536 16777216
sysctl –w net.core.rmem_max=16777216
sysctl –w net.core.wmem_max=16777216
O segundo passo, usando os buffers de 67MB:
sysctl –w net.ipv4.tcp_rmem=4096 87380 67108864
sysctl –w net.ipv4.tcp_wmem=4096 16384 67108864
sysctl –w net.ipv4.tcp_mem=4096 65536 67108864
102](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-124-320.jpg)
![TCP em Redes de Elevado Débito
A próxima tentativa foi utilizar outro programa que substituisse o gerador de atraso do dummynet. A
aplicação escolhida foi o Netem [93], que já vem integrado no kernel Linux. Para se efectuar a sua
configuração é apenas necessário introduzir o comando seguinte:
tc qdisc add dev eth0 root netem delay 500ms
Esta aplicação teve um desempenho, claramente, mais fraco que o Dummynet, como se pode verificar na
Figura 4.7. O máximo throughput atingido foi apenas de 11Mbit/s.
Figura 4.7 – Simulação com buffer máximo de 67MB e atraso de 1000ms (Netem)
Ao verificar-se que nenhuma das aplicações funcionava com os valores pretendido, decidiu-se diminuir o
atraso para metade (500ms). Desta forma, os requisitos para simulação dos testes efectuados no estudo
não conseguem ser correctamente cumpridos.
As configurações para implementar o novo atraso no Netem são:
tc qdisc add dev eth0 root netem delay 250ms
Os resultados, considerando, o Netem mantêm-se muito fracos.
Voltou-se a usar novamente o Dummynet por, claramente, apresentar resultados mais coerentes,
repetindo-se todos os testes realizados no Netem com o atraso configurado a 500ms:
ipfw pipe 1 config delay 500ms
Foram consideradas as duas situaçãoes de buffers referidas anteriormente, estando o resultado expresso na
Figura 4.8.
104](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-126-320.jpg)
![TCP em Redes de Elevado Débito
Ao analisar os resultados verifica-se que o atraso máximo para manter a largura de banda a 100Mbit/s é
de 300ms.
TRPR
Outro problema que surgiu foi o facto do TRPR, aplicação para descodificar o ficheiro gerado pelo
Tcpdump, não permitir descodificar ficheiros maiores que 2GB. Este facto gerou alguns problemas, pois
limita o tamanho de captura do Tcpdump. Como tal, os protocolos que aproveitavam melhor a largura de
banda só podem ser testados durante um menor período de tempo, pois os ficheiros gerados pelo
Tcpdump ultrapassam o limite imposto pelo TRPR. Em relação aos protocolos mais lentos, como
transferem menor quantidade de informação durante o mesmo período de tempo, os ficheiros do Tcpdump
não ultrapassam os limites do TRPR, logo, poderão ser testados num maior período de tempo.
Kernel Linux
Outra dificuldade que surgiu, foi o facto do kernel Linux, que vem por omissão com a distribuição
Kubuntu utilizada, não ser compilado com todas as versões do protocolo TCP que o Linux suporta. Como
tal, foi necessário compilar um novo kernel [101] para se poder utilizar todas as versões. Para adicionar
todas as versões, é necessário garantir que algumas opções que se encontram no ficheiro .config se
encontram selecionadas. Na primeira coluna encontram-se as opções por omissão, na segunda coluna
encontram-se todas as opções para as versões TCP que devem ser seleccionadas:
CONFIG_TCP_CONG_ADVANCED=n CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=n CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=n CONFIG_TCP_CONG_WESTWOOD=y
CONFIG_TCP_CONG_HTCP=n CONFIG_TCP_CONG_HTCP=y
CONFIG_TCP_CONG_HSTCP=n CONFIG_TCP_CONG_HSTCP=y
CONFIG_TCP_CONG_HYBLA=n CONFIG_TCP_CONG_HYBLA=y
CONFIG_TCP_CONG_VEGAS=n CONFIG_TCP_CONG_VEGAS=y
CONFIG_TCP_CONG_SCALABLE=n CONFIG_TCP_CONG_SCALABLE=y
CONFIG_TCP_CONG_LP=n CONFIG_TCP_CONG_LP=y
CONFIG_TCP_CONG_VENO=n CONFIG_TCP_CONG_VENO=y
106](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-128-320.jpg)
![TCP em Redes de Elevado Débito
Figura 4.20 – Simulação com a versão H-TCP (amostragem a 10s).
Figura 4.21 – Simulação com a versão H-TCP (amostragem a 5s).
4.1.4. Conclusões
Com a análise aos resultados obtidos através dos testes efectuados, constata-se facilmente que alguns
algoritmos não são próprios para alto débito, principalmente considerando redes LFN. O caso do
newReno foi demonstrado pelo artigo “Experimental Evaluation of TCP Protocolos for High-Speed
Network” [5], o qual se comprovou, também, através destes testes. No estudo, o protocolo é testado com
atraso real, sem qualquer componente simulado; os testes efectuados recorrem sempre a uma componente
simulada, que levantou diversos problemas (ver Cap. 4.1.2).
A falta de eficiência no aproveitamento da largura de banda não é só uma dificuldade do algoritmo Reno
pois o Westwood+, o Veno, o Vegas, também não são propícios para redes de alto débito e grande atraso.
No caso dos outros algoritmos, excepto o LP, existe um melhor aproveitamento da largura de banda por
terem sido desenvolvidos para o meio específico das redes LFN; é o caso do HighSpeed, Scalable, BIC,
114](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-136-320.jpg)
![4. Testes Práticos
CUBIC e H-TCP. Na Figura 4.22 estão todos os resultados dos testes de forma comparativa. A distinção
entre preparação para alto débito e a não preparação é bastante distingível.
Figura 4.22 – Simulação com todas as versões testadas.
De todas as principais versões do TCP as únicas que não foram testadas foram o FAST TCP (ver Cap.
3.6.6) e o Compound TCP (ver Cap. 3.6.7). A versão estável do TCP Compound apenas está disponível
no Microsof Windows Vista®, o FAST TCP ainda não se encontra estável o suficiente para ser inserido
no kernel Linux. Ainda em relação ao TCP Compound, este já se encontra em kernel de desenvolvimento.
Conclui-se também que para efectuar simulações deste tipo, caso não existam recursos suficientes para
efectuar os testes, recorreendo a componentes simuladas (geradores de atraso), deve-se optar por
plataformas de simulação. As plataformas de simulação, actualmente, estão bastante desenvolvidas e
conseguem resultados mais fiáveis do que usar cenários reais com componentes de simulação.
4.2. NS2
A principal vantagem de um simulador de redes de dados é, sem dúvida, a pouco necessidade de recursos.
Apesar desta situação, as plataformas de simulação são hoje bem mais do que só essa vantagem,
permitindo aos programadores diversas facilidades na implementação dos seus novos conceitos e
algoritmos. Existem dois principais simuladores: NS2 [103] e OPNET [104], e um simulador importante
por factos históricos: X-SIM [105]. Em relação ao X-SIM, utilizar a plataforma não se revela a melhor
opção, principalmente, devido ao facto da plataforma já ser bastante antiga e o seu desenvolvimento se
encontrar parado. O NS2 é uma plataforma Open-Source que não necessita de qualquer tipo de
licenciamento, ao contrário do OPNET [102] . Esse facto contribui decisivamente para a opção NS2 que
se encontra em grande desenvolvimento, sendo as únicas contrariedades o facto de existir menos
documentação e alguma falta de estabilidade no desenvolvimento de certos algoritmos.
115](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-137-320.jpg)
![TCP em Redes de Elevado Débito
O NS2 tem como base uma programação orientada aos objectos em C++, interligada com a linguagem de
script OTCL, também ela orientada aos objectos. A razão do NS2 usar estas duas linguagens é devido a
duas funções distintas que necessita de disponibilizar. A primeira função é fornecer detalhadas formas de
manipulações de bytes, cabeçalhos, implementações de diversos algoritmos, etc.; para este tipo de tarefas
é necessária maior preocupação no tempo de compilação. A segunda função tem como base a
configuração e reconfiguração rápida de cenários de rede, sendo mais prioritário o tempo que se demora a
alterar o código, do que propriamente compilá-lo (a configuração corre apenas uma vez, sem qualquer
ciclo).
A arquitectura NS é, então, composta por um cenário de rede que, conforme os dispositivos, estará ligado
a diversos algoritmos. Após toda a simulação efectuada poderão ser gerados ficheiros de trace49
, que
poderão ser posteriormente analisados por diversas aplicações. Toda esta arquitectura NS está
representada na Figura 4.23.
Figura 4.23 – Arquitectura NS (Fonte: [106]).
4.2.1. Classes TCP
As classes consideradas neste capítulo são as classes existentes na versão 2.30 do NS2, a mesma versão é
utilizada durante toda fase de implementação e testes.
As principais entidades de rede do NS2 são os nós, a aplicação e o agente. Estas entidades traduzem-se
em três classes: Node, Application, Agent. A classe Node não tem qualquer tipo associado. No que diz
respeito à classe Application existem diversos tipos associados [107], mas o único que permite a
49
Ficheiros para posterior análise de tráfego
116](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-138-320.jpg)
![4. Testes Práticos
utilização conjunta com um Agent TCP é o FTP (File Trasfer Protocol). Em relação à classe Agent
existem também alguns, sendo referenciados agora os TCP.
Existem dois tipos principais de TCP Agents: one-way Agents e two-way Agent. One-way Agents são
ainda sub-divididos numa gama de emissores TCP e receptores TCP (“sinks”).
O two-way Agent é considerado simétrico, devido ao facto de representar tanto um emissor como um
receptor. Este tipo está ainda em desenvolvimento pelo que não será utilizado.
Os emissores TCP one-way suportados por omissão estão representados na Tabela 4.2.
Agente Emissor Definição
Agent/TCP Um emissor TCP que utiliza a versão TCP Tahoe
(ver Cap. 3.5.1)
Agent/TCP/Reno Um emissor TCP que utiliza a versão TCP Reno
(ver Cap. 3.5.2)
Agent/TCP/Newreno Um emissor TCP que utiliza a versão TCP
newReno (ver Cap. 3.5.3).
Agent/TCP/Sack1 Um emissor TCP que utiliza Sack (ver Cap.
3.3.2.5) (é necessária a existência de um receptor,
também deste tipo, para que este protocolo
funcione).
Agent/TCP/Vegas Um emissor TCP que utiliza TCP Vegas (ver Cap.
3.5.4).
Agent/TCP/Fack Um emissor TCP Reno com FACK. Um algoritmo
que utiliza os blocos SACK para maior detalhe
sobre situações de congestão [37].
Tabela 4.2 – Definição dos Agentes Emissores TCP.
Considerado o outro extremo, os receptores TCP one-way, suportados por omissão, estão representados
na Tabela 4.3.
Agente Receptor Definição
Agent/TCPSink O normalmente utilizado, considera
117](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-139-320.jpg)
![4. Testes Práticos
patch [113], o utilizador NS2 tem, automaticamente, acesso a todas as versões TCP implementadas no
kernel mais recente do Linux. Para além disso, o código disponibilizado é exactamente o mesmo da stack
do sistema operativo, suportado por uma nova classe auxiliar criada para o efeito. A adição de qualquer
versão TCP deste sistema operativo pode também ser adicionada facilmente. As versões do TCP
disponibilizadas por esta implementação são neste momento: BIC, CUBIC, HighSpeed TCP, H-TCP,
Hybla, newReno, Scalable, Vegas, Westwood, Veno e Compound.
A nova classe Agent adicionada é a Agent/Linux. Nessa classe basta apenas efectuar a inicialização de
uma variável com a versão TCP pretendida, para que sejam invocados os algoritmos correspondentes. Um
simples cenário em que é utilizada esta implementação encontra-se no Anexo A.3.1.
É de referir também que esta versão, para além de todas as versões testadas, adiciona a versão Compound
TCP. Esta versão apenas se encontra implementada nos kernel mais instáveis, sendo essa a razão de não
existir no kernel usado anteriormente (ver Cap. 4.1).
4.2.3. Cenários
A definição de cenários em NS2 foi a primeira fase de todo o planeamento de testes depois da nova
versão implementada (ver Cap. 5.3). A principal preocupação dos cenários é conseguir que todos os
parâmetros que se pretende analisar sejam correctamente identificados. Foram definidos então dois
cenários:
• Cenário Lumbbell;
Este cenário é bastante conhecido de todas as comunidades de investigação do protocolo TCP. Baseia-se
essencialmente em 2 emissores, 2 routers e 2 receptores. As principais vantagens na utilização deste
cenário passam principalmente pela comparação de dois fluxos de duas versões diferentes, analisando
parâmetros como fairness e ocupação total de largura de banda. A configuração deste cenário encontra-se
representada na Figura 4.24, o respectivo script OTCL encontra-se no Anexo A.3.2.
119](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-141-320.jpg)
![5. EIC TCP
5.EIC TCP
Este capítulo corresponde à nova versão do protocolo TCP implementado.
Após toda a fase de estudo e testes práticos, o objectivo passou a ser a definição de novos parâmetros, que
fornecessem ao TCP novas formas de tratar todo o processo de congestão. Diversos conceitos surgiram,
baseados principalmente em algumas falhas das versões já implementadas. Obviamente os testes a essas
versões encontram-se já numa fase bastante avançada, verificando em maior detalhe algumas falhas. Este
facto veio facilitar imenso toda a análise efectuada.
5.1. Motivação
“Quando o emissor TCP aumenta a sua transmissão, o RTT pode não aumentar se não existir qualquer
tipo de congestionamento nas filas dos dispositivos. Este argumento é potencialmente válido para uma
ligação em que a ligação bottleneck tenha uma largura de banda bastante elevada”.[23]
O projecto foi iniciado através da verificação de um estudo [5]. A motivação para a nova versão iria
surgir, também, com base em outra publicação [23].
Existem duas motivações principais para todo o processo de especificação e posterior implementação:
• A cada vez mais fraca relação que existe entre o RTT e a taxa de transmissão da rede, à medida
que a largura de banda da rede aumenta;
• O Ack Compression [12] proporcionado pela filas de espera dos dispositivos, gerando alterações
bruscas no RTT de cada fluxo, sem necessariamente existir congestão.
A Relação Taxa de Transmissão e RTT
A relação existente entre a taxa de transmissão e o RTT não é muito fácil de analisar. As redes não têm a
mesma capacidade ao longo de todas as ligações, sendo aqui que surge o principal problema relacional.
Imaginando ligações conjuntas de baixo débito e alto débito, variados buffers das aplicações (sockets),
variados atrasos; existem uma série de condições que podem tornar a relação RTT e taxa de transmissão
muito reduzida.
121](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-143-320.jpg)
![TCP em Redes de Elevado Débito
A situação ideal para a maximização desta relação é ligações de baixo débito onde os buffers se
encontram sempre bastante sobrecarregados. A situação onde esta relação se encontra bastante
minimizada são ligações de alto débito, com tamanhos bastante curtos dos buffers aplicacionais e onde o
atraso seja reduzido; desta forma os buffers são muito menos testados, podendo existir atrasos que nada
têm a ver com congestão (opção por outros caminhos de rede, atraso variável do próprio meio etc.).
O conceito desta versão é tentar garantir que os buffers da rede se encontrem sempre em constantes testes,
retirando, após esses testes, as devidas decisões para as posteriores modificações na janela de congestão.
Ack Compression
Este problema já foi referido anteriormente, usando o TCP Vegas a técnica Spike Compression (ver Cap.
3.5.4) para atenuar esta situação. O problema desta técnica é que apenas limita a forma como o
espaçamento é efectuado, não definindo qualquer tipo específico de espaçamento. Esta nova versão tenta
contornar este problema, através de uma nova técnica de espaçamento entre os segmentos.
Estas duas situações, com a correcta solução implementada, poderão melhorar imenso toda a perfomance
TCP. A perfomance será adquirida, principalmente, porque as decisões a tomar ganham uma maior
garantia de que as filas estão mesmo congestionadas.
5.2. Especificação
“Supondo que um carro tem um controlo especial no pedal: o carro acelera com uma probabilidade ρ e
desacelera com uma probabilidade ρ-1, cada vez que o controlo é activado. A questão agora é: qual a
gama de valores para o qual ρ permite a arquitectura de um sistema fiável?”[23]
O principal problema de toda a especificação é não exagerar nos testes aos buffers, sob pena de em vez de
prevenir a congestão, aumentá-la.
Sendo o objectivo testar os buffers, nada melhor do que considerar a situação mais problemática para os
mesmos. Essa situação são segmentos enviados em burst.
Conforme o grau de congestionamento das filas, conforme a reacção ao burst; se as filas de encontrarem
bastante pouco sobrecarregadas, então o burst, provavelmente, passará pela rede como outro qualquer
conjunto de segmentos; se as filas se encontrarem com algum grau de congestionamento, então poderá
existir um aumento no RTT dos segmentos; se as filas estiverem já bastante congestionadas (situação
122](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-144-320.jpg)
![7. Bibliografia
7.Bibliografia
Livros
[1] STEVENS. R. – TCP/IP Illustrated, Volume 1; Addison-Wesley Professional, ISBN
0201633469, 1993.
[2] COMER. D. – Internetworking with TCP/IP, Fourth Edition; Prentice Hall, ISBN 0130183806,
2000.
[3] TANENBAUM. A. – Computer Networks, Fourth Edition; Prentice Hall, ISBN 0130661023,
2002.
[4] KOZIEROK. C. – The TCP/IP Guide, ISBN 159327047X, 2005, http://www.tcpipguide.com/
Artigos e Papers
[5] YEE-TING, L.; LEITH, D.; SHORTEN L. – Experimental Evaluation of TCP Protocols for
High-Speed Networks, Hamilton Institute, 2005.
[6] NOUREDDINE, W.; TOBAGI, F. – Transmission Control Protocol, ICIR, 2002.
[7] HOUSTON, G. – TCP Performance, The Internet Protocol Journal, Volume 3, Número 2, 2000.
[8] HOUSTON, G. – The Future for TCP, The Internet Protocol Journal, Volume 3, Número 3,
2000.
[9] HOUSTON, G. – Gigabit TCP, The Internet Protocol Journal, Volume 9, No. 2, Junho 2006.
[10] KARN, P.; PARTRIDGE, C.; Estimating Round-Trip Times in Reliable Transport Protocols,
Proceedings SIGCOMM’87, 1987.
[11] JAIN, RAJ. – A Timeout-Based Congestion Control Scheme for Window Flow-Controlled
Networks, IEEE Journal, 1987.
[12] MOGUL. J. – Observing TCP Dynamics in Real World, Western Research Laboratory,
Research Report 92/2, 1992.
[13] JABOBSON, V.; KARELS, M. – Congestion Avoidance and Control, Proceedings of
SIGCOMM’88, 1988.
149](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-171-320.jpg)
![TCP em Redes de Elevado Débito
[14] JACOBSON, V. – Modified TCP congestion avoidance algorithm, Mailing List end2end-
interest@ISI.EDU, 1990.
[15] BRAKMO, L.; O'MALLEY, S.; PETERSON L. – TCP Vegas: New techniques for congestion
detection and avoidance, Proceedings of SIGCOMM’94, 1994.
[16] AHN, J.; DANZIG, P.; LIE, Z.; YAM, L. – Evaluation of TCP Vegas: Emulation and
Experiment, Proceedings of SIGCOMM’95, 1995.
[17] BRAKMO, L., PETERSON. L. – TCP Vegas: End to End Congestion Avoidance on a Global
Internet, IEEE Journal on Selected Areas in Communication, Volume 13, Número 8, 1995.
[18] HENGARTNER U.; BOLLIGER J.; Gross, T. – TCP Vegas Revisited, INFOCOM00, 2000.
[19] HOE, J. – Improving Startup-Behavior of a Congestion Control Scheme for TCP, Proceedings
of SIGCOMM’96, 1996.
[20] CAINI, C.; FIRRINCIELLI, R. – TCP Hybla: a TCP enhancement for heterogeneous networks,
Internacional Journal of Sattelite Communications and Networking, 547–566, 2004.
[21] FU, C.; LIEW, S. – TCP Veno: TCP Enhancement for Transmission Over Wireless Access
Networks, IEEE Journal, Volume 91, Número 2, 2003.
[22] KUZMANOVIC, A.; KNIGHTLY, E. – TCP-LP: A Distributed Algorithm for Low Priority
Data Transfer, Rice University, 2003.
[23] BIAZ, S.; VAYDIA, N. – Is the Roundtrip Time Correlated with the Number of Packets in
Flight ?, Internet Measurement Conference 2003, 2003.
[24] CROWROFT, J.; OECHCSLIN, P. – Differentiated End-to-End Internet Services Using a
Weighted Proportional Fair Sharing TCP, ACM SIGCOMM Computer Communication
Review, Volume 28, Número 3, 1998.
[25] KELLY, T. – Scalable TCP: Improving Performance in High-Speed Wide Area Networks,
ACM SIGCOMM Computer Communication Review, Volume 33, Número 2, 2003.
[26] XU. L.; HARFOUSH, K.; RHEE. I. – Binary Increase Congestion Control (BIC) for Fast Long-
Distance Networks, Proceedings of IEEE INFOCOMM 2004, 2004.
[27] XU, L.; RHEE, I. – CUBIC: A New TCP-Friendly High-Speed TCP Variant, PFLDnet 2005,
2005.
[28] GERLA, M.; SANADIDI, Y.; WANG, R.; ZANELLA, A.; CASSETI, C.; MASCOLO, S. –
TCP Westwood: Congestion Window Control Using Bandwidth Estimation, Proceedings of
IEEE Globecom 2001, Volume 3, 2001.
150](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-172-320.jpg)
![7. Bibliografia
[29] DELL’AERA, A.; GRECO, L. – Linux 2.4 Implementation of Westwood+ TCP with Rate-
Halving: A Performance Evaluation over the Internet, Tech. Rep. Número 08/03/S, Politecnico
di Bari.
[30] JIN, C.; WEI, X.; LOW, S. – FAST TCP: Motivation, Architecture, Algorithms, Performance,
Proceedings of IEEE INFOCOM 2004, 2004.
[31] TAN, K.; JINGMIN, S.; ZHANG, Q.; SRIDHARAN, M. – A Compound TCP Approach for
High-speed and Long Distance Networks, Microsoft Research Publications, 2005.
[32] KATABI, D.; HANDLEY, M.; ROHRS, C. – Congestion Control for High Bandwidth-Delay
Product Networks, ACM SIGCOMM Computer Communication Review, Volume 32, Número
4, 2002.
[33] MEDINA, A.; FLOYD, S. – Measuring The Evolution of Protocol of Transport Protocols in the
Internet, ICIR, 2004.
[34] SMART, M; MALAN, G.; JAHANIAN F. – Defeating TCP/IP Stack Fingerprinting, 9th
USENIX Security Symposium, 2000.
[35] BULLOT, H.; COTTRELL, L; JONES, R. – Evaluation of Advanced TCP Stacks on Fast Long-
Distance production Networks, PFLDnet 2004, 2004.
[36] TIERNEY, B.; LEE, J. – Techniques for Testing Experimental Network Protocols, PFLDnet
2004, 2004.
[37] MATTIS, M.; MAHDAVI, J. – Forward Acknowledgement: Refining TCP Congestion Control,
Pittsburgh Supercomputer Center, 1996.
RFC e drafts
[38] POSTEL. J. – Transmission Control Protocol (RFC793), 1981, ftp://ftp.rfc-editor.org/in-
notes/rfc793.txt
[39] CLARK. D. – Window and Acknowledgment Strategy in TCP (RFC813), 1982, ftp://ftp.rfc-
editor.org/in-notes/rfc813.txt
[40] NAGLE. G. – Congestion control in IP/TCP internetworks (RFC896), 1984, ftp://ftp.rfc-
editor.org/in-notes/rfc896.txt
[41] BRADEN. R. – Requirements for Internet Hosts – Communication Layers (RFC1122), 1989,
ftp://ftp.rfc-editor.org/in-notes/rfc1122.txt
[42] JACOBSON, V.; BRADEN, R.; BORMAN, D. – TCP Extensions for High Perfomance
(RFC1323), 1992, ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt
151](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-173-320.jpg)
![TCP em Redes de Elevado Débito
[43] MATHIS, M.; MAHDAVI, J.; FLOYD, S.; ROMANOW, A. – TCP Selective Acknowledgment
Options (RFC2018), 1996, ftp://ftp.rfc-editor.org/in-notes/rfc2018.txt
[44] ALLMAN, M.; GLOVER, D.; SANCHEZ, L. – Enhancing TCP Over Satellite Channels using
Standard Mechanisms (RFC2488), 1999, ftp://ftp.rfc-editor.org/in-notes/rfc2488.txt
[45] ALLMAN, M. – TCP Congestion Control (RFC2581), 1999, ftp://ftp.rfc-editor.org/in-
notes/rfc2581.txt
[46] FLOYD, S.; HENDERSON, T. – The NewReno Modification to TCP’s Fast Recovery
Algorithm (RFC2582), 1999, ftp://ftp.rfc-editor.org/in-notes/rfc2582.txt
[47] FLOYD, S.; MAHDAVI, J.; MATHIS, M.; PODOLSKY, M. – An Extension to the Selective
Acknowledgement (SACK) Option for TCP (RFC2883), 2000, ftp://ftp.rfc-editor.org/in-
notes/rfc2883.txt
[48] ALLMAN, M.; BALAKRISHNAN, H.; FLOYD S. – Enhancing TCP's Loss Recovery Using
Limited Transmit (RFC3042), 2001, ftp://ftp.rfc-editor.org/in-notes/rfc3042.txt
[49] RAMAKRISHNAN, K.; FLOYD, S.; BLACK, D. – The Addition of Explicit Congestion
Notification (ECN) to IP (RFC3168), 2001, ftp://ftp.rfc-editor.org/in-notes/rfc3168.txt
[50] ALLMAN, M.; FLOYD, S.; PARTRIDGE, C. – Increasing TCP's Initial Window (RFC3390),
2002, ftp://ftp.rfc-editor.org/in-notes/rfc3390.txt
[51] FLOYD, S. – HighSpeed TCP for Large Congestion Windows (RFC3649), 2003, ftp://ftp.rfc-
editor.org/in-notes/rfc3649.txt
[52] FLOYD, S.; HENDERSON, T.; GURTOV, A. – The NewReno Modification to TCP's Fast
Recovery Algorithm (RFC3782), 2004, ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt
[53] KOHLER, E.; HANDLEY, M.; FLOYD S. – Datagram Congestion Control Protocol (DCCP)
(RFC3782), 2006, ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt
[54] FLOYD, S.; ALLMAN, M. – QuickStart for TCP and IP (RFC4782), 2007, ftp://ftp.rfc-
editor.org/in-notes/rfc4782.txt
[55] LEITH, S.; SHORTEN. R. – H-TCP: TCP Congestion Control for High Bandwidth-Delay
Product Paths, http://www.ietf.org/internet-drafts/draft-leith-tcp-htcp-03.txt
Apresentações
[56] LOUREIRO, P. – Diapositivos das aulas de Gestão Inteligente de Redes e Serviços, ESTG-
Leiria, 2006.
[57] VEIGA, N. – Diapositivos das aulas de Sistemas Operativos 2, ESTG-Leiria, 2003.
152](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-174-320.jpg)
![7. Bibliografia
[58] Prevenção e controlo de congestão, Disciplina de Sistemas Telemáticos, Universidade do
Minho, 2005.
[59] LOW, S. – TCP Congestion Control: Algoritms & Models, IPAM, 2002.
[60] NAVEEN, M. – TCP Variations, University of Delawan, 2005.
[61] ANIRBAN, M. – Transmission Control Protocol, University of Calgary, 2004.
[62] RAVOT, S. – TCP Transfers over high latency/bandwidth networks & Grid DT, PFLDnet,
2003.
[63] PRASAD. R.; JAIN, M.; DOVROLIS, C. – On the Effect of Delay Based Congestion
Avoidance, PFLDnet, 2004.
[64] K. NAKAUCHI, K.; BOBAYASHI, K. – Studying Congestion Control with Explicit Router
Feedback Using Hardware-based Network Emulator, PFLDnet, 2005.
Websites
[65] Bell 10Gbit/s Record, http://www.sciencedaily.com/releases/1999/05/990512000130.htm
[66] NTT 14Tbit/s Record, http://arstechnica.com/news.ars/post/20061002-7878.html
[67] IEC Tutorial, http://www.iec.org/online/tutorials/opt_ethernet/index.html
[68] TCP Maintenance and Minor Extensions, http://tools.ietf.org/wg/tcpm/
[69] Transport Area Working Group, http://tools.ietf.org/wg/tsvwg/
[70] Lawrence Berkeley Laboratory, http://www.lbl.gov/
[71] Paco Alto Research Center, http://www.parc.xerox.com/about/pressroom/news/2006-11-20-
contentcentric.html/
[72] IEEE, http://www.ieee.org/
[73] Special Interest Group, http://www.acm.org/sigs/guide98.html/
[74] SIGCOMM96, http://www.sigcomm.org/sigcomm96/program.html/
[75] ICSI, http://www.icsi.berkeley.edu/
[76] RED, http://en.wikipedia.org/wiki/Random_early_detection
[77] PDLDnet 2003, http://datatag.web.cern.ch/datatag/pfldnet2003/
[78] PFLDnet 2004, http://www-didc.lbl.gov/PFLDnet2004/
[79] PFLDnet 2005, http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/
[80] PFLDnet 2006, http://www.hpcc.jp/pfldnet2006/
[81] IANA Assignments TCP header flags, http://www.iana.org/assignments/tcp-header-flags/
[82] IANA Assignments TCP parameters, http://www.iana.org/assignments/tcp-parameters/
[83] Ethereal, http://www.ethereal.com/
153](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-175-320.jpg)
![TCP em Redes de Elevado Débito
[84] Ethernet and TCP Throughput Model, http://www.babinszki.com/Networking/Max-Ethernet-
and-TCP-Throughput.html/
[85] Description of Windows TCP features, http://support.microsoft.com/kb/224829/
[86] DEC, http://www.answers.com/topic/digital-equipment-corporation
[87] Kubuntu, http://www.kubuntu.org/
[88] Xgraph, http://www.xgraph.org/
[89] Gnuplot, http://www.gnuplot.info/
[90] Tcpdump, http://www.tcpdump.org/
[91] Iperf, http://dast.nlanr.net/Projects/Iperf/
[92] Dummynet, http://freshmeat.net/projects/dummynet/
[93] Netem, http://linux-net.osdl.org/index.php/Netem/
[94] Trpr, http://pf.itd.nrl.navy.mil/protools/trpr.html/
[95] Internet Land Speed Record, http://www.internet2.edu/lsr/
[96] FreeBSD, http://www.freebsd.org/
[97] Wireshark, http://www.wireshark.org/
[98] How to Achieve Gigabit Speeds in Linux, http://datatag.web.cern.ch/datatag/howto/tcp.html/
[99] TOE, http://www.networkworld.com/details/653.html/
[100] TCP Tuning Guide, http://www-didc.lbl.gov/TCP-tuning/linux.html/
[101] Kernel Compilation Ubuntu, http://www.howtoforge.com/kernel_compilation_ubuntu/
NS2
[102] LUCIO, G.; FARRERA, M.; JAMMEH, E., FLEURY, M.; REED, M. – OPNET Modeler and
Ns-2: Comparing the Accuracy of Network Simulators for Packet-Level Analysis using a
Network Testbed, University of Essex, 2003.
[103] NS2 Official Page, http://www.isi.edu/nsnam/ns/
[104] OPNET, http://www.opnet.com/
[105] X-SIM, http://nsr.bioeng.washington.edu/Software/XSIM/xsim_download.html/
[106] REIS, L.; VICENTE, M. –Tutorial Network Simulator, ESTG Leiria, 2006
[107] FALL, K.; VARADHAN, K. – The ns Manual, The VINT Project, 2006.
154](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-176-320.jpg)
![7. Bibliografia
[108] ALTMAN, E.; JIMENEZ, T. – NS Simulator for Begginers, University de Los Andes, 2003.
[109] ANTILA, J. – TCP Perfomance Simulations using NS2, Helsinki University of Tecnology, 1999
[110] NS Simulator Course for Beginners,
http://www.sop.inria.fr/mistral/personnel/Eitan.Altman/ns.htm/
[111] Pedro Vale Estrela – NS2, http://mega.ist.utl.pt/~pmsrve/ns2/
[112] Mark Greis’s Tutorial, http://www.isi.edu/nsnam/ns/tutorial/index.html/
[113] Linux TCP Implementation, http://www.cs.caltech.edu/~weixl/technical/ns2linux/index.html/
155](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-177-320.jpg)
![TAnexos
A análise do código das diversas versões implementadas é essencial para toda a compreensão da
implementação de uma nova versão. A localização no diverso código dos algoritmos e mecanismos
estudados na teórica é essencial nesta tarefa.
5. Nova Versão
A fase de implementação aborda todas as tarefas relacionadas com a nova versão do protocolo que se
pretende implementado.
5.1 Especificação 5.2 Implementação
A definição de tudo o que vai ser esta nova
versão.
Toda a parte de programação necessária ao
cumprimento da especificação é abordada nesta
tarefa.
5.3 Testes
Fase de controlo, e prova de tudo o que foi implementado.
A.2. Novo Protocolo
Neste anexo encontra-se o código inicial para a implementação de um novo protocolo TCP, baseado na
versão Reno. Para incluir o código na compilação NS são necessários alguns passos:
• No Makefile (directoria ns-2.30): Inserir Novo_Protocolo/Novo_Protocolo-end.o
• Colocar a pasta Novo_Protocolo em ns-2.30
• Compilar: make ns
• Pasta Novo_Protocolo: ns Novo_Protocolo-teste.tcl
• Confirmar o resultado: nam out.nam
A.2.1. Ficheiro novo_protocolo.cc
#ifndef lint
static const char rcsid[] =
"@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/xcp/xcp-end-sys.cc,v 1.7 2005/02/03
18:27:12 haldar Exp $";
#endif
163](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-185-320.jpg)
![TCP em Redes de Elevado Débito
//dynamically grow the timestamp array if it's getting full
if (bugfix_ts_ && window() > tss_size_* 0.9) {
double *ntss;
ntss = (double*) calloc(tss_size_*2, sizeof(double));
printf("resizing timestamp tablen");
if (ntss == NULL) exit(1);
for (int i=0; i<tss_size_; i++)
ntss[(highest_ack_ + i) % (tss_size_ * 2)] =
tss[(highest_ack_ + i) % tss_size_];
free(tss);
tss_size_ *= 2;
tss = ntss;
}
if (tss!=NULL)
tss[seqno % tss_size_] = tcph->ts();
tcph->ts_echo() = ts_peer_;
tcph->reason() = reason;
tcph->last_rtt() = int(int(t_rtt_)*tcp_tick_*1000);
if (ecn_) {
hf->ect() = 1; // ECN-capable transport
}
if (cong_action_ && (!is_retransmit || SetCWRonRetransmit_)) {
hf->cong_action() = TRUE; // Congestion action.
cong_action_ = FALSE;
}
/* Check if this is the initial SYN packet. */
if (seqno == 0) {
if (syn_) {
databytes = 0;
curseq_ += 1;
168](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-190-320.jpg)
![TAnexos
class Novo_ProtocoloSink : public TcpSink {
public:
Novo_ProtocoloSink(Acker* acker);
void recv(Packet* pkt, Handler*);
int command(int argc, const char*const* argv);
virtual void ack(Packet* opkt);
protected:
};
#endif /* ns_Novo_Protocolo_end_h */
A.3. Scripts
Neste anexo encontram-se os scripts com os cenários dos testes para se realizar as simulações.
A.3.1. Cenário Simples Linux NS2 Implementation
set ns [new Simulator]
#ficheiros com a janelas de congestão
#ficheiros com a largura de banda
set lb [open "lb1 1000Gb 100ms 1-.tr" w]
175](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-197-320.jpg)
![TCP em Redes de Elevado Débito
set winfile1 [open "winFile1 1000Gb 100ms 1-" w]
# Especifica um procedimento 'finish' para término da simulação
proc finish {} {
close $lb
close $winfile1
exit 0
}
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
set n4 [$ns node]
$ns duplex-link $n1 $n2 1000Mb 5ms DropTail
$ns duplex-link $n2 $n3 1000Mb 100ms DropTail
$ns duplex-link $n3 $n4 1000Mb 5ms DropTail
$ns queue-limit $n2 $n3 10000
set tcp1 [new Agent/TCP/Linux]
$tcp1 set timestamps_ true
$tcp1 set window_ 67108864
$ns at 0 "$tcp1 select_ca bic"
$tcp0 set packetSize_ 1460
$ns attach-agent $n1 $tcp1
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
set sink1 [new Agent/TCPSink/Sack1]
$sink1 set ts_echo_rfc1323_ true
176](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-198-320.jpg)
![TAnexos
$ns attach-agent $n6 $sink1
$ns connect $tcp1 $sink1
proc record {} {
global sink1 lb
#Criar uma inst cia do simulador
set ns [Simulator instance]
#Define o tempo depois do qual o procedimento deve ser chamado novamente
set time 0.9
#Quantos bytes foram recebidos pelos sinks?
set bw1 [$sink1 set bytes_]
#Obter o tempo actual
set now [$ns now]
#Calcular a largura de banda(MBit/s) e escrever nos ficheiros
puts $lb "$now [expr $bw1/$time*8/1000000]"
#Faz o reset aos bytes das fontes de traego (sink)
$sink1 set bytes_ 0
$ns at [expr $now+$time] "record"
}
proc plotWindow {tcpSource file} {
global ns
set time 0.1
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file"
}
# Definir tempos dos geradores de trafego
$ns at 0.0 "plotWindow $tcp1 $winfile1"
177](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-199-320.jpg)
![TCP em Redes de Elevado Débito
$ns at 0.0 "record"
$ns at 0.1 "$ftp1 start"
$ns at 1199.9 "$ftp1 stop"
# Processa o procedimento finish apos 1200 segundos de tempo de simulacao
$ns at 1200 "finish"
# Executa a simulacao
$ns run
A.3.2. Cenário Lumbbell
set ns [new Simulator]
#ficheiros com a janelas de congestão
#ficheiros com a largura de banda
set lb [open "lb1 1000Gb 100ms 1-.tr" w]
set lbb [open "lb2 1000Gb 100ms 1-.tr" w]
set lbt [open "lbt 1000Gb 100ms 1-.tr" w]
set winfile1 [open "winFile1 1000Gb 100ms 1-" w]
set winfile2 [open "winFile2 1000Gb 100ms 1-" w]
# Especifica um procedimento 'finish' para término da simulação
proc finish {} {
close $lb
close $lbb
close $winfile1
close $winfile2
exit 0
}
set n1 [$ns node]
set n2 [$ns node]
178](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-200-320.jpg)
![TAnexos
set n3 [$ns node]
set n4 [$ns node]
set n5 [$ns node]
set n6 [$ns node]
$ns duplex-link $n1 $n3 1000Mb 5ms DropTail
$ns duplex-link $n2 $n3 1000Mb 5ms DropTail
$ns duplex-link $n3 $n4 1000Mb 100ms DropTail
$ns duplex-link $n5 $n4 1000Mb 5ms DropTail
$ns duplex-link $n6 $n4 1000Mb 5ms DropTail
$ns queue-limit $n3 $n4 10000
$ns queue-limit $n1 $n3 10000
set tcp0 [new Agent/TCP/Reno/EIC]
$tcp0 set window_ 67108864
$tcp0 set packetSize_ 1460
$ns attach-agent $n1 $tcp0
set tcp1 [new Agent/TCP/Linux]
$tcp1 set timestamps_ true
$tcp1 set window_ 67108864
$ns at 0 "$tcp1 select_ca bic"
$tcp0 set packetSize_ 1460
$ns attach-agent $n2 $tcp1
set ftp0 [new Application/FTP]
$ftp0 attach-agent $tcp0
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
set sink0 [new Agent/TCPSink]
179](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-201-320.jpg)
![TCP em Redes de Elevado Débito
$ns attach-agent $n5 $sink0
set sink1 [new Agent/TCPSink/Sack1]
$sink1 set ts_echo_rfc1323_ true
$ns attach-agent $n6 $sink1
$ns connect $tcp0 $sink0
$ns connect $tcp1 $sink1
proc record {} {
global sink0 lb
global sink1 lbb
global all lbt
#Criar uma inst cia do simulador
set ns [Simulator instance]
#Define o tempo depois do qual o procedimento deve ser chamado novamente
set time 0.9
#Quantos bytes foram recebidos pelos sinks?
set bw1 [$sink0 set bytes_]
set bw2 [$sink1 set bytes_]
set bwt [expr $bw1+$bw2]
#Obter o tempo actual
set now [$ns now]
#Calcular a largura de banda(MBit/s) e escrever nos ficheiros
puts $lb "$now [expr $bw1/$time*8/1000000]"
puts $lbb "$now [expr $bw2/$time*8/1000000]"
puts $lbt "$now [expr $bwt/$time*8/1000000]"
#Faz o reset aos bytes das fontes de traego (sink)
$sink0 set bytes_ 0
$sink1 set bytes_ 0
$ns at [expr $now+$time] "record"
}
180](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-202-320.jpg)
![TAnexos
proc plotWindow {tcpSource file} {
global ns
set time 0.1
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file"
}
# Definir tempos dos geradores de trafego
$ns at 0.0 "plotWindow $tcp0 $winfile1"
$ns at 0.0 "plotWindow $tcp1 $winfile2"
$ns at 0.0 "record"
$ns at 0.1 "$ftp0 start"
$ns at 50 "$ftp1 start"
$ns at 1199.9 "$ftp0 stop"
$ns at 1199.9 "$ftp1 stop"
# Processa o procedimento finish apos 1200 segundos de tempo de simulacao
$ns at 1200 "finish"
# Executa a simulacao
$ns run
A.3.3. Cenário Internet
Este script tem como base outro script, anteriormente, efectuado em Stanford (ver
http://yuba.stanford.edu/rcp/).
Para se executar este script deve-se corer primeiro o ficheiro run.pl, depois o average.pl e por fim
executar a última linha de código deste capítulo para criar o gráfico.
Para correr a simulação deve-se correr o ficheiro run.pl. O conteúdo deste ficheiro encontra-se a seguir:
181](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-203-320.jpg)
![TCP em Redes de Elevado Débito
#!/usr/bin/perl -w
$numFlows = 100000;
$cap = 1;
$rtt = 0.1;
$load = 0.8;
$numbneck = 1;
$BWdelay = ($rtt*$cap*1000000000)/(1000*8);
$init_nr_flows = 100000;
#$meanFlowSize = $BWdelay/1000;
$meanFlowSize = 25;
@pareto_shape = (1.6); #, 1.8, 2.2);
for ($i = 0; $i < @pareto_shape; $i++) {
`nice -n +20 ns sim-tcp-pareto.tcl $numFlows $cap $rtt $load $numbneck $init_nr_flows
$meanFlowSize $pareto_shape[$i] > logFile`;
`mv logFile logFile-pareto-sh$pareto_shape[$i]`;
`mv flow.tr flow-pareto-sh$pareto_shape[$i].tr`;
`mv queue.tr queue-pareto-sh$pareto_shape[$i].tr`;
}
O ficheiro tcl que contem o cenário deve chamar-se sim-tcp-pareto.tcl e o seguinte código é o seu
conteúdo:
Class TCP_pair
TCP_pair instproc init {args} {
$self instvar pair_id group_id id debug_mode
$self instvar tcps tcpr;# Sender TCP, Receiver TCP
eval $self next $args
$self set tcps [new Agent/TCP/Linux] ;# Sender TCP
$tcps select_ca highspeed
182](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-204-320.jpg)
![TAnexos
$tcps set timestamps_ true
$tcps set window_ 67108864
$self set tcpr [new Agent/TCPSink/Sack1] ;# Receiver TCP
$tcpr set ts_echo_rfc1323_ true
$tcps set_callback $self
$tcpr set_callback $self
$self set pair_id 0
$self set group_id 0
$self set id 0
$self set debug_mode 1
#puts "init TCP_pair"
}
TCP_pair instproc set_debug_mode { mode } {
$self instvar debug_mode
$self set debug_mode $mode
}
TCP_pair instproc setup {snode dnode} {
#Directly connect agents to snode, dnode.
#For faster simulation.
global ns link_rate
$self instvar tcps tcpr;# Sender TCP, Receiver TCP
$self instvar san dan ;# memorize dumbell node (to attach)
$self set san $snode
$self set dan $dnode
$ns attach-agent $snode $tcps;
$ns attach-agent $dnode $tcpr;
183](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-205-320.jpg)
![TCP em Redes de Elevado Débito
$ns connect $tcps $tcpr
#puts "setup TCP_pair"
}
TCP_pair instproc create_agent {} {
$self instvar tcps tcpr;# Sender TCP, Receiver TCP
$self set tcps [new Agent/TCP/Reno] ;# Sender TCP
$self set tcpr [new Agent/TCPSink] ;# Receiver TCP
#puts "create_agent TCP_pair"
}
TCP_pair instproc setup_wnode {snode dnode link_dly} {
#New nodes are allocated for sender/receiver agents.
#They are connected to snode/dnode with link having delay of link_dly.
#Caution: If the number of pairs is large, simulation gets way too slow,
#and memory consumption gets very very large..
#Use "setup" if possible in such cases.
global ns link_rate
$self instvar sn dn ;# Source Node, Dest Node
$self instvar tcps tcpr;# Sender TCP, Receiver TCP
$self instvar san dan ;# memorize dumbell node (to attach)
$self instvar delay ;# local link delay
$self set delay link_dly
$self set sn [$ns node]
$self set dn [$ns node]
$self set san $snode
$self set dan $dnode
184](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-206-320.jpg)
![TAnexos
$ns duplex-link $snode $sn [set link_rate]Gb $delay DropTail
$ns duplex-link $dn $dnode [set link_rate]Gb $delay DropTail
$ns attach-agent $sn $tcps;
$ns attach-agent $dn $tcpr;
$ns connect $tcps $tcpr
#puts "setup_wnode TCP_pair"
}
TCP_pair instproc set_fincallback { controller func} {
$self instvar aggr_ctrl fin_cbfunc
$self set aggr_ctrl $controller
$self set fin_cbfunc $func
#puts "set_fincallback TCP_pair"
}
TCP_pair instproc set_startcallback { controller func} {
$self instvar aggr_ctrl start_cbfunc
$self set aggr_ctrl $controller
$self set start_cbfunc $func
#puts "set_startcallback TCP_pair"
}
TCP_pair instproc setgid { gid } {
$self instvar group_id
$self set group_id $gid
#puts "setgid TCP_pair"
}
TCP_pair instproc setpairid { pid } {
$self instvar pair_id
185](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-207-320.jpg)
![TCP em Redes de Elevado Débito
$self set pair_id $pid
#puts "setpairid TCP_pair"
}
TCP_pair instproc setfid { fid } {
$self instvar tcps tcpr
$self instvar id
$self set id $fid
$tcps set fid_ $fid;
$tcpr set fid_ $fid;
#puts "setfid TCP_pair"
}
TCP_pair instproc set_debug_mode { mode } {
$self instvar debug_mode
$self set debug_mode $mode
#puts "set_debug_mode TCP_pair"
}
TCP_pair instproc start { nr_pkts } {
global ns
$self instvar tcps id group_id
$self instvar start_time pkts
$self instvar aggr_ctrl start_cbfunc
$self instvar pair_id
$self instvar siz
$self instvar debug_mode
$self set start_time [$ns now] ;# memorize
$self set pkts $nr_pkts ;# memorize
set pktsize [$tcps set packetSize_]
186](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-208-320.jpg)
![TAnexos
if { $debug_mode == 1 } {
puts "stats: [$ns now] start grp $group_id fid $id $nr_pkts pkts
($pktsize +40)"
}
if { [info exists aggr_ctrl] } {
$aggr_ctrl $start_cbfunc
}
#set c [new Application/FTP]
#$c attach-agent $tcps
#$ns at $start_time "$c send [expr $pktsize * $nr_pkts]"
$self set siz [expr $pktsize * $nr_pkts]
$tcps send $siz
puts "start TCP_pair $start_time $siz"
}
TCP_pair instproc stop {} {
$self instvar tcps tcpr
$tcps reset
$tcpr reset
#puts "stop TCP_pair"
}
TCP_pair instproc fin_notify {} {
global ns
$self instvar sn dn san dan
$self instvar tcps tcpr
187](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-209-320.jpg)
![TCP em Redes de Elevado Débito
$self instvar aggr_ctrl fin_cbfunc
$self instvar pair_id
$self instvar pkts
$self instvar dt
$self instvar pps
$self flow_finished
$tcps reset
$tcpr reset
if { [info exists aggr_ctrl] } {
$aggr_ctrl $fin_cbfunc $pair_id $pkts $dt $pps
}
#puts "fin_notify TCP_pair"
}
TCP_pair instproc flow_finished {} {
global ns
$self instvar start_time pkts id group_id
$self instvar dt pps
$self instvar debug_mode
set ct [$ns now]
$self set dt [expr $ct - $start_time]
$self set pps [expr $pkts / $dt ]
if { $debug_mode == 1 } {
puts "stats: $ct fin grp $group_id fid $id fldur $dt sec $pps pps"
}
#puts "flow_finished TCP_pair"
}
188](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-210-320.jpg)
![TAnexos
Agent/TCP/Linux instproc set_callback {tcp_pair} {
$self instvar ctrl
$self set ctrl $tcp_pair
#puts "set_callback Reno"
}
Agent/TCPSink/Sack1 instproc set_callback {tcp_pair} {
$self instvar ctrl
$self set ctrl $tcp_pair
#puts "set_callback Reno"
}
Agent/TCP/Linux instproc done {} {
global ns sink
$self instvar ctrl
#puts "[$ns now] $self fin-ack received";
if { [info exists ctrl] } {
$ctrl fin_notify
}
#puts "done Reno "
}
Agent/TCPSink/Sack1 instproc done {} {
global ns sink
$self instvar ctrl
#puts "[$ns now] $self fin-ack received";
if { [info exists ctrl] } {
$ctrl fin_notify
}
#puts "done Reno "
}
189](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-211-320.jpg)
![TCP em Redes de Elevado Débito
Class Agent_Aggr_pair
Agent_Aggr_pair instproc init {args} {
eval $self next $args
#puts "init Agent_Aggr_pair"
}
Agent_Aggr_pair instproc attach-logfile { logf logf1} {
#Public
$self instvar logfile logfile1
$self set logfile $logf
$self set logfile1 $logf1
#puts "attach-logfile Agent_Aggr_pair"
}
Agent_Aggr_pair instproc setup {snode dnode gid nr agent_pair_type} {
$self instvar apair ;# array of Agent_pair
$self instvar group_id ;# group id of this group (given)
$self instvar nr_pairs ;# nr of pairs in this group (given)
$self set group_id $gid
$self set nr_pairs $nr
for {set i 0} {$i < $nr_pairs} {incr i} {
$self set apair($i) [new $agent_pair_type]
#$apair($i) setup_wnode $snode $dnode 0.01
$apair($i) setup $snode $dnode
$apair($i) setgid $group_id ;# let each pair know our group id
$apair($i) setpairid $i ;# let each pair know his pair id
}
$self resetvars ;# other initialization
#puts "setup Agent_Aggr_pair"
190](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-212-320.jpg)
![TCP em Redes de Elevado Débito
$self instvar rv_flow_intval rv_npkts
set pareto_shape $shape
set rng1 [new RNG]
$rng1 seed $rands1
$self set rv_flow_intval [new RandomVariable/Exponential]
$rv_flow_intval use-rng $rng1
$rv_flow_intval set avg_ [expr 1.0/$lambda]
set rng2 [new RNG]
$rng2 seed $rands2
$self set rv_npkts [new RandomVariable/Pareto]
$rv_npkts use-rng $rng2
$rv_npkts set avg_ $mean_npkts
$rv_npkts set shape_ $pareto_shape
#puts "set_PParrival_process Agent_Aggr_pair"
}
Agent_Aggr_pair instproc set_PEarrival_process {lambda mean_npkts rands1 rands2} {
#setup random variable rv_flow_intval and rv_npkts.
#To get the r.v. call "value" function.
#ex) $rv_flow_intval value
#- PEarrival
#flow arrival: poissson with rate lambda
#flow length : exp with mean mean_npkts pkts.
$self instvar rv_flow_intval rv_npkts
set rng1 [new RNG]
192](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-214-320.jpg)
![TAnexos
$rng1 seed $rands1
$self set rv_flow_intval [new RandomVariable/Exponential]
$rv_flow_intval use-rng $rng1
$rv_flow_intval set avg_ [expr 1.0/$lambda]
set rng2 [new RNG]
$rng2 seed $rands2
$self set rv_npkts [new RandomVariable/Exponential]
$rv_npkts use-rng $rng2
$rv_npkts set avg_ $mean_npkts
#puts "set_PEarrival_process Agent_Aggr_pair"
}
Agent_Aggr_pair instproc set_PBarrival_process {lambda mean_npkts S1 S2 rands1 rands2}
{
#Public
#setup random variable rv_flow_intval and rv_npkts.
#To get the r.v. call "value" function.
#ex) $rv_flow_intval value
#- PParrival:
#flow arrival: poissson with rate $lambda
#flow length : pareto with mean $mean_npkts pkts and shape parameter $shape.
$self instvar rv_flow_intval rv_npkts
set rng1 [new RNG]
$rng1 seed $rands1
$self set rv_flow_intval [new RandomVariable/Exponential]
$rv_flow_intval use-rng $rng1
193](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-215-320.jpg)
![TCP em Redes de Elevado Débito
$rv_flow_intval set avg_ [expr 1.0/$lambda]
set rng2 [new RNG]
$rng2 seed $rands2
$self set rv_npkts [new Binomial_RV]
$rv_npkts use-rng $rng2
$rv_npkts set p_ [expr (1.0*$mean_npkts - $S2)/($S1-$S2)]
$rv_npkts set S1_ $S1
$rv_npkts set S2_ $S2
if { $p < 0 } {
puts "In PBarrival, prob for bimodal p_ is negative %p_ exiting.. "
exit 0
} else {
puts "# PBarrival S1: $S1 S2: $S2 p_: $p_ mean $mean_npkts"
}
#puts "set_PBarrival_process Agent_Aggr_pair"
}
Agent_Aggr_pair instproc resetvars {} {
#Private
#Reset variables
$self instvar stat_nr_finflow ;# statistics nr of finished flows
$self instvar stat_sum_fldur ;# statistics sum of finished flow durations
$self instvar fid ;# current flow id of this group
$self instvar last_arrival_time ;# last flow arrival time
$self instvar actfl ;# nr of current active flow
$self instvar stat_nr_arrflow ;# statistics nr of arrived flows
$self instvar stat_nr_arrpkts ;# statistics nr of arrived packets
$self set last_arrival_time 0.0
194](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-216-320.jpg)
![TAnexos
$self set fid 0 ;# flow id starts from 0
$self set stat_nr_finflow 0
$self set stat_sum_fldur 0.0
$self set stat_sum_pps 0.0
$self set actfl 0
$self set stat_nr_arrflow 0
$self set stat_nr_arrpkts 0
#puts "resetvars Agent_Aggr_pair"
}
Agent_Aggr_pair instproc schedule { pid } {
#Private
#Note:
#Schedule pair (having pid) next flow time
#according to the flow arrival process.
global ns
$self instvar apair
$self instvar fid
$self instvar last_arrival_time
$self instvar rv_flow_intval rv_npkts
$self instvar stat_nr_arrflow
$self instvar stat_nr_arrpkts
set dt [$rv_flow_intval value]
set tnext [expr $last_arrival_time + $dt]
set t [$ns now]
if { $t > $tnext } {
puts "Error, Not enough flows ! Aborting! pair id $pid"
flush stdout
195](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-217-320.jpg)
![TCP em Redes de Elevado Débito
exit
}
$self set last_arrival_time $tnext
$apair($pid) setfid $fid
incr fid
set tmp_ [expr ceil ([$rv_npkts value])]
incr stat_nr_arrflow
$self set stat_nr_arrpkts [expr $stat_nr_arrpkts + $tmp_]
$ns at $tnext "$apair($pid) start $tmp_"
#puts "schedule at $tnext $pid $tmp_"
}
Agent_Aggr_pair instproc fin_notify { pid pkts fldur pps } {
global ns
$self instvar logfile
$self instvar stat_sum_fldur stat_nr_finflow stat_sum_pps
$self instvar group_id
$self instvar actfl
$self instvar apair
#Here, we re-schedule $apair($pid).
#according to the arrival process.
$self set actfl [expr $actfl - 1]
incr stat_nr_finflow
$self set stat_sum_fldur [expr $stat_sum_fldur + $fldur]
196](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-218-320.jpg)
![TAnexos
$self set stat_sum_pps [expr $stat_sum_pps + $pps]
set fin_fid [$apair($pid) set id]
###### OUPUT STATISTICS #################
if { [info exists logfile] } {
puts $logfile "flow_stats: [$ns now] gid $group_id fid $fin_fid pkts $pkts
fldur $fldur avgfldur [expr $stat_sum_fldur/$stat_nr_finflow] actfl $actfl avgpps
[expr $stat_sum_pps/$stat_nr_finflow] finfl $stat_nr_finflow"
}
$self schedule $pid ;# re-schedule a pair having pair_id $pid.
#puts "fin_notify Agent_Aggr_pair"
}
Agent_Aggr_pair instproc start_notify {} {
#Callback Function
#Note:
#If we registor $self as "setcallback" of
#$apair($id), $apair($i) will callback this
#function with argument id when the flow between the pair finishes.
#i.e.
#If we set: "$apair(13) setcallback $self" somewhere,
#"start_notyf 13" is called when the $apair(13)'s flow is started.
global ns
$self instvar logfile1
$self instvar group_id
$self instvar actfl
incr actfl;
if { [info exists logfile1] } {
197](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-219-320.jpg)
![TCP em Redes de Elevado Débito
puts $logfile1 "flow_stats: [$ns now] gid $group_id actfl $actfl"
}
#puts "start_notify Agent_Aggr_pair"
}
Agent_Aggr_pair instproc statistics {} {
$self instvar stat_nr_finflow ;# statistics nr of finished flows
$self instvar stat_sum_fldur ;# statistics sum of finished flow durations
$self instvar fid ;# current flow id of this group
$self instvar last_arrival_time ;# last flow arrival time
$self instvar actfl ;# nr of current active flow
$self instvar stat_nr_arrflow ;# statistics nr of arrived flows
$self instvar stat_nr_arrpkts ;# statistics nr of arrived packets
puts "Aggr_pair statistics1: $self arrflows $stat_nr_arrflow finflow
$stat_nr_finflow remain [expr $stat_nr_arrflow - $stat_nr_finflow]"
puts "Aggr_pair statistics2: $self arrpkts $stat_nr_arrpkts avg_flowsize [expr
$stat_nr_arrpkts/$stat_nr_arrflow]"
#puts "statistics Agent_Aggr_pair"
}
#add/remove packet headers as required
#this must be done before create simulator, i.e., [new Simulator]
remove-all-packet-headers ;# removes all except common
add-packet-header Flags IP TCP ;# hdrs reqd for TCP (Do not remove "Flags")
set ns [new Simulator]
puts "Date: [clock format [clock seconds]]"
set sim_start [clock seconds]
puts "Host: [exec uname -a]"
198](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-220-320.jpg)
![TAnexos
#set tf [open traceall.tr w]
#$ns trace-all $tf
#set nf [open out.nam w]
#t$ns namtrace-all $nf
if {$argc != 8} {
puts "usage: ns xxx.tcl numflows link_rate(Gbps) RTT(per hop,sec) load numbneck
init_nr_flows meanFlowSize pareto_shape"
exit 0
}
set numflows [lindex $argv 0]
set link_rate [lindex $argv 1]
set mean_link_delay [expr [lindex $argv 2] / 2.0]
set load [lindex $argv 3]
set numbneck 1
set init_nr_flow [lindex $argv 5]
set mean_npkts [lindex $argv 6]
set pareto_shape [lindex $argv 7]
puts "Simulation input:"
puts "TCP Single bottleneck"
puts "numflows $numflows"
puts "link_rate $link_rate Gbps"
puts "RTT [expr $mean_link_delay * 2.0] sec"
puts "load $load"
puts "numbneck $numbneck"
puts "init_nr_flow $init_nr_flow"
puts "mean flow size $mean_npkts pkts"
puts "pareto shape $pareto_shape"
puts " "
#packet size is in bytes.
199](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-221-320.jpg)
![TCP em Redes de Elevado Débito
set pktSize 1460
puts "pktSize(payload) $pktSize Bytes"
puts "pktSize(include header) [expr $pktSize + 40] Bytes"
#Random Seed
set arrseed 4
set pktseed 7
puts "arrseed $arrseed pktseed $pktseed"
set lambda [expr ($link_rate*$load*1000000000)/($mean_npkts*($pktSize+40)*8.0)]
puts "Arrival: Poisson with lambda $lambda, FlowSize: Pareto with avg $mean_npkts pkts
shape $pareto_shape"
set sim_end 200
puts "sim_end $sim_end sec (may not be reached)"
#Only for TCP
Agent/TCP/Reno set packetSize_ $pktSize
#Agent/TCP set packetSize_ $pktSize
set tcpwin_ [expr 4 * int (ceil (($mean_link_delay * 2.0 * $link_rate *
1000000000.0/8.0) / ($pktSize+40.0)))]
Agent/TCP/Reno set window_ $tcpwin_
#Agent/TCP set window_ $tcpwin_
puts "Agent/TCP/Reno/CTN set window_ $tcpwin_"
############ Buffer SIZE ######################
#In case TCP , BWxRTT
set queueSize [expr int (ceil (($mean_link_delay * 2.0 * $link_rate *
1000000000.0/8.0) / ($pktSize+40.0)))]
Queue set limit_ $queueSize
puts "queueSize $queueSize packets"
200](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-222-320.jpg)
![TAnexos
############# Topoplgy #########################
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
$ns duplex-link $n0 $n1 [set link_rate]Gb 90ms DropTail
$ns duplex-link $n2 $n0 [expr $link_rate*2]Gb 5ms DropTail
$ns duplex-link $n1 $n3 [expr $link_rate*2]Gb 5ms DropTail
$ns queue-limit $n1 $n0 $queueSize
$ns queue-limit $n0 $n1 $queueSize
set bnecklink [$ns link $n0 $n1]
############# Agents #########################
set agtagr0 [new Agent_Aggr_pair]
puts "Creating initial $init_nr_flow agents ..."; flush stdout
$agtagr0 setup $n2 $n3 0 $init_nr_flow "TCP_pair"
#$agtagr0 setup $n0 $n1 0 $init_nr_flow "TCP_pair"
set flowlog [open flow.tr w]
set flowlog1 [open start.tr w]
$agtagr0 attach-logfile $flowlog $flowlog1
puts "Initial agent creation done";flush stdout
#For Poisson/Pareto
$agtagr0 set_PParrival_process $lambda $mean_npkts $pareto_shape $arrseed $pktseed
$agtagr0 init_schedule
201](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-223-320.jpg)
![TCP em Redes de Elevado Débito
$agtagr0 statistics
puts "Simulation started!"
$ns at 0.0 "check_fin"
proc check_fin {} {
global ns agtagr0 numflows
set nrf [$agtagr0 set stat_nr_finflow]
if { $nrf > $numflows } {
$agtagr0 statistics
finish
}
#puts "nr_finflow $nrf"
$ns after 1 "check_fin"
}
############# Queue Monitor #########################
set qf [open queue.tr w]
set qm [$ns monitor-queue $n0 $n1 $qf 0.1]
$bnecklink queue-sample-timeout
#$bnecklink start-tracing
$ns at $sim_end "finish"
proc finish {} {
global ns qf flowlog
global sim_start
$ns flush-trace
close $qf
close $flowlog
202](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-224-320.jpg)
![TAnexos
set t [clock seconds]
puts "Simulation Finished!"
puts "Time [expr $t - $sim_start] sec"
puts "Date [clock format [clock seconds]]"
exit 0
}
$ns run
Para analisar os ficheiros criados pelo script run.pl deve usar-se o ficheiro average.pl para este retirar os
resultados. O ficheiro encontra-se a seguir:
#!/usr/bin/perl -w
@fNameIn = ("flow-pareto-sh1.6.tr");
@fNameOut = ("flowSizeVsDelay-sh1.6");
$maximum = 0;
for ($i=0; $i<=$#fNameIn; $i++) {
for ($j=0; $j< 10000000; $j++) {
$sumDur[$j] = 0;
$avgDur[$j] = 0;
$maxDur[$j] = 0;
$numFlows[$j] = 0;
}
open(fileOut, ">$fNameOut[$i]") or die("Can't open $fNameOut[$i] for writing:
$!");
open(fileIn, "$fNameIn[$i]") or die ("Can't open $fNameIn[$i]: $!");
$maximum = 0;
$simTime = 0;
203](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-225-320.jpg)
![TCP em Redes de Elevado Débito
while (<fileIn>) {
chomp;
@items = split;
if ($items[7] > $maximum) {
$maximum = $items[7];
}
$sumDur[$items[7]] += $items[9];
if ($items[9] > $maxDur[$items[7]]) {
$maxDur[$items[7]] = $items[9];
}
$numFlows[$items[7]] += 1;
$avgDur[$items[7]] = $sumDur[$items[7]] / $numFlows[$items[7]];
}
for ($j=1; $j<= $maximum; $j++) {
if ($avgDur[$j] != 0) {
printf fileOut "$j sum_ $sumDur[$j] numFlows_ $numFlows[$j] avg_ $avgDur[$j]
max_ $maxDur[$j] n";
}
}
close(fileIn);
close(fileOut);
}
Para fazer o gráfico através dos ficheiros gerados pelo average.pl deve usar-se a seguinte linha:
cut -f1,7 -d" " flowSizeVsDelay-sh1.6 > grafico
A.4. Código EIC TCP
Nesta secção encontra-se o código alterado do protocolo.
204](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-226-320.jpg)
![TAnexos
A.4.1. Ficheiro eic-end.cc
#ifndef lint
static const char rcsid[] =
"@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/xcp/xcp-end-sys.cc,v 1.7 2005/02/03
18:27:12 haldar Exp $";
#endif
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include "ip.h"
#include "tcp.h"
#include "flags.h"
#include "agent.h"
#include "packet.h"
#include "flags.h"
#include "tcp-sink.h"
#include "eic-end.h"
#include "random.h"
#include "hdr_qs.h"
#define TRACE 0 // when 0, we don't print any debugging info.
static class EicRenoTcpClass : public TclClass {
public:
EicRenoTcpClass() : TclClass("Agent/TCP/Reno/EIC") {}
TclObject* create(int, const char*const*) {
return (new EicAgent());
205](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-227-320.jpg)
![TCP em Redes de Elevado Débito
void EicAgent::output(int seqno, int reason)
{
int force_set_rtx_timer = 0;
Packet* p = allocpkt();
hdr_tcp *tcph = hdr_tcp::access(p);
hdr_flags* hf = hdr_flags::access(p);
hdr_ip *iph = hdr_ip::access(p);
int databytes = hdr_cmn::access(p)->size();
tcph->seqno() = seqno;
tcph->ts() = Scheduler::instance().clock();
int is_retransmit = (seqno < maxseq_);
// Mark packet for diagnosis purposes if we are in Quick-Start Phase
if (qs_approved_) {
hf->qs() = 1;
}
// store timestamps, with bugfix_ts_. From Andrei Gurtov.
// (A real TCP would use scoreboard for this.)
if (bugfix_ts_ && tss==NULL) {
tss = (double*) calloc(tss_size_, sizeof(double));
if (tss==NULL) exit(1);
}
//dynamically grow the timestamp array if it's getting full
if (bugfix_ts_ && window() > tss_size_* 0.9) {
double *ntss;
ntss = (double*) calloc(tss_size_*2, sizeof(double));
printf("resizing timestamp tablen");
if (ntss == NULL) exit(1);
for (int i=0; i<tss_size_; i++)
ntss[(highest_ack_ + i) % (tss_size_ * 2)] =
220](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-242-320.jpg)
![TAnexos
tss[(highest_ack_ + i) % tss_size_];
free(tss);
tss_size_ *= 2;
tss = ntss;
}
if (tss!=NULL)
tss[seqno % tss_size_] = tcph->ts();
tcph->ts_echo() = ts_peer_;
tcph->reason() = reason;
tcph->last_rtt() = int(int(t_rtt_)*tcp_tick_*1000);
if (ecn_) {
hf->ect() = 1; // ECN-capable transport
}
if (cong_action_ && (!is_retransmit || SetCWRonRetransmit_)) {
hf->cong_action() = TRUE; // Congestion action.
cong_action_ = FALSE;
}
/* Check if this is the initial SYN packet. */
if (seqno == 0) {
if (syn_) {
databytes = 0;
curseq_ += 1;
hdr_cmn::access(p)->size() =
tcpip_base_hdr_size_;
}
if (ecn_) {
hf->ecnecho() = 1;
// hf->cong_action() = 1;
hf->ect() = 0;
}
221](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-243-320.jpg)
![TCP em Redes de Elevado Débito
* 0 0 0 reno_action
* 0 0 1 reno_action [impossible]
* 0 1 0 reno_action
* 0 1 1 retransmit, return
* 1 0 0 nothing
* 1 0 1 nothing [impossible]
* 1 1 0 nothing
* 1 1 1 retransmit, return
*/
void EicAgent::dupack_action()
{
/* Executa se a janela tiver aumentado, estipulando o máximo que a
janela de congetão
pode crescer para não aumentar demasiado rápido transmitindo mais
que a capacidade
da rede */
if(max_cwnd_decreased_ == 0)
{
max_cwnd_ = cwnd_*2/3;
temp_max_cwnd_ = 0;
max_cwnd_decreased_ = 1;
}
int recovered = (highest_ack_ > recover_);
int allowFastRetransmit = allow_fast_retransmit(last_cwnd_action_);
if (recovered || (!bug_fix_ && !ecn_) || allowFastRetransmit
|| (bugfix_ss_ && highest_ack_ == 0)) {
// (highest_ack_ == 0) added to allow Fast Retransmit
// when the first data packet is dropped.
// From bugreport from Mark Allman.
goto reno_action;
}
226](https://image.slidesharecdn.com/project-190623000053/85/New-TCP-version-for-large-bandwidth-networks-248-320.jpg)
New TCP version for large bandwidth networks
- 1. Instituto Politécnico deLeiria 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
- 3. Instituto Politécnico deLeiria 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
- 5. Dedicatória Dedicatória Seguindo o carácterpessoal 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
- 6. TCP em Redesde 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
- 7. Resumo Resumo Através de uumapublicaçã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
- 8. TCP em Redesde Elevado Débito Í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
- 9. Í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
- 10. TCP em Redesde Elevado Débito 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
- 11. Í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
- 12. TCP em Redesde Elevado Débito 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
- 13. Lista de Siglase 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
- 14. TCP em Redesde Elevado Débito 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
- 15. Lista de Figuras Listade 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
- 16. TCP em Redesde Elevado Débito 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
- 17. Lista de Figuras Figura3.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
- 18. TCP em Redesde Elevado Débito 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
- 19. Lista de Figuras Figura5.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
- 20. TCP em Redesde Elevado Débito 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
- 21. Lista e Definiçãode 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
- 22. TCP em Redesde Elevado Débito 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
- 23. 1. Introdução 1.Introdução Ao contráriode 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
- 24. TCP em Redesde Elevado Débito 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
- 25. 2. Planeamento • Umponto 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
- 26. TCP em Redesde Elevado Débito 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
- 27. 2. Planeamento Restrições danova 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
- 28. TCP em Redesde Elevado Débito 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
- 29. 2. Planeamento Em relaçãoa 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
- 30. TCP em Redesde Elevado Débito 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
- 31. 2. Planeamento estável). Irãotambé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
- 32. TCP em Redesde Elevado Débito 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
- 33. 2. Planeamento Figura 2.8– Gráfico de Gantt, representativo da sequência e relacionamento entre actividade. 11
- 34. TCP em Redesde Elevado Débito 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
- 35. 3. Enquadramento aoProtocolo 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
- 36. TCP em Redesde Elevado Débito 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
- 37. 3. Enquadramento aoProtocolo 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
- 38. TCP em Redesde Elevado Débito 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
- 39. 3. Enquadramento aoProtocolo 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
- 40. TCP em Redesde Elevado Débito 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
- 41. 3. Enquadramento aoProtocolo 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
- 42. TCP em Redesde Elevado Débito 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
- 43. 3. Enquadramento aoProtocolo 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
- 44. TCP em Redesde Elevado Débito 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
- 45. 3. Enquadramento aoProtocolo 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
- 46. TCP em Redesde Elevado Débito 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
- 47. 3. Enquadramento aoProtocolo • 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
- 48. TCP em Redesde Elevado Débito 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
- 49. 3. Enquadramento aoProtocolo • 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
- 50. TCP em Redesde Elevado Débito • 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
- 51. 3. Enquadramento aoProtocolo 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
- 52. TCP em Redesde Elevado Débito 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
- 53. 3. Enquadramento aoProtocolo 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
- 54. TCP em Redesde Elevado Débito • 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
- 55. 3. Enquadramento aoProtocolo - 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
- 56. TCP em Redesde Elevado Débito Em relação às opções o MSS é negociado, assim como o Sack. O MSS e o Sack são sempre negociados no início do estabelecimento da ligação, i.e., quando a flag SYN está activada. Figura 3.10 – Primeiro segmento TCP de uma sessão de dados. Após o estabelecimento da ligação de dados, os valores das sequências já não são gerados aleatoriamente. O cabeçalho capturado representando na Figura 3.11 é o segundo segmento TCP após o correcto estabelecimento da ligação. Por essa mesma razão o número de sequência não é “1”, mas “625”, i.e., o tamanho do primeiro segmento mais “1”. O tamanho do campo Window manteve-se inalterado em relação à Figura anterior. Este facto não indica que o buffer do receptor não está carregado, pois provavelmente o emissor ainda não recebeu o ack do receptor que irá notificar de novo a sua Window. Figura 3.11 – Primeiro segmento TCP, após estabelecimento da sessão. 3.3.2. Os mecanismos Os mecanismos genéricos, em conjunto com o cabeçalho, estão presentes em todas as versões TCP existentes, proporcionando fiabilidade e controlo. Essa fiabilidade e controlo de fluxo são garantidas com algumas das seguintes formas: • Quando o TCP envia um segmento é mantido um temporizador, que espera até que o receptor o notifique da recepção. Se a notificação não é recebida durante o tempo do temporizador, o 34
- 57. 3. Enquadramento aoProtocolo segmento volta a ser retransmitido. Para este procedimento o emissor guarda uma cópia do segmento transmitido, pronta a ser retransmitida; • Quando o TCP recebe os segmentos de dados do receptor ele envia uma notificação ao emissor, essa notificação é chamada de acknowledgement, ou abreviando, ack; • TCP mantém um checksum no seu cabeçalho. O checksum é extremo-a-estremo, com o objectivo de detectar qualquer modificação dos dados na rede. Se um segmento chegar ao receptor com o checksum inválido o TCP automaticamente o descarta, não transmitindo qualquer ack de recepção. • Os segmentos TCP são transmitidos em pacotes IP, podendo chegar fora de ordem ao receptor por diversas razões, algumas delas de encaminhamento. Devido a essa razão, o receptor TCP consegue voltar a sequenciar os dados se necessário, passando os dados de forma correcta para a aplicação; • Os dados podem também chegar em duplicado, nesse caso o receptor TCP descarta os pacotes redundantes; • Cada extremo de uma conexão TCP tem um tamanho de buffer finito. O receptor TCP só permite ao outro extremo lhe enviar dados para os quais o seu buffer está preparado. [1] Todos estes funcionamentos são conseguidos através de mecanismos interligados, sendo a base de todo o protocolo. Para qualquer posterior desenvolvimento a nível de congestão no TCP é necessária a aprendizagem de alguns deles, principalmente aqueles directamente ligados à eficiência. 3.3.2.1. Acks e Piggybacking Os acks são uma presença constante em todos os protocolos orientados à ligação, esta situação não foge a regra no protocolo TCP. Numa sessão de dados os acks servem, essencialmente, para existir notificação de recebimento por parte de determinada entidade receptora, a partir daí a entidade emissora descarta toda a responsabilidade no envio do segmento TCP a que foi notificada a recepção. A entidade receptora será agora a responsável por todo o posterior tratamento ao segmento, sendo o seu normal destino os buffers do processo aplicacional. Outro procedimento que irá acontecer no receptor é o descarte da cópia guardada do segmento a que foi notificada a recepção, o que irá disponibilizar mais espaço no buffer emissor. Cada ack preenche o campo number acknowledgement com o próximo número de sequência que pretenda receber. Se entretanto o segmento TCP que se pretenda não chegue ao receptor, o ack enviado para cada segmento TCP recebido (que não seja o pretendido), é o ack com o pacote pretendido. 35
- 58. TCP em Redesde Elevado Débito Uma importante propriedade dos acks é o facto de serem cumulativos, i.e., se o número do ack for superior ao número de sequência de um segmento TCP que ainda não tenha sido notificado, então significa que esse segmento também já foi recebido. Tal como os emissores também têm um temporizador. Esse temporizador tem o intuito de juntar várias notificações num só ack, utilizando a propriedade cumulativa. A Figura 3.12 representa um possível funcionamento de uma troca de dados TCP com os seus envios e notificações de recepção (acks). O emissor envia três segmentos TCP (1, 1025, 2049); até ser dado o timeout por parte do receptor, são recebidos dois segmentos (1, 1025); o receptor envia então o ack com o número de sequência do terceiro pacote enviado (2049), mas como entretanto recebe esse mesmo segmento, manda seguidamente um ack com o próximo número de sequência pretendido. Verifica-se então uma clara situação de redundância, pois se o temporizador do receptor tivesse esperado mais um pouco, a dupla notificação não seria necessária. É de referir também que a janela notificada baixa no último ack, isto acontece pois o receptor ainda tem o último segmento em buffer. Figura 3.12 – Exemplo de troca de dados 1. A próxima figura poderia ocorrer na mesma sessão de dados, esse facto prende-se com o carácter algo aleatório dos componentes da rede, nomeadamente os atrasos existentes na ligação. Na Figura 3.13 foi apenas enviado um ack após o receber do segmento 1025, a notificação para o segmento 2049 é feita no último ack (4097). Pressupõe-se então que o segmento 2049 chegou ao receptor por volta do tempo do segmento 3073 e 4097. Pressupor é uma palavra-chave em muitas áreas do TCP, principalmente o controlo de congestão. 36
- 59. 3. Enquadramento aoProtocolo Figura 3.13 – Exemplo de troca de dados 2. Para envio de um ack é necessário um campo e uma flag do cabeçalho TCP, não tendo o segmento TCP qualquer segmento de dados. Este facto, junto com a simplicidade inerente de um ack, leva por vezes à desvalorização dos acks no capítulo da ocupação da largura de banda, porém se para os acks não forem utilizados mecanismos próprios para optimização da largura de banda ocupada, cada ack pode ser obrigado a enviar todo o cabeçalho TCP, sem ter qualquer segmento de dados. Um dos mecanismos utilizados para a optimização da largura de banda é o mecanismo de Piggybacking. Piggybacking Este mecanismo não foi especificado directamente para o TCP, sendo também utilizado em outros protocolos. Consiste em enviar os acks em conjunto com segmentos com dados por parte do emissor/receptor, poupando assim o envio de cabeçalhos TCP por parte dos acks. Piggybacking significa “boleia”, e é exactamente esse o objectivo deste mecanismo. Para o efeito é utilizado um temporizador que faz o ack esperar até que exista algum segmento de dados no emissor/receptor. A Figura 3.14 representa este mecanismo. O emissor envia os dados; o receptor também está pronto para enviar dados, logo, ao receber o segmento do emissor, envia no seu segmento dados o ack. 37
- 60. TCP em Redesde Elevado Débito Figura 3.14 – O mecanismo de Piggybacking (Fonte: Washinton University). Como foi referido anteriormente, os acks são de propriedade cumulativa. Esta propriedade é extremamente importante no capítulo da optimização da largura de banda juntamente com o piggybacking. O mecanismo responsável pela atribuição desta propriedade é o Sliding Window. 3.3.2.2. A janela A janela, ou window como normalmente é referenciada, também existe em diversos protocolos, porém, ela é especialmente importante considerando todos os mecanismos TCP. Essa razão prende-se com o facto de ser o elo de ligação entre eles, controlando congestão e fluxo. É composta basicamente por um campo e um mecanismo. O campo foi já referenciado (ver Cap. 3.3.1), o mecanismo denomina-se Sliding Window7 ou “janela deslizante”. Existem vários tipos de Sliding Windows, o TCP tem a janela adaptada às suas variadas necessidade, sendo a principal, notificar os acks de forma cumulativa. O mecanismo divide essencialmente a janela em quatro partes distintas: • O que já se sabe ter sido correctamente recebido; • O que já se enviou, mas não se sabe se foi bem recebido; • O que não se pode enviar; • O que está para enviar. Todas estas divisões estão relacionadas com o campo Window, sendo ele que define as diversas divisões, excepto o que está para enviar. 7 Existe também a definição como protocolo SWP (Sliding Window Protocol). A principal razão de por vezes ser referenciado como protocolo prende-se com a sua importância. 38
- 61. 3. Enquadramento aoProtocolo A Figura 3.15 demonstra todo o funcionamento do Sliding Window. Estão representados 11 segmentos: 3 segmentos (1, 2, 3) foram já enviados, tendo sido recebido o seu respectivo ack; 3 segmentos (4, 5 ,6) foram enviados e ainda não foi recebido o seu ack; outros 3 (7, 8, 9) poderão ainda ser enviados e o resto dos segmentos não podem ainda ser enviados. A janela oferecida pelo receptor através do campo Window é o tamanho dos 6 segmentos (os enviados sem ack, e os para enviar). Figura 3.15 – Representação do mecanismo Sliding Window. A Figura 3.16 demonstra o funcionamento da janela durante a troca de segmentos TCP. O próximo segmento TCP (6) é enviado; o receptor notifica então o receptor com o número de ack 5, o que significa que segmento TCP 4 já foi recebido; o emissor fecha então a sua janela até ao segmento 5. O tamanho da janela oferecida porém, já não é igual ao tamanho de 6 segmentos, sendo agora igual a apenas 4, fechando a janela. Após o encolher da janela, o número de segmentos que se podem enviar sobra para apenas 1 (8), porém um ack duplicado é recebido, existindo novamente um acréscimo no valor oferecido da janela; então a janela irá abrir novamente até ao segmento 10. Figura 3.16 – Representação das várias movimentações ao longo das trocas de segmentos TCP. A última figura demonstra toda a dinâmica do mecanismo sliding window, essa dinâmica é suportada por três movimentos principais: • A janela fecha à medida que o limite esquerdo avança para a direita. Este movimento sucede quando existem segmentos enviados e foi recebido o seu respectivo ack; 39
- 62. TCP em Redesde Elevado Débito • A janela abre quando o limite direito avança para a direita, permitindo a mais dados serem enviados. Esta situação acontece quando o processo aplicacional receptor liberta dados no buffer, sendo posteriormente aumentado o valor da janela oferecida; • A janela encolhe quando o limite direito se movimenta para o lado esquerdo. Esta situação acontece quando o valor da janela oferecida é diminuído. Esta situação não é aconselhada [RFC1222]. Estes três movimentos estão representados sucintamente na Figura 3.17. Figura 3.17 – Movimentos do Sliding Window. Com Sliding Window, para cada segmento recebido não é necessário uma notificação imediata do ack, sendo o ack enviado posteriormente, utilizando a propriedade cumulativa. Além disso, devido ao facto do Sliding Window manter a rede completamente saturada com segmentos, consegue um melhor throughput do que um protocolo apenas com o simples mecanismo de acks [2]. O Tamanho da janela (buffer) O processo aplicacional a usufruir largura de banda de rede é, geralmente, o principal responsável pelas respectivas mudanças no tamanho da janela disponível. A Figura 3.18 exemplifica todo o funcionamento de libertação do buffer, e posterior aviso da janela. O pacote IP é entregue pela camada de rede e é processado pelo TCP até entrar para o processo aplicacional; quanto mais rápido for o processo a tratar os dados, mais vazio ficará o buffer, sendo posteriormente maior o valor da janela oferecida. Figura 3.18 – Relação Window/Buffer. 40
- 63. 3. Enquadramento aoProtocolo O tamanho da janela8 é um aspecto que afecta directamente a perfomance do TCP. O tamanho da janela deve ser adaptado à disponibilidade da largura de banda e ao atraso da ligação em questão. Maiores larguras de banda e maiores atrasos implicam sempre maiores janelas. Alguns sistemas operativos limitam também a perfomance TCP por não terem o tamanho de janela adequada às ligações de que usufruem, um desses casos é o Windows XP. O sistema operativo mais usado nos dias de hoje utiliza para ethernet uma janela de 17520KBytes, i.e., utiliza aproximadamente metade do valor máximo da janela, podendo piorar se o outro extremo utilizar Options como Sack ou Timestamp. Em ligações ethernet que suportem 1Gbit/s, a largura de banda nunca consegue ser correctamente aproveitada com uma janela deste tamanho [84], mesmo com atrasos na ordem dos 0.1ms. A janela pode ser aumentada no sistema operativo [85] melhorando a perfomance, mas o aproveitamento total da largura de banda nunca é conseguido. É de referir que a versão de TCP (TCP Reno) utilizada no Windows também prejudica a perfomance, considerando ligações de alto débito (ver Cap. 3.6.1). No Linux o tamanho da janela vem por omissão o máximo (64K), sendo a perfomance a mesma que nos sistemas Windows, se for considerada a mesma versão de protocolo e o mesmo atraso. O tamanho da janela TCP de forma a utilizar a largura de banda de forma eficiente pode ser calculado utilizando a seguinte fórmula: (sec)*sec)/(arg)( RTTbitsbandadeuraLBDPCapacidade = Esta fórmula permite-nos obter a capacidade da rede, também chamado de BDP (Bandwidth Delay Product). Este valor pode variar, tal como foi dito anteriormente, conforme os valores de largura de banda e RTT. O valor da janela para aproveitar a largura de banda de forma eficiente é igual ao valor do BDP. O valor recomendado é duas vezes o BDP. Existem também algumas recomendações acerca do valor inicial da janela por parte da IETF [50]. A Relação com o RTT Podemos comparar o RTT com o comprimento de um canal de dados. Se o comprimento do canal de dados é maior, então existirá consequentemente uma maior capacidade da rede (BDP) no transporte dos dados. Existindo mais capacidade, significa automaticamente, mais segmentos TCP a circular na rede. A Figura 3.19 exemplifica a relação entre segmentos e RTT; o dobro do RTT, o dobro dos segmentos. 8 Janela neste caso é o equivalente a dizer “buffer”. Existe também a definição de “window” como buffer disponível, como é o caso da Figura 3.17. A razão é esse ser o nome do campo do cabeçalho TCP. 41
- 64. TCP em Redesde Elevado Débito Figura 3.19 – Relação RTT/segmentos TCP. A relação com a janela provém do facto de que para “encher9 ” devidamente um canal, seja necessário uma maior janela. Se a janela não for suficientemente grande o canal vai ficar subaproveitado, sendo perdida grande eficiência por parte do TCP. A Figura 3.20 exemplifica essa situação. No início a primeira janela não permite à ligação utilizar de forma eficiente todo o canal; na segunda existe uma muito melhor ocupação do canal. Figura 3.20 – Relação RTT/Janela. A Relação com a largura de banda Aumentar a largura de banda implica igualmente maior capacidade do canal, podendo ser comparado a um alargamento do canal de dados. A Figura 3.21 demonstra a relação entre a largura de banda e os segmentos TCP. Ao duplicar a largura de banda, automaticamente, se verifica que 4 pacotes não conseguem ocupar todo o canal. 9 “Encher” como atingir a maior taxa de ocupação da rede. 42
- 65. 3. Enquadramento aoProtocolo Figura 3.21 – Relação largura de banda/segmentos TCP. Devido à situação de o canal permitir maior débito e capacidade do canal, se existirem janelas equivalentes para ligações normais e ligações de alto débito, a situação representada na Figura 3.22 torna- se uma realidade. Para o mesmo atraso, a janela na ligação normal consegue aproveitar todo o canal; para alto débito a ligação usa toda a sua janela, sendo aproveitada apenas uma pequena parte do canal. A ligação em alto débito com janelas pouco apropriadas obriga a um tipo de transmissão em pequenos blocos que poderão ocupar percentagens mínimas de ocupação da largura de banda. Essas percentagens irão variar conforme a janela e a ligação de alto débito em questão. Figura 3.22 – Problema da janela com ligação de alto débito. Um dos problemas da falta de eficiência do TCP está muitas vezes ligado ao tamanho da janela. Este será, provavelmente, um dos problemas mais simples, sendo solucionado muitas vezes por aumentos das 43
- 66. TCP em Redesde Elevado Débito janelas nos próprios sistemas operativos, ou utilizando a Window Scale Option (ver Cap. 3.3.4.2). Novos problemas a que estão inerentes as ligações de alto débito irão sendo explicados. Silly Window Syndrome A condição Silly Window Syndrome10 pode acontecer em qualquer implementação que possua mecanismos de janela. Foi verificada pela primeira vez formalmente em 1982 [39]. O que se verifica, quando esta situação ocorre, são pequenas trocas de segmentos TCP em vez dos segmentos completos. A causa é muitos simples, o receptor está constantemente a oferecer pequenas janelas, em vez de esperar por maiores janelas. Do outro lado, o emissor está constantemente a enviar pequenos segmentos de dados em vez de esperar por dados adicionais. A Figura 3.23 representa todo o processo de ocorrência do Silly Window Syndrome. A janela (buffer) do receptor está cheia sendo que a aplicação lê apenas um byte da janela, libertando 1 byte na respectiva janela; o byte livre é então notificado ao emissor; o emissor transmitirá então um segmento com 1 byte, enchendo de novo a janela. Figura 3.23 – Reprentação do Silly Window Syndrome (Fonte: [3]). As soluções passam por modificações por parte de emissor e receptor. Em relação ao receptor a solução é clara: o emissor não deve oferecer pequenas janelas. A janela só deve então aumentar perante duas situações: • A janela pode ser aumentada até ao valor de um segmento TCP (utilizando o valor MSS negociado); • A janela pode ser aumentada, apenas, até ao valor da sua metade. 10 Por vezes também referenciado como SWS. Devido ao facto de não ser um protocolo ou mecanismo optou-se pela definição extensa. 44
- 67. 3. Enquadramento aoProtocolo No extremo responsável pela emissão as seguintes opções devem ser tomadas, bastando uma ser verdadeira para se poder executar o envio: • Enviar apenas quando um segmento TCP tem o seu valor máximo (utilizando o valor MSS negociado); • Enviar apenas quando o segmento é, pelo menos, metade da maior janela alguma vez oferecida pelo receptor; • Enviar todos os dados em buffer caso existam dados por confirmar (à espera de ack) não estando o algorirmo de Nagle (ver Cap. 3.3.3.1) activo. A situação de Silly Window Syndrome está directamente relacionada com o persist timer (ver Cap. 3.3.2.4) e com o algoritmo de Nagle. As ligações mais sujeitas a esta situação são claramente ligações com emissores rápidos e receptores lentos. 3.3.2.3. Estimação do RTT “Um bom estimador de RTT, o núcleo do temporizador de retransmissão, é a mais importante característica para a implementação de um protocolo que pretende suportar grandes cargas”. [13] A medição do RTT tem sido alvo de preocupação desde a inicial especificação do TCP [38], tendo sofrido duas importantes modificações. O RTT reflecte o estado da rede, sendo, tal como o desempenho das ligações, bastante variável ao longo do tempo da sessão de dados. A estimação correcta de toda essa variância é o objectivo de toda a estimação do RTT. A primeira medida que o TCP efectua é o cálculo em relação a um segmento TCP e respectivo ack, garantindo a receptividade desse segmento. É de realçar de novo a propriedade cumulativa, que neste caso é o principal problema de medição RTT, na medida em que não existe uma relação de um para um entre segmento TCP e respectivo ack. A especificação inicial calculava o RTT através de uma relação ponderada entre o RTT medido11 e o antigo RTT. A relação é dada pela seguinte fórmula: MRR )1( αα −+← RTTEstimadorR = 11 Sempre que se falar de RTT medido, está-se a referir à medição entre segmento TCP e qualquer ack que notifique a sua receptividade. 45
- 68. TCP em Redesde Elevado Débito medidoValorM = 9.0== entoarredondamdefactorα Sendo o factor de arredondamento aconselhado igual a 0.9, 90% do valor calculado (R) irá ter como base o antigo valor, e 10% do valor calculado irá ter como base o novo valor medido. A passagem de RTT para o temporizador, também conhecido como RTO (Retransmission Timeout Value) é feita com recurso a outra fórmula: βRRTO = 2== atrasodoriaçãovadefactorβ O factor de variação do atraso é recomendado na especificação ser igual a 2. Este factor de variação pode ser optimizado à ligação conforme os seus atrasos inerentes. Van Jacobson (ver Cap. 3.2.1.2) detalhou os problemas desta fórmula [13] na estimação dos RTT, nomeadamente o facto da variação do atraso ser um parâmetro difícil e pouco coerente de escolher, obrigando muitas vezes a retransmissões desnecessárias. Foram então definidas novas fórmulas que estimam o RTT com base na média e variância: AMErr −= médiaA = medidoValorM = Esta primeira fórmula é também responsável pelo cálculo da média de todos os RTT calculados. Err é a diferença entre o valor RTT medido é a média. A média e o desvio são calculados da seguinte forma: )|(| DErrhDD −+← gErrAA +← DesvioD = 4 1 == desviodoganhoh 8 1 == médiadaganhog A média tem um valor ponderado g que é recomendado de valor 0.125. De igual forma existe um ganho h para o desvio com recomendação de 0.25. Ao ser aumentado o ganho do desvio, significa que o RTO terá um aumento mais acentuado. O RTO é dado por: 46
- 69. 3. Enquadramento aoProtocolo DARTO 4+= Existem porém uma modificação para a situação inicial na troca de dados: DARTO 2+= Esta última fórmula faz com que o RTO não seja tão elevado na sua fase inicial. A Figura 3.24 representa uma comparação do valor estimado com o valor real fornecido por um analisador de tráfego; o eixo dos xx é o valor RTT/RTO, o eixo dos yy o tempo em segundos; no início o valor calculado (calculated RTO) começa por ser alto, tornando-se a estimação ao longo do tempo de transmissão bem mais perfeita. Figura 3.24 – Cálculo do RTT medido por analisador de tráfego, comparado com o calculado TCP (Fonte: [1]). A segunda modificação, a adição de um campo timestamp option já teve a sua introdução anteriormente (ver Cap. 3.3.1) e vai ser explicada em maior detalhe na (ver Cap. 3.3.4.1). A implementação das formas de estimar o RTT varia imenso. Existem pequenas modificações nas fórmulas, medições feitas apenas por janela, etc. Essencialmente é o tipo de ligações que define as implementações; por exemplo, no caso de existir apenas uma medição do RTT por janela, essa situação funciona bastante bem para baixas larguras de banda, mas levanta diversos problemas para alto débito, onde uma estimação detalhada do RTT se revela crucial. A estimação do RTT está directamente associada a um temporizador de retransmissão, porém esta associação verifica-se apenas para a primeira retransmissão. Existem também algumas situações onde o RTT não deve ser medido (ver Cap. 3.3.3.2). O funcionamento dos temporizadores após a primeira retransmissão vai ser explicada seguidamente. 47
- 70. TCP em Redesde Elevado Débito 3.3.2.4. Os Temporizadores “Um elemento crítico de qualquer implementação é a estratégia timeout/retransmissão”. [1] Os temporizadores são essenciais a toda a eficiência da rede, na medida em que mal configurados podem significar desnecessárias transmissões/retransmissões. As retransmissões são iniciadas por dois tipos de eventos: timeouts e acks duplicados; as retransmissões devido a acks duplicados são explicadas no Cap. 3.5.1.1. Retransmit timer A implementação/configuração do retrasmit timer12 pode por vezes se tornar complicada. Algumas complicações surgem perante as seguintes situações: • Timeout um pouco maior que o RTT; Esta situação é a mais comum. Se tudo estivesse em equilíbrio então a situação ideal seria o temporizador igual ao RTT, porém os atrasos vão variando ao longo de toda a ligação e têm que ser definidas margens de aceitação para certos atrasos. A solução neste caso prende-se essencialmente com uma correcta estimação do RTT, e um bom conhecimento da rede em questão, principalmente os atrasos a que pode estar inerente. • Timeout demasiado pequeno; Esta situação pode ocorrer, geralmente, quando a rede está sujeita a muitas perdas e tem poucos atrasos, nesse caso são usados temporizadores pequenos pois o grau de desconfiança na rede é elevado. Temporizadores pequenos em redes com algum atraso e perdas pouco relevantes significam, geralmente, retransmissões desnecessárias. • Timeout demasiado longo; Situação ocorrente quando existe um grau de confiança elevado na rede (em relação às perdas), ou o atraso da rede é elevada. Numa rede que não reúna essas características irá ser verificado uma reacção bastante lenta aquando da perca de um qualquer segmento TCP. Quando ocorre um timeout são executadas duas operações: retransmissão do segmento TCP que causou o timeout e o reiniciar do temporizador. O temporizador altera também o seu tempo conforme o número de 12 Termo mais usado, que corresponde a temporizador de retransmissão. 48
- 71. 3. Enquadramento aoProtocolo retransmissões, i.e., o tempo da primeira retransmissão é geralmente calculado pelo RTT, de seguida o temporizador é inicializado a “1”, depois “3” e duplicado consecutivamente até 64 segundos (1, 3, 6, 12, 24, 48 e 64). O valor de 64 segundos é o limite para o temporizador; conforme a implementação ele continuará a tentar retransmitir o segmento TCP de 64 em 64 segundos até acabar por desistir. Esta duplicação de tempo é chamada de exponencial backoff, e tem como principal objectivo dar mais tempo ao receptor para recuperar de uma qualquer avaria. A Figura 3.25 representa esta técnica. Figura 3.25 – Representação da técnica exponential backoff. Foi dito anteriormente que tanto o emissor e o receptor possuem temporizadores. O retransmit timer é provavelmente o temporizador mais conhecido do TCP. Porém existem diversos temporizadores que divergem tanto no objectivo como na localização. Alguns deles são: • SYN timer • Keepalive timer13 ; • 2MSL14 (Max Segment Life) timer; • FIN_WAIT2 timer; • Persist timer15 ; • Delayed Ack Timer. 13 Termo mais usado, correspondente a temporizador de manutenção da ligação. 14 Muitas vezes também referenciado como Time-Wait timer. 15 Termo mais usado, correspondente a temporizador de persistência. 49
- 72. TCP em Redesde Elevado Débito Os quatro primeiros timers pertencem a todo o estabelecimento da ligação de dados não pertencendo ao âmbito de projecto. Persist Timer O persist timer está relacionado com os mecanismos de janela do TCP. É usado quando o receptor não oferece qualquer espaço da sua janela ao receptor, obrigando o emissor a parar a sua transmissão até nova actualização da janela por parte do receptor. A Figura 3.26 demonstra como é activado este temporizador. Após o envio de 4 segmentos TCP (1, 1025, 2049 e 3073) a janela do receptor fica totalmente ocupada, notificando “0” como capacidade da sua janela. Figura 3.26 – Processo de activação do Persist Timer. Depois da activação do persist timer o temporizador irá expirar, fazendo com que seja enviado um window probe; A função do window probe será perguntar ao receptor se já existe espaço na sua janela. Este window probe pode parecer desnecessário devido ao facto de o receptor, após algum tempo, notificar o emissor da sua nova janela. O problema surge quando essa notificação (através do ack) se perde, então, emissor e receptor ficariam parados à espera um do outro. Se com os window probes a janela continuar a inalterada, tal como o retransmit timer, existirá exponential backoff, com a diferença de os tempos serem de 5 a 60 (5, 6, 12, 24, 48, 60) e nunca existir desistência por parte do emissor em mandar os window probes. A forma como este persist timer está directamente ligado ao Silly Window Syndrome é agora estabelecida: devido ao facto de andar constantemente a “forçar” novo espaço na janela, a janela muitas vezes anunciará pequenos tamanhos. 50
- 73. 3. Enquadramento aoProtocolo Delayed Ack Timer Na parte do receptor existe o delayed ack timer. Este temporizador define o tempo que o receptor deve esperar, entre o correcto receber do segmento e o envio do respectivo ack. A espera é útil para optimização da largura de banda, notificando vários segmentos num só ack (propriedade cumulativa), sendo também útil para o mecanismo de piggybacking (ver Cap. 3.3.2.1). Os valores de timeout deste temporizador variam bastante de implementação para implementação, sendo o valor mais usado 200ms. 3.3.2.5. Sack O Sack é um protocolo especificado formalmente em 1996 [43] com o objectivo de melhorar todo o mecanismo de acknowledgment. Os mecanismos de acknowledgment (ver Cap 3.3.2.1) devido à propriedade cumulativa têm algumas vantagens e desvantagens, o Sack fixou-se em todas a desvantagens desta propriedade. As desvantagens são: • A recepção de segmentos fora de sequência nunca tem associado um ack; • O receptor manda acks duplicados; • O emissor apenas pode receber uma notificação de segmento recebido (ack) por RTT. Este protocolo usa as opções do TCP Sack Permitted e Sack (ver Cap. 3.3.2.5). A opção Sack armazena os blocos de dados que já foram recebidos, permitindo ao protocolo TCP, além da notificação do normal ack, a notificação de diversos blocos de dados já recebidos. A Figura 3.27 exemplifica o funcionamento do Sack; São enviados 5 blocos de dados (100, 200, 300, 400 e 500), 2 deles (200 e 400) são perdidos; após o esgotar do delay ack timer é enviado o normal ack 200, mas com a notificação de que os blocos 500-600 e 300-400 já foram recebidos, ajudando assim o emissor a melhor decidir o que transmitir. Figura 3.27 – Exemplo de funcionamento do protocolo Sack. 51
- 74. TCP em Redesde Elevado Débito A Sack Option é de comprimento variável, com limite para quatro blocos, sendo composta da forma representado na Figura 3.28. O limite direito representa o primeiro número de sequência desse bloco, o limite esquerdo é o número a seguir ao último número de sequência do bloco. Figura 3.28 – Representação dos blocos da Sack Option. Existe uma extensão feita a este protocolo a que foi dado o nome de D-Sack [47] . Esta opção pretende utilizar o primeiro bloco Sack para notificação de segmentos duplicados. O objectivo principal é notificar ao emissor que foram efectuadas retransmissões desnecessárias. Desta forma, o emissor poderá reagir, anulando por exemplo os algoritmos de controlo de congestão. Esta extensão ainda possui poucas implementações e quando existe implementação não se verifica por omissão. 3.3.3. Os algoritmos Existem vários tipos de algoritmos no TCP. Um algoritmo no TCP caracteriza-se por poucas linhas de código, aquando das implementações. Geralmente alteram também de forma muito significativa o desempenho da rede. Os algoritmos surgem, também geralmente, associados ao seu criador dividindo-se em três tipos: • Algoritmos de controlo de congestão; Algoritmos que previnem o emissor de não congestionar toda a rede. • Algoritmos de controlo de erros; Algoritmos de recuperação para situações de perdas de segmentos. • Algoritmos de controlo de fluxo. Algoritmos que previnem o emissor de não sobrecarregar o receptor com informação, tentando que o mesmo envie os dados de forma adequada à largura de banda. O objectivo de cada tipo de algoritmo é diferente, mas toda a implementação é feita de forma combinada, fazendo com que uma correcta separação entre eles não se verifique simples de efectuar. 52
- 75. 3. Enquadramento aoProtocolo Os algoritmos de congestão e de controlo de erros vão ser analisados mais à frente (ver Cap. 3.6), sendo agora analisados dois algoritmos, correspondentes ao controlo de fluxo. 3.3.3.1. Algoritmo de Nagle O primeiro algoritmo, definido para optimizar a ocupação da rede por parte do TCP, foi especificado em 1984 [40]. O nome atribuído foi o nome do seu criador (John Nagle), tendo sido um algoritmo criado na fase inicial dos colapsos da Internet (ver Cap. 3.2) e por isso considerado, por vezes, o primeiro algoritmo de congestão. Porém, geralmente são referidos como algoritmos congestão outro tipo de algoritmos, criados um pouco mais tarde (ver Cap. 3.6). O algoritmo especifica que quando uma ligação TCP tem segmentos que ainda não foram confirmados da recepção, pequenos segmentos não podem ser enviados, até que os acks sejam recebidos. Em vez dessa situação, pequenas quantidades de dados da aplicação vão sendo somadas, sendo posteriormente enviadas apenas num segmento TCP quando todos os ack chegarem. O algoritmo é extremamente simples e de uma tremenda utilidade, pois em situações de congestão, se existirem aplicações interactivas16 na rede o desempenho da rede aumenta exponencialmente. Além disso, não precisa de qualquer tipo de sincronização adicional, pois à medida que a rede vai ficando descongestionada (acks a chegar) mais rápida será a transmissão dos dados. 3.3.3.2. Algoritmo de Karn Especificado em 1987 [10], este algoritmo está directamente ligado à estimação de RTT (ver Cap. 3.3.2.3). Phil Karn reparou num problema de ambiguidade durante as retransmissões a que foi dado o nome de retransmission ambiguity problem. Um segmento é transmitido e para esse segmento o retransmission timer esgota, enviando um novo segmento; de seguida é recebido um ack do segmento retransmitido. A pergunta que agora se faz é se este ack é do segmento transmitido atrasado ou do segmento restransmitido? A resposta seria fácil se existisse forma de saber que o primeiro segmento tinha sido perdido, porém não existe nenhum mecanismo que permita essa verificação. De qualquer forma, se ele for correctamente recebido não há forma alguma de saber a que segmento se refere o ack. A Figura 3.29 representa a situação de ambiguidade atrás explicada. 16 Este tipo de aplicações tem a característica de enviar uma grande quantidade de pequenos segmentos de dados para a rede. 53
- 76. TCP em Redesde Elevado Débito Figura 3.29 – Representação do retransmission ambiguity problem. Perante esta situação Karn especificou que quando existe timeout e consecutiva retransmissão não deve ser actualizado o estimador RTT, pois não sabemos a que se refere o ack recebido, podendo ele significar ou um longo atraso ou uma rápida notificação. 3.3.4. Os mecanismos para alto débito Anteriormente já foram abordados alguns dos problemas que afectam as redes de alto débito, serão agora referidos os principais, com especial referência aos mecanismos que utilizam as opções do cabeçalho TCP. Existindo actualmente um grande número de redes deste tipo, fácil é perceber a importância que os mecanismos específicos para este tipo de rede auferem. Alguns dos problemas verificados aquando do surgimento das redes de alto débito foram: • O tamanho da janela TCP oferecida é dado pelo campo Window no cabeçalho TCP. O campo tem 16 bits, limitando a janela a uma notificação de 65535 bytes (a Figura 3.21 exemplificava este problema); • Muitas implementações TCP ainda estimam apenas um valor de RTT por janela. É necessária uma pormenorizada estimação RTT em de todos os segmentos em redes de alto débito; • O TCP identifica cada byte de dados através de um campo sequence number de 32 bits. Este campo tem de garantir a coerência na identificação dos segmentos. O problema surge quando aparecem acks atrasados de sessões de dados já terminadas. Existe um temporizador (2MSL tmer) que estabelece o tempo de vida máximo do segmento após término da sessão, este timer resolve o problema nas redes com débito pouco acentuado, mas não resolve para alto débito. As redes de 10Mbit/s demoram cerca de 60 minutos a esgotar os números de sequência, com 100Mbit/s demoram cerca de 12 minutos e com uma rede de 1Gbit/s demoram cerca de 37 segundos. O temporizador é geralmente implementado com valores entre 30 segundos e 2 minutos. A situação 54
- 77. 3. Enquadramento aoProtocolo problemática surge quando os números de sequência esgotam antes do tempo deste temporizador, fazendo com que os números de sequência se possam repetir na mesma ligação. Para a solução destes três problemas foram criados três mecanismos especificados em 1992 [42], juntamente com as alterações ao cabeçalho. 3.3.4.1. Timestamp Option A timestamp option foi a última modificação mais relevante, aplicada aos estimadores de RTT. O conceito é a adição de uma nova marcação de tempo em cada segmento TCP. A essa marcação, o receptor responderá na forma de um echo reply17 . A forma como essa opção está estruturada é representada na Figura 3.30. O primeiro campo (TS Value) é preenchido pelo emissor, o segundo campo (Tsecr) é preenchido pelo receptor. Figura 3.30 – Representação dos campos do Timestamp Option. Existem várias considerações a ter nesta troca de valores. O facto de o preenchimento ser um echo reply traz consigo duas vantagens: não é necessário qualquer tipo de sincronização (para além da já existente nos normais mecanismos TCP), não é necessário o receptor saber como está estruturada a informação no campo preenchido pelo receptor. O valor do TS Value é um valor fornecido pelo relógio do sistema. Também devido ao echo reply por parte do receptor foi necessário a criação de duas formas de funcionamento: • Se um ack estiver a utilizar a propriedade cumulativa a notificar o emissor, o valor do Timestamp Option será sempre o do primeiro segmento que for recebido; • Se um segmento estiver fora de sequência, implicando que um antigo segmento foi perdido, quando esse segmento é recebido, o valor da Timestamp Option será o do segmento perdido. Através destes mecanismos, esta opção permite saber para além do RTT do último segmento a ser recebido, o do primeiro. Desta forma o RTT terá uma melhor estimação, ganhado o TCP uma melhor preparação para redes de alto débito. 17 O emitido pelo emissor será igual ao preenchido pelo receptor. 55
- 78. TCP em Redesde Elevado Débito 3.3.4.2. Window Scale Option A sua especificação vem resolver todos os problemas da janela em relação às ligação de alto débito. O tamanho máximo passará dos normais 16 bits para 32 bits. Devido ao facto de os 16 bits serem suficientes para ligações de menos débito, foi adicionado uma nova opção (ver Cap. 3.3.1), não sendo alterado o cabeçalho estático18 . Essa opção vem aplicar um factor de escala ao antigo campo Window; o TCP considera então internamente19 o conjunto dos dois campos como um campo de 32 bits. Os valores que a janela poderá tomar estão especificados na Tabela 3.1. A tabela representa o factor de escala, os valores iniciais da janela, os ganhos em relação à janela inicial e a janela já escalonada. Foi considerado o valor máximo da janela no campo window (65535), podendo o escalonamento ser feito com valores mais baixos. Factor de escala Valor do Window inicial Ganho Janela escalonada 0 65535 1 65535 3 65535 8 524280 6 65535 64 4194240 10 65535 1024 33553920 12 65535 4096 268431360 14 65535 16386 1073725440 Tabela 3.1 – Valores da Window Scale Option. 3.3.4.3. PAWS O PAWS20 (Protection Against Wrapped Sequence) usa a Timestamp Option como forma de distinguir segmentos com sequências que possam ser repetidas. Se uma sessão de dados terminar com algum segmento em atraso e outro sessão de dados iniciar, um ack poderá chegar atrasado, mas, para além do número de sequência desse mesmo segmento será também analisado o timestamp. O timestamp devido ao 18 O cabeçalho que é comum em qualquer segmento TCP. 19 Dentro do seu código de implementação. 20 O PAWS é conhecido principalmente como um algorimo, porém o seu âmbito não se encaixa na maioria dos algoritmos para alto débito. 56
- 79. 3. Enquadramento aoProtocolo facto de ser incrementado ao longo do tempo, facilmente se distingue uma sessão de dados a terminar de uma sessão de dados a iniciar. 3.4. Os limites teóricos Todos os mecanismos de controlo de fluxo explicados permitem ao TCP adquirir grande parte da sua estabilidade e eficiência. Por vezes a resolução de certos problemas traz consigo a adição de outros, pelo que toda a estrutura deve ser sempre vista como um todo. Existem certas limitações que dificilmente serão ultrapassadas, pelo que o dever de toda a comunidade de investigação deste protocolo será aproximar-se tanto quanto possível do limite. Foi dito anteriormente que o cabeçalho TCP sem opções ocupa 20 bytes, apesar disso, os dados a circular na rede não possuem só um cabeçalho TCP, possuindo também diversos cabeçalhos nas restantes camadas do modelo TCP/IP. A Tabela 3.2 representa toda a adição de dados por parte de todas as camadas; o preâmbulo ethernet representa toda informação proveniente de camada física, seguindo-se os campos ethernet; o cabeçalho IPv4 ocupa também os mesmos 20 bytes do cabeçalho TCP sem opções; o segmento de dados ocupa os 1460 bytes permitidos pela rede ethernet (tamanho de frame máximo); existe também um pad (no caso de ser um ack) para cumprimento dos requisitos mínimos do frame ethernet; por fim o checksum, e os dados raw devido ao tempo de espera para troca de frame. Campo Tamanho Tamanho Ack Preâmbulo Ethernet 8 8 Ethernet Destination Address 6 6 Ethernet Source Address 6 6 Ethernet Type Field 2 2 Cabeçalho IPv4 20 20 Cabeçalho TCP 20 20 Segmento de dados 1460 0 Pad 0 6 Ethernet CRC 4 4 Interframe gap 12 12 Total 1538 84 57
- 80. TCP em Redesde Elevado Débito Tabela 3.2 – Tamanho do segmento que circula numa rede ethernet TCP/IP. A rede ethernet a que a Tabela 3.2 se refere permite calcular a quantidade real máxima de dados que uma rede consegue suportar. Pode então ser calculado o goodput21 para variados débitos e janelas. Considerando que cada ack notifica dois segmentos TCP (situação com janelas pequenas), o goodput será calculado da seguinte forma para uma ligação de 10Mbit/s: sbitssbytesGoodput /9240504/1155063 8 10000000 * 841538*2 1460*2 == + = Aumentando o valor da janela para o tamanho máximo (não usando Window Scale Option), i.e., aumentando a janela para 65535 poderão ser enviados 44 1460 65535 = segmentos sem ack, considerando um ack por 22 segmentos (situação em que será oferecido metade do valor da janela), o goodput aumenta então consideravelmente: sbitssbytesGoodput /9469336/1183667 8 10000000 * 841538*22 1460*22 == + = Considerando uma rede de 1Gbit/s e os mesmos parâmetros acima definidos, os cálculos vão ser: sbitssbytesGoodput /924050632/115506329 8 1000000000 * 841538*2 1460*2 == + = sbitssbytesGoodput /946933962/118366745 8 1000000000 * 841538*22 1460*22 == + = Conclui-se então que em ambas as situações (10Mbit/s e 1Gbit/s) a percentagem de ocupação por parte dos dados é idêntica, correspondente a 92,4% para a janela mais pequena e 94,6% para a janela maior. Apesar dessa situação, como a largura de banda é maior, maior quantidade de dados22 ficará por transmitir: 53066038 bits considerando a maior janela e 1Gbit/s, 530664 bits considerando a maior janela e 10Mbit/s. Os cálculos acima efectuados foram feitos considerando situações óptimas, sem qualquer tipo de perdas. Foi considerado, também, que a ligação tem uma largura de banda constante ao longo de todo o caminho, sem qualquer tipo de atraso. Os cálculos servem apenas de referência como o máximo que uma rede deste tipo poderia alcançar na troca de informação. 21 Definição para a quantidade de dados úteis na rede por segundo. Os dados são gerados por processos aplicacionais. 22 Neste caso os dados fazem referência aos dados de utilizador provenientes da aplicação. 58
- 81. 3. Enquadramento aoProtocolo 3.5. A Congestão e as versões TCP Considerando todos os mecanismos atrás explicados e considerando, ainda, que também existe algum controlo de fluxo por parte de outras camadas do modelo TCP/IP, era talvez de esperar que qualquer rede conseguisse ter a eficiência e fiabilidade que se pretende. A situação não se revelou assim tão simples para o TCP, tendo sido posteriormente confrontado com o seu primeiro grande desafio (2ºciclo – A Congestão, ver Cap. 3.2). Quando a carga oferecida a qualquer meio é maior do que ela pode aguentar, a congestão instala-se. As redes de computadores não são excepção, assim como não foi toda a Internet, sendo vítima de variados colapsos. A forma de solucionar toda a congestão foi usar alguns conceitos muitas vezes aplicados a outras áreas completamente distintas do ramo tecnológico. A Figura 3.31 demonstra duas figuras ilustrativas de estudos com prováveis situações de congestão no ramo do tráfego automóvel e do tráfego populacional. Figura 3.31 – Análise do tráfego automóvel e populacional (Fonte: Universidade Técnica de Dresden e Crowd Dynamics). Claramente, nem todos os conceitos de congestão das diversas áreas se aplicam, mas alguns conceitos podem ser adoptados às redes de dados. O conceito é simples: só injectar um segmento na rede quando outro segmento se retirar. A normal janela (ver Cap. 3.3.2.2) já implementava este tipo de conceito, o problema é que a janela funciona apenas por parte do receptor, podendo ainda existir congestão ao longo de todo o percurso, sendo assim necessário algo mais do que os mecanismos do capítulo anterior. A Figura 3.32 ilustra este problema através de um exemplo hidráulico. Existem quatro entidades: a torneira (emissor), o cano (a rede), o balde (receptor) e a água (segmentos TCP). Na situação a), enquanto a torneira não enviar água suficiente para encher o pequeno balde, nenhuma água será perdida; Na situação b) o balde é maior, mas o factor limite não é a capacidade do balde, mas sim a capacidade do cano. 59
- 82. TCP em Redesde Elevado Débito Figura 3.32 – Exemplo hidráulico de uma situação de congestão (Fonte: [3]). Devido ao facto de as redes de computadores, principalmente a Internet, não terem a mesma capacidade ao longo da ligação, entende-se facilmente a razão dos colapsos. Assim sendo, a solução foi abordar os problemas de duas formas: o controlo da capacidade da rede e o controlo da capacidade do receptor. As soluções vieram em forma de versões TCP com os seus algoritmos de congestão que se vieram a verificar de extrema importância. 3.5.1. TCP Tahoe “Os caminhos óbvios para implementar um protocolo de transporte baseado em janela, pode resultar, exactamente, no comportamento errado no que diz respeito à congestão da rede”. [13] O TCP Tahoe é especificado em 1988 [13], num paper que se viria a tornar um clássico23 no ramo das redes de computadores. O nome “Tahoe” não surgiu aquando da sua especificação, sendo o nome atribuído, posteriormente, após implementação dos algoritmos e mecanismos de congestão em BSD (Berkeley Software Distribution). A versão é caracterizada essencialmente pela adição de uma nova janela (janela de congestão), e os algoritmos de congestão Slow Start e Fast Retrasmit. 23 Definição usada para referir algo que, actualmente, ainda se verifique uma grande referência. 60
- 83. 3. Enquadramento aoProtocolo 3.5.1.1. Janela de Congestão A janela de congestão24 é uma segunda janela, com o intuito de solucionar a situação de congestão na rede (a congestão no receptor é já solucionada pela janela referida anteriormente). A janela de congestão não tem qualquer tipo de relação com o receptor, funcionando como uma forma de controlo de fluxo por parte do emissor. O papel do emissor será transmitir o mínimo destas duas janelas; o receptor pode oferecer assim determinada janela, mas o emissor através da sua janela de congestão poderá saber que ao injectar segmentos até aquele limite irá congestionar a rede. A Figura 3.33 exemplifica a relação entre as duas janelas. A janela irá oferecer 8Kb ao emissor para enviar, por outro lado a sua janela de congestão só lhe permite 4Kb; finalmente serão enviados os 4Kb. Figura 3.33 – Funcionamento da janela de receptor/janela congestão. A janela de congestão irá funcionar em conjunto com os algoritmos de congestão, variando o seu valor conforme os acontecimentos da rede. É de referir também que o valor da janela é medido em bytes e não em segmentos. 3.5.1.2. Slow Start “Um novo pacote não pode ser colocado na rede até que um velho pacote saia. A física do fluxo prevê que os sistemas com esta propriedade deve ser robustos em relação à congestão“. [13] O mecanismo de acks (ver Cap. 3.3.2.1) funciona basicamente como o relógio do TCP. Essa situação permite ao TCP adquirir outra propriedade: self-clocking25 . Esta propriedade permite ao TCP adquirir um determinado ritmo, onde os acks conseguem ser gerados à mesma velocidade dos segmentos. Desta forma é atingido o estado de equilíbrio representado na Figura 3.34, onde os variados tempos de transmissão são sempre mantidos. 24 Muitas vezes referenciado como congestion window ou cwnd. 25 Termo mais usado, correspondente a auto sincronização. 61
- 84. TCP em Redesde Elevado Débito Figura 3.34 – Representação do estado de equilíbrio (Fonte: [13]). O objectivo será, então, conseguir manter este estado de equilíbrio na rede. O problema principal é iniciar esse mesmo estado de equilíbrio, sendo o Slow Start, o responsável por essa mesma inicialização. O processo de funcionamento do Slow Start é observar a velocidade a que devem ser injectados os segmentos na rede, através da velocidade a que os acks são devolvidos por parte do receptor. O valor inicial da janela de congestão representa o primeiro segmento que será enviado, esse valor será o MSS negociado, aquando do estabelecimento da ligação. A partir do primeiro segmento enviado, para cada ack recebido (do segmento enviado), a janela de congestão será incrementada em mais um segmento. A Figura 3.35 demonstra este comportamento. O emissor começa por transmitir um segmento e espera pelo seu ack; quando o ack é recebido a janela de congestão é aumentada de 1 (1) para 2 (2, 3) segmentos; quando cada ack desses segmentos chega ao emissor, a janela de congestão é aumentada para 4 segmentos (4, 5, 6, 7); após os acks, a janela aumenta para 8 segmentos (8, 9, 10, 11, 12, 13, 14, 15); a multiplicação continua a subir exponencialmente até ocorrer alguma situação que active outro algoritmo. Figura 3.35 – Representação do comportamento do Slow Start (Fonte: [13]). 62
- 85. 3. Enquadramento aoProtocolo Como já foi anteriormente referido (ver Cap. 3.2), as primeiras implementação foram feitas em BSD que na altura ia na sua versão 4.3. Uma exemplo de uma rede com essa implementação é representado na Figura 3.36. A rede em questão é uma rede ethernet de 10Mbit/s característica da altura, com ligação backbone de 230.4Kbit/s; o eixo dos xx representa o tempo, o yy representa o número de sequência dos segmentos, a linha a tracejado representa a largura de banda disponibilizada; para aproveitar ao máximo os segmentos deviam seguir a linha a tracejado, porém, esse comportamento não se verifica, sendo o tráfego caracterizado por constantes retransmissões que pioram ao longo do tempo, existindo até segmentos retransmitidos 4 e 5 vezes. O aproveitamento da largura de banda por parte desta rede, não surpreendentemente, será cerca de 35%. Figura 3.36 – Representação da perfomance de uma implementação 4.3BSD (Fonte: [13]). A mesma rede, com exactamente as mesmas configurações da representada na Figura 3.35, sendo alterado apenas a implementação para BSD 4.3+, é agora representada na Figura 3.36. Esta implementação foi uma versão intermédia entre a versão BSD 4.3 e a BSD 4.3 Tahoe, que apenas implementava o algorimo Slow Start. Os melhoramentos verificados são: excepto até ao 16º segmento, os segmentos seguem exactamente a linha da largura de banda disponibilizada; são correctamente26 enviados cerca de 155 segmentos, ao longo de aproximadamente 9 segundos (para o mesmo tempo, a antiga implementação enviava correctamente cerca de 65). Não existe qualquer retransmissão, limitando os “tempos mortos” do emissor ao tempo de chegada dos acks. 26 Correctamente neste caso implica o envio sem descarte e com ack (excepto nos segmentos finais que poderão ainda não ter sido notificados). 63
- 86. TCP em Redesde Elevado Débito Figura 3.37 – Representação da perfomance de uma implementação 4.3 BSD+ (Fonte [13]). A única desvantagem que se retira deste algoritmo são os 2 segundos iniciais em que se afasta um pouco da largura de banda disponibilizada, após os 2 segundos o termo “slow” 27 perde todo o seu sentido, superando em velocidade de pacotes enviados correctamente qualquer outra implementação feita. A melhoria de perfomance proporcionada por este algoritmo em relação aos normais mecanismos implementados não deixou qualquer dúvida às comunidades de investigação, passando rapidamente a ser adoptado em qualquer rede de computadores e principalmente na Internet. O slow start, tal como os algoritmos que irão posteriormente ser explicados, teve origem em algoritmos implementados anteriormente pela DEC (Digital Equipment Corportaion) [86], nomeadamente o CUTE (Congestion Control Using Timeouts at the End-to-End) [11]. Especificados em 1986, dois anos antes do TCP Tahoe, estes algoritmos deram origem ao termo “Linear Decrease and Sudden Decrease”, que viria a ser adaptado pelas versões TCP como AIMD (Additive Increase and Multiplicate Decrease). Os algoritmos AIMD são caracterizados pela aplicação de multiplicações, adições e divisões na janela de congestão conforme a correspondente situação da rede. O Slow Start é especialmente importante na medida em que a maioria das ligações TCP não dura muito tempo, assim sendo, muitas das vezes apenas este algoritmo é invocado. 27 O inglês “slow” significa lento. 64
- 87. 3. Enquadramento aoProtocolo 3.5.1.3. Congestion Avoidance Após começar toda a fase de equilíbrio, em algum ponto a capacidade da rede será ultrapassada e algum dispositivo na rede começará a descartar segmentos. Esse descarte terá de indicar ao emissor que a sua janela de congestão passou dos limites. Nesse caso entramos na fase de Congestion Avoidance. Existem duas formas de os segmentos serem perdidos: • Danificados durante o caminho; A probabilidade de isso acontecer nas redes actuais de cabos é completamente desprezável. Na altura da especificação do Congestion Avoidance foi considerada uma probabilidade menor de 1% para segmentos danificados pelo meio. • Rede congestionada, indicando que ao longo do caminho existiu um buffer com capacidade insuficiente. O Congestion Avoidance apenas considera esta situação. Existem também duas possíveis indicações de que um segmento foi perdido e está a ocorrer congestão: • A ocorrência de um timeout28 ; • O emissor recebe um ack duplicado. Ao existir perda o emissor tem de tomar decisões, as opções são: • Segmento tem de ser transmitido; Quando existe timeout, existirá sempre uma decisão obrigatória. • Velocidade tem de ser adaptada para que não exista outra vez perda. A velocidade quando se está no Congestion Avoidance é conseguida através de um incremento de 1/cwnd cada vez que é recebido um novo ack (valor bem mais reduzido do que acontecia no slow start). Desta forma é permitido, no máximo, o envio de um segmento por RTT. O Slow start e o Congestion Avoidance estão os dois directamente relacionados. É usado Congestion Avoidance quando se quer diminuir o ritmo e Slow Start quando se quer recomeçar a enviar normalmente. 28 O timeout refere-se à expiração do temporizador de retransmissão. 65
- 88. TCP em Redesde Elevado Débito Para esta relação é necessário o uso de duas simples variáveis: cwnd29 , responsável pelo tamanho actual da janela de congestão; ssthresh, o threshold30 do Slow Start onde poderá ocorrer congestão. O relacionamento entre Slow Start e Congestion Avoidance baseia-se essencialmente nos seguintes pontos: • Quando a congestão ocorre, verificada pelas possíveis indicações, metade do valor da janela de congestão ficará guardado na variável ssthresh, ficando esse o limite da zona de congestão; • Se existir um timeout, adicionalmente a variável cwnd baixa para o valor MSS inicial; • Quando é notificada a recepção de novos segmentos, a forma como a janela é aumentada depende da situação que o emissor pensa estar a rede. Se ssthreshcwnd ≤ não se passou o limite de congestão, sendo usado o normal crescimento Slow Start; se pelo contrário , então passou-se o limite de congestão, sendo usado o incremento Congestion Avoidance. ssthreshcwnd ≥ A Figura 3.38 demonstra como os algoritmos e respectivas variáveis se relacionam. O eixo dos xx representa os RTT, o eixo dos yy representa o valor da cwnd em segmentos. Pressupõe-se nesta representação que uma anterior situação de congestão já sucedeu aquando do segmento 32, sendo verificado um timeout; por essa mesma razão o ssthresh ficou armazenado com o valor 16; de seguida o Slow Start começa novamente a partir do 1º segmento até ao 16º segmento (valor do ssthresh); após ultrapassar o valor do ssthresh entrou-se na zona de possível congestão, diminuindo assim a velocidade de envio. Figura 3.38 – Representação gráfica da relação Slow Start/Congestion Avoidance (Fonte: [1]). 29 Por vezes utilizada para referenciar a própria janela de congestão, neste caso referenciada como uma variável. 30 O inglês “threshold” significa ponto inicial, neste caso referenciado como ponto inicial de congestão. 66
- 89. 3. Enquadramento aoProtocolo A forma de um ack duplicado indicar ou não indicar congestão levanta alguns problemas. O algoritmo Congestion Avoidance considera que a duplicação de um ack representa a proximidade de congestão apenas reduzindo, reduzindo a velocidade de envio. O algoritmo Fast Retransmit melhora esta situação. 3.5.1.4. Fast Retransmit O algoritmo Fast Retransmit baseia-se essencialmente na questão dos acks duplicados. Até que ponto um ack duplicado poderá significar uma perda e posterior situação de congestão? A resposta dada neste algoritmo é simples: ao terceiro ack duplicado. O conceito é simples: como não se pode saber se um ack duplicado é um segmento perdido, ou apenas um simples segmento atrasado, vítima de outros segmentos que chegaram antes; assume-se que existirão apenas 1 ou 2 segmentos duplicados, antes que exista a correcta ordenação. Se existirem 3 ou mais é uma forte indicação de que o segmento se perdeu e estará a ocorrer congestão. Na Figura 3.39 pode-se verificar as probabilidades de perda do Fast Retransmit atribuídas aos acks duplicados. Figura 3.39 – Probabilidade de existir perda de segmento. O algoritmo após indicação de congestão (3ºack duplicado) efectuará a retransmissão sem esperar que o timeout ocorra, eliminado assim o tempo de espera. Na especificação do TCP Tahoe foi também definido uma melhor forma de estimação RTT (Cap) que foi implementada conjuntamente com os algoritmos na especificação BSD 4.3 Tahoe. Os colapsos da Internet começaram a desaparecer com esta implementação, sendo agora necessário optimizar ainda mais todo o aproveitamento da largura de banda. 67
- 90. TCP em Redesde Elevado Débito 3.5.2. TCP Reno Em 1990 Van Jacobson (ver Cap. 3.2.1.2), continuando a precisa análise de eficiência das redes de computadores efectua modificações ao algoritmo Congestion Avoidance [14]. O algoritmo principal desta nova versão é o Fast Recovery. 3.5.2.1. Fast Recovery Fast Recovery permite uma recuperação mais rápida, enviando menos. As modificações efectuadas devem-se em grande parte a uma situação verificada: apesar de um ack duplicado poder indicar congestão, significa também que um segmento chegou bem ao receptor e saiu da rede. Foram especificadas as seguintes situações: • Por cada vez que cada ack duplicado chegar ao emissor, em vez de usar a normal forma de incrementação Congestion Avoidance, incrementa-se a cwnd no valor de um segmento; • Quando o segmento é retransmitido devido ao algoritmo Fast retransmit, a cwnd assume o valor do ssthresh mais três segmentos. Desta forma é feito directamente Congestion Avoidance em vez de iniciar Slow Start, o valor dos três segmentos é devido ao facto de 3 acks duplicados significarem que 3 segmentos saíram da rede; • Transmite um segmento se for permitido pela cwnd e pela janela do receptor; • Quando tudo voltar ao normal e novos segmentos notificados ao emissor, a cwnd toma o valor do ssthresh, de forma a ser feita a normal incrementação Congestion Avoidance em vez do Slow Start. A Figura 3.40 exemplifica uma situação com todos os algoritmos de congestão em funcionamento (Slow Start, Congestion Avoidance, Fast Retransmit e Fast Recovery). O eixo dos xx representa o tempo, o eixo dos yy a janela de congestão; o valor máximo do yy é o valor do ssthresh, que será por sua vez o tamanho máximo da janela do receptor (64KB). O algoritmo inicial é o Slow Start que é automaticamente invocado; passado algum tempo um timeout ocorre e o ssthresh toma metade do valor da cwnd; o Slow Start inicia outra vez, mas agora, quando atinge o valor do ssthresh o limite de congestão é atingido e o Congestion Avoidance invocado com a sua incrementação 1/cwnd; o próximo acontecimento é uma perda detectada pelo 3º ack duplicado, sendo então invocado o Fast Retransmit que rapidamente transmite o segmento, sem que exista tempo morto por parte do emissor; por fim é invocado o Fast Recovery ficando a cwnd com o valor de ssthresh mais a adição de 3 segmentos, entrando directamente em Congestion Avoidance. Continuando, ainda são invocados mais duas vezes o Fast Retransmit, Fast Recovery e Congestion Avoidance sucessivamente. 68
- 91. 3. Enquadramento aoProtocolo Figura 3.40 – Representação dos algoritmos de congestão em funcionamento (Fonte: [6]). Van Jacobson acabava aqui o seu ciclo de algoritmos, porém um melhoramento final aos seus algoritmos ia ainda ser efectuado. Todos os algoritmos de congestão anteriormente referenciados ficaram referenciados em RFC [45]. 3.5.3. TCP newReno Janey Hoe (ver Cap. 3.2.1.2 ) iria desenvolver o último algoritmo deste ciclo. Especificado numa primeira vez em 1996 [19] e finalmente em RFC em 1999 [46] e 2004 [52], este foi talvez o algoritmo que mais demorou a ser adoptado. Essa tardia adopção deveu-se provavelmente ao facto de as melhorias não se verificarem tão grandes, quanto as verificadas aquando da criação dos anteriores algoritmos. O newReno foca, essencialmente, a fraca capacidade do Reno em recuperar de uma múltipla perda de segmentos. Verificou-se que para uma única perda de segmento a recuperação é bastante boa, mas que passando esse limite a perfomance torna-se bastante reduzida. O problema acontece aquando da activação do algoritmo Fast Retransmit. Como foi referenciado anteriormente, o algoritmo Fast Retransmit é activado sempre que o emissor recebe um terceiro ack duplicado, sendo que o segmento é rapidamente retransmitido. A situação problemática surge quando para a mesma janela mais de um segmento se perdeu, sendo necessário mais do que uma transmissão. Imaginando que o 3ºack duplicado é o 1, ao retransmitir é recebido o ack do 2; a situação não é normal, pois até receber o 3ºack duplicado foram pelo menos enviados 3 segmentos e no funcionamento normal existe um ack de n segmentos. Assim sendo, existe uma alta probabilidade de o 3 estar perdido que não foi considerada nos algoritmos anteriores. 69
- 92. TCP em Redesde Elevado Débito O facto dessa probabilidade não ser considerada leva ao exemplo padrão da Figura 3.41, verificado na anterior implementação Reno. O problema é o facto de apenas numa janela existirem duas invocações do Fast Retransmit/Fast Recovery. O eixo dos xx representa a janela de congestão, o eixo dos yy o tempo; na primeira invocação tudo resulta bem, chegando segmentos ao receptor, que por sua vez enviará os acks duplicados; na segunda vez, o segmento já foi perdido à bastante tempo, a janela de congestão já não permite mais envios e estando agora a rede com poucos segmentos que irão chegar ao receptor, é já muito elevada a probabilidade de existirem acks duplicados para a rede funcionar, ficando assim a rede parada; o caminho será então o timeout do segmento que iniciará, posteriormente, o Slow Start. Figura 3.41 – Representação do padrão problemático Fast Retransmit/Fast Recovery. O que se verificou com este padrão foram dois problemas principais: • O valor inicial do sshthresh (valor máximo da janela de recepção) é um dos grandes responsáveis pela múltipla perda de pacotes, sendo este padrão verificado muitas vezes no início da ligação; A solução para este problema foi tentar obter uma melhor forma para definir o parâmetro inicial ssthresh. Sendo o ssthresh um limite para a ocorrência de congestão, a ligação à capacidade da rede é fácil de adivinhar. Dessa forma, usando a propriedade self-clocking do TCP e a estimação RTT, podemos calcular a capacidade da rede (BDP) e associá-la directamente ao ssthresh diminuindo bastantes as múltiplas perdas. • A falha do algorimo Fast Retrasmit ao tentar recuperar de múltiplas perdas de segmentos. Um algoritmo que não desça a sua janela de congestão até todas as perdas daquela janela terem ocorrido é o que se pretende. É primeiro necessário saber quando estão a ocorrer múltiplas perdas ou uma simples perda, pois nesta segunda situação os anteriores algoritmos atingem boas perfomances. Para isso é definida uma variável recover com o último número de sequência dos segmentos enviados, antes do 3ºack iniciar o Fast Retransmit. Esta variável é a responsável por duas condições: 70
- 93. 3. Enquadramento aoProtocolo o Se o 3ºack duplicado for menor que a variável recover então estamos perante um Partial Ack, i.e., não foram recebidos todos os segmentos; Neste caso não são efectuado nem Fast Retransmit nem Fast Recovery. O valor ssthresh não vai ser afectado nem a cwnd, porém será enviado um segmento por RTT. Esse envio acontece pois cada vez que um ack duplicado chegue ao emissor a janela do receptor irá permitir mais um envio, como a janela de congestão como não foi diminuída irá permiti-lo, até todos os segmentos da janela serem retransmitidos. o Se o 3ºack duplicado for maior que a variável recover então todos os segmentos foram correctamente recebidos. Funcionamento normal31 por parte do Fast Retransmit e Fast Recovery. As semelhanças nas preocupações entre TCP newReno e Sack (ver Cap. 3.3.2.5) são bem notórias: ambos se preocupam com a optimização na retransmissão de segmentos. Apesar dessa situação o TCP newReno com Sack supera em perfomance o normal Reno com Sack. Existe porém um cenário onde o Reno tem melhor perfomance: sem perdas, mas com suficiente reordenamento para o emissor receber 3ºack e ser “enganado” por não se tratar de uma perda. Com Reno apenas um segmento seria transmitido, com newReno o “engano” dá origem a uma sucessão de retransmissões. O newReno após algum tempo foi totalmente adoptado em todas as implementações. Muitas implementações actuais não diferenciam Reno e newReno, considerando o primeiro como o segundo, e nunca o segundo como o primeiro. A recuperação de perdas é ainda actualmente um problema muito debatido e nada simples de resolver, foi especificada uma RFC específica para esse procedimento [48]. A Figura 3.42 é um resumo de todas as versões TCP até agora explicadas. Todos são implementados em conjunto, pelo que é normal existir dificuldade em definir o âmbito de cada um. O Fast Retransmit perde todo o seu objectivo sem Fast Recovery, o Congestion Avoidance perde o objectivo se for retirado o Slow Start. 31 Normal neste caso significa o funcionamento da versão anterior (TCP Reno). 71
- 94. TCP em Redesde Elevado Débito Figura 3.42 – Resumo de todas as operações e algoritmos de congestão, proporcionados pelas versões TCP Tahoe, Reno e newReno. Ao longo do desenvolvimento notou-se também, cada vez mais, uma análise mais pormenorizada da perfomance. A versão newReno foi detectada por variados testes e uma análise pormenorizada detectou um padrão de menor perfomance. Esta seria a forma com que actualmente se desenvolvem as novas versões: análise de perfomance, análise de padrões de menor perfomance, verificação da existência de problemas, implementação da solução. 3.5.4. TCP Vegas “O principal resultado que se verifica neste paper é o facto do Vegas conseguir atingir entre 40 a 70% melhor throughput que o Reno”. [15] O TCP Vegas foi especificado por Lawrence Brakmo (ver Cap. 3.2.1.2) em 1994 [15]. O seu objectivo foi providenciar novos horizontes a todo controlo de congestão, propondo modificações para que o TCP pudesse explorar esses mesmos horizontes. Essas modificações dividem-se em sete melhoramentos, com o principal objectivo de aumentar o throughput da rede e diminuir as perdas. Os melhoramentos são: 1. Melhoria significativa nos mecanismos de estimação RTT; 2. Melhor retransmissão de segmentos; 3. Melhor retransmissão, considerando múltiplas perdas; 4. Ajustamento à forma como é estabelecido o redimensionamento da janela de congestão no Reno; 5. Melhor espaçamento entre os segmentos; 72
- 95. 3. Enquadramento aoProtocolo 6. Responsável pela maior novidade, permitindo ao TCP antecipar a ocorrência de congestão, ajustando posteriormente o envio de segmentos; 7. Modificação no Slow Start baseada no ponto 6. Melhoria na estimação RTT O Reno faz a normal estimação do RTT com base num temporizador com amostragem de 500ms, o que em certas situações pode tornar a estimação menos precisa. A melhoria efectuada verifica-se apenas no caso do TCP não ter activado a Timestamp Option, pois dessa forma a estimação não é efectuada recorrendo ao normal temporizador. O TCP Vegas utiliza o relógio do sistema de cada vez que um segmento é enviado. Desta forma, quando o ack chega ao emissor volta a ler o relógio do sistema e calcula o RTT. A vantagem entre esta implementação e a Timestamp Option é que desta forma não é necessária qualquer ajuda por parte do receptor. Melhoramentos para retransmissão de um segmento perdido A primeira técnica tem a sua origem na dependência do Reno em necessitar de 3 acks duplicados para efectuar uma retransmissão. O Vegas efectua uma comparação quando um ack duplicado é recebido, sendo essa comparação o valor RTT do segmento com o valor de timeout. Se o valor for superior o segmento é imediatamente retransmitido. A segunda técnica opera logo a seguir à primeira retransmissão. Se o ack seguinte for o do primeiro ou segundo após o segmento retransmitido, imediatamente o segmento em questão é retransmitido. É de referir que esta especificação foi efectuada antes do newReno, pelo que esta situação iria ser abordada de melhor forma nessa mesma versão. Modificação no redimensionamento da janela de congestão Baseado num problema do Reno que também seria abordado de melhor forma na versão newReno. O problema verificado é o facto da janela de congestão poder decrescer mais do que uma vez por RTT. O TCP Vegas não permite essa situação, considerando que as perdas após o primeiro decréscimo da janela já não dizem respeito ao valor da janela reduzida. 73
- 96. TCP em Redesde Elevado Débito Melhoria para melhor espaçamento entre os segmentos Verificou-se que no Reno grande parte das perdas é devido a bursts32 de segmentos. A razão dos bursts é principalmente falhas nos mecanismos responsáveis pelo self-clocking. As duas razões para isso acontecer são: • Acks largamente cumulativos; Geralmente esta situação acontece quando o receptor acumula bastantes notificações de segmentos para poder fazer piggybacking (ver Cap. 3.3.2.1). • Ack Compression. Este mecanismo foi descrito pela primeira vez em 1992 [12]. A razão prende-se com o facto de os buffers acumularem diversos segmentos nas suas filas de espera33 e quando geralmente a aplicação os retira, retira-os bruscamente dando origem a acks muito poucos espaçados. O TCP Reno não controla a forma como o espaçamento entre segmentos é efectuado. A janela de congestão apenas limita a quantidade de segmentos a enviar, não implementando qualquer mecanismo de controlo de espaçamento. Desta forma, a probabilidade das filas encherem é bastante grande. O valor ideal de espaçamento é dado pela seguinte fórmula: )( cwnd MaxSegment RTTSeqSpacing = Esta fórmula é utilizada pelo TCP Vegas no mecanismo Spike Supression. Este mecanismo consiste em permitir apenas um envio de 2 vezes o MaxSegment por cada intervalo SegSpacing. O total de bytes que se poderá transmitir continua limitado pela janela de congestão, porém, desta forma é apenas permitido transmitir 2 vezes o número ideal de bytes por SegSpacing. Outra forma de tratar a congestão Como já foi visto anteriormente, o TCP Reno utiliza a perda de segmentos como sinal de congestão. Não existe qualquer mecanismo no TCP Reno que permite detectar estados antecipados de congestão, desta forma o TCP não previne mas apenas reage. O TCP Reno é assim considerado um protocolo reactivo e não proactivo. O TCP Vegas traz como principal novidade a sua proactividade (ver Cap. 2.1.5.2) já referida anteriormente para tratar a congestão. Assim sendo, as abordagens para tratar a congestão poderão agora ser divididas por: 32 O inglês “burst” significa rajada, neste caso referenciado a segmentos em rajada. 33 Filas de espera neste caso têm um significado genérico, não estando presente qualquer mecanismo específico. 74
- 97. 3. Enquadramento aoProtocolo • Controlo de Congestão (Reactiva) Actua depois da rede estar sobrecarregada. • Prevenção de Congestão (Proactiva) Actua antes da rede estar sobrecarregada. No controlo proactivo do TCP Vegas o conceito é comparar um throughput medido a cada operação na rede, a um througput que se esperava que a rede tivesse. Desta forma o Vegas controla a quantidade de dados extra34 que estão na rede, sendo o principal objectivo manter na rede a quantidade ideal de dados sem que ocorra congestão. O Vegas baseia-se então em duas considerações principais: • Se a ligação está a enviar muito, a congestão está próxima; • Se enviar pouco, significa que a rede não tem capacidade para suportar grandes acréscimos de transmissão. A fórmula utilizada para calcular o throughput esperado é a seguinte: BaseRTT cwnd TExpected = O valor da cwnd é o valor corrente da janela de congestão, o valor BaseRTT é sempre o RTT mínimo da ligação. No que diz respeito ao throughput actual é calculado armazenando o tempo de envio do segmento e contabilizando os bytes que foram enviados, entre o tempo de envio e o tempo que foi recebido. De seguida é feita uma divisão pelo RTT desse segmento. Após os cálculos anteriores serem efectuados é calculada a diferença entre o esperado e o corrente: ActualExpected TTDiff −= São definidos dois thresholds: βα e ; para estabelecer as decisões a tomar, conforme a diferenciação entre throughputs. O valor dos thresholds irá definir a “agressividade35 ” da versão TCP Vegas no que diz respeito a ocupação de recursos. Os valores mais usados são 3,1 == βα ; 4,2 == βα . Os valores são definidos como segmentos por RTT, sendo o β responsável pelo valor máximo para diminuir a janela de congestão. 34 Dados que estão a mais na rede. 35 Referencia o grau de risco em relação à ocorrência de congestão na rede. 75
- 98. TCP em Redesde Elevado Débito As decisões referentes ao redimensionamento da janela de congestão são: • Se α<Diff então a janela de congestão irá aumentar linearmente no valor de 1/cwnd; • Se β>Diff então a janela de congestão irá diminuir no valor de 1/cwnd; • Se βα << Diff então a janela será mantida. A Figura 3.43 representa o funcionamento do TCP Vegas, considerando a relação entre a velocidade de transmissão e a diferença de throughput verificada. Quanto maior o throughput actual, maior será a velocidade de envio (aumento da janela); quanto menor o throughput actual, menor será a velocidade de envio (diminuição da janela); a fase ideal é um intermédio das duas anteriores, não sendo alterada a velocidade de transmissão. Figura 3.43 – Relação throughput/velocidade transmissão [Fonte: [15]]. O algoritmo anterior explicado não é directamente aplicado na fase de Slow Start, tendo esse algoritmo sido alvo de uma modificação. Modificação no Slow Start O Slow Start é um algoritmo bastante “caro36 ” a nível de perdas, se o buffer do emissor não for limitado. Quando o Slow Start começa a sobrecarregar a rede já podem existir perdas na ordem de metade da janela de congestão. O TCP Vegas podia começar a usar de início o seu algoritmo de prevenção, mas a falta de aproveitamento de largura de banda seria enorme. A solução encontrada foi um intermédio entre a abordagem Reno e a abordagem Vegas. O Reno aumenta exponencialmente a janela de congestão por cada RTT, o Vegas aumenta exponencialmente uma vez por RTT e no próximo previne com o seu algoritmo. Também neste caso é definido um thresholdγ com objectivos idênticos aos outros dois thresholds, mas para definir especificamente a “agressividade” do algoritmo Slow Start. 36 Caro em relação a que para ter elevado débito implica outras desvantagens. 76
- 99. 3. Enquadramento aoProtocolo A Figura 3.44 representa um gráfico característico da versão TCP Vegas. Ao contrário da versão Reno não se verificam grandes oscilações; o gráfico é caracterizado por um uma janela de congestão que lhe garante uma transmissão bastante constante ao longo do tempo; os thresholds β e α definem todo o controlo de transmissão; verifica-se também que só existe Slow Start e Congestion Avoidance ao longo do tempo. Figura 3.44 – Gráfico característico do TCP Vegas. Apesar deste ser um gráfico aproximado do que costumam ser as transmissões com TCP Vegas, todos os algoritmos do Reno estão presentes. A principal vantagem do Vegas é que como tem uma taxa de 2 a 5 vezes menos perdas que o Reno, raramente os invoca. A seguir à sua inicial especificação foram efectuados alguns melhoramentos [16][17]. Os principais foram uma redução para ¼ da janela (no Reno era ½) aquando da verificação de congestão, e um valor inicial da janela de 2 MSS (no Reno era 1 MSS). Após toda a fase de especificação variados testes foram feitos. Provavelmente TCP Reno e TCP Vegas foram as versões a que mais testes tiveram sujeitas, principalmente testes de comparação entre os dois. A inicial especificação definia o TCP Vegas como garantia de mais 40% a 70% throughput que o Reno, mas essa garantia não é assim tão simples e directa. Praticamente todos os estudos deram melhor perfomance para o Vegas em situações com diferentes RTT, baixos atrasos e poucas retransmissões [16][17][18]. Apesar desta situação, ligações com altos atrasos têm melhor perfomance usando Reno [18]. Existe também um problema a que o TCP Vegas está inerente: o facto de poderem existir mudanças de rotas ao longo do percurso, alterando bruscamente o RTT; estando o TCP Vegas tão depende do RTT para as suas decisões, o resultado são baixas perfomances. Outros problemas prendem-se principalmente com fairness37 ; a principal razão prende-se outra vez com o RTT: o primeiro fluxo que usar a rede terá sempre um menor RTT mínimo do que o segundo fluxo, dessa forma terá sempre a sua janela maior, transferindo posteriormente mais dados. 37 O inglês “fairness” significa justiça, neste caso justiça na atribuição de recursos. 77
- 100. TCP em Redesde Elevado Débito Os testes verificam principalmente uma nova situação: a existência de duas versões, cada uma funcionando melhor com certas condições de rede. Era dado aqui o primeiro passo para uma série de versões cada vez mais específicas. 3.5.5. Outros meios, outras versões Foi evidenciado no Cap. 3.1.1 que o desenvolvimento a partir de determinados pressupostos. Apesar desta situação, as versões anteriormente referenciadas são eficientes para a maioria dos meios, não implicando claro que sejam altamente eficientes em cada meio específico. As novas versões que surgiram abordam esta situação, tentando atingir níveis de alta eficiência em meios específicos. A maior quantidade de versões existentes tem como meio específico o alto débito (ver Cap. 3.6). Apesar disso, existem outros meios igualmente importantes, com abordagens diferentes aos normais algoritmos de congestão. 3.5.5.1. Comunicações Satélite As comunicações de Satélite são caracterizadas principalmente por: altos atrasos, erros nas transmissões, perda de conectividade e altas larguras de banda assimétricas. Apesar de todos estes parâmetros afectarem directamente a aquisição de eficiência por parte do TCP, o mais crítico são os altos atrasos, na ordem dos 480ms a 560ms. A preocupação evidenciada pelas comunidades de investigação na obtenção da máxima eficiência deste tipo de meios, deu origem a uma RFC [44] que fornece recomendações acerca dos algoritmos de congestão a usar, aumento do tamanho da janela de recepção e outros melhoramentos. Mais tarde iria surgir uma nova versão TCP, especificamente, direccionada para este tipo de meios: o TCP Hybla. TCP Hybla O TCP Hybla, especificado em 2004 [20] tem como principal objectivo quebrar a relação entre RTT e janela de congestão. Devido aos altos atrasos inerentes às comunicações satélites, os valores do RTT irão ser de índice bastante superior a qualquer outro meio. A forma como os normais algoritmos do Reno e Vegas decidem sobre a transmissão, ou não, de mais segmentos por parte do emissor é feita a cada RTT. Desta forma, é fácil perceber que a forma instantânea com que os antigos protocolos transmitiam para a rede, não se revela assim tão instantânea considerando altos RTT. 78
- 101. 3. Enquadramento aoProtocolo O Hybla tenta devolver a instantaneidade em falta no que diz respeito à transmissão de segmentos. A solução encontrada foi tornar as regras de aumento de congestão independentes do RTT, através de uma mudança de escala temporal no envio de segmentos. 3.5.5.2. Comunicações Wireless As redes wireless, apesar da tecnologia não ser recente, tornaram-se bastante comuns actualmente. Quando esta tecnologia surgiu, exigiu novos requerimentos que resultaram em diversos protocolos e mecanismos de rede específicos. O TCP na altura do surgimento desta tecnologia não foi sujeito a qualquer modificação ou melhoramento. Essa situação, ocorreu muito por culpa da eficiência e compatibilidade proporcionada pelos normais mecanismos e algoritmos de congestão deste protocolo. Só mais tarde, após o surgimento das diversas versões TCP adaptadas a meios específicos, o TCP iria ser melhorado para este tipo de meio tão peculiar. Os meios wireless são caracterizados por: baixas larguras de banda e muitos erros de transmissão. A característica mais crítica são os erros de transmissão que por vezes podem ultrapassar a barreira do 1% (considerando bits/s). Estes erros geralmente quando ocorrem, ocorrem em burst. Foi referido, anteriormente nos algoritmos de congestão (ver Cap. 3.5), que existem dois tipos de perdas e que um desses tipos era desprezado (os erros do meio de transmissão). Neste tipo de meios essa situação não pode acontecer, sob pena de ser perdida toda a eficiência na ocupação de largura de banda disponível. Distinguir entre perdas devido a congestão e perdas devido ao meio de transmissão, assim como providenciar formas de medição para a sua diferenciação é um problema fundamental para o TCP em meios wireless e a sua solução não se revela fácil de adquirir. Existem duas versões principais, especialmente, concebidas para este tipo de meio: o TCP Westwood e o TCP Veno. TCP Westwood O TCP Westwood [29] foi a primeira versão a surgir. É um protocolo bastante estável utilizado por omissão em diversas distribuições Linux. Apesar de ser concebido especificamente para redes wireless, adapta-se bastante bem a todos os outros meios. Em todos os meios revela um aproveitamento de largura de banda bastante superior ao TCP Reno e Vegas. As redes de alto débito não são excepção, apesar de os meios sem fios não serem meios caracterizados por altas larguras de banda. O conceito mais inovador do TCP Westwood é uma contínua estimação do débito da rede, monitorizando toda a chegada dos respectivos acks. Todo este débito estimado é depois usado para alterações na forma como é alterada a janela de congestão e o ssthresh. O objectivo será então uma maior dinâmica às perdas, 79
- 102. TCP em Redesde Elevado Débito não exagerando nas descidas da janela de congestão. O algoritmo dinâmico de recuperação é referenciado como “Faster Recovery38 ”, o algoritmo de medição é referenciado como BWE (Bandwidth Estimate). Estes dois algoritmos são as principais novidades desta versão, apesar disso, o RTT também é utilizado para definir a taxa de transmissão. Assim, o RTT mínimo servirá para verificar o estado da rede, enquanto o BWE servirá para saber o débito fluxo-a-fluxo, eliminando situações de monopolização da largura de banda conhecidas dos algoritmos DCA (Delay Congestion Avoidance, ver Cap. 3.5.6). Imaginando uma situação prática com perda por erro de transmissão, o TCP Westwood não o detecta; mas, ao efectuar a recuperação, verificará o BWE que provavelmente estará com um bom débito para que não ocorra congestão; então, vai verificar o RTT vendo que ele era o mínimo da transmissão (indicação que a rede estava de “boa saúde” no que diz respeito a congestão); finalmente, perante estas situações a janela de congestão não vai descer e o débito será mantido, sendo a perda praticamente ignorada. Existe também um melhoramento a este algoritmo que permite uma melhor perfomance mesmo com ack compression [12]. Essa versão é referenciada como Westwood+ [29]. TCP Veno O TCP Veno [21] surgiu um pouco mais tarde do que o TCP Westwood trazendo uma menor componente de inovação. O próprio nome “Veno” é uma analogia à junção dos mecanismos do Reno e Vegas. O TCP Veno efectua a decisão que não é directamente tomada pelo TCP Westwood. Para efectuar essa decisão utiliza todo o algoritmo de estimação RTT do TCP Vegas. O conceito é simples: se o RTT estimado for muito elevado em relação ao mínimo, então poderá estar a ocorrer congestão e, posteriormente, se ocorrer perda foi devido a congestão, invocando assim os normais algoritmos do Reno; caso contrário, a perda é devido a erros de transmissão e a janela deve descer apenas 1/5, utilizando também os normais algoritmos do Reno. Para além destas versões, existem mais de 200. Apesar desse facto, 90% das versões são ainda experimentais, estando em constante desenvolvimento e em constantes testes comparativos. As versões anteriores referenciadas encontram-se já com um desenvolvimento bastante estável. 38 O nome tem uma razão comparativa com o anterior algoritmo do Reno “Fast Recovery”, significando maior rapidez (Faster). 80
- 103. 3. Enquadramento aoProtocolo 3.5.5.3. TCP de baixa prioridade Se até aqui se tem falado de eficiência e máxima ocupação da largura de banda disponível, o que dizer de uma versão que apenas aproveita os “restos39 ” da largura de banda de uma ligação? A resposta é simples: se existirem ficheiros em que a o tempo da sua transferência não seja importante, não se revela necessário requisitar largura de banda de outros fluxos. Para redes com débitos bastante reduzidos este tipo de versões providencia o algoritmo para que os outros fluxos consigam ter elevados tempos de resposta em aplicações interactivas, sendo simultaneamente transferidos ficheiros, para os quais o tempo de resposta não é importante. A versão mais conhecida que aborda este conceito é o TCP Low Priority40 [22], sendo o seu objectivo usar a largura de banda não utilizada pelos outros fluxos de uma forma não intrusiva, i.e., transparente aos outros fluxos. 3.5.6. DCA VS LCA Durante o desenvolvimento de novas versões, mais se reparou nas vantagens e desvantagens entre as implementações usando a base do TCP Reno e a base do TCP Vegas. Estas abordagens são referenciadas como Loss-Based Congestion Avoidance (LCA), caso do TCP Reno e Delay Congestion Avoidance (DCA), caso do TCP Vegas. O primeiro passo na especificação de uma nova versão é ter a correcta noção do que induz cada uma destas abordagens. As duas adequam-se mais a certos meios, as duas incorrem em alguma falta de eficiência em certas situações, e as duas são absolutamente necessárias para a existência de versões adaptadas, específicas a meios de transmissão. Muitas das vantagens foram sendo explicadas anteriormente, será dado agora maior ênfase às diversas desvantagens. As desvantagens da abordagem LCA são: • Throughtput será sempre obrigatoriamente menor do que a largura de banda disponibilizada; Sendo uma abordagem que testa a rede até ao limite, fácil será perceber que a rede acabaria por ceder, descartando segmentos. • Muitas perdas; Testar a rede até ao limite traz também esta desvantagem. O primeiro teste será onde ocorrerá maiores perdas (Slow Start). O objectivo é estudar a rede para perder menos; 39 Referindo a disponibilidade de largura de banda que não é ocupada. 40 Também referenciado como TCP-LP 81
- 104. TCP em Redesde Elevado Débito • Altas variações nos atrasos; Geralmente neste caso, ou os atrasos são pequenos, ou os atrasos são muito grande estando já a ocorrer congestão. • Alto requerimento de buffers por parte dos routers; Sendo esta uma forma um pouco agressiva de tratar a rede (testando até existir perdas), os routers têm de estar melhor preparados. • Risco de diminuição da janela de congestão de forma exagerada; Tendo apenas um nível de congestão (ou existe ou não existe), é complicado tomar uma decisão eficiente no que diz respeito ao decréscimo da janela. • Mais problemático quando existe perdas devido ao meio de transmissão; Devido ao facto de existirem mais oscilações, quando existe perdas que não são devido a congestão é perdida mais eficiência. A comunidade de investigação geralmente atribui a abordagem DCA como menos arriscada, traduzindo esse facto menos desvantagens. Apesar dessa situação existem também algumas: • Pequenas variações no RTT não são valorizadas; Em casos de bottleneck41 muito pequenos existirá variações RTT que o estimador RTT não irá notar devido a amostragem do tempo, desvalorizando assim a possível ocorrência de congestão. • Problema de fluxos serem monopolizados por outros; Se existir um fluxo na ligação que esteja a manipular todo o bottleneck, os RTT indicarão congestão baixando assim a taxa de transmissão, porém esses RTT são controlados pelo outro fluxo. • Falta de justiça na atribuição de recursos aquando uma situação de congestão. Numa situação de congestão, os algoritmos DCA não descem como os LCA. Desta forma toda a justiça na atribuição de recursos (fairness) é perdida. • Problemas entre a relação RTT e a congestão; Existem variados estudos [23] que estabelecem uma fraca relação entre o aumento da janela de congestão e o RTT. 41 O ingês “bottleneck” significa pescoço de garrafa, numa analogia a estreitamento do caminho, ou neste caso, a ligação mais lenta. 82
- 105. 3. Enquadramento aoProtocolo 3.6. Versões TCP alto débito O TCP Westwood devido às melhorias “emprestadas42 ” ao alto débito marcou a passagem ao 3ºciclo de desenvolvimento (ver Cap. 3.2). Após as comunicações por satélite e as comunicações wireless, as ligações de alto débito e, principalmente, a preocupação com as LFN levaram a uma grande resposta da comunidade investigação, sendo actualmente o meio específico para o qual mais versões foram criadas. 3.6.1. O problema com o alto débito O problema das anteriores versões TCP com as larguras de banda de alto débito baseia-se essencialmente na verificação de um Slow Start (ver Cap. 3.5.1.2) aceitável mas um Congestion Avoidance (ver Cap. 3.5.1.3) extremamente lento. Este problema verifica-se de forma mais acentuada no protocolo TCP Reno. O problema que surgiu foi uma verificação de perda de eficiência bastante acentuada devido ao facto do topo da largura de banda nestes meios ser bastante elevado. Uma única perda neste tipo de meio, é quase catastrófica. Essa situação acontece pois como a escala é bastante grande, a diminuição da transmissão é extremamente elevada. Porém, a forma como cresce continua igual, como se o topo da largura de banda disponível tivesse bastante próximo de ser alcançado. O elevado atraso sempre inerente neste tipo de ligações (principalmente se for LFN) também não vem facilitar a tarefa, diminuindo ainda mais a velocidade com que os segmentos são injectados na rede. Na altura de especificação do Reno e Vegas foram consideradas velocidades de 10Mbit/s que não revelavam o elevado tempo de recuperação. Considerando uma ligação de 10Mbit/s com um RTT de 70ms e 1500 bytes por segmento, são necessários cerca de 42 segmentos (considerando um incremento de 1 segmento, e decremento de ½ no sshthresh) para recuperar com a incrementação Congestion Avoidance, o que perfaz um total de aproximadamente 3 segundos de recuperação. Considerando o mesmo caso para 10Gbit/s, o tempo passa para 34 minutos até chegar a todo o aproveitamento da largura de banda. A Figura 3.45 representa esta situação no caso da rede ser de 10Gbit/s, verifica-se também que o tempo do Slow Start foi bastante aceitável. Após um certo período de tempo o débito médio desta rede será de aproximadamente 7.5Gbit/s, não utilizando eficientemente 2.5Gbit/s disponíveis. 42 Refere-se ao facto de o TCP Westwood não ter sido especialmente desenvolvido para melhoria da eficiência em ambientes de alto débito. 83
- 106. TCP em Redesde Elevado Débito Figura 3.45 – Comportamento do TCP Reno numa LFN de 10Gbit/s (Fonte: [9]). A forma de cálculo deste tempo de recuperação por parte do algoritmo Congestion Avoidance (na versão Reno) é fornecida pela seguinte fórmula, permitindo calcular o tempo de resposta (responsivness): MSS RTTC 2 )( 2 =∂ respostadetempo=∂ rededaCapacidadeC = Alguns valores fornecidos por esta fórmula estão expressos na Tabela 3.3. Verifica-se uma subida acentuada do tempo de resposta em relação ao aumento da capacidade da rede, ou em relação ao seu atraso (RTT). É de realçar também que ao aumentar o tamanho do segmento, este tempo diminui bastante (última ligação WAN Futura), para isso serão necessários buffers enormes por parte dos routers. Ligação Capacidade RTT (ms) MSS (Byte) Valores de tempo de resposta LAN típica em 1988 10 Mb/s [ 2 ; 20 ] 1460 [ 1.7 ms ; 171 ms ] Típica LAN actualmente 1 Gb/s 2 (pior caso) 1460 96 ms Futura LAN 10 Gb/s 2 (pior caso) 1460 1.7s WAN 1 Gb/s 120 1460 10 min WAN 1 Gb/s 180 1460 23 min 84
- 107. 3. Enquadramento aoProtocolo WAN 1 Gb/s 300 1460 1 h 04 min WAN 2.5 Gb/s 180 1460 58 min WAN Futura 10 Gb/s 120 1460 1 h 32 min WAN Futura 10 Gb/s 120 8960 (Jumbo Frame) 15 min Tabela 3.3 – Tabela com valores de tempo de resposta conforme tipo de ligação (Fonte: [62]). O objectivo das novas versões para alto débito é principalmente baixar este tempo de resposta, com o intuito de aumentar o débito médio da rede. As versões abaixo referenciadas são aquelas em que o desenvolvimento se encontra mais estável, assumindo um elevado grau de importância devido aos novos conceitos adicionados. 3.6.2. HighSpeed TCP “Uma forma de olhar a proposta HighSpeed TCP é que ela opera da mesma forma que um turbo de um motor; quanto mais rápido o motor está, mais rápido o turbo opera até que o motor funcione na sua normal velocidade”. [9] O HighSpeed TCP é de todas as versões de alto débito aqui referenciadas a versão que se encontra mais avançada em termos de desenvolvimento e adopção. É a única versão TCP para alto débito especificada em RFC [51], tendo sido desenvolvida por Sally Floyd (ver Cap. 3.2.1.3). O HighSpeed TCP surgiu com base num conceito de uma versão TCP para alto débito bastante simples: o MulTCP [24]. MulTCP Tal como foi referido anteriormente, o principal problema está no Congestion Avoidance (ver), devendo as mudanças essenciais serem efectuadas nesse algoritmo (responsável pela reacção às perdas). O MulTCP quando invoca o Congestion Avoidance incrementa a sua janela de congestão em N segmentos por RTT, em vez do normal incremento 1/cwnd; após uma perda reduz a sua janela de congestão em cwnd/(2N), em vez do normal cwnd/2. É também utilizada uma versão alterada do SlowStart, onde a janela de congestão aumenta 3 segmentos em vez dos normais 2. 85
- 108. TCP em Redesde Elevado Débito O MulTCP não tem qualquer algoritmo de congestão específico, pelo que considerá-lo uma versão TCP poderá ser exagerado, sob o facto de existirem apenas alterações nos parâmetros AIMD. A sua principal inovação é a criação do factor N responsável pela definição dos variados parâmetros. Assim, se o N for demasiado elevado, o MulTCP tem uma tendência para requisitar largura de banda exageradamente; se o valor for demasiado baixo, não retirará o devido proveito da largura de banda disponibilizada. O problema do MulTCP é pecar por demasiada especificidade ao meio de transmissão, sendo obrigatório modificar o factor para cada tipo de meio de transmissão. O HighSpeed TCP vem solucionar o problema de especificidade MulTCP, fornecendo como solução o conceito de que a resposta do débito às perdas não deve ser através de um factor fixo, mas adaptativamente conforme as perdas existentes na rede, i.e., reparando que o número de perdas aumentam conforme a largura de banda disponibilizada. Quanto maiores forem as perdas, maior será a disponibilização de largura de banda, quanto maior for a disponibilização, mais rápido deverá crescer a janela de congestão. O algoritmo HighSpeed TCP só é invocado perante um certo limite de perdas, caso contrário, os normais algoritmos TCP Reno são invocados. Na prática os valores aproximados de decréscimo e incremento da janela de congestão durante o Congestion Avoidance por parte do HighSpeed TCP são: Até 10Mbit/s, os normais algoritmos TCP Reno; Para 100Mbit/s, decréscimo de 1/3 na janela de congestão, incremento de 6 segmentos/RTT; Para 1Gbit/s, decréscimo de 1/5 na janela de congestão, incremento de 26 segmentos/RTT; Para 10Gbit/s, decréscimo de 1/10 na janela de congestão, incremento de 70 segmentos/RTT. A Figura 3.46 representa as versões MulTCP e HighSpeed TCP numa ligação LFN de 10Gbit/s. O Slow Start começa demorando cerca 1,2s, sendo o Slow Start MulTCP na ordem dos 0.8 segundos; de seguida começa o Congestion Avoidance, o MulTCP revela-se completamente adaptado ao meio sabendo exactamente até onde pode subir, o TCP HighSpeed sobe até ao disponível em cerca de 27 segundos, o normal TCP (TCP Reno) sobe muito lentamente; após Fast Recovery a janela de congestão do TCP HighSpeed desce pouco, permitindo alcançar o seu máximo em cerca de 8 segundos, bem melhor que os normais 34 minutos usando o normal TCP (ver Figura 3.45). 86
- 109. 3. Enquadramento aoProtocolo 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]). O aumento de perfomance é imenso, sendo traduzidos os cerca de 8 segundos de recuperação, em pelo menos, velocidades médias de ligação de 9Gbit/s. 3.6.3. Scalable TCP O Scalable TCP [Scalable] foi desenvolvido ainda antes do HighSpeed TCP, tendo como principal objectivo quebrar o relacionamento entre as modificações na janela de congestão e o RTT. Os desenvolvimentos efectuados no TCP Scalable são a substituição da normal função aditiva do Congestion Avoidance, pela adição de um valor constante a , e a redução da janela por uma fracção de b. A característica principal é o uso de um aumento multiplicativo à janela de congestão em vez do normal aumento linear, aumentando assim a frequência de oscilação. Esta versão é bastante oscilante, contrastando por exemplo com o TCP Vegas (o menos oscilante). Na Figura 3.47 estão representadas as modificações efectuadas à janela de congestão, aquando da situação de congestão; a fórmula para cálculo do intervalo de oscilação está também presente, bem como todo o padrão de oscilação. 87
- 110. TCP em Redesde Elevado Débito Figura 3.47 – Representação das modificações na janela de congestão efectuadas pelo TCP Scalable (Fonte: [25]). O Scalable TCP possui semelhanças com o MulTCP na medida em que é escalável43 , apesar disso, ao contrário do MulTCP, os valores aconselhados e quase sempre usados para qualquer largura de banda são . A125.0,01.0 == ba Figura 3.48 demonstra o comportamento destas duas variações TCP (Scalable TCP e MulTCP) e o normal TCP, na mesma ligação de 10Gbit/s da Figura. Verifica-se novamente o carácter oscilante do Scalable TCP. 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]). 3.6.4. BIC e CUBIC O BIC (Binary Increase Congestion Avoidance) [26] e o CUBIC [27] são duas versões que abordam todas estas formas de incrementos na janela de congestão de uma forma totalmente inovadora. O conceito 43 O inglês “Scalable” significa escalável. 88
- 111. 3. Enquadramento aoProtocolo é assumir que a taxa de transmissão que se procura é aquela bastante próxima de onde ocorreram as perdas. O funcionamento tem como base a memória do máximo anterior da janela de congestão, onde ocorreram as perdas; a partir daí o máximo é estabelecido como esse valor, sendo o mínimo, o valor da janela de congestão após perdas (neste caso ½ da anterior janela); de seguida é invocado o algoritmo Binary Search Increase que automaticamente irá atribuir à janela de congestão o valor intermédio entre máximo e mínimo; após a primeira invocação o algoritmo continua a estabelecer máximos e mínimos atribuindo à janela de congestão o valor intermédio entre os dois; finalmente, quando o máximo e o mínimo estiverem bastante próximos, será atribuído um incremento mínimo (mininum increment, ). Todas estas iterações são feitas a cada RTT. minS A Figura 3.49 exemplifica o algoritmo anteriormente explicado com 4 RTT, sendo representado a vermelho os valores que a janela de congestão irá tomar. Figura 3.49 – Representação do algoritmo Binary Search Increase. O BIC tem também um mecanismo protector que não permite a invocação deste algoritmo quando a distância entre mínimo e máximo é muito elevada sob pena de sobrecarregar a rede, principalmente se existirem vários fluxos a funcionar paralelamente. A janela de congestão nesses casos é incrementada recorrendo a um maximum increment ( ), até ser viável a invocação do algoritmo.maxS Existe um factor β que relaciona as variáveis e . O seu valor aconselhado é de 0.125, traduzindo uma relação de 0.01 para e 32 para . O grau de “agressividade” desta versão pode ser definido nesta variável, apesar disso, esta versão será sempre das mais agressivas, pois é aquela que efectua mudanças mais repentinas. minS maxS minS maxS O CUBIC vem atenuar um pouco a agressividade do BIC, através de uma função polinomial de 3ºordem, aquando das mudanças repentinas na janela de congestão. A Figura 3.50 demonstra o crescimento de ambas as versões. A versão BIC tem um primeiro crescimento linear até achar confortável usar o seu algoritmo (Binary Search Increase); o crescimento do CUBIC é 89
- 112. TCP em Redesde Elevado Débito bastante mais “arredondado”, sendo sempre usado o algoritmo Binary Search Increase, mas sempre recorrendo a uma função polinomial atenuando todas as alterações bruscas. Figura 3.50 – Funções de crescimento BIC e CUBIC (Fonte: [27]). É de referir que o BIC se encontra como a versão TCP por omissão na maioria das distribuições Linux. 3.6.5. H-TCP O H-TCP (Hamilton TCP) [55] não traz propriamente qualquer inovação, funcionando como uma junção evolucionária do HighSpeed TCP, TCP Scalable e TCP Westwood. Do Highspeed TCP foi adoptado a sua aumento adaptativo na janela de congestão através das perdas; do TCP Westwood foi adoptado sua moderação, aquando do decréscimo da janela de congestão; em relação ao Scalable TCP foi retirada toda a sua oscilação, que o torna independente do RTT. Esta versão do protocolo veio adoptar todos os algoritmos mais interessantes das versões anteriores. Essa adopção permitiu diversos melhoramentos. Por exemplo: um dos problemas do TCP Westwood é que apesar de ter um grande controlo nas descidas das suas janelas de congestão, não tem qualquer algoritmo específico para incrementação; com a adição do algoritmo do TCP HighSpeed esta situação é eliminada. O Scalable TCP não tem qualquer tipo de controlo adaptativo da sua janela; o algoritmo TCP Westwood permite agora esse tipo de controlo. 3.6.6. FAST TCP O FAST TCP é o único descendente do TCP Vegas (ver Cap. 3.5.4), considerando todas as versões de alto débito analisadas. Quando especificado [30], foi especialmente tido em conta a vantagem do TCP Vegas em relação ao TCP Reno nos meios de alto débito. A vantagem do TCP Vegas utilizando pouca largura de banda revela-se mínima, porém, quando se trata de alto débito verifica-se decisiva. O objectivo foi criar uma versão melhorada do TCP Vegas, especifica ao esse meio de transmissão de alto débito. 90
- 113. 3. Enquadramento aoProtocolo Foi referido anteriormente (ver Capítulo) que a incrementação e diminuição da janela de congestão do TCP Vegas é sempre correspondente a 1/cwnd. Esta forma de decrescimento e crescimento leva a que o TCP Vegas demore bastante a atingir a sua fase de equilíbrio. A principal modificação do FAST TCP diz respeito a uma alteração nesta forma de incremento/decremento. No FAST TCP a forma como são efectuadas modificações à janela por RTT depende de dois factores: • A variação do RTT; • O valor da janela de congestão corrente. Com base nestes dois parâmetros, a fórmula de crescimento/decrescimento será igual a: α+×= )/( RTTRTTbaseWW O valor baseRTT continua a representar o RTT mínimo da ligação, representado o RTT o seu valor corrente. Oα foi já referenciado anteriormente no TCP Vegas (ver). Através deste tipo de incremento a janela será ajustada rapidamente até ao seu estado de equilíbrio; à medida que a janela cresce, maior será o incremento; aumentando o RTT, o crescimento será bastante atenuado. O FAST TCP considera assim quatro componentes de controlo de congestão: • Controlo de Dados; Escolhe que tipo de segmentos transmitir (apenas utilizado para a estimação); • Controlo de Janela; Escolhe a quantidade de dados a transmitir; • Controlo de Burst. Escolhe o tempo que os irá transmitir, ligado aos tempos RTT que verificam o estado dos buffers. A Figura 3.51 representa toda a arquitectura FAST TCP. Os campos a vermelho representam os campos directamente relacionados; o controlo de janela afecta a estimação, a estimação afecta o controlo de janela; o mesmo acontece com o controlo de burst; em relação ao controlo de dados, irá afectar a estimação, mas a estimação não tem qualquer controlo sobre ele. Figura 3.51 – Arquitectura FAST TCP (adaptado de [30] ). 91
- 114. TCP em Redesde Elevado Débito 3.6.7. Compound TCP O Compound TCP [31] é especialmente importante por ser a versão usada pelo Windows Vista®, tendo sido desenvolvida pela Microsoft®. As principais preocupações do Compound TCP são três: • Eficiência em redes de alto débito; • RTT fairness; Tem obrigatoriamente de existir uma justiça na atribuição de recursos entre protocolos, especialmente quando diferentes fluxos têm diferentes RTT. • TCP fairness; Não deve ser reduzida a perfomance de outros fluxos regulares a competir na mesma ligação, i.e., os protocolos para alto débito devem usar a largura de banda disponível e não roubá-la de outros fluxos. A ênfase dada nesta versão à forma como os fluxos TCP interagem é muito maior do que em todas as versões anteriores. Uma forma de ver esta versão é considerá-la uma junção entre a versão TCP Reno e TCP Vegas, este tipo de versão já tinha sido verificado anteriormente com o TCP Veno (ver Cap. 3.5.5.1). Porém, o TCP Compound é bem mais que uma simples junção, existindo algoritmos específicos para que as melhores características de cada abordagem sejam realçadas. A principal inovação nesta versão é a adição de uma 3ºjanela de congestão (após janela de receptor e janela de congestão), a janela de atraso. A janela será responsável por cuidar de todas as alterações delay based 44 . Algumas alterações efectuadas no normal incremento TCP foram: ),min( rwndlwndcwndwin += Com a adição da janela lwnd, o máximo de segmentos que é permitido ao emissor enviar será o mínimo entre a janela de recepção, e a soma da janela de congestão com a janela de atraso )(1 dwndcwndlcwndcwnd ++= O incremento será também feito recorrendo à janela de atraso. Não é efectuado nenhuma alteração à forma como é incrementada a normal janela de congestão. No que diz respeito à janela de atraso, existe uma correspondência com a forma que o TCP Vegas decidia acerca da mudança da janela de congestão; apesar dessa situação, a forma de diminuir e aumentar a dwnd já não 44 Variações no RTT ao longo do tempo de ligação. 92
- 115. 3. Enquadramento aoProtocolo é o normal incremento TCP, sendo utilizadas funções polinomiais que lhe permitem uma maior dinâmica no crescimento. A Figura 3.52 demonstra toda a dinâmica do uso destas duas janelas, sendo os pontos D, E, F, G os pontos mais críticos de mudança. O TCP representa todo o normal crescimento da janela de congestão; o DWND representa a janela de atraso; o CTCP referencia o funcionamento Compound TCP usando ambas as janelas. As janelas são incrementadas até ao ponto E, a partir daí a janela de congestão (Janela Reno) indica a continuação do aumento de envio de segmentos; por outro lado, a janela de atraso (janela Vegas) indica que a rede está próxima da congestão, sendo necessário baixar o ritmo; a soma das duas janelas revela a decisão tomada para o correcto funcionamento da rede. Figura 3.52 – Representação do funcionamento das janelas de congestão e atraso Compound TCP. 3.6.8. Outros As versões específicas para alto débito dividem-se, essencialmente, entre abordagens LCA ou DCA, ou ambas; com maior justiça na atribuição de recursos, ou mais “agressivas”. Para além das versões anteriores, existem variadas versões: TCP Africa, TCP Libra, TCP Paris, TCP Rome, etc. Algumas destas versões utilizam também uma divisão em fluxos paralelos de dados para alcançar maior eficiência na rede. Outra forma de abordar a requisição de eficiência por parte da rede é utilizar a assistência dos próprios routers utilizando mecanismos de congestão explícita (ver Cap. 2.1.5.2). Um importante protocolo para essa operação é o XCP [32]. Esta forma de controlo de congestão foi primeiro explorada no conceito ECN, sendo mais tarde generalizada no XCP. 93
- 116. TCP em Redesde Elevado Débito No XCP o feedback45 acerca da carga existente na rede é baseado em sinal explícitos, providenciando aos routers notificarem individualmente o seu estado de congestão. As desvantagens desta abordagem são principalmente o facto de não ser respeitado o conceito extremo-a- extremo da camada de transporte e ser necessário a alteração dos dispositivos de redes intermédios. Apesar disso, também ainda não foi provado que este tipo de protocolo atinge maior perfomance que os normais algoritmos de congestão implícita para alto débito [9]. 3.7. Ponto de Situação No que diz respeito a qual é a melhor versão para alto débito, a questão não se revela nada simples de responder. Cada versão aborda o alto débito de diferente forma, existindo sempre condições da própria rede, utilizadas para maximizar a eficiência dos seus testes. Porém, recorrendo à IETF como entidade reguladora de todo o desenvolvimento de redes, o HighSpeed TCP será a versão que mais eficiência traz ao alto débito, estando proposto para standard; seguidamente surge o Scalable TCP ainda em estado de draft46 . Apesar das normas recomendadas pela IETF, a situação em relação à adopção do Highspeed TCP não é elevada, muito por culpa de não ser a versão por omissão de nenhum sistema operativo. De uma forma simples poderemos definir a percentagem de utilização de uma versão pela percentagem de utilização de um sistema operativo. Por exemplo: o TCP newReno sendo a única versão permitida ao utilizador Windows® será utilizado em cerca de 90%, pois 90% é a percentagem aproximada de utilização deste sistema operativo. O BIC e o Westwood são as versões por omissão do Linux (conforme a distribuição), sendo então utilizadas cerca de 8%; apesar dessa situação é bastante simples alterar a versão TCP no sistema operativo Linux. Apesar desta simples relação são necessários estudos de maior grau de detalhe e complexidade. Esses estudos para além das versões TCP devem também verificar a utilização de todos os diversos mecanismos. O último desses estudos foi efectuado em Fevereiro de 2004 [33]. O estudo revelou-se bastante importante, na medida em que revelou todo o estado do TCP na Internet. Baseou-se em testes a servidores Web induzindo diversas situações de perdas, re-ordenações, erros, etc. com o objectivo principal de verificar os algoritmos de controlo de congestão dos servidores e seus diversos mecanismos TCP. De igual forma, foram também testados os dispositivos intermédios (Firewalls, NAT, proxies, etc) que prejudicam por vezes as comunicações extremo-a-extremo. 45 Notificação ao emissor. 46 Referência IETF a uma especificação ainda em estado de desenvolvimento. 94
- 117. 3. Enquadramento aoProtocolo O estudo revelou situações bastante surpreendentes: em relação às firewalls foi verificado que algumas identificam a negociação de ECN como uma aplicação port-scanner47 , quebrando de imediato a ligação; em relação aos servidores foram verificadas versões sem Fast Retransmit (sendo a única explicação implementações defeituosas de um qualquer sistema operativo), e versões que não respeitavam as normas dos números de sequência através de um mecanismo intitulado TCP/IP fingerprint scrubbers [34] para protecção a ataques de hacking. Neste teste não foram verificadas as versões para alto débito, tendo sido apenas efectuadas formas de induzir mecanismos das versões newReno, Reno, ou Tahoe, principalmente a forma como reagiam a uma simples perdas e a múltiplas perdas (diferença entre newReno e Reno). Os testes efectuados em 84394 servidores revelaram-se esclarecedores, estando representados na Tabela 3.4. A adopção do newReno verifica-se bastante elevada, seguida do Reno (15%), existindo ainda a versão Tahoe (4%) em alguns servidores. Versão Percentagem de uso newReno 76% Reno 15% Tahoe 4% Outro 1% Tabela 3.4 – Valores de percentagem de utilização do TCP Tahoe, Reno e newReno. Como apenas foram testados alguns mecanismos, dentro da abrangência newReno poderão existir algumas versões alto débito (baseados em LCA). É de referir também que 68% dos servidores efectua correctamente a negociação para Sack, e 93% não permite negociação ECN. São agora necessários novos estudos, de forma a ser verificado, detalhadamente, todo o processo de adopção das versões TCP para alto débito. 47 O inglês “port scanner” significa escutador de portos, sendo uma aplicação muito utilizada para efeitos maliciosos. 95
- 118. TCP em Redesde Elevado Débito 4.Testes Práticos Não é pretendido nos testes deste capítulo uma verificação exaustiva das várias implementações existentes. Cada implementação foi já sujeita a diversos testes de perfomance, tendo como cenário ambientes completamente reais48 [35]. O objectivo principal dos testes é verificar quais as versões TCP disponíveis para o normal utilizador poder adquirir um maior grau de eficiência, principalmente, considerando as redes de alto débito e grandes atrasos. Ao longo deste capítulo existem considerações a ter em conta que não pertencem ao âmbito do TCP, sendo igualmente importantes nos testes, algumas delas são: • A velocidade da rede não pode ser mais rápida do que a velocidade da sua ligação mais lenta; • A rede não pode ser mais rápida que a capacidade de memória da máquina mais lenta; • A rede não pode ser mais rápida que o tamanho de janela oferecido pelo receptor sobre o RTT. Esta fórmula é feita substituindo o tamanho da janela pelo BDP (ver Cap. 3.3.2.2), na fórmula utilizada para calcular a capacidade da rede. A fórmula ficará a seguinte: RTT Janela Throughput = • Ter a certeza de que a amostra de tempo retirada permite verificar todas as condições, eliminando qualquer incerteza na medição; • Conhecimento de todas as interfaces utilizadas durante os testes: aplicações, buffers das aplicações, placas de rede, buffers da rede, rede, etc. • As componentes de simulação por vezes não têm resultados tão próximos da realidade; • É bastante simples adquirir mais largura de banda (apenas com a desvantagem dos custos), sendo bastante mais complicado adquirir menos atraso (implica modificações nos protocolos, sistema operativo, interfaces de rede, etc.). Os testes TCP de diversas publicações por vezes não se revelam também muito coerentes, tornando a sua análise bastante difícil. Este facto prende-se, principalmente, com a dispersão de parâmetros que existem, 48 Sem recorrer a qualquer componente de simulação. 96
- 119. 4. Testes Práticos aquandoa configuração dos cenários. Quase todos os testes efectuados às diversas versões são efectuados com diferentes parâmetros, tornando bastante difícil uma correcta comparação entre eles. Provavelmente, esse facto prende-se com razões de maximização de eficiência por parte de cada versão, funcionando então os testes como uma prova de às comunidades de investigação, de todas as máximas potencialidades da respectiva versão. Cada vez mais se exigem correctas comparações, pelo que existem tentativas de tornar os cenários cada vez mais genéricos entre as versões [36]. 4.1. Testes Linux O surgimento deste projecto teve como base os resultados apresentados no documento “Experimental Evaluation of TCP Protocolos for High-Speed Networks” [5]. Neste artigo é mencionado o facto da versão normal do TCP, newReno, não aproveitar convenientemente os recursos que as ligações proporcionam em ambientes LFN. Como tal, antes de iniciar o desenvolvimento de uma nova versão, realizaram-se testes num cenário bastante simples, tentando simular ao máximo as condições descritas no documento, de modo a averiguar a validade das conclusões. No capítulo seguinte são referenciadas todas as configurações, necessárias para a simulação do ambiente de testes do artigo. 4.1.1. Planeamento dos testes No artigo é relatado que o teste foi realizado numa ligação transatlântica entre Dublin e Chicago a 1Gbit/s e atraso de propagação de 100ms. Para simular este cenário utilizaram-se 3 PCs, dois extremos para enviar e receber os dados e um PC (Personal Computer) a ligar os outros dois; este último PC introduz atraso aos segmentos. O esquema de configuração do cenário inicial encontra-se na Figura 4.1. Figura 4.1 – Cenário Simulado Inicial. 97
- 120. TCP em Redesde Elevado Débito A Tabela 4.1 representa as especificações dos PC utilizados, verificando-se uma máquina bastante actualizada em termos de hardware e duas já com um hardware um pouco antigo. PC CPU RAM Placa de Rede SO Emissor 3GHz 512Mbytes Intel PRO/1000 CT Kubuntu 06.10 Receptor 1.1GHz 354Mbytes SMC Networks SMC9452TX-1 EZ Card 1000 Kubuntu 06.10 Intermédia 1.1GHz 512Mbytes 2 x SMC Networks SMC9452TX EZ Card 1000 FreeBSD 6.1 Tabela 4.1 – Especificações de Hardware e SO usado por PC. As máquinas emissora e receptora utilizam o sistema operativo Linux, por ser o sistema operativo em que primeiro se implementam todas as novas versão TCP, verificando-se também uma maior gama na escolha das versões. A distribuição escolhida foi o Kubuntu por ser actualmente dos mais utilizados e ter um grande apoio técnico por parte das suas comunidade. A aplicação utilizada para gerar tráfego foi o Iperf [91]; a escolha deste programa, deve-se ao facto desta aplicação ter sido usada para bater o recorde actual [95] do máximo de largura de banda utilizada por um único fluxo TCP. Para a captura de segmentos utilizou-se o Tcpdump [90] por ser a aplicação mais poderosa, superando o Wireshark [97]. Na descodificação dos ficheiros gerados pelo Tcpdump utilizou-se o TRPR [94]. No PC intermédio que interliga o emissor e o receptor foi utilizado o sistema operativo FreeBSD [96], com a aplicação Dummynet [92] para introduzir atraso na ligação. Desta forma é simulada uma ligação transatlântica. Devido a vários problemas encontrados, na tentativa de simular as características da rede mencionadas no artigo, foi impossível verificar de forma coerente as conclusões do documento. O cenário que, devido a todas as restrições encontradas, foi possível testar e que pretende simular um ambiente LFN, encontra-se na Figura 4.2. Figura 4.2 – Cenário Final. 98
- 121. 4. Testes Práticos Paraa configuração do cenário final, são necessários variados passos referenciados a seguir: Configurações Linux • As configurações necessárias para configurar os buffers do cenário no PC emissor e receptor: sysctl –w net.ipv4.tcp_rmem=4096 16777216 67108864 sysctl –w net.ipv4.tcp_wmem=4096 16777216 67108864 sysctl –w net.ipv4.tcp_mem=4096 16777216 67108864 sysctl –w net.core.tcp_rmem= 67108864 sysctl –w net.core.tcp_rmem= 67108864 Configurações BSD • Activação no PC intermédio da ipfw (IP Firewall), adicionando as seguintes linhas ao ficheiro /etc/rc.conf: firewall_enable=”YES” firewall_type=”open” router_enable=”YES” gateway_enable=”YES” • Activação do Dummynet adicionando a seguinte linha ao ficheiro /boot/loader.conf: dummynet_load=YES” • Para não ser necessário reiniciar a máquina deve-se introduzir o próximo comando (opcional): kldload dummynet • Configuração do atraso na aplicação Dummynet: ipfw add pipe 1 ip from 192.168.0.1 to 192.168.1.1 ipfw pipe 1 config delay 300ms queue 1000k ipfw add allow ip from 192.168.0.1 to 192.168.1.1 ipfw add allow ip from 192.168.1.1 to 192.168.0.1 99
- 122. TCP em Redesde Elevado Débito Os gráficos apresentados no Capitulo 4.1.3 têm uma amostragem de 10 segundos. Considerou-se essa amostragem coerente para mostrar o funcionamento dos algoritmos, sem qualquer grau de incerteza nas alterações. Quando se achar necessário, será apresentado o gráfico com 5 segundos de amostragem, para a vericação detalhada de certas operações. Todas as dificuldades que surgiram ao tentar simular as condições de uma rede LFN e que impediram a utilização das configurações iniciais estão documentadas no próximo capítulo, sendo eles a justificação para a mudança da configuração do cenário da Figura 4.2. 4.1.2. Problemas Todos os testes efectuados neste capítulo têm como intuito tentar resolver todas as dificuldades que surgiram, ao longo da tentativa da reprodução dos testes do documento. Foram efectuados com o algoritmo BIC por ser o algoritmo de congestão configurado por omissão na distribuição, e por ser indicado para redes de alto débito . Velocidades 1Gbit/s A aplicação Dummynet encontrava-se inicialmente configurada com o seguinte comando: ipfw pipe 1 config delay 100ms Ao tentar reproduzir o teste efectuado na publicação, verificou-se ser impraticável realizá-lo pois com o hardware fornecido não foi possível alcançar velocidades Gigabit. Essa razão deve-se ao facto do computador não ter capacidade de processamento da informação da rede, verificar checksums (tanto TCP como IP), números de sequência, controlo de congestão, opções adicionais do TCP e o próprio encaminhamento. A Figura 4.3 foi retirada durante a realização de um teste. Pode-se constatar que a utilização do CPU estava a 100%, sendo essa a razão que impedia a velocidade da rede de aumentar. Figura 4.3 – CPU a utilizar 100% da capacidade de processamento Com a máquina emissora e a máquina receptora ligadas com um cabo cruzado a velocidade máxima era de 500 Mbit/s. Quando a Figura 4.4 foi retirada estava configurado o cenário inicial e ligações a 1Gbit/s, 100
- 123. 4. Testes Práticos semter a simulação do atraso configurada. Mesmo com a introdução de atraso esperam-se os mesmos os resultados, diferindo apenas no facto de demorar mais tempo a verificar-se o congestionamento, pois a aceleração do troughput depende inversamente do atraso. O eixo dos xx representa os segundos, o eixo dos yy o débito alcançado, esta definição é valida para todos os testes deste capítulo. Figura 4.4 – Largura de banda ocupada com velocidade de 1Gbit/s, sem qualquer tipo de atraso. A resolução deste problema passaria pela utilização de hardware com maior capacidade de processamento [98]. A Tecnologia TOE (TCP Offload Engine) [99] também poderá ser utilizada, retirando assim bastante carga de processamento ao CPU nas operações de rede. Configuração 100Mbit/s e atraso de 1000ms Perante esta situação problemática, alterou-se a velocidade para 100Mbit/s e aumentou-se o atraso, de modo a que o produto troughput/atraso se mantenha. A fórmula seguinte foi já anteriormente referenciada (ver Cap. 3.3.2.2). Para a relação entre a velocidade e o atraso se manter o BDP será igual, logo, sabendo a velocidade que é 100Mbit/s pode-se determinar que o atraso é de 1000ms. atrasoMbitBDP mssMbitBDP ×= ×= 100 100/1000 msatraso ms sMbit sMbit atraso mssMbitsMbitatraso 1000 100 /100 /1000 100/1000/100 = ×= ×=× Iniciou-se então a reconfiguração de todo o cenário. Mesmo ao diminuir a largura de banda e aumentar o atraso proporcionalmente, não foi possível realizar o teste proposto, pois com esta configuração o troughput ainda não atinge o valor desejado, atingindo cerca de 35Mbit/s como se pode verificar pela Figura 4.5. 101
- 124. TCP em Redesde Elevado Débito Figura 4.5 – Simulação com atraso de 1000ms e 100Mbit/s (dummynet) Para tentar resolver este novo problema decidiu-se alterar os valores dos buffers do TCP para verificar se o problema seria desta configuração. Inicialmente os buffers encontravam-se configurados da seguinte forma: net.ipv4.tcp_rmem=4096 87380 174760 net.ipv4.tcp_wmem=4096 16384 131072 net.ipv4.tcp_mem=4096 65536 98304 net.core.rmem_max=105472 net.core.wmem_max=105472 O valor máximo dos buffers foram alterados com o comando sysctl no valor de aproximadamente 16KB e 67MB, usando os valores recomendandos por um manual para gigabit em Linux [100] (sendo o máximo um múltiplo de 2). O primeiro passo, usando os buffers de 16KB: sysctl –w net.ipv4.tcp_rmem=4096 87380 16777216 sysctl –w net.ipv4.tcp_wmem=4096 16384 16777216 sysctl –w net.ipv4.tcp_mem=4096 65536 16777216 sysctl –w net.core.rmem_max=16777216 sysctl –w net.core.wmem_max=16777216 O segundo passo, usando os buffers de 67MB: sysctl –w net.ipv4.tcp_rmem=4096 87380 67108864 sysctl –w net.ipv4.tcp_wmem=4096 16384 67108864 sysctl –w net.ipv4.tcp_mem=4096 65536 67108864 102
- 125. 4. Testes Práticos sysctl–w net.core.rmem_max= 67108864 sysctl –w net.core.wmem_max= 67108864 Os resultados obtidos encontram-se nas Figura 4.6. Figura 4.6 – Simulação com buffer de 16MB e buffer de 67MB (DummyNet). Ao analisar os resultados, verifica-se que a limitação da largura de banda não está relacionada com o tamanho máximo dos buffers. Para existir, ainda, uma maior certeza de que os buffers não eram a causa do problema, alterou-se o valor anunciado, aquando do início da ligação TCP. sysctl –w net.ipv4.tcp_rmem=4096 16777216 67108864 sysctl –w net.ipv4.tcp_wmem=4096 16777216 67108864 sysctl –w net.ipv4.tcp_mem=4096 16777216 67108864 sysctl –w net.core.rmem_max= 67108864 sysctl –w net.core.wmem_max= 67108864 Ao efectuar-se um novo teste verificou-se o mesmo resultado da Figura 4.6, considerando o gráfico de 67MB. Ao fazer comparações entre os testes determinou-se que não era a configuração do buffer que impedia o throughput de alcançar os valores esperados. A próxima “suspeita” recaiu sobre a fila da aplicação Dummynet, tendo sido o seu valor aumentado para o máximo permitido: ipfw pipe 1 config delay 1000ms queue 1000k A consequência desta alteração nenhum impacto teve no desempenho do protocolo TCP, tendo em conta o melhor aproveitamento da largura de banda disponível. Conclui-se portanto que o tamanho da fila de espera do dummynet de cerca de 1MB não é suficiente para se efectuar este teste. 103
- 126. TCP em Redesde Elevado Débito A próxima tentativa foi utilizar outro programa que substituisse o gerador de atraso do dummynet. A aplicação escolhida foi o Netem [93], que já vem integrado no kernel Linux. Para se efectuar a sua configuração é apenas necessário introduzir o comando seguinte: tc qdisc add dev eth0 root netem delay 500ms Esta aplicação teve um desempenho, claramente, mais fraco que o Dummynet, como se pode verificar na Figura 4.7. O máximo throughput atingido foi apenas de 11Mbit/s. Figura 4.7 – Simulação com buffer máximo de 67MB e atraso de 1000ms (Netem) Ao verificar-se que nenhuma das aplicações funcionava com os valores pretendido, decidiu-se diminuir o atraso para metade (500ms). Desta forma, os requisitos para simulação dos testes efectuados no estudo não conseguem ser correctamente cumpridos. As configurações para implementar o novo atraso no Netem são: tc qdisc add dev eth0 root netem delay 250ms Os resultados, considerando, o Netem mantêm-se muito fracos. Voltou-se a usar novamente o Dummynet por, claramente, apresentar resultados mais coerentes, repetindo-se todos os testes realizados no Netem com o atraso configurado a 500ms: ipfw pipe 1 config delay 500ms Foram consideradas as duas situaçãoes de buffers referidas anteriormente, estando o resultado expresso na Figura 4.8. 104
- 127. 4. Testes Práticos Figura4.8 – Simulação com buffer de 16MB e buffer de 67MB, ambos com atraso de 50ms. Através da realização destes testes, verifica-se mais uma vez que não é possível chegar a 100Mbit/s, mesmo com metade do atraso pretendido. Para se poder efectuar o teste foi experimentado qual o atraso em que seria possível atingir o máximo da largura de banda possível, considerando o maior atraso possível. De seguida encontram-se as respectivas configurações para cada teste e os respectivos gráficos na Figura 4.9. ipfw pipe 1 config delay 350ms ipfw pipe 1 config delay 300ms ipfw pipe 1 config delay 250ms Figura 4.9 – Simulação com atraso configurado a 350ms, 300ms e 250ms. 105
- 128. TCP em Redesde Elevado Débito Ao analisar os resultados verifica-se que o atraso máximo para manter a largura de banda a 100Mbit/s é de 300ms. TRPR Outro problema que surgiu foi o facto do TRPR, aplicação para descodificar o ficheiro gerado pelo Tcpdump, não permitir descodificar ficheiros maiores que 2GB. Este facto gerou alguns problemas, pois limita o tamanho de captura do Tcpdump. Como tal, os protocolos que aproveitavam melhor a largura de banda só podem ser testados durante um menor período de tempo, pois os ficheiros gerados pelo Tcpdump ultrapassam o limite imposto pelo TRPR. Em relação aos protocolos mais lentos, como transferem menor quantidade de informação durante o mesmo período de tempo, os ficheiros do Tcpdump não ultrapassam os limites do TRPR, logo, poderão ser testados num maior período de tempo. Kernel Linux Outra dificuldade que surgiu, foi o facto do kernel Linux, que vem por omissão com a distribuição Kubuntu utilizada, não ser compilado com todas as versões do protocolo TCP que o Linux suporta. Como tal, foi necessário compilar um novo kernel [101] para se poder utilizar todas as versões. Para adicionar todas as versões, é necessário garantir que algumas opções que se encontram no ficheiro .config se encontram selecionadas. Na primeira coluna encontram-se as opções por omissão, na segunda coluna encontram-se todas as opções para as versões TCP que devem ser seleccionadas: CONFIG_TCP_CONG_ADVANCED=n CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=n CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=n CONFIG_TCP_CONG_WESTWOOD=y CONFIG_TCP_CONG_HTCP=n CONFIG_TCP_CONG_HTCP=y CONFIG_TCP_CONG_HSTCP=n CONFIG_TCP_CONG_HSTCP=y CONFIG_TCP_CONG_HYBLA=n CONFIG_TCP_CONG_HYBLA=y CONFIG_TCP_CONG_VEGAS=n CONFIG_TCP_CONG_VEGAS=y CONFIG_TCP_CONG_SCALABLE=n CONFIG_TCP_CONG_SCALABLE=y CONFIG_TCP_CONG_LP=n CONFIG_TCP_CONG_LP=y CONFIG_TCP_CONG_VENO=n CONFIG_TCP_CONG_VENO=y 106
- 129. 4. Testes Práticos 4.1.3.Resultados Após o estabelecimento de um cenário em que fossem garantidos resultados coerentes (ver Figura 4.2), foram efectuados testes às diversas versões que o Linux disponibiliza, num estado já bastante estável. As versões apresentadas a seguir são as versões a que o normal utilizador tem acesso, para a maximização de eficiência por parte do protocolo TCP. A amostragem temporal é de 10 segundos para a maioria dos testes, sendo uma vez necessário diminuir a taxa de amostragem para 5 segundos para demostrar certos comportamentos. 4.1.3.1. TCP newReno A versão newReno (ver Cap. 3.5.3) foi a primeira versão a ser testado e a sua prestação encontra-se na Figura 4.10. Como se pode constatar, mesmo depois de decorridos 30 minutos (1800 segundos), o algoritmo não consegue sequer ocupar metade da largura de banda, sendo por demais evidente que tem uma fraca performance em redes LFN. Os testes efectuados têm por base medir o aproveitamento da largura de banda. Em relação ao Reno, o newReno apenas melhorou o desempenho aquando a ocorrência de perdas, logo, conclui-se que nem o Reno nem o newReno aproveitam eficientemente a largura de banda. Figura 4.10 – Simulação com a versão newReno (amostragem 10s). 4.1.3.2. TCP Vegas A próxima versão trata-se do Vegas (ver Cap. 3.5.4) e pode ser vista na Figura 4.11. Esta versão tem um aproveitamento de largura de banda muito ineficiente que se pôde testar por mais 10 minutos (problema TRPR, ver 4.1.2); chegando ao final desses 10 minutos, ou seja 40 minutos (2400 segundos), o débito verificou-se pouco acima dos 20Mbit/s. O algoritmo de controlo de congestão desta versão funciona com 107
- 130. TCP em Redesde Elevado Débito base na estimação da largura de banda através da variação do RTT. O algoritmo aparenta ser pouco eficaz no aproveitamento da largura de banda neste cenário particular. Figura 4.11 – Simulação com a versão TCP Vegas (amostragem 10s). 4.1.3.3. TCP Hybla Com o versão Hybla (ver Cap. 3.5.5.1) retirou-se o gráfico da Figura 4.12. Como se observa na Figura 4.12, o aproveitamento da largura de banda é bastante melhor, atingindo a estabilidade aos 80Mbit/s. O seu algoritmo é bastante bom para as ligações com elevado RTT pois não depende deste. Como o atraso deste cenário é bastante significativo o Hybla obtém uma boa perfomance. Figura 4.12 – Simulação com a versão TCP Hybla (amostragem 10s). 108
- 131. 4. Testes Práticos 4.1.3.4.TCP Westwood+ No próximo teste avalia-se a versão Westwood+ (ver Cap. 3.5.5.2). Ao efectuar a análise do gráfico na Figura 4.13, torna-se evidente que, também, não se trata de um bom algoritmo para redes com estas características. Este algoritmo apenas efectua alterações à forma como a janela é modificada, aquando a invocação do algoritmo Fast Retransmit (ver Cap.3.5.1.4). Não existe qualquer modificação na forma como o crescimento da janela é efectuado, assemelhando-se assim o gráfico ao normal gráfico do Reno. Figura 4.13 – Simulação com a versão Westwood+ (Amostragem 10s). 4.1.3.5. TCP Veno O próximo teste trata-se da versão Veno (ver Cap. 3.5.5.2) que é analisado na Figura 4.14. O algoritmo desta versão também não faz o uso eficiente da largura de banda disponível. Como este algoritmo é um híbrido entre o Vegas e o Reno, o seu desempenho estará algures entre o desempenho do Reno e o desempenho do Vegas. Sabendo que o desempenho destas duas versões (Reno e Vegas) é bastante reduzido, é fácil concluir que esta versão também será ineficiente. 109
- 132. TCP em Redesde Elevado Débito Figura 4.14 – Simulação com a versão Veno (amostragem 10s). 4.1.3.6. TCP Low Priority A versão Low Priority (ver Cap. 4.1.3.6) foi a próxima versão a ser testada. Testar o Low Priority neste cenário nunca irá mostrar as suas potencialidades, porém, é mais uma versão disponibilizada no sistema operativo Linux. Este algoritmo é o que apresenta pior desempenho de todos os algoritmos testados, não chegando à velocidade de 10Mbit/s. É bastante compreensível este comportamento, pois este protocolo tem como objectivo transferir dados ocupando uma minoria da largura de banda, em detrimento de não ocupar a largura de banda de outros fluxos. Os resultados podem ser visualizados na Figura 4.15. Figura 4.15 – Simulação com a versão Low Priority TCP (amostragem 10s). 110
- 133. 4. Testes Práticos 4.1.3.7.HighSpeed TCP A versão HighSpeed TCP (ver Cap. 3.6.2) é a primeira das versões para alto débito a serem testadas, encontrando-se representada na Figura 4.16. Demora algum tempo a chegar ao máximo da largura de banda (cerca de 4 minutos, 240 segundos), mas depois de chegar pela primeira vez ao máximo a taxa de eficiênca sobe bastante. O algoritmo baseia-se no número de perdas para aumentar a janela de congestão. Desta forma a primeira subida é mais lenta, pois ainda não se verificaram perdas. É de referir que este é a única versão de protocolo, testada até agora, em que se verificaram perdas, sendo posteriormente invocado Fast Retransmit (ver Cap. 3.5.1.4) e Fast Recovery (ver Cap. 3.5.2.1). Figura 4.16 – Simulação com a versão HighSpeed TCP (amostragem 10s). 4.1.3.8. Scalable TCP A segunda versão para alto débito testada foi o Scalable (ver Cap. 3.6.3). A Figura 4.17 demonstra o fucnionamento da versão. Para atingir a máxima largura de banda o seu algoritmo demora 2 minutos (120 segundos), aproveitando depois a largura de banda de forma mais eficiente, aquando da ocorrência de perdas; após as perdas nota-se a sua extrema “agressividade” a subir. O nível de descida da janela mantem-se constante, assim como os valores de subida. A oscilação desta versão também é facilmente verificada. 111
- 134. TCP em Redesde Elevado Débito Figura 4.17 – Simulação com a versão Scalable TCP (amostragem 10s). 4.1.3.9. BIC A próxima versão é o BIC (ver Cap. 3.6.4) estando representada na Figura 4.18. A principal diferença do seu algoritmo, comparando com todos os outros testados até ao momento, é a sua rápida subida inicial (cerca de 2 minutos, 120 segundos). Como o funcionamento do algoritmo (Binary Search Increase) se baseia em descobrir o máximo da largura de banda e aumentar bastante a tramsmissão, até se aproximar desse mesmo máximo, o aproveitamento da largura de banda é bastante eficiente. Nota-se, ainda, que depois de cada perda de segmento o algoritmo entra na fase Binary Search Increase, crescendo pouco e acelerando bruscamente, à medida que determinado valor é atingido. Figura 4.18 - Simulação com a versão BIC (amostragem 10s). 112
- 135. 4. Testes Práticos 4.1.3.10.CUBIC A Figura 4.19 representa o teste ao melhoramento do BIC, o CUBIC. Verifica-se também um bom aproveitamento da largura de banda, apesar de atingir o máximo da largura de banda menos vezes que o BIC. A principal diferença é o uso de apenas um algoritmo ao longo do tempo, não existindo assim grandes abrandamentos aquando da ocorrência perdas, subindo um pouco mais lentamente, mas a um ritmo constante. A “agressividade” do BIC é, assim, bastante atenuada por esta versão. Figura 4.19 – Simulação com a versão CUBIC (amostragem 10s). 4.1.3.11. H-TCP Os testes efectuados têm como resultado a Figura 4.20 e Figura 4.21. A versão utilizada é o H-TCP (ver Cap. 3.6.5). Este é um protocolo que junta conceitos de 3 versões: Scalable, HighSpeed e Westwood. A Figura 4.20 demontra de forma coerente o crescimento parecido com o algoritmo do HighSpeed e a descida de janela parecida com o algoritmo do Westwood. As oscilações são mais explícitas com uma menor taxa de amostragem temporal. Com o gráfico de amostragem com 5 segundos (Figura 4.21) pode ver-se claramente que este é um protocolo com oscilações muito rápidas, indo desde os 65Mbit/s a 90Mbit/s até ocorrer alguma perda. Até atingir os 90Mbit/s, o crescimento é feito testando o limite, também recorrendo a oscilações. 113
- 136. TCP em Redesde Elevado Débito Figura 4.20 – Simulação com a versão H-TCP (amostragem a 10s). Figura 4.21 – Simulação com a versão H-TCP (amostragem a 5s). 4.1.4. Conclusões Com a análise aos resultados obtidos através dos testes efectuados, constata-se facilmente que alguns algoritmos não são próprios para alto débito, principalmente considerando redes LFN. O caso do newReno foi demonstrado pelo artigo “Experimental Evaluation of TCP Protocolos for High-Speed Network” [5], o qual se comprovou, também, através destes testes. No estudo, o protocolo é testado com atraso real, sem qualquer componente simulado; os testes efectuados recorrem sempre a uma componente simulada, que levantou diversos problemas (ver Cap. 4.1.2). A falta de eficiência no aproveitamento da largura de banda não é só uma dificuldade do algoritmo Reno pois o Westwood+, o Veno, o Vegas, também não são propícios para redes de alto débito e grande atraso. No caso dos outros algoritmos, excepto o LP, existe um melhor aproveitamento da largura de banda por terem sido desenvolvidos para o meio específico das redes LFN; é o caso do HighSpeed, Scalable, BIC, 114
- 137. 4. Testes Práticos CUBICe H-TCP. Na Figura 4.22 estão todos os resultados dos testes de forma comparativa. A distinção entre preparação para alto débito e a não preparação é bastante distingível. Figura 4.22 – Simulação com todas as versões testadas. De todas as principais versões do TCP as únicas que não foram testadas foram o FAST TCP (ver Cap. 3.6.6) e o Compound TCP (ver Cap. 3.6.7). A versão estável do TCP Compound apenas está disponível no Microsof Windows Vista®, o FAST TCP ainda não se encontra estável o suficiente para ser inserido no kernel Linux. Ainda em relação ao TCP Compound, este já se encontra em kernel de desenvolvimento. Conclui-se também que para efectuar simulações deste tipo, caso não existam recursos suficientes para efectuar os testes, recorreendo a componentes simuladas (geradores de atraso), deve-se optar por plataformas de simulação. As plataformas de simulação, actualmente, estão bastante desenvolvidas e conseguem resultados mais fiáveis do que usar cenários reais com componentes de simulação. 4.2. NS2 A principal vantagem de um simulador de redes de dados é, sem dúvida, a pouco necessidade de recursos. Apesar desta situação, as plataformas de simulação são hoje bem mais do que só essa vantagem, permitindo aos programadores diversas facilidades na implementação dos seus novos conceitos e algoritmos. Existem dois principais simuladores: NS2 [103] e OPNET [104], e um simulador importante por factos históricos: X-SIM [105]. Em relação ao X-SIM, utilizar a plataforma não se revela a melhor opção, principalmente, devido ao facto da plataforma já ser bastante antiga e o seu desenvolvimento se encontrar parado. O NS2 é uma plataforma Open-Source que não necessita de qualquer tipo de licenciamento, ao contrário do OPNET [102] . Esse facto contribui decisivamente para a opção NS2 que se encontra em grande desenvolvimento, sendo as únicas contrariedades o facto de existir menos documentação e alguma falta de estabilidade no desenvolvimento de certos algoritmos. 115
- 138. TCP em Redesde Elevado Débito O NS2 tem como base uma programação orientada aos objectos em C++, interligada com a linguagem de script OTCL, também ela orientada aos objectos. A razão do NS2 usar estas duas linguagens é devido a duas funções distintas que necessita de disponibilizar. A primeira função é fornecer detalhadas formas de manipulações de bytes, cabeçalhos, implementações de diversos algoritmos, etc.; para este tipo de tarefas é necessária maior preocupação no tempo de compilação. A segunda função tem como base a configuração e reconfiguração rápida de cenários de rede, sendo mais prioritário o tempo que se demora a alterar o código, do que propriamente compilá-lo (a configuração corre apenas uma vez, sem qualquer ciclo). A arquitectura NS é, então, composta por um cenário de rede que, conforme os dispositivos, estará ligado a diversos algoritmos. Após toda a simulação efectuada poderão ser gerados ficheiros de trace49 , que poderão ser posteriormente analisados por diversas aplicações. Toda esta arquitectura NS está representada na Figura 4.23. Figura 4.23 – Arquitectura NS (Fonte: [106]). 4.2.1. Classes TCP As classes consideradas neste capítulo são as classes existentes na versão 2.30 do NS2, a mesma versão é utilizada durante toda fase de implementação e testes. As principais entidades de rede do NS2 são os nós, a aplicação e o agente. Estas entidades traduzem-se em três classes: Node, Application, Agent. A classe Node não tem qualquer tipo associado. No que diz respeito à classe Application existem diversos tipos associados [107], mas o único que permite a 49 Ficheiros para posterior análise de tráfego 116
- 139. 4. Testes Práticos utilizaçãoconjunta com um Agent TCP é o FTP (File Trasfer Protocol). Em relação à classe Agent existem também alguns, sendo referenciados agora os TCP. Existem dois tipos principais de TCP Agents: one-way Agents e two-way Agent. One-way Agents são ainda sub-divididos numa gama de emissores TCP e receptores TCP (“sinks”). O two-way Agent é considerado simétrico, devido ao facto de representar tanto um emissor como um receptor. Este tipo está ainda em desenvolvimento pelo que não será utilizado. Os emissores TCP one-way suportados por omissão estão representados na Tabela 4.2. Agente Emissor Definição Agent/TCP Um emissor TCP que utiliza a versão TCP Tahoe (ver Cap. 3.5.1) Agent/TCP/Reno Um emissor TCP que utiliza a versão TCP Reno (ver Cap. 3.5.2) Agent/TCP/Newreno Um emissor TCP que utiliza a versão TCP newReno (ver Cap. 3.5.3). Agent/TCP/Sack1 Um emissor TCP que utiliza Sack (ver Cap. 3.3.2.5) (é necessária a existência de um receptor, também deste tipo, para que este protocolo funcione). Agent/TCP/Vegas Um emissor TCP que utiliza TCP Vegas (ver Cap. 3.5.4). Agent/TCP/Fack Um emissor TCP Reno com FACK. Um algoritmo que utiliza os blocos SACK para maior detalhe sobre situações de congestão [37]. Tabela 4.2 – Definição dos Agentes Emissores TCP. Considerado o outro extremo, os receptores TCP one-way, suportados por omissão, estão representados na Tabela 4.3. Agente Receptor Definição Agent/TCPSink O normalmente utilizado, considera 117
- 140. TCP em Redesde Elevado Débito o normal ack por segmento. Agent/TCPSink/DelAck Um receptor TCP que considera um determinado atraso por ack, sendo esse atraso configurável. Agent/TCPSink/Sack1 Um receptor TCP que considera Sack (é necessária a existência de um emissor deste tipo para que este protocolo funcione). Agent/TCPSink/Sack1/DelAck Um receptor TCP com Sack e com um atraso de ack configurável. Tabela 4.3 – Definição dos Agentes Receptores TCP. Todos estes Agents têm diversas variáveis associadas, responsáveis por todas as definições e decisões do algoritmo. Essas variáveis encontram-se armazenadas no ficheiro de linguagem OTCL do Agent. No que diz respeito ao algoritmo, este encontra-se num ficheiro C++ que irá ser invocado pelo Agent. Desta forma, o funcionamento global de toda a simulação começa no Node que invoca a Application; a Application tem também um agente associado que irá ser invocado; conforme o Agent associado irão ser invocados os algoritmos correspondentes. Uma das grandes vantagens de implementar em NS2 é a linguagem orientada aos objectos. Devido a essa situação podemos apenas redefinir certas versões, sem qualquer tipo de modificação no ficheiro original. Como foi referido anteriormente, todas as versões têm como base a versão Reno (LCA) ou Vegas (DCA). Assim sendo, no Anexo A.2 encontra-se um template50 em código, de uma redefinição à versão Reno. 4.2.2. Outras implementações TCP No capítulo anterior foram referidos todos os agentes que existem por omissão no NS2. Para além dos referidos, existem diversas versões que disponibilizam o seu código para posteriores simulações e modificações em NS2. O NS2 funciona, quase sempre, como a implementação inicial de quase todas as versões, estando já bastante alargada a sua influência pelas comunidades de investigação. Este facto faz com que exista, praticamente, código NS2 em qualquer versão do TCP. A implementação NS2 Linux Implementation, para além de simples código, vem trazer algo de novo ao próprio NS2 e simultaneamente à comunidade de investigação. O objectivo desta implementação é aproximar todo o desenvolvimento desta plataforma a toda a stack TCP do Linux. Através de uma simples 50 Neste caso referencia o passo inicial, na criação de uma nova versão TCP. 118
- 141. 4. Testes Práticos patch[113], o utilizador NS2 tem, automaticamente, acesso a todas as versões TCP implementadas no kernel mais recente do Linux. Para além disso, o código disponibilizado é exactamente o mesmo da stack do sistema operativo, suportado por uma nova classe auxiliar criada para o efeito. A adição de qualquer versão TCP deste sistema operativo pode também ser adicionada facilmente. As versões do TCP disponibilizadas por esta implementação são neste momento: BIC, CUBIC, HighSpeed TCP, H-TCP, Hybla, newReno, Scalable, Vegas, Westwood, Veno e Compound. A nova classe Agent adicionada é a Agent/Linux. Nessa classe basta apenas efectuar a inicialização de uma variável com a versão TCP pretendida, para que sejam invocados os algoritmos correspondentes. Um simples cenário em que é utilizada esta implementação encontra-se no Anexo A.3.1. É de referir também que esta versão, para além de todas as versões testadas, adiciona a versão Compound TCP. Esta versão apenas se encontra implementada nos kernel mais instáveis, sendo essa a razão de não existir no kernel usado anteriormente (ver Cap. 4.1). 4.2.3. Cenários A definição de cenários em NS2 foi a primeira fase de todo o planeamento de testes depois da nova versão implementada (ver Cap. 5.3). A principal preocupação dos cenários é conseguir que todos os parâmetros que se pretende analisar sejam correctamente identificados. Foram definidos então dois cenários: • Cenário Lumbbell; Este cenário é bastante conhecido de todas as comunidades de investigação do protocolo TCP. Baseia-se essencialmente em 2 emissores, 2 routers e 2 receptores. As principais vantagens na utilização deste cenário passam principalmente pela comparação de dois fluxos de duas versões diferentes, analisando parâmetros como fairness e ocupação total de largura de banda. A configuração deste cenário encontra-se representada na Figura 4.24, o respectivo script OTCL encontra-se no Anexo A.3.2. 119
- 142. TCP em Redesde Elevado Débito Figura 4.24 – Cenário Lumbbell em NS2. • Cenário Internet. Devido à importância deste ambiente, numa segunda fase serão configuradas condições que o consigam simular devidamente. O objectivo é saber como se comportaria a versão, caso fosse adoptado como o protocolo da Internet. A configuração deste cenário está representada na Figura 4.25, o respectivo script OTCL encontra-se no Anexo A.3.3. Neste cenário o emissor (0) transfere vários fluxos com variados tamanhos, simulando toda a interligação de fluxos existente na rede global. Figura 4.25 – Cenário Internet. 120
- 143. 5. EIC TCP 5.EICTCP Este capítulo corresponde à nova versão do protocolo TCP implementado. Após toda a fase de estudo e testes práticos, o objectivo passou a ser a definição de novos parâmetros, que fornecessem ao TCP novas formas de tratar todo o processo de congestão. Diversos conceitos surgiram, baseados principalmente em algumas falhas das versões já implementadas. Obviamente os testes a essas versões encontram-se já numa fase bastante avançada, verificando em maior detalhe algumas falhas. Este facto veio facilitar imenso toda a análise efectuada. 5.1. Motivação “Quando o emissor TCP aumenta a sua transmissão, o RTT pode não aumentar se não existir qualquer tipo de congestionamento nas filas dos dispositivos. Este argumento é potencialmente válido para uma ligação em que a ligação bottleneck tenha uma largura de banda bastante elevada”.[23] O projecto foi iniciado através da verificação de um estudo [5]. A motivação para a nova versão iria surgir, também, com base em outra publicação [23]. Existem duas motivações principais para todo o processo de especificação e posterior implementação: • A cada vez mais fraca relação que existe entre o RTT e a taxa de transmissão da rede, à medida que a largura de banda da rede aumenta; • O Ack Compression [12] proporcionado pela filas de espera dos dispositivos, gerando alterações bruscas no RTT de cada fluxo, sem necessariamente existir congestão. A Relação Taxa de Transmissão e RTT A relação existente entre a taxa de transmissão e o RTT não é muito fácil de analisar. As redes não têm a mesma capacidade ao longo de todas as ligações, sendo aqui que surge o principal problema relacional. Imaginando ligações conjuntas de baixo débito e alto débito, variados buffers das aplicações (sockets), variados atrasos; existem uma série de condições que podem tornar a relação RTT e taxa de transmissão muito reduzida. 121
- 144. TCP em Redesde Elevado Débito A situação ideal para a maximização desta relação é ligações de baixo débito onde os buffers se encontram sempre bastante sobrecarregados. A situação onde esta relação se encontra bastante minimizada são ligações de alto débito, com tamanhos bastante curtos dos buffers aplicacionais e onde o atraso seja reduzido; desta forma os buffers são muito menos testados, podendo existir atrasos que nada têm a ver com congestão (opção por outros caminhos de rede, atraso variável do próprio meio etc.). O conceito desta versão é tentar garantir que os buffers da rede se encontrem sempre em constantes testes, retirando, após esses testes, as devidas decisões para as posteriores modificações na janela de congestão. Ack Compression Este problema já foi referido anteriormente, usando o TCP Vegas a técnica Spike Compression (ver Cap. 3.5.4) para atenuar esta situação. O problema desta técnica é que apenas limita a forma como o espaçamento é efectuado, não definindo qualquer tipo específico de espaçamento. Esta nova versão tenta contornar este problema, através de uma nova técnica de espaçamento entre os segmentos. Estas duas situações, com a correcta solução implementada, poderão melhorar imenso toda a perfomance TCP. A perfomance será adquirida, principalmente, porque as decisões a tomar ganham uma maior garantia de que as filas estão mesmo congestionadas. 5.2. Especificação “Supondo que um carro tem um controlo especial no pedal: o carro acelera com uma probabilidade ρ e desacelera com uma probabilidade ρ-1, cada vez que o controlo é activado. A questão agora é: qual a gama de valores para o qual ρ permite a arquitectura de um sistema fiável?”[23] O principal problema de toda a especificação é não exagerar nos testes aos buffers, sob pena de em vez de prevenir a congestão, aumentá-la. Sendo o objectivo testar os buffers, nada melhor do que considerar a situação mais problemática para os mesmos. Essa situação são segmentos enviados em burst. Conforme o grau de congestionamento das filas, conforme a reacção ao burst; se as filas de encontrarem bastante pouco sobrecarregadas, então o burst, provavelmente, passará pela rede como outro qualquer conjunto de segmentos; se as filas se encontrarem com algum grau de congestionamento, então poderá existir um aumento no RTT dos segmentos; se as filas estiverem já bastante congestionadas (situação 122
- 145. 5. EIC TCP maisproblemáticas), então o aumento do RTT será bastante elevado, ou o burst poderá induzir alguns descartes (situação bastante indesejável). Compreensivelmente, a rede não pode funcionar em constantes bursts. As filas nunca aguentariam e seriam descartados diversos segmentos, sendo a eficiência da rede extremamente afectada. A solução passa pela definição de dois tipos de envio de segmentos: os segmentos em burst e um envio de segmentos mais espaçado. Os segmentos irão sendo referenciados, respectivamente, como segmentos Burst (BS) e segmentos Loose51 (LS). No que diz respeito ao Ack Compression por parte das filas, a técnica que permite a atenuação é o espaçamento dos segmentos LS. Em todas as outras versões TCP o espaçamento nunca é, especificamente, controlado pela versão, deixando a aplicação definir o seu prório ritmo de espaçamento e apenas o limitando por vezes (TCP Vegas e FAST TCP). O problema de segmentos sucessivos de um fluxo à espera nas filas, sendo “despachados52 ” todos de uma vez (alterando repentinamente o RTT para todos os segmentos) é resolvido nesta versão, simplesmente, com a comum situação de existirem variados fluxos na rede. Usando apenas um fluxo, apesar do espaçamento existente, a rede está sempre sujeita a que exista Ack Compression. A Figura 5.1 representa toda a técnica atrás referida. Na primeira situação (1) apenas um fluxo com a versão EIC TCP se encontra na rede (a vermelho encontram-se os BS, a verde os LS). Na segunda situação (2), variados fluxos (amarelo, rosa e preto) aparecem entre o espaçamento LS; desta forma quando os segmentos chegarem às filas o fluxo EIC TCP terá bem menos probabilidade de ter os seus segmentos, de forma consecutiva, à espera nas filas; posteriormente, quando a fila os “despachar” não existirá a mesma mudança repentina para todos os segmentos do fluxo, devido ao facto de a fila ter necessidade de tratar, também, outro tipo de fluxos. Figura 5.1 – Técnica de atenuação de Ack Compression. 51 O inglês “loose” significa solto 52 Refere-se a quando o processo aplicacional vai retirar segmentos aos buffers de rede. 123
- 146. TCP em Redesde Elevado Débito A parte mais crítica de qualquer versão TCP é a sua capacidade de decisão. Esse facto provém da característica fundamental do TCP: adivinhar tudo o que se passa na rede. A capacidade de adivinhar desta versão encontra-se nas duas formas de envio BS e LS, mais propriamente, num único segmento de cada tipo. A dificuldade será escolher esses mesmos segmentos: uma escolha de segmentos próximos poderá não ser coerente em termos de diferença entre RTT, verificando-se tempos bastante semelhantes; uma escolha de segmentos afastados é necessário um maior tempo de espera para a decisão, sendo a eficiência da rede afectada. Os segmentos escolhidos são referenciados como Burst Probe (BP) para os Segmentos Burst, Loose Probe para os segmentos Loose. Ambos podem ser vistos como ponteiros; o primeiro é um ponteiro estático que aponta sempre para o último segmento do BS; o segundo é um ponteiro dinâmico que irá apontar para um determinado segmento do LS, conforme o tamanho da janela de congestão. Através deste funcionamento é conseguido um maior grau de adaptabilidade ao débito existente na rede, mantendo sempre uma distância intermédia ponderada entre BP e LP. A adaptabilidade à rede é extremamente importante, dado o grau de acontecimentos a que uma rede de dados está sujeita. Para além do segmento LP, o espaçamento do LS também diminui conforme o número de segmentos que a rede transporta, aumentando conforme o RTT. A Figura 5.2 representa todas as modificações a que está sujeita esta versão, ao longo da transferência de dados. A relação que existe entre BS e a janela de congestão é de 30% o valor da cwnd, considerando também um valor máximo de 8 segmentos para o Burst; desta forma é conseguido um limite para que a fila não seja testada de forma excessiva. Em relação ao espaçamento LS é conseguido através de uma relação entre o seu próprio número de segmentos e o RTT, conseguindo assim que com altos débitos o canal permaneça ocupado. O LP escolhido terá como base 35% do valor da cwnd, encontrando assim o tempo intermédio para efectuar a decisão. Figura 5.2 – Adaptabilidade da versão EIC TCP. 124
- 147. 5. EIC TCP Otempo em que as decisões são efectuadas, ao contrário da maioria das versões, não é nem a cada RTT, nem a cada ack recebido. Devido ao facto de a comparação ser feita com segmentos que se encontram algo distanciados no tempo é necessário esperar o RTT e ainda o tempo dessa distância. O tempo a que será efectuada cada decisão é calculado pela seguinte fórmula: )*35.0( cwndTRTTTdecisão += A arquitectura de toda a versão é então conseguida através de uma estrutura de decisão que utiliza como parâmetros a quantidade de envio de segmentos (modificações na janela de congestão), o controlo de espaçamento desses mesmos segmentos e o estado dos buffers (diferença do RTT). A Figura 5.3 representa a arquitectura referida, através de um diagrama de blocos. Figura 5.3 – Arquitectura EIC TCP. Nesta especificação não foram considerados os valores de alteração da janela de congestão (Controlo de Envio). Essa situação acontece, devido a alguma falta de sensibilidade no que diz respeito ao aumento da taxa de transmissão do emissor. Foi preferido apenas especificar um valor inicial simbólico e, posteriormente, ir redefinindo os valores, conforme os testes intermédios da implementação. Será guardado também o último valor da janela de congestão, aquando a ocorrência de perdas, para existir um maior controlo no nível dos bursts. 5.3. Implementação Na criação de uma nova versão do TCP torna-se essencial utilizar o código já implementado, modificando apenas parte do código, necessária à implementação da nova versão. A análise de código já existente é fundamental para a correcta modificação e para o correcto funcionamento de toda a especificação. A implementação da versão EIC TCP encontra-se na class C++ EicAgent e herda as características da versão Reno que tem como classe C++ a RenoTcpAgent. A classe RenoTCPAgent deriva da versão Tahoe pela class C++ TcpAgent. A Figura 5.4 representa o diagrama de classes da versão EIC TCP. 125
- 148. TCP em Redesde Elevado Débito Figura 5.4 – Diagrama de Classes EIC TCP. As funções alteradas foram: send_much(int, int, int), reset(), opencwnd() e a output(int, int), considerando a class C++ TcpClass; na classe RenoTcpClass foram alteradas a recv(Packet, Handler), timeout(int) e dupaction(). Na função recv(Packet, Handler) efectuaram-se as mudanças que se encontram na Figura 5.5. O código foi acrescentado no final da função, depois de todas as verificações feitas ao segmento (mesmo antes de se libertar a memória onde está alojado o segmento). Na sua essência, o código adicionado verifica se não existem segmentos perdidos, ou se a dimensão da variável cwnd é adequada para iniciar o algoritmo. Em caso afirmativo verifica-se se o segmento que foi recebido é o segmento LP ou BP, se isto se confirmar é calculado o RTT dos segmentos. Figura 5.5 – Diagrama de fluxo da recepção de segmentos do EIC TCP. 126
- 149. 5. EIC TCP Noenvio dos segmentos alterou-se duas funções: output(int, int) e a send_much(int, int , int). A alteração da função send_much(int, int, int) prende-se com o facto da decisão do tamanho do burst, da posição do BP e da posição do LP. A região do fluxograma da Figura 5.6 onde se indica como são enviados os segmentos é executada pela função output(int, int). Figura 5.6 – Fluxograma de envio de segmentos do EIC TCP. 127
- 150. TCP em Redesde Elevado Débito Para aumentar a cwnd alterou-se apenas a função opencwnd(), que caso não sejam reunidas as condições necessárias deverá utilizar o código normal do Reno. Se existirem condições para utilizar o algoritmo do EIC TCP, calcula a divisão do RTT do LP por BP e toma a decisão do aumento da cwnd, calculando o novo tempo intersegmentos para os LS. Figura 5.7 – Algoritmo da abertura de janela do EIC TCP 128
- 151. 5. EIC TCP Nasfunções timeout(int) e reset(), a única modificação ao código original foi a inclusão de uma função para fazer reset a todas as variáveis de controlo que a nova versão possui. Para a função dupaction() a alteração tem por base a definição de um máximo, de modo a que a cwnd ao crescer não seja maior que o valor onde se verificaram perdas anteriormente. Uma análise detalhada do código é possível no Anexo A.4. Para testar o comportamento da nova versão efectuaram-se testes que se encontram descritos no capítulo seguinte. 5.4. Testes Testes à nova versão que não estabeleçam comparações com os outros algoritmos das versões anteriores têm pouco valor. Para determinar a eficiência de um novo protocolo é essencial existir comparações de diversos parâmetros como throughput, convergência, fairness e estabilidade. Para estabelecer esta comparação efectuaram-se dois tipos de testes: cenário lumbbell, onde se criaram dois fluxos de versões diferentes, cada um com os seus algoritmos a “competir” por largura de banda; cenário Internet, onde se simulou com tráfego característico que, normalmente, transita na Internet e se usaram as diversas versões em diferentes espaços de tempo, calculando o tempo que os fluxos demoram a enviar todos os segmentos. Torna-se importante realçar que o desenvolvimento da nova versão é um processo que ainda está a decorrer. Na análise da versão notar-se-á que existe ainda bastante desenvolvimento por realizar, para que se possa considerar esta versão como a versão final. Os vários testes servem essencialmente como um ponto de situação do actual estado de desenvolvimento. 5.4.1. Testes Lumbbell O propósito deste teste foi a realização da competição entre dois fluxos. Um fluxo a utilizar a versão EIC TCP, outro fluxo a usar uma versão presente no kernel de desenvolvimento do Linux. Ambos os fluxos partilham sempre a mesma ligação. Trata-se de um cenário Lumbbell com um atraso de 100ms, sendo a velocidade de todas as ligações de 1Gbit/s. As ligações utilizam cablagem e ethernet (MSS de 1460). Ambos os fluxos começam ao mesmo tempo, competindo pela largura de banda durante 1200 segundos. A ligação que é partilhada pelos dois fluxos tem uma fila de 10000 segmentos. Optou-se por usar estes valores nas ligações pois a grandezas são adequadas e típicas de ligações LFN. Em todos os testes verifica-se primeiro ambas as versões em separado e de seguida o somatório do throughput das duas. 129
- 152. TCP em Redesde Elevado Débito É de realçar que todas as versões comparadas estão a usar Sack (ver Cap. 3.3.2.5), menos a versão EIC TCP. 5.4.1.1. TCP newReno Contra a versão newReno (ver Cap. 3.5.3) a nova versão EIC TCP (ver Cap. 5) aproveita eficientemente a largura de banda. Essa situação acontece pois o newReno cresce muito lentamente, tendo em conta o RTT e a largura de banda máxima que se pode ocupar. Na análise da Figura 5.8 verifica-se que o novo algoritmo ocupa a largura de banda de forma bastante rápida passando os 900Mbit/s em poucos segundos e mantendo-se nessa velocidade de forma bastante estável. Com o decorrer do tempo o throughput do EIC TCP vai diminuindo, à medida que o newReno vai aumentando a sua janela de congestão. Derivado à fraca prestação da versão newReno, num cenário com essas características não se verifica qualquer perda. Constata-se, ainda, pelo gráfico da largura de banda total que esta é usada na sua totalidade a partir dos 2 minutos (120 segundos). O somatório do throughput das duas versões é, assim, quase perfeito, ocupando toda a largura de banda disponibilizada. Figura 5.8 – Simulação com a versão newReno Vs. EIC TCP e somatório das duas. 5.4.1.2. TCP Vegas A competição entre o EIC TCP e o Vegas (ver Cap. 3.5.4) consegue uma boa ocupação da largura de banda, chegando a 1Gbit/s em menos de 3 minutos (200 segundos) como demonstra a Figura 5.9. Mais uma vez o EIC TCP chega rapidamente a 900Mbit/s, rapidamente estabilizando, mas desta vez subindo ao longo do tempo. A versão que utiliza o algortimo Vegas vai aumentando o throughtput até aos 3 minutos (200 segundos). Passando este período de tempo, o aproveitamento da largura de banda começa a descer, chegando quase a zero no final do teste. Esta descida acontece pois o algoritmo Vegas diminui a janela de congestão ao detectar que a congestão está iminente. 130
- 153. 5. EIC TCP Othroughput somado das duas versões continua quase perfeito, não existindo qualqur perda. Figura 5.9 – Simulação com a versão TCP Vegas Vs. EIC TCP e somatório das duas. 5.4.1.3. TCP Hybla Como o seu crescimento não depende do RTT o algoritmo do Hybla (ver Cap. 3.5.5.1) cresce bastante rápido. Como se constata no início do gráfico da Figura 5.10, crescem os dois algoritmos bastante rápido. Como isto sucede, ocorrem naturalmente perdas, o que origina timeouts por parte do EIC TCP. O EIC TCP tenta recuperar, mas voltam rapidamente a ocorrer timeouts. O funcionamento EIC TCP com Hybla não é tão prioritário por o Hybla não ser uma versão para o meio específico da versão EIC TCP. A largura de banda total não é aproveitada de forma eficiente, visto que o Hybla ocupa no máximo 200Mbit/s. Figura 5.10 - Simulação com a versão TCP Hybla Vs. EIC TCP e somatório das duas 131
- 154. TCP em Redesde Elevado Débito 5.4.1.4. TCP Westwood+ Como se pode constatar pela Figura 5.11, verificam-se os mesmos resultados do newReno utilizando Westwood+ (ver Cap. 3.5.5.2). Não existindo qualquer tipo de perda (ponto forte desta versão), o aproveitamento é idêntico ao seu antecessor. Figura 5.11 – Simulação com a versão TCP Westwood+ Vs. EIC TCP e somatório das duas. 5.4.1.5. TCP Veno Os gráficos gerados pela competição entre a versão Veno (ver Cap. 3.5.5.2) e a nova versão são bastante semelhantes aos resultados gerados pelo teste da versão newReno e Westwood+ como pode ser visto pela Figura 5.12. A nível da largura de banda total continua quase pefeito, sem qualquer tipo de perda. Figura 5.12 – Simulação com a versão TCP Veno Vs. EIC TCP e somatório das duas. 132
- 155. 5. EIC TCP 5.4.1.6.TCP Low Priority Os testes da competição entre a versão Low Priority e EIC TCP apresenta os resultados com as mesmas características que os outros algoritmos baseados no newReno. A largura de banda total também é ocupada de forma eficiente. O objectivo do Low Priority é cumprido, não interferindo a sua versão na largura de banda do EIC TCP. Figura 5.13 – Simulação com a versão TCP Low Priority Vs. EIC TCP e somatório das duas. 5.4.1.7. HighSpeed TCP A Figura 5.14 demonstra a versão HighSpeed com um funcionamento problemático em relação ao EIC TCP. Devido ao diferente grau de “agressividade” do algoritmo HighSpeed (ver Cap. 3.6.4) em relação às outras versões, as perdas de segmentos começam a surgir. De início o EIC TCP cresce rapidamente como nos testes anteriores; após chegar quase a 1Gbit/s começa a perder largura de banda, devido o aumento do throughput da versão HighSpeed; ao haver perdas de segmentos a versão EIC TCP deixa de funcionar correctamente, ocorrendo timeout sempre que há perdas; após o timeout, o EIC TCP é capaz de recuperar rapidamente, embora por pouco tempo. Esta situação inviabiliza o correcto funcionamento das duas versões, alcançando a versão HighSpeed apenas 200Mbit/s no seu valor máximo. A largura de banda total é mal aproveitada, saindo prejudicadas ambas as versões. 133
- 156. TCP em Redesde Elevado Débito Figura 5.14 – Simulação com a versão HighSpeed Vs. EIC TCP e somatório das duas. 5.4.1.8. Scalable TCP A versão Scalable TCP (ver Cap. 3.6.3) pode ser vista na Figura 5.15. A principal diferença em relação ao HighSpeed é que a ocorrência dos timeouts é independente do valor do throughput EIC TCP. O que acontece é que o Scalable transfere um pouco do seu funcionamento para a nova versão, tornando-o extrememamente oscilativo independentemente da janela de congestão e RTT. O Scalable TCP não consegue aproveitar convenientemente a largura de banda, utilizando em média 200Mbit/s. Sendo um TCP bastante oscilante, junto com o EIC TCP e principalmente devido aos timeouts, o seu carácter oscilativo ainda é mais elevado. A largura de banda total é, provavelmente, das mais mal aproveitadas. Figura 5.15 – Simulação com a versão Scalable Vs. EIC TCP e somatório das duas. 134
- 157. 5. EIC TCP 5.4.1.9.BIC Como a “agressividade” do algoritmo BIC (ver Cap. 3.6.4) é bastante maior do que a das outras versões, as perdas de segmentos começam a surgir de forma muito acentuada, verificando-se as oscilações da Figura 5.16. De início o EIC TCP cresce rapidamente como nos testes anteriores; após chegar ao 900Mbit/s começa a perder largura de banda, com um desenvolvimento posterior, semelhante ao dos testes com a versão HighSpeed. Esta situação inviabiliza novamente o funcionamento das duas versões, alcançado a versão BIC 300Mbit/s. A largura de banda total continua mal aproveitada. Figura 5.16 – Simulação com a versão BIC Vs. EIC TCP e somatório das duas. 5.4.1.10. CUBIC A utilização da versão do CUBIC (ver Cap. 3.6.4) apresenta-se na Figura 5.17, sendo bastante semelhante ao teste anteriormente efectuado com o BIC. O CUBIC também só consegue atingir 300Mbit/s, ficando a largura de banda total pouco aproveitada. O CUBIC tenta diminuir um pouco a “agressividade” do BIC, porém, neste caso a diminuição não é suficiente. 135
- 158. TCP em Redesde Elevado Débito Figura 5.17 – Simulação com a versão CUBIC Vs. EIC TCP e somatório das duas. 5.4.1.11. H-TCP Ao competir com o H-TCP (ver Cap. 3.6.5), verificando a Figura 5.18, acontece à versão EIC TCP o mesmo que nas versões que aproveitam melhor a largura de banda disponibilizada, ou seja, perdas seguidas de timeout. Embora com o algoritmo H-TCP, a largura de banda total é menos aproveitada do que com as outras versões, tal como sucedia com o Scalable. Figura 5.18 – Simulação com a versão H-TCP Vs. EIC TCP e somatório das duas. 136
- 159. 5. EIC TCP 5.4.1.12.TCP Compound A competição entre o Compound TCP (ver Cap. 3.6.7) e o EIC TCP é diferente das outras versões para alto débito. Verificando a Figura 5.19, o EIC TCP cresce muito rápido, chegando quase ao máximo da largura de banda estabelecido. O Compound TCP comporta-se de forma semelhante à versão newReno. Cresce também inicialmente, embora muito menos, estabilizando também como o EIC TCP; passado 3 minutos (180 segundos) o Compound começa a crescer novamente ao longo de todo o tempo de teste; ao EIC TCP acontece a situação inversa, a partir dos 3 minutos começa a decrescer, continuando a decrescer o resto da simulação. Apesar de ser uma versão para alto débito, a preocupação com fairness do Compound permite que outras versões mais “agressivas” lhe diminuam bastante a forma de como requisitar largura de banda. A largura de banda total é aproveitada na sua totalidade. Figura 5.19 - Simulação com a versão Compound TCP Vs. EIC TCP e somatório das duas. 5.4.1.13. EIC TCP Na competição entre EIC TCP contra EIC TCP nota-se que apenas um dos fluxos é que ocupa a largura de banda, ficando o outro com uma parte residual. Esta é a situação mais problemática de todos os testes, o problema pode ser verificado em maior detalhe na Figura 5.20. 137
- 160. TCP em Redesde Elevado Débito Figura 5.20 – Simulação com a versão EIC TCP VS EIC TCP e somatório das duas. 5.4.2. Testes Internet O propósito deste teste é o de analisar se as várias versões do TCP conseguem enviar tráfego típico que circula na Internet no menor espaço de tempo. Este tráfego é caracterizado por uma distribuição Pareto, ou seja, muitos fluxos com poucos segmentos e poucos com muitos segmentos. Foram efectuados dois tipos de teste, um onde a média do tamanho dos segmentos é de 25 e outra em que a média é 200. Por minuto são criados em média 4000 novos fluxos, com uma duração de 200 segundos ou até completar 100000 fluxos. O cenário é composto por quatro dispositivos, dispostos como a representação da Figura 4.25. Todas as ligações têm 1Gbit/s. Em relação ao atraso, as ligações que ligam ao receptor e emissor possuem um atraso de 5ms, a ligação de core tem 90ms, o que dá um total de 100ms de atraso. As filas das ligações são calculadas pelo script. Nos testes em que a média dos segmentos é de 200, por vezes os gráficos tiveram de ser editados. A razão dessa edição é que quando apenas um fluxo termina, após um grande espaço de tempo, altera de forma drástica a escala de visualização. Devido a esta situação, por vezes nas versões de alto débito opta-se por não considerar esse fluxo na simulação. 138
- 161. 5. EIC TCP 5.4.2.1.TCP newReno Com a análise do gráfico da Figura 5.21 retira-se que o EIC TCP é pior na maioria das situações do que o protocolo newReno. Independentemente do tamanho dos fluxos no algoritmo newReno (ver Cap. 3.5.3), regra geral, os fluxos acabam sempre primeiro. Esta situação só ocorre para os segmentos que são enviados durante a fase de SlowStart, notando-se claramente o formato de uma escada que correspondem aos valores do SlowStart. Os segmentos que não se encontram no seguimento dessa linha tratam-se de fluxos que sairam da fase SlowStart por alguma razão, entrando na fase Congestion Avoidance, demorando assim muito mais tempo do que os restantes fluxos para o mesmo número de segmentos. Portanto quando os fluxos têm de sair da fase SlowStart, o algoritmo do EIC TCP torna-se mais eficiente, não ocorrendo tantos desvios. Figura 5.21 – Simulação na Internet com TCP newReno (25 segmentos e 200 segmentos de média). 5.4.2.2. TCP Vegas A versão Vegas (ver Cap. 3.5.4) do TCP é bastante similar à versão newReno, como se pode verificar na Figura 5.22. Segmentos que não saiem da fase de Slow Start (ver Cap. 3.5.1.2) são mais rápidos comparando com o algoritmo do EIC TCP; quando os fluxos entram na fase de Congestion Avoidance (ver Cap. 3.5.1.3) demoram mais tempo a transferir a totalidade dos segmentos. Esta situação é particularmente evidente quando se aumenta a média dos segmentos, pois começam a existir mais desvios e por uma grande margem. 139
- 162. TCP em Redesde Elevado Débito Figura 5.22 – Simulação na Internet com TCP Vegas (25 e 200 segmentos de média). 5.4.2.3. TCP Hybla A versão Hybla (ver Cap. 3.5.5.1) é a mais rápida a transferir fluxos pequenos por não depender do RTT, demorando assim apenas cerca 0.5 segundos a trasnmitir fluxos até 7000 segmentos. Quando se aumenta a média do tamanho dos fluxos existem alguns desvios equiparando-se ao EIC TCP. Todo este funcionamento pode ser verificado na Figura 5.23. Figura 5.23 – Simulação na Internet com TCP Hybla (25 e 200 segmentos de média). 5.4.2.4. TCP Westwood+ Com a versão Westwood+ (ver Cap. 4.1.3.4) os resultados dos testes são, regra geral, semelhantes aos produzidos com o algoritmo newReno. Os resultados são apresentados na Figura 5.24. 140
- 163. 5. EIC TCP Figura5.24 – Simulação na Internet com TCP Westwood+ (25 e 200 segmentos de média). 5.4.2.5. TCP Veno Os resultados dos testes ao Veno (ver Cap. 3.5.5.1) são, também, em tudo similares aos resultados apresentados pelo algoritmo newReno, como se verifica na Figura 5.25. Figura 5.25 – Simulação na Internet com TCP Veno (25 e 200 segmentos de média). 5.4.2.6. HighSpeed TCP O TCP HighSpeed (ver Cap. 3.6.2) inicia a fase de testes na Internet com versões de alto débito. Quando a versão HighSpeed sai da fase de Slow Start origina um desvio bastante acentuado. Como tal, é mais veloz a trasnmitir segmentos caso não saia da fase Slow Start. Este algoritmo apresenta resultados bastante similarers aos produzidos com o algoritmo Vegas, mesmo não tendo nada em comum com esta versão em termos de funcionamento. 141
- 164. TCP em Redesde Elevado Débito Figura 5.26 – Simulação na Internet com HighSpeed TCP (25 e 200 segmentos de média). 5.4.2.7. TCP Scalable O Scalable (ver Cap. 3.6.3) apresentou resultados idênticos aos gerados pelo newReno, com um ligeiro decréscimo na grandeza dos desvios. A Figura 5.27 demonstra esses resultados. Figura 5.27 – Simulação na Internet com Scalable TCP (25 e 200 segmentos de média). 142
- 165. 5. EIC TCP 5.4.2.8.TCP BIC Com a versão BIC (ver Cap. 3.6.4) observa-se na Figura 5.28 que se trata de uma versão que não apresenta muitos desvios, seja qual for a média de segmentos dos fluxos gerados. Também se constata que não possui uma fase de Slow Start como o do newReno. O algoritmo BIC consegue, à semelhança dos outros algoritmos, transferir os segmentos com menor dimensão mais rápidamente do que a versão EIC TCP. O mesmo não é verdade para os fluxos com mais de 4000 sgementos, onde o algoritmo EIC TCP é mais rápido a transferir os fluxos. Figura 5.28 - Simulação na Internet com BIC (25 e 200 segmentos de média). 5.4.2.9. TCP CUBIC Os resultados gerados pelo CUBIC (ver 3.6.4) são bastante similares aos obtidos pelo BIC, com a diferença de existirem menos desvios e a transferência de segmentos ser mais demorada. Assim, a versão CUBIC consegue transferir mais rapidamente fluxos com poucos segmentos do que o EIC TCP, e menos eficientemente fluxos com mais segmentos. O Funcionamento pode ser verificado na Figura 5.29. 143
- 166. TCP em Redesde Elevado Débito Figura 5.29 – Simulação na Internet com CUBIC (25 e 200 segmentos de média). 5.4.2.10. H-TCP O H-TCP (ver Cap. 3.6.5), como o resto dos protocolos que utiliza o Slow Start do newReno, é mais rápido a transferir todos os segmentos dos fluxos nessa fase. Ao contrário dos outros algoritmos em que acontecem muitos desvios no tempo de transmissão de fluxos, o H-TCP desvia tanto como o EIC TCP. Os resultados estão expressos na Figura 5.30. Figura 5.30 – Simulação na Internet com H-TCP (25 e 200 segmentos de média). 5.4.2.11. TCP Compound Os resultados gerados na Figura 5.31 pela versão Compound TCP (ver Cap. 3.6.7) também são bastantes parecidos aos obtidos com o newReno. 144
- 167. 5. EIC TCP Figura5.31 – Simulação na Internet com Compound TCP (25 e 200 segmentos de média). 5.4.3. Conclusões Ao analisar os resultados torna-se evidente que é, por demais, fundamental que se implemente um sistema mais eficiente de tratamento de perdas, pois na maiorias das vezes que se perdem segmentos na rede ocorre um timeout na versão EIC TCP. Esta situação perturba imenso o correcto funcionamento da versão e posteriormente do desempenho da rede. Estudando atentamente o caso da competição EIC TCP contra EIC TCP (ver Cap. 5.4.1.13) chega-se à conclusão que o problema observado na Figura 5.20 é um problema que poderá acontecer a abordagens DCA. Por utilizar a abordagem DCA (ver Cap. 3.5.6), usando o RTT para aumentar o seu débito de transmissão (janela de congestão), a subida desta versão é demasiado repentina e quando um segundo fluxo requer largura de banda, o RTT já se verifica demasiado elevado. Uma solução será seguidamente abordada (ver Cap. 5.5). De notar também que pelas perdas não estarem devidamente implementadas faz com que uma das versões do EIC TCP dê origem a muitos timeouts, pois com o sistema de perdas melhorado o protocolo deverá crescer no mínimo igual à versão Reno. Em relação aos testes Internet, um aspecto essencial que precisa de ser melhorado é o inicio da ligação, pois todas as versões que utilizam Slow Start têm um desempenho bastante elevado, conseguindo enviar fluxos de poucos segmentos com uma maior rapidez que o EIC TCP. O Slow Start revela-se um algoritmo extremamente eficaz para o ínicio da ligação e, consequentemente, para a Internet, onde a maioria das ligações são bastante curtas. A nova versão revelou-se, porém, bastante estável comparando todas as outras versões, não existindo grandes desvios no que diz respeito ao tempo de transmissão dos fluxos. Poderá demorar mais a transmiti- los em certas fases, mas o espalhamento temporal dos fluxos é bastante bom. Os testes devem passar por várias fases. Não estando esta versão no seu estado final, testes por uma terceira entidade (imparcial no processo de criação da versão) não devem ainda ser considerados, devendo 145
- 168. TCP em Redesde Elevado Débito ainda ser efectuadas modificações e testes, no âmbito da própria comunidade de investigação que o desenvolveu. 5.5. Trabalho Futuro A versão encontra-se especificada e implementada. Todos os testes efectuados posteriormente não originaram qualquer tipo de modificação na implementação, servido apenas para efectuar um ponto de situação e iniciar futuro desenvolvimento. A versão revelou-se, na globalidade, bastante estável ao longo do tempo. Os principais problemas verificam-se no início da sessão de dados e após ocorrerem perdas. O objectivo desta versão é prevenir as perdas (abordagem DCA, 3.5.6), porém, elas acabarão sempre por ocorrer e a versão não se encontra muito bem preparada. Devido ao envio ser baseado no burst, o risco das perdas ocorrerem também em burst deve aumentar bastante, devendo esse ser, provavelmente, a razão dos timeouts. Outra parte do desenvolvimento que ainda não se encontra nesta versão é o suporte ECN e Sack. O Sack é, especialmente, importante por ajudar bastante o emissor quando existem múltiplas perdas numa só janela. O ECN vai servir, essencialmente, para ajudar na prevenção. O diagrama de blocos que se pretende está representado na Figura 5.32. Figura 5.32 – Futura arquitectura EIC TCP. Os principais aspectos e soluções que devem ser considerados no posterior caminho de desenvolvimento desta versão são: • Testes com vários tipo de mecanismo de filas; Foi apenas considerado o mais comum tipo de filas, as filas FIFO. Existem diversos mecanismos que têm uma melhor ou pior reação aos bursts, podendo por isso modifcar o comportamento desta versão. Alguns destes mecanismos AQM (Active Queue Management) são: RED, DropTail, REM (Random exponencial Marking), etc. • Mais parâmetros do que o RTT para efectuar decisões; 146
- 169. 5. EIC TCP Estaé a solução ao problema verificado no teste de dois fluxos com EIC TCP (ver Cap. 5.4.1.13). O problema do segundo fluxo não conseguir crescer, prende-se também por não existir suficiente valor RTT para o efeito. Ao adicionar novos parâmetros para modificação da janela de congestão, se outro fluxo manipular os valores RTT, o outro parâmetro fornecerá valores para ajudar o fluxo a impor-se. Um parâmetro pode ser por exemplo a sua prória janela de congestão: se o valor tiver muito baixo, então deve subir, mesmo se o RTT desaconselhar; outro parâmetro pode ser as perdas: se o fluxo não tiver perdas num longo período de tempo, então parte-se do princípio que o fluxo está em baixo e deve subir; etc. • Uma fase inicial mais rápida; O Slow Start revelou-se bastante superior em todos os fluxos de poucos segmentos. O algoritmo do EIC TCP inicial tem de ser reconsiderado. Algumas soluções poderiam passar por diminuir o número de segmentos mínimos para inciar o algoritmo, ou mesmo iniciar a transferência de dados já com o algoritmo. • O valor do burst com um valor mais dinâmico; Uma melhoria no capítulo da adapatabilidade desta versão. O burst desta versão atinge um máximo de 8 segmentos. Com bons mecanismos de recuperação às perdas, juntamente com o Sack, tornar este valor completamente dinâmico (limite definido sempre pelo próprio algoritmo) pode ser uma boa opção. • Tratamento das perdas; O tratamento das perdas deve ser efectuado com uma abordagem distinta entre BS e LS. Esta abordagem pode ser bastante eficiente em ambientes wireless, pois ao existirem perdas nos segmentos Burst existe mais probabilidade de serem perdas de congestão; nos outros segmentos, a probabilidade de serem perdas do meio de transmissão é bastante mais elevada. • Optimização do crescimento da janela; Determinar qual o melhor valor do RTT para crescer e a optimização do tamanho do crescimento da janela. • Adaptação para o kernel Linux. Só deve ser feita na fase final do desnevolvimento desta versão. É obrigatoriamente o caminho final de cada versão TCP, permitindo ao normal utilizador a sua utilização. 147
- 170. TCP em Redesde Elevado Débito 6.Conclusão Fazer parte da comuninade de investigação deste protocolo revela-se bastante motivador. Publicações de diversos conceitos são efectuadas e posteriormente melhoradas, na maioria das vezes, por grupos de investigação totalmente distintos. Este projecto segue toda a sua génese antecessora, iniciando e terminando com base em duas publicações. Outros passos intermédios passaram pela definição de uma alargada base de estudo, confirmação dos testes e posterior análise. A base de estudo tem uma preocupação acrescida para possíveis novos grupos de investigação nesta área, simplificando todo o necessário levantamento de recursos informativos e direccionado mais para toda a parte de implementação. Em relação aos testes permitiram um contacto mais prático com o protocolo TCP, fornecendo parâmetros acrescidos a toda a parte teórica estudada. Foi também a fase mais problemática de todo o projecto, o que obrigou a um esforço acrescido para a resolução dos mesmos. O objectivo principal desta nova versão, a versão EIC TCP, não é ser uma melhor opção do que qualquer uma das outras, mas sim fornecer novos caminhos de ajuda ao TCP no capítulo da aquisição de eficiência. Os posteriores testes da versão servem, essencialmente, como um ponto de situação do actual desenvolvimento da mesma e provavaram já alguma estabilidade na aquisição de eficiência. O TCP torna toda a Internet eficiente; a Internet devido à sua ajuda na globalização da informação, torna toda a investigação TCP eficiente. Assim se formou um ciclo que não se pretende ver terminado. 148
- 171. 7. Bibliografia 7.Bibliografia Livros [1] STEVENS.R. – TCP/IP Illustrated, Volume 1; Addison-Wesley Professional, ISBN 0201633469, 1993. [2] COMER. D. – Internetworking with TCP/IP, Fourth Edition; Prentice Hall, ISBN 0130183806, 2000. [3] TANENBAUM. A. – Computer Networks, Fourth Edition; Prentice Hall, ISBN 0130661023, 2002. [4] KOZIEROK. C. – The TCP/IP Guide, ISBN 159327047X, 2005, http://www.tcpipguide.com/ Artigos e Papers [5] YEE-TING, L.; LEITH, D.; SHORTEN L. – Experimental Evaluation of TCP Protocols for High-Speed Networks, Hamilton Institute, 2005. [6] NOUREDDINE, W.; TOBAGI, F. – Transmission Control Protocol, ICIR, 2002. [7] HOUSTON, G. – TCP Performance, The Internet Protocol Journal, Volume 3, Número 2, 2000. [8] HOUSTON, G. – The Future for TCP, The Internet Protocol Journal, Volume 3, Número 3, 2000. [9] HOUSTON, G. – Gigabit TCP, The Internet Protocol Journal, Volume 9, No. 2, Junho 2006. [10] KARN, P.; PARTRIDGE, C.; Estimating Round-Trip Times in Reliable Transport Protocols, Proceedings SIGCOMM’87, 1987. [11] JAIN, RAJ. – A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks, IEEE Journal, 1987. [12] MOGUL. J. – Observing TCP Dynamics in Real World, Western Research Laboratory, Research Report 92/2, 1992. [13] JABOBSON, V.; KARELS, M. – Congestion Avoidance and Control, Proceedings of SIGCOMM’88, 1988. 149
- 172. TCP em Redesde Elevado Débito [14] JACOBSON, V. – Modified TCP congestion avoidance algorithm, Mailing List end2end- interest@ISI.EDU, 1990. [15] BRAKMO, L.; O'MALLEY, S.; PETERSON L. – TCP Vegas: New techniques for congestion detection and avoidance, Proceedings of SIGCOMM’94, 1994. [16] AHN, J.; DANZIG, P.; LIE, Z.; YAM, L. – Evaluation of TCP Vegas: Emulation and Experiment, Proceedings of SIGCOMM’95, 1995. [17] BRAKMO, L., PETERSON. L. – TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communication, Volume 13, Número 8, 1995. [18] HENGARTNER U.; BOLLIGER J.; Gross, T. – TCP Vegas Revisited, INFOCOM00, 2000. [19] HOE, J. – Improving Startup-Behavior of a Congestion Control Scheme for TCP, Proceedings of SIGCOMM’96, 1996. [20] CAINI, C.; FIRRINCIELLI, R. – TCP Hybla: a TCP enhancement for heterogeneous networks, Internacional Journal of Sattelite Communications and Networking, 547–566, 2004. [21] FU, C.; LIEW, S. – TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks, IEEE Journal, Volume 91, Número 2, 2003. [22] KUZMANOVIC, A.; KNIGHTLY, E. – TCP-LP: A Distributed Algorithm for Low Priority Data Transfer, Rice University, 2003. [23] BIAZ, S.; VAYDIA, N. – Is the Roundtrip Time Correlated with the Number of Packets in Flight ?, Internet Measurement Conference 2003, 2003. [24] CROWROFT, J.; OECHCSLIN, P. – Differentiated End-to-End Internet Services Using a Weighted Proportional Fair Sharing TCP, ACM SIGCOMM Computer Communication Review, Volume 28, Número 3, 1998. [25] KELLY, T. – Scalable TCP: Improving Performance in High-Speed Wide Area Networks, ACM SIGCOMM Computer Communication Review, Volume 33, Número 2, 2003. [26] XU. L.; HARFOUSH, K.; RHEE. I. – Binary Increase Congestion Control (BIC) for Fast Long- Distance Networks, Proceedings of IEEE INFOCOMM 2004, 2004. [27] XU, L.; RHEE, I. – CUBIC: A New TCP-Friendly High-Speed TCP Variant, PFLDnet 2005, 2005. [28] GERLA, M.; SANADIDI, Y.; WANG, R.; ZANELLA, A.; CASSETI, C.; MASCOLO, S. – TCP Westwood: Congestion Window Control Using Bandwidth Estimation, Proceedings of IEEE Globecom 2001, Volume 3, 2001. 150
- 173. 7. Bibliografia [29] DELL’AERA,A.; GRECO, L. – Linux 2.4 Implementation of Westwood+ TCP with Rate- Halving: A Performance Evaluation over the Internet, Tech. Rep. Número 08/03/S, Politecnico di Bari. [30] JIN, C.; WEI, X.; LOW, S. – FAST TCP: Motivation, Architecture, Algorithms, Performance, Proceedings of IEEE INFOCOM 2004, 2004. [31] TAN, K.; JINGMIN, S.; ZHANG, Q.; SRIDHARAN, M. – A Compound TCP Approach for High-speed and Long Distance Networks, Microsoft Research Publications, 2005. [32] KATABI, D.; HANDLEY, M.; ROHRS, C. – Congestion Control for High Bandwidth-Delay Product Networks, ACM SIGCOMM Computer Communication Review, Volume 32, Número 4, 2002. [33] MEDINA, A.; FLOYD, S. – Measuring The Evolution of Protocol of Transport Protocols in the Internet, ICIR, 2004. [34] SMART, M; MALAN, G.; JAHANIAN F. – Defeating TCP/IP Stack Fingerprinting, 9th USENIX Security Symposium, 2000. [35] BULLOT, H.; COTTRELL, L; JONES, R. – Evaluation of Advanced TCP Stacks on Fast Long- Distance production Networks, PFLDnet 2004, 2004. [36] TIERNEY, B.; LEE, J. – Techniques for Testing Experimental Network Protocols, PFLDnet 2004, 2004. [37] MATTIS, M.; MAHDAVI, J. – Forward Acknowledgement: Refining TCP Congestion Control, Pittsburgh Supercomputer Center, 1996. RFC e drafts [38] POSTEL. J. – Transmission Control Protocol (RFC793), 1981, ftp://ftp.rfc-editor.org/in- notes/rfc793.txt [39] CLARK. D. – Window and Acknowledgment Strategy in TCP (RFC813), 1982, ftp://ftp.rfc- editor.org/in-notes/rfc813.txt [40] NAGLE. G. – Congestion control in IP/TCP internetworks (RFC896), 1984, ftp://ftp.rfc- editor.org/in-notes/rfc896.txt [41] BRADEN. R. – Requirements for Internet Hosts – Communication Layers (RFC1122), 1989, ftp://ftp.rfc-editor.org/in-notes/rfc1122.txt [42] JACOBSON, V.; BRADEN, R.; BORMAN, D. – TCP Extensions for High Perfomance (RFC1323), 1992, ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt 151
- 174. TCP em Redesde Elevado Débito [43] MATHIS, M.; MAHDAVI, J.; FLOYD, S.; ROMANOW, A. – TCP Selective Acknowledgment Options (RFC2018), 1996, ftp://ftp.rfc-editor.org/in-notes/rfc2018.txt [44] ALLMAN, M.; GLOVER, D.; SANCHEZ, L. – Enhancing TCP Over Satellite Channels using Standard Mechanisms (RFC2488), 1999, ftp://ftp.rfc-editor.org/in-notes/rfc2488.txt [45] ALLMAN, M. – TCP Congestion Control (RFC2581), 1999, ftp://ftp.rfc-editor.org/in- notes/rfc2581.txt [46] FLOYD, S.; HENDERSON, T. – The NewReno Modification to TCP’s Fast Recovery Algorithm (RFC2582), 1999, ftp://ftp.rfc-editor.org/in-notes/rfc2582.txt [47] FLOYD, S.; MAHDAVI, J.; MATHIS, M.; PODOLSKY, M. – An Extension to the Selective Acknowledgement (SACK) Option for TCP (RFC2883), 2000, ftp://ftp.rfc-editor.org/in- notes/rfc2883.txt [48] ALLMAN, M.; BALAKRISHNAN, H.; FLOYD S. – Enhancing TCP's Loss Recovery Using Limited Transmit (RFC3042), 2001, ftp://ftp.rfc-editor.org/in-notes/rfc3042.txt [49] RAMAKRISHNAN, K.; FLOYD, S.; BLACK, D. – The Addition of Explicit Congestion Notification (ECN) to IP (RFC3168), 2001, ftp://ftp.rfc-editor.org/in-notes/rfc3168.txt [50] ALLMAN, M.; FLOYD, S.; PARTRIDGE, C. – Increasing TCP's Initial Window (RFC3390), 2002, ftp://ftp.rfc-editor.org/in-notes/rfc3390.txt [51] FLOYD, S. – HighSpeed TCP for Large Congestion Windows (RFC3649), 2003, ftp://ftp.rfc- editor.org/in-notes/rfc3649.txt [52] FLOYD, S.; HENDERSON, T.; GURTOV, A. – The NewReno Modification to TCP's Fast Recovery Algorithm (RFC3782), 2004, ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt [53] KOHLER, E.; HANDLEY, M.; FLOYD S. – Datagram Congestion Control Protocol (DCCP) (RFC3782), 2006, ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt [54] FLOYD, S.; ALLMAN, M. – QuickStart for TCP and IP (RFC4782), 2007, ftp://ftp.rfc- editor.org/in-notes/rfc4782.txt [55] LEITH, S.; SHORTEN. R. – H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths, http://www.ietf.org/internet-drafts/draft-leith-tcp-htcp-03.txt Apresentações [56] LOUREIRO, P. – Diapositivos das aulas de Gestão Inteligente de Redes e Serviços, ESTG- Leiria, 2006. [57] VEIGA, N. – Diapositivos das aulas de Sistemas Operativos 2, ESTG-Leiria, 2003. 152
- 175. 7. Bibliografia [58] Prevençãoe controlo de congestão, Disciplina de Sistemas Telemáticos, Universidade do Minho, 2005. [59] LOW, S. – TCP Congestion Control: Algoritms & Models, IPAM, 2002. [60] NAVEEN, M. – TCP Variations, University of Delawan, 2005. [61] ANIRBAN, M. – Transmission Control Protocol, University of Calgary, 2004. [62] RAVOT, S. – TCP Transfers over high latency/bandwidth networks & Grid DT, PFLDnet, 2003. [63] PRASAD. R.; JAIN, M.; DOVROLIS, C. – On the Effect of Delay Based Congestion Avoidance, PFLDnet, 2004. [64] K. NAKAUCHI, K.; BOBAYASHI, K. – Studying Congestion Control with Explicit Router Feedback Using Hardware-based Network Emulator, PFLDnet, 2005. Websites [65] Bell 10Gbit/s Record, http://www.sciencedaily.com/releases/1999/05/990512000130.htm [66] NTT 14Tbit/s Record, http://arstechnica.com/news.ars/post/20061002-7878.html [67] IEC Tutorial, http://www.iec.org/online/tutorials/opt_ethernet/index.html [68] TCP Maintenance and Minor Extensions, http://tools.ietf.org/wg/tcpm/ [69] Transport Area Working Group, http://tools.ietf.org/wg/tsvwg/ [70] Lawrence Berkeley Laboratory, http://www.lbl.gov/ [71] Paco Alto Research Center, http://www.parc.xerox.com/about/pressroom/news/2006-11-20- contentcentric.html/ [72] IEEE, http://www.ieee.org/ [73] Special Interest Group, http://www.acm.org/sigs/guide98.html/ [74] SIGCOMM96, http://www.sigcomm.org/sigcomm96/program.html/ [75] ICSI, http://www.icsi.berkeley.edu/ [76] RED, http://en.wikipedia.org/wiki/Random_early_detection [77] PDLDnet 2003, http://datatag.web.cern.ch/datatag/pfldnet2003/ [78] PFLDnet 2004, http://www-didc.lbl.gov/PFLDnet2004/ [79] PFLDnet 2005, http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/ [80] PFLDnet 2006, http://www.hpcc.jp/pfldnet2006/ [81] IANA Assignments TCP header flags, http://www.iana.org/assignments/tcp-header-flags/ [82] IANA Assignments TCP parameters, http://www.iana.org/assignments/tcp-parameters/ [83] Ethereal, http://www.ethereal.com/ 153
- 176. TCP em Redesde Elevado Débito [84] Ethernet and TCP Throughput Model, http://www.babinszki.com/Networking/Max-Ethernet- and-TCP-Throughput.html/ [85] Description of Windows TCP features, http://support.microsoft.com/kb/224829/ [86] DEC, http://www.answers.com/topic/digital-equipment-corporation [87] Kubuntu, http://www.kubuntu.org/ [88] Xgraph, http://www.xgraph.org/ [89] Gnuplot, http://www.gnuplot.info/ [90] Tcpdump, http://www.tcpdump.org/ [91] Iperf, http://dast.nlanr.net/Projects/Iperf/ [92] Dummynet, http://freshmeat.net/projects/dummynet/ [93] Netem, http://linux-net.osdl.org/index.php/Netem/ [94] Trpr, http://pf.itd.nrl.navy.mil/protools/trpr.html/ [95] Internet Land Speed Record, http://www.internet2.edu/lsr/ [96] FreeBSD, http://www.freebsd.org/ [97] Wireshark, http://www.wireshark.org/ [98] How to Achieve Gigabit Speeds in Linux, http://datatag.web.cern.ch/datatag/howto/tcp.html/ [99] TOE, http://www.networkworld.com/details/653.html/ [100] TCP Tuning Guide, http://www-didc.lbl.gov/TCP-tuning/linux.html/ [101] Kernel Compilation Ubuntu, http://www.howtoforge.com/kernel_compilation_ubuntu/ NS2 [102] LUCIO, G.; FARRERA, M.; JAMMEH, E., FLEURY, M.; REED, M. – OPNET Modeler and Ns-2: Comparing the Accuracy of Network Simulators for Packet-Level Analysis using a Network Testbed, University of Essex, 2003. [103] NS2 Official Page, http://www.isi.edu/nsnam/ns/ [104] OPNET, http://www.opnet.com/ [105] X-SIM, http://nsr.bioeng.washington.edu/Software/XSIM/xsim_download.html/ [106] REIS, L.; VICENTE, M. –Tutorial Network Simulator, ESTG Leiria, 2006 [107] FALL, K.; VARADHAN, K. – The ns Manual, The VINT Project, 2006. 154
- 177. 7. Bibliografia [108] ALTMAN,E.; JIMENEZ, T. – NS Simulator for Begginers, University de Los Andes, 2003. [109] ANTILA, J. – TCP Perfomance Simulations using NS2, Helsinki University of Tecnology, 1999 [110] NS Simulator Course for Beginners, http://www.sop.inria.fr/mistral/personnel/Eitan.Altman/ns.htm/ [111] Pedro Vale Estrela – NS2, http://mega.ist.utl.pt/~pmsrve/ns2/ [112] Mark Greis’s Tutorial, http://www.isi.edu/nsnam/ns/tutorial/index.html/ [113] Linux TCP Implementation, http://www.cs.caltech.edu/~weixl/technical/ns2linux/index.html/ 155
- 178. TCP em Redesde Elevado Débito Anexos A.1. Planeamento A.1.1. Entregas Fase 1º Tipo de Entrega Múltipla Funcionamento Definição do âmbito do projecto e respectiva comunicação do mesmo. Atribuição de tarefas, gestão do tempo, recursos e comunicações Objectivo Principal Comunicação do planeamento de todo o projecto. Canal de Comunicação Reunião Fase 2º Tipo de Entrega Múltipla Funcionamento Nesta primeira fase inicial o estudo dos variados protocolos funcionará como entregas para cada reunião efectuada, servindo as entregas para esclarecimento de dúvidas, e orientação sobre o estudo efectuado e a efectuar. Objectivo Principal O controlo do âmbito de estudo. Canal de Comunicação Reunião 156
- 179. TAnexos Fase 3º Tipo deEntrega Única Funcionamento Após o estudo serão seleccionados os temas que se acharam mais relevantes, sendo posteriormente elaborado um índice com resumo acerca das ideias a abordar. Esse índice será sobre toda a parte teórica estudada e será debatido em reunião. Objectivo Principal Elaboração de um índice sobre toda a parte teórica estudada. Canal de Comunicação Reunião ou E-mail Fase 4º Tipo de Entrega Múltipla Funcionamento Os testes serão efectuados após todo o estudo teórico ser efectuado. A reunião inicial onde ficarão definidos os testes a serem efectuados é uma parte crucial, bem como a apresentação dos testes nas entregas posteriores. As possíveis dificuldades da confirmação teórica nos testes práticos serão responsáveis pela quantidade de entregas necessárias. Objectivo Principal Definição e apresentação dos testes. Canal de Comunicação Reunião Fase 5º Tipo de Entrega Única Funcionamento Tal como na segunda fase, após os testes práticos será elaborado um índice relativo, igualmente com resumos de ideias de toda a parte prática realizada. Objectivo Principal Elaboração de um índice sobre toda a parte prática (testes efectuados). 157
- 180. TCP em Redesde Elevado Débito Canal de Comunicação Reunião ou E-mail Fase 6º Tipo de Entrega Múltipla Funcionamento Esta entrega é a mais prioritária, será a entrega que vai especificar com base nos estudos teóricos, e posteriores testes práticos o novo protocolo TCP a implementar. Esta especificação deverá ficar definida e entregue o mais rapidamente possível, para posterior implementação. Porém devido a sua importância deverão ser feitas diversas entregas que deverão ser sujeitos a diversas correcções durante as reuniões. Objectivo Principal Especificação da nova versão do protocolo Canal de Comunicação Reunião Fase 7º Tipo de Entrega Múltipla Funcionamento Serão entregues diversas versões incompletas da implementação feita. As divergências entre o especificado e o código implementado serão o principal objecto de discussão. Objectivo Principal Controlo especificação/implementação Canal de Comunicação Reunião Fase 8º Tipo de Entrega Única Funcionamento Serão apresentados os resultado dos testes efectuados com a nova versão. Estes testes serão baseados nos já realizados para que possa existir uma comparação 158
- 181. TAnexos coerente. Objectivo Principal Apresentação dos testespráticos para a nova versão do protocolo. Canal de Comunicação Reunião Fase 9º Tipo de Entrega Única Funcionamento Inicio da fase de documentação acerca da fase de especificação, e posterior implementação e testes ao novo protocolo. Serão também incluídos resumos acerca dos temas a abordar em cada capítulo, tal como nas anteriores entregas de índices. Objectivo Principal Elaboração de um índice acerca do novo protocolo. Canal de Comunicação Reunião ou E-mail Fase 10º Tipo de Entrega Única Funcionamento O relatório preliminar será entregue nesta fase, sendo agora importante uma verificação de coerência, entre toda a documentação efectuada durante o projecto. Objectivo Principal Entrega do relatório preliminar. Canal de Comunicação Reunião ou E-mail Fase 11º 159
- 182. TCP em Redesde Elevado Débito Tipo de Entrega Única Funcionamento O relatório final será entregue nesta fase, ficando apenas por esclarecer detalhes de artigo, apresentação e poster. Objectivo Principal Entrega do relatório final. Canal de Comunicação Reunião ou E-mail A.1.2. WBS 1. Planeamento A Tarefa de planeamento de todo este projecto é crucial, na medida em que serve de orientação para todas as outras. 1.1 Gestão do Âmbito 1.2 WBS A Forma como é gerido o âmbito apesar de consumir algum tempo inicialmente, poderá poupar imenso a longo prazo, principalmente se as áreas de projecto forem variadas (como é o caso). A Decomposição de todo o projecto em tarefas mais simples e manejáveis. O WBS do projecto apenas tem 2 níveis hierárquicos. Esta situação acontece devido ao facto de ser um projecto bastante relacionado com a investigação, onde existe inicialmente algum desconhecimento sobre as tarefas envolvidas, limitando assim o seu detalhe. 1.3 Gestão do Tempo Afecta directamente o tempo dispendido nas diversas tarefas do projecto. 2. Estudo Geral Protocolo TCP Toda a base de estudo e principal investigação está concentrada nesta tarefa. 2.1 TCP Genérico 2.2 TCP Banda Larga O estudo relacionado com todo o tipo de algoritmos/mecanismos do TCP, nas suas versões O estudo específico de mecanismos/algoritmos relacionados com versões do TCP para banda 160
- 183. TAnexos mais genéricas. largae elevadas latências. 2.3 Verificação de Falhas 2.4 Filtragem Em cooperação com as tarefas de estudo, é necessário verificar o que poderá ser melhorado. Quando o estudo estiver numa fase mais madura, uma filtragem de todas as características/algoritmos/mecanismos, que poderão interessar para a especificação da nova versão do protocolo devem ser consideradas. 3. Documentação A tarefa de documentação será feita constantemente, de forma paralela às outras tarefas. Em todas as tarefas é muito importante a respectiva documentação, na medida em que vai ser uma das partes mais visíveis de todo o projecto. 3.1 Definição índice (parte teórica) 3.2 Definição índice (parte prática) A definição de um índice após o estudo, que irá documentar de forma estruturada, todo o estudo teórico necessário à compreensão do protocolo TCP. A definição de um índice após testes práticos, que irá documentar de forma estruturada, todos os testes práticos e posteriores análises. 3.3 Definição índice (nova versão do protocolo) 3.4 Definição da bibliografia A definição de um índice onde será abordada a especificação da nova versão do protocolo, bem como testes efectuados à nova versão. Existe variada bibliografia associada ao tema do projecto, a maior parte dela são artigos apresentados em diversas conferências. Esta tarefa tem o objectivo de filtrar a bibliografia mais relevante no que diz respeito ao tema TCP em banda larga. Uma definição dos recursos bibliográficos em relação ao TCP genérico também é bastante importante, em relação a esta área, existem já livros bastantes específicos. 3.5 Definição Esquemas 3.6 Escrita Através do estudo são analisados diversos esquemas e figuras explicativas. Alguns esquemas A escrita é sem dúvida a tarefa que irá consumir o maior espaço de tempo de todo o projecto. Irá 161
- 184. TCP em Redesde Elevado Débito têm o objectivo principal de elucidar da melhor forma sobre os diversos mecanismos/algoritmos responsáveis por todo o bom funcionamento do TCP. Esta tarefa tem como principal objectivo uma boa selecção de esquemas e figuras que se revelem importantes numa qualquer explicação de um mecanismo/algoritmo. Outro objectivo desta tarefa é a definição de esquemas e figuras de uma qualquer ideia, que se verifique ser a imagem uma das melhores forma de elucidação. principalmente relatar tudo o que foi estudado e efectuado. 4. Testes Tarefa representativa da primeira parte prática de todo este projecto. Os testes de verificação de funcionamento dos vários tipos de versões TCP são aqui abordados. 4.1 Linux 4.2 Plataforma NS2 Tarefa responsável pelos testes usando o sistema operativo Linux, PC ligados directamente em rede, um gerador de tráfego e um simulador de atraso. Tarefa responsável pelos testes a efectuar na plataforma de simulação NS2. 4.3 Aprendizagem das plataformas 4.4 Análise resultados obtidos O objectivo principal desta tarefa será a aprendizagem da plataforma NS, e suas linguagens de programação. Porém, a ambientação a aplicações de Linux, principalmente no que diz respeito à geração de tráfego, atraso e estatísticas também devem ser considerada nesta tarefa. Fase onde se deverá recorrer bastante à parte teórica com o objectivo de confirmar resultados e problemas de eficiência nas versões. 4.5 Análise do Código 162
- 185. TAnexos A análise docódigo das diversas versões implementadas é essencial para toda a compreensão da implementação de uma nova versão. A localização no diverso código dos algoritmos e mecanismos estudados na teórica é essencial nesta tarefa. 5. Nova Versão A fase de implementação aborda todas as tarefas relacionadas com a nova versão do protocolo que se pretende implementado. 5.1 Especificação 5.2 Implementação A definição de tudo o que vai ser esta nova versão. Toda a parte de programação necessária ao cumprimento da especificação é abordada nesta tarefa. 5.3 Testes Fase de controlo, e prova de tudo o que foi implementado. A.2. Novo Protocolo Neste anexo encontra-se o código inicial para a implementação de um novo protocolo TCP, baseado na versão Reno. Para incluir o código na compilação NS são necessários alguns passos: • No Makefile (directoria ns-2.30): Inserir Novo_Protocolo/Novo_Protocolo-end.o • Colocar a pasta Novo_Protocolo em ns-2.30 • Compilar: make ns • Pasta Novo_Protocolo: ns Novo_Protocolo-teste.tcl • Confirmar o resultado: nam out.nam A.2.1. Ficheiro novo_protocolo.cc #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/xcp/xcp-end-sys.cc,v 1.7 2005/02/03 18:27:12 haldar Exp $"; #endif 163
- 186. TCP em Redesde Elevado Débito #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include "ip.h" #include "tcp.h" #include "flags.h" #include "agent.h" #include "packet.h" #include "flags.h" #include "tcp-sink.h" #include "Novo_Protocolo.h" #include "random.h" #include "hdr_qs.h" #define TRACE 0 // when 0, we don't print any debugging info. int hdr_Novo_Protocolo::offset_; static class Novo_ProtocoloHeaderClass : public PacketHeaderClass { public: Novo_ProtocoloHeaderClass() : PacketHeaderClass("PacketHeader/Novo_Protocolo", sizeof(hdr_Novo_Protocolo)) { bind_offset(&hdr_Novo_Protocolo::offset_); } } class_Novo_Protocolohdr; static class Novo_ProtocoloRenoTcpClass : public TclClass { public: 164
- 187. TAnexos Novo_ProtocoloRenoTcpClass() : TclClass("Agent/TCP/Reno/Novo_Protocolo") {} TclObject*create(int, const char*const*) { return (new Novo_ProtocoloAgent()); } } class_Novo_Protocolo; static class Novo_ProtocoloSinkClass : public TclClass { public: Novo_ProtocoloSinkClass() : TclClass("Agent/TcpSink/Novo_ProtocoloSink") {} TclObject* create(int, const char*const*) { return (new Novo_ProtocoloSink(new Acker)); } } class_Novo_Protocolosink; Novo_ProtocoloAgent::Novo_ProtocoloAgent(): RenoTcpAgent(), shrink_cwnd_timer_(this) { ola = 1; printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); } void Novo_ProtocoloAgent::delay_bind_init_all() { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); TcpAgent::delay_bind_init_all(); } 165
- 188. TCP em Redesde Elevado Débito int Novo_ProtocoloAgent::delay_bind_dispatch(const char *varName, const char *localName, TclObject *tracer) { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); return TcpAgent::delay_bind_dispatch(varName, localName, tracer); } void Novo_ProtocoloAgent::recv(Packet *pkt, Handler*a){ printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); RenoTcpAgent::recv(pkt,a); } void Novo_ProtocoloAgent::opencwnd() { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); TcpAgent::opencwnd(); return; } void Novo_ProtocoloAgent::timeout(int tno) { printf("%s - %s - %d n",__FILE__,__FUNCTION__,__LINE__); RenoTcpAgent::timeout(tno); } 166
- 189. TAnexos void Novo_ProtocoloAgent::slowdown(int how) { printf("%s -%s - %d n",__FILE__,__FUNCTION__,__LINE__); TcpAgent::slowdown(how); } void Novo_ProtocoloAgent::output(int seqno, int reason) { printf("%s - %s - %d n",__FILE__,__FUNCTION__,__LINE__); //RenoTcpAgent::output(seqno, reason); int force_set_rtx_timer = 0; Packet* p = allocpkt(); hdr_tcp *tcph = hdr_tcp::access(p); hdr_flags* hf = hdr_flags::access(p); hdr_ip *iph = hdr_ip::access(p); int databytes = hdr_cmn::access(p)->size(); tcph->seqno() = seqno; tcph->ts() = Scheduler::instance().clock(); int is_retransmit = (seqno < maxseq_); // Mark packet for diagnosis purposes if we are in Quick-Start Phase if (qs_approved_) { hf->qs() = 1; } // store timestamps, with bugfix_ts_. From Andrei Gurtov. // (A real TCP would use scoreboard for this.) if (bugfix_ts_ && tss==NULL) { tss = (double*) calloc(tss_size_, sizeof(double)); if (tss==NULL) exit(1); } 167
- 190. TCP em Redesde Elevado Débito //dynamically grow the timestamp array if it's getting full if (bugfix_ts_ && window() > tss_size_* 0.9) { double *ntss; ntss = (double*) calloc(tss_size_*2, sizeof(double)); printf("resizing timestamp tablen"); if (ntss == NULL) exit(1); for (int i=0; i<tss_size_; i++) ntss[(highest_ack_ + i) % (tss_size_ * 2)] = tss[(highest_ack_ + i) % tss_size_]; free(tss); tss_size_ *= 2; tss = ntss; } if (tss!=NULL) tss[seqno % tss_size_] = tcph->ts(); tcph->ts_echo() = ts_peer_; tcph->reason() = reason; tcph->last_rtt() = int(int(t_rtt_)*tcp_tick_*1000); if (ecn_) { hf->ect() = 1; // ECN-capable transport } if (cong_action_ && (!is_retransmit || SetCWRonRetransmit_)) { hf->cong_action() = TRUE; // Congestion action. cong_action_ = FALSE; } /* Check if this is the initial SYN packet. */ if (seqno == 0) { if (syn_) { databytes = 0; curseq_ += 1; 168
- 191. TAnexos hdr_cmn::access(p)->size() = tcpip_base_hdr_size_; } if (ecn_){ hf->ecnecho() = 1; // hf->cong_action() = 1; hf->ect() = 0; } if (qs_enabled_) { hdr_qs *qsh = hdr_qs::access(p); // dataout is kilobytes queued for sending int dataout = (curseq_ - maxseq_ - 1) * (size_ + headersize()) / 1024; int qs_rr = rate_request_; if (qs_request_mode_ == 1) { // PS: Avoid making unnecessary QS requests // use a rough estimation of RTT in qs_rtt_ // to calculate the desired rate from dataout. if (dataout * 1000 / qs_rtt_ < qs_rr) { qs_rr = dataout * 1000 / qs_rtt_; } // qs_thresh_ is minimum number of unsent // segments needed to activate QS request if ((curseq_ - maxseq_ - 1) < qs_thresh_) { qs_rr = 0; 169
- 192. TCP em Redesde Elevado Débito } } if (qs_rr > 0) { // QuickStart code from Srikanth Sundarrajan. qsh->flag() = QS_REQUEST; qsh->ttl() = Random::integer(256); ttl_diff_ = (iph->ttl() - qsh->ttl()) % 256; qsh->rate() = hdr_qs::Bps_to_rate(qs_rr * 1024); qs_requested_ = 1; } else { qsh->flag() = QS_DISABLE; } } } else if (useHeaders_ == true) { hdr_cmn::access(p)->size() += headersize(); } hdr_cmn::access(p)->size(); /* if no outstanding data, be sure to set rtx timer again */ if (highest_ack_ == maxseq_) force_set_rtx_timer = 1; /* call helper function to fill in additional fields */ output_helper(p); ++ndatapack_; ndatabytes_ += databytes; send(p, 0); 170
- 193. TAnexos if (seqno ==curseq_ && seqno > maxseq_) idle(); // Tell application I have sent everything so far if (seqno > maxseq_) { maxseq_ = seqno; if (!rtt_active_) { rtt_active_ = 1; if (seqno > rtt_seq_) { rtt_seq_ = seqno; rtt_ts_ = Scheduler::instance().clock(); } } } else { ++nrexmitpack_; nrexmitbytes_ += databytes; } if (!(rtx_timer_.status() == TIMER_PENDING) || force_set_rtx_timer) /* No timer pending. Schedule one. */ set_rtx_timer(); } Novo_ProtocoloSink::Novo_ProtocoloSink(Acker* acker) : TcpSink(acker) { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); } 171
- 194. TCP em Redesde Elevado Débito void Novo_ProtocoloSink::recv(Packet* pkt, Handler*ha) { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); TcpSink::recv(pkt, ha); } int Novo_ProtocoloSink::command(int argc, const char*const* argv) { printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); return (TcpSink::command(argc, argv)); } void Novo_ProtocoloSink::ack(Packet* opkt){ printf("%s - %s - %dn",__FILE__,__FUNCTION__,__LINE__); TcpSink::ack(opkt); } A.2.2. Ficheiro novo_protocolo.h #ifndef ns_Novo_Protocolo_end_h #define ns_Novo_Protocolo_end_h #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include "ip.h" #include "tcp.h" #include "flags.h" #include "agent.h" 172
- 195. TAnexos #include "packet.h" #include "flags.h" #include"tcp-sink.h" //----------- The Congestion Header ------------// class Novo_ProtocoloAgent; struct hdr_Novo_Protocolo { int win_; double ack_time_; int packet_received; static int offset_; // offset for this header inline static int& offset() { return offset_; } inline static hdr_Novo_Protocolo* access(Packet* p) { return (hdr_Novo_Protocolo*) p->access(offset_); } }; class cwndShrinkingTimer : public TimerHandler { public: cwndShrinkingTimer(Novo_ProtocoloAgent *a) : TimerHandler() { a_ = a; } protected: virtual void expire(Event *e); Novo_ProtocoloAgent *a_; }; 173
- 196. TCP em Redesde Elevado Débito class Novo_ProtocoloAgent : public RenoTcpAgent { public: int ola; Novo_ProtocoloAgent(); virtual void recv(Packet *pkt, Handler*); virtual void opencwnd(); virtual void slowdown(int); virtual void timeout(int tno); protected: double time_now() { return Scheduler::instance().clock(); }; virtual void output(int seqno, int reason = 0); virtual void delay_bind_init_all(); virtual int delay_bind_dispatch(const char *varName, const char *localName, TclObject *tracer); void trace_var(char * var_name, double var); cwndShrinkingTimer shrink_cwnd_timer_; }; 174
- 197. TAnexos class Novo_ProtocoloSink :public TcpSink { public: Novo_ProtocoloSink(Acker* acker); void recv(Packet* pkt, Handler*); int command(int argc, const char*const* argv); virtual void ack(Packet* opkt); protected: }; #endif /* ns_Novo_Protocolo_end_h */ A.3. Scripts Neste anexo encontram-se os scripts com os cenários dos testes para se realizar as simulações. A.3.1. Cenário Simples Linux NS2 Implementation set ns [new Simulator] #ficheiros com a janelas de congestão #ficheiros com a largura de banda set lb [open "lb1 1000Gb 100ms 1-.tr" w] 175
- 198. TCP em Redesde Elevado Débito set winfile1 [open "winFile1 1000Gb 100ms 1-" w] # Especifica um procedimento 'finish' para término da simulação proc finish {} { close $lb close $winfile1 exit 0 } set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] $ns duplex-link $n1 $n2 1000Mb 5ms DropTail $ns duplex-link $n2 $n3 1000Mb 100ms DropTail $ns duplex-link $n3 $n4 1000Mb 5ms DropTail $ns queue-limit $n2 $n3 10000 set tcp1 [new Agent/TCP/Linux] $tcp1 set timestamps_ true $tcp1 set window_ 67108864 $ns at 0 "$tcp1 select_ca bic" $tcp0 set packetSize_ 1460 $ns attach-agent $n1 $tcp1 set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 set sink1 [new Agent/TCPSink/Sack1] $sink1 set ts_echo_rfc1323_ true 176
- 199. TAnexos $ns attach-agent $n6$sink1 $ns connect $tcp1 $sink1 proc record {} { global sink1 lb #Criar uma inst cia do simulador set ns [Simulator instance] #Define o tempo depois do qual o procedimento deve ser chamado novamente set time 0.9 #Quantos bytes foram recebidos pelos sinks? set bw1 [$sink1 set bytes_] #Obter o tempo actual set now [$ns now] #Calcular a largura de banda(MBit/s) e escrever nos ficheiros puts $lb "$now [expr $bw1/$time*8/1000000]" #Faz o reset aos bytes das fontes de traego (sink) $sink1 set bytes_ 0 $ns at [expr $now+$time] "record" } proc plotWindow {tcpSource file} { global ns set time 0.1 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } # Definir tempos dos geradores de trafego $ns at 0.0 "plotWindow $tcp1 $winfile1" 177
- 200. TCP em Redesde Elevado Débito $ns at 0.0 "record" $ns at 0.1 "$ftp1 start" $ns at 1199.9 "$ftp1 stop" # Processa o procedimento finish apos 1200 segundos de tempo de simulacao $ns at 1200 "finish" # Executa a simulacao $ns run A.3.2. Cenário Lumbbell set ns [new Simulator] #ficheiros com a janelas de congestão #ficheiros com a largura de banda set lb [open "lb1 1000Gb 100ms 1-.tr" w] set lbb [open "lb2 1000Gb 100ms 1-.tr" w] set lbt [open "lbt 1000Gb 100ms 1-.tr" w] set winfile1 [open "winFile1 1000Gb 100ms 1-" w] set winfile2 [open "winFile2 1000Gb 100ms 1-" w] # Especifica um procedimento 'finish' para término da simulação proc finish {} { close $lb close $lbb close $winfile1 close $winfile2 exit 0 } set n1 [$ns node] set n2 [$ns node] 178
- 201. TAnexos set n3 [$nsnode] set n4 [$ns node] set n5 [$ns node] set n6 [$ns node] $ns duplex-link $n1 $n3 1000Mb 5ms DropTail $ns duplex-link $n2 $n3 1000Mb 5ms DropTail $ns duplex-link $n3 $n4 1000Mb 100ms DropTail $ns duplex-link $n5 $n4 1000Mb 5ms DropTail $ns duplex-link $n6 $n4 1000Mb 5ms DropTail $ns queue-limit $n3 $n4 10000 $ns queue-limit $n1 $n3 10000 set tcp0 [new Agent/TCP/Reno/EIC] $tcp0 set window_ 67108864 $tcp0 set packetSize_ 1460 $ns attach-agent $n1 $tcp0 set tcp1 [new Agent/TCP/Linux] $tcp1 set timestamps_ true $tcp1 set window_ 67108864 $ns at 0 "$tcp1 select_ca bic" $tcp0 set packetSize_ 1460 $ns attach-agent $n2 $tcp1 set ftp0 [new Application/FTP] $ftp0 attach-agent $tcp0 set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 set sink0 [new Agent/TCPSink] 179
- 202. TCP em Redesde Elevado Débito $ns attach-agent $n5 $sink0 set sink1 [new Agent/TCPSink/Sack1] $sink1 set ts_echo_rfc1323_ true $ns attach-agent $n6 $sink1 $ns connect $tcp0 $sink0 $ns connect $tcp1 $sink1 proc record {} { global sink0 lb global sink1 lbb global all lbt #Criar uma inst cia do simulador set ns [Simulator instance] #Define o tempo depois do qual o procedimento deve ser chamado novamente set time 0.9 #Quantos bytes foram recebidos pelos sinks? set bw1 [$sink0 set bytes_] set bw2 [$sink1 set bytes_] set bwt [expr $bw1+$bw2] #Obter o tempo actual set now [$ns now] #Calcular a largura de banda(MBit/s) e escrever nos ficheiros puts $lb "$now [expr $bw1/$time*8/1000000]" puts $lbb "$now [expr $bw2/$time*8/1000000]" puts $lbt "$now [expr $bwt/$time*8/1000000]" #Faz o reset aos bytes das fontes de traego (sink) $sink0 set bytes_ 0 $sink1 set bytes_ 0 $ns at [expr $now+$time] "record" } 180
- 203. TAnexos proc plotWindow {tcpSourcefile} { global ns set time 0.1 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } # Definir tempos dos geradores de trafego $ns at 0.0 "plotWindow $tcp0 $winfile1" $ns at 0.0 "plotWindow $tcp1 $winfile2" $ns at 0.0 "record" $ns at 0.1 "$ftp0 start" $ns at 50 "$ftp1 start" $ns at 1199.9 "$ftp0 stop" $ns at 1199.9 "$ftp1 stop" # Processa o procedimento finish apos 1200 segundos de tempo de simulacao $ns at 1200 "finish" # Executa a simulacao $ns run A.3.3. Cenário Internet Este script tem como base outro script, anteriormente, efectuado em Stanford (ver http://yuba.stanford.edu/rcp/). Para se executar este script deve-se corer primeiro o ficheiro run.pl, depois o average.pl e por fim executar a última linha de código deste capítulo para criar o gráfico. Para correr a simulação deve-se correr o ficheiro run.pl. O conteúdo deste ficheiro encontra-se a seguir: 181
- 204. TCP em Redesde Elevado Débito #!/usr/bin/perl -w $numFlows = 100000; $cap = 1; $rtt = 0.1; $load = 0.8; $numbneck = 1; $BWdelay = ($rtt*$cap*1000000000)/(1000*8); $init_nr_flows = 100000; #$meanFlowSize = $BWdelay/1000; $meanFlowSize = 25; @pareto_shape = (1.6); #, 1.8, 2.2); for ($i = 0; $i < @pareto_shape; $i++) { `nice -n +20 ns sim-tcp-pareto.tcl $numFlows $cap $rtt $load $numbneck $init_nr_flows $meanFlowSize $pareto_shape[$i] > logFile`; `mv logFile logFile-pareto-sh$pareto_shape[$i]`; `mv flow.tr flow-pareto-sh$pareto_shape[$i].tr`; `mv queue.tr queue-pareto-sh$pareto_shape[$i].tr`; } O ficheiro tcl que contem o cenário deve chamar-se sim-tcp-pareto.tcl e o seguinte código é o seu conteúdo: Class TCP_pair TCP_pair instproc init {args} { $self instvar pair_id group_id id debug_mode $self instvar tcps tcpr;# Sender TCP, Receiver TCP eval $self next $args $self set tcps [new Agent/TCP/Linux] ;# Sender TCP $tcps select_ca highspeed 182
- 205. TAnexos $tcps set timestamps_true $tcps set window_ 67108864 $self set tcpr [new Agent/TCPSink/Sack1] ;# Receiver TCP $tcpr set ts_echo_rfc1323_ true $tcps set_callback $self $tcpr set_callback $self $self set pair_id 0 $self set group_id 0 $self set id 0 $self set debug_mode 1 #puts "init TCP_pair" } TCP_pair instproc set_debug_mode { mode } { $self instvar debug_mode $self set debug_mode $mode } TCP_pair instproc setup {snode dnode} { #Directly connect agents to snode, dnode. #For faster simulation. global ns link_rate $self instvar tcps tcpr;# Sender TCP, Receiver TCP $self instvar san dan ;# memorize dumbell node (to attach) $self set san $snode $self set dan $dnode $ns attach-agent $snode $tcps; $ns attach-agent $dnode $tcpr; 183
- 206. TCP em Redesde Elevado Débito $ns connect $tcps $tcpr #puts "setup TCP_pair" } TCP_pair instproc create_agent {} { $self instvar tcps tcpr;# Sender TCP, Receiver TCP $self set tcps [new Agent/TCP/Reno] ;# Sender TCP $self set tcpr [new Agent/TCPSink] ;# Receiver TCP #puts "create_agent TCP_pair" } TCP_pair instproc setup_wnode {snode dnode link_dly} { #New nodes are allocated for sender/receiver agents. #They are connected to snode/dnode with link having delay of link_dly. #Caution: If the number of pairs is large, simulation gets way too slow, #and memory consumption gets very very large.. #Use "setup" if possible in such cases. global ns link_rate $self instvar sn dn ;# Source Node, Dest Node $self instvar tcps tcpr;# Sender TCP, Receiver TCP $self instvar san dan ;# memorize dumbell node (to attach) $self instvar delay ;# local link delay $self set delay link_dly $self set sn [$ns node] $self set dn [$ns node] $self set san $snode $self set dan $dnode 184
- 207. TAnexos $ns duplex-link $snode$sn [set link_rate]Gb $delay DropTail $ns duplex-link $dn $dnode [set link_rate]Gb $delay DropTail $ns attach-agent $sn $tcps; $ns attach-agent $dn $tcpr; $ns connect $tcps $tcpr #puts "setup_wnode TCP_pair" } TCP_pair instproc set_fincallback { controller func} { $self instvar aggr_ctrl fin_cbfunc $self set aggr_ctrl $controller $self set fin_cbfunc $func #puts "set_fincallback TCP_pair" } TCP_pair instproc set_startcallback { controller func} { $self instvar aggr_ctrl start_cbfunc $self set aggr_ctrl $controller $self set start_cbfunc $func #puts "set_startcallback TCP_pair" } TCP_pair instproc setgid { gid } { $self instvar group_id $self set group_id $gid #puts "setgid TCP_pair" } TCP_pair instproc setpairid { pid } { $self instvar pair_id 185
- 208. TCP em Redesde Elevado Débito $self set pair_id $pid #puts "setpairid TCP_pair" } TCP_pair instproc setfid { fid } { $self instvar tcps tcpr $self instvar id $self set id $fid $tcps set fid_ $fid; $tcpr set fid_ $fid; #puts "setfid TCP_pair" } TCP_pair instproc set_debug_mode { mode } { $self instvar debug_mode $self set debug_mode $mode #puts "set_debug_mode TCP_pair" } TCP_pair instproc start { nr_pkts } { global ns $self instvar tcps id group_id $self instvar start_time pkts $self instvar aggr_ctrl start_cbfunc $self instvar pair_id $self instvar siz $self instvar debug_mode $self set start_time [$ns now] ;# memorize $self set pkts $nr_pkts ;# memorize set pktsize [$tcps set packetSize_] 186
- 209. TAnexos if { $debug_mode== 1 } { puts "stats: [$ns now] start grp $group_id fid $id $nr_pkts pkts ($pktsize +40)" } if { [info exists aggr_ctrl] } { $aggr_ctrl $start_cbfunc } #set c [new Application/FTP] #$c attach-agent $tcps #$ns at $start_time "$c send [expr $pktsize * $nr_pkts]" $self set siz [expr $pktsize * $nr_pkts] $tcps send $siz puts "start TCP_pair $start_time $siz" } TCP_pair instproc stop {} { $self instvar tcps tcpr $tcps reset $tcpr reset #puts "stop TCP_pair" } TCP_pair instproc fin_notify {} { global ns $self instvar sn dn san dan $self instvar tcps tcpr 187
- 210. TCP em Redesde Elevado Débito $self instvar aggr_ctrl fin_cbfunc $self instvar pair_id $self instvar pkts $self instvar dt $self instvar pps $self flow_finished $tcps reset $tcpr reset if { [info exists aggr_ctrl] } { $aggr_ctrl $fin_cbfunc $pair_id $pkts $dt $pps } #puts "fin_notify TCP_pair" } TCP_pair instproc flow_finished {} { global ns $self instvar start_time pkts id group_id $self instvar dt pps $self instvar debug_mode set ct [$ns now] $self set dt [expr $ct - $start_time] $self set pps [expr $pkts / $dt ] if { $debug_mode == 1 } { puts "stats: $ct fin grp $group_id fid $id fldur $dt sec $pps pps" } #puts "flow_finished TCP_pair" } 188
- 211. TAnexos Agent/TCP/Linux instproc set_callback{tcp_pair} { $self instvar ctrl $self set ctrl $tcp_pair #puts "set_callback Reno" } Agent/TCPSink/Sack1 instproc set_callback {tcp_pair} { $self instvar ctrl $self set ctrl $tcp_pair #puts "set_callback Reno" } Agent/TCP/Linux instproc done {} { global ns sink $self instvar ctrl #puts "[$ns now] $self fin-ack received"; if { [info exists ctrl] } { $ctrl fin_notify } #puts "done Reno " } Agent/TCPSink/Sack1 instproc done {} { global ns sink $self instvar ctrl #puts "[$ns now] $self fin-ack received"; if { [info exists ctrl] } { $ctrl fin_notify } #puts "done Reno " } 189
- 212. TCP em Redesde Elevado Débito Class Agent_Aggr_pair Agent_Aggr_pair instproc init {args} { eval $self next $args #puts "init Agent_Aggr_pair" } Agent_Aggr_pair instproc attach-logfile { logf logf1} { #Public $self instvar logfile logfile1 $self set logfile $logf $self set logfile1 $logf1 #puts "attach-logfile Agent_Aggr_pair" } Agent_Aggr_pair instproc setup {snode dnode gid nr agent_pair_type} { $self instvar apair ;# array of Agent_pair $self instvar group_id ;# group id of this group (given) $self instvar nr_pairs ;# nr of pairs in this group (given) $self set group_id $gid $self set nr_pairs $nr for {set i 0} {$i < $nr_pairs} {incr i} { $self set apair($i) [new $agent_pair_type] #$apair($i) setup_wnode $snode $dnode 0.01 $apair($i) setup $snode $dnode $apair($i) setgid $group_id ;# let each pair know our group id $apair($i) setpairid $i ;# let each pair know his pair id } $self resetvars ;# other initialization #puts "setup Agent_Aggr_pair" 190
- 213. TAnexos } Agent_Aggr_pair instproc init_schedule{} { #Public #Note: #Initially schedule flows for all pairs #according to the arrival process. global ns $self instvar nr_pairs apair for {set i 0} {$i < $nr_pairs} {incr i} { #### Callback Setting ######################## $apair($i) set_fincallback $self fin_notify $apair($i) set_startcallback $self start_notify ############################################### $self schedule $i } #puts "init_schedule Agent_Aggr_pair" } Agent_Aggr_pair instproc set_PParrival_process {lambda mean_npkts shape rands1 rands2} { #Public #setup random variable rv_flow_intval and rv_npkts. #To get the r.v. call "value" function. #ex) $rv_flow_intval value #- PParrival: #flow arrival: poissson with rate $lambda #flow length : pareto with mean $mean_npkts pkts and shape parameter $shape. 191
- 214. TCP em Redesde Elevado Débito $self instvar rv_flow_intval rv_npkts set pareto_shape $shape set rng1 [new RNG] $rng1 seed $rands1 $self set rv_flow_intval [new RandomVariable/Exponential] $rv_flow_intval use-rng $rng1 $rv_flow_intval set avg_ [expr 1.0/$lambda] set rng2 [new RNG] $rng2 seed $rands2 $self set rv_npkts [new RandomVariable/Pareto] $rv_npkts use-rng $rng2 $rv_npkts set avg_ $mean_npkts $rv_npkts set shape_ $pareto_shape #puts "set_PParrival_process Agent_Aggr_pair" } Agent_Aggr_pair instproc set_PEarrival_process {lambda mean_npkts rands1 rands2} { #setup random variable rv_flow_intval and rv_npkts. #To get the r.v. call "value" function. #ex) $rv_flow_intval value #- PEarrival #flow arrival: poissson with rate lambda #flow length : exp with mean mean_npkts pkts. $self instvar rv_flow_intval rv_npkts set rng1 [new RNG] 192
- 215. TAnexos $rng1 seed $rands1 $selfset rv_flow_intval [new RandomVariable/Exponential] $rv_flow_intval use-rng $rng1 $rv_flow_intval set avg_ [expr 1.0/$lambda] set rng2 [new RNG] $rng2 seed $rands2 $self set rv_npkts [new RandomVariable/Exponential] $rv_npkts use-rng $rng2 $rv_npkts set avg_ $mean_npkts #puts "set_PEarrival_process Agent_Aggr_pair" } Agent_Aggr_pair instproc set_PBarrival_process {lambda mean_npkts S1 S2 rands1 rands2} { #Public #setup random variable rv_flow_intval and rv_npkts. #To get the r.v. call "value" function. #ex) $rv_flow_intval value #- PParrival: #flow arrival: poissson with rate $lambda #flow length : pareto with mean $mean_npkts pkts and shape parameter $shape. $self instvar rv_flow_intval rv_npkts set rng1 [new RNG] $rng1 seed $rands1 $self set rv_flow_intval [new RandomVariable/Exponential] $rv_flow_intval use-rng $rng1 193
- 216. TCP em Redesde Elevado Débito $rv_flow_intval set avg_ [expr 1.0/$lambda] set rng2 [new RNG] $rng2 seed $rands2 $self set rv_npkts [new Binomial_RV] $rv_npkts use-rng $rng2 $rv_npkts set p_ [expr (1.0*$mean_npkts - $S2)/($S1-$S2)] $rv_npkts set S1_ $S1 $rv_npkts set S2_ $S2 if { $p < 0 } { puts "In PBarrival, prob for bimodal p_ is negative %p_ exiting.. " exit 0 } else { puts "# PBarrival S1: $S1 S2: $S2 p_: $p_ mean $mean_npkts" } #puts "set_PBarrival_process Agent_Aggr_pair" } Agent_Aggr_pair instproc resetvars {} { #Private #Reset variables $self instvar stat_nr_finflow ;# statistics nr of finished flows $self instvar stat_sum_fldur ;# statistics sum of finished flow durations $self instvar fid ;# current flow id of this group $self instvar last_arrival_time ;# last flow arrival time $self instvar actfl ;# nr of current active flow $self instvar stat_nr_arrflow ;# statistics nr of arrived flows $self instvar stat_nr_arrpkts ;# statistics nr of arrived packets $self set last_arrival_time 0.0 194
- 217. TAnexos $self set fid0 ;# flow id starts from 0 $self set stat_nr_finflow 0 $self set stat_sum_fldur 0.0 $self set stat_sum_pps 0.0 $self set actfl 0 $self set stat_nr_arrflow 0 $self set stat_nr_arrpkts 0 #puts "resetvars Agent_Aggr_pair" } Agent_Aggr_pair instproc schedule { pid } { #Private #Note: #Schedule pair (having pid) next flow time #according to the flow arrival process. global ns $self instvar apair $self instvar fid $self instvar last_arrival_time $self instvar rv_flow_intval rv_npkts $self instvar stat_nr_arrflow $self instvar stat_nr_arrpkts set dt [$rv_flow_intval value] set tnext [expr $last_arrival_time + $dt] set t [$ns now] if { $t > $tnext } { puts "Error, Not enough flows ! Aborting! pair id $pid" flush stdout 195
- 218. TCP em Redesde Elevado Débito exit } $self set last_arrival_time $tnext $apair($pid) setfid $fid incr fid set tmp_ [expr ceil ([$rv_npkts value])] incr stat_nr_arrflow $self set stat_nr_arrpkts [expr $stat_nr_arrpkts + $tmp_] $ns at $tnext "$apair($pid) start $tmp_" #puts "schedule at $tnext $pid $tmp_" } Agent_Aggr_pair instproc fin_notify { pid pkts fldur pps } { global ns $self instvar logfile $self instvar stat_sum_fldur stat_nr_finflow stat_sum_pps $self instvar group_id $self instvar actfl $self instvar apair #Here, we re-schedule $apair($pid). #according to the arrival process. $self set actfl [expr $actfl - 1] incr stat_nr_finflow $self set stat_sum_fldur [expr $stat_sum_fldur + $fldur] 196
- 219. TAnexos $self set stat_sum_pps[expr $stat_sum_pps + $pps] set fin_fid [$apair($pid) set id] ###### OUPUT STATISTICS ################# if { [info exists logfile] } { puts $logfile "flow_stats: [$ns now] gid $group_id fid $fin_fid pkts $pkts fldur $fldur avgfldur [expr $stat_sum_fldur/$stat_nr_finflow] actfl $actfl avgpps [expr $stat_sum_pps/$stat_nr_finflow] finfl $stat_nr_finflow" } $self schedule $pid ;# re-schedule a pair having pair_id $pid. #puts "fin_notify Agent_Aggr_pair" } Agent_Aggr_pair instproc start_notify {} { #Callback Function #Note: #If we registor $self as "setcallback" of #$apair($id), $apair($i) will callback this #function with argument id when the flow between the pair finishes. #i.e. #If we set: "$apair(13) setcallback $self" somewhere, #"start_notyf 13" is called when the $apair(13)'s flow is started. global ns $self instvar logfile1 $self instvar group_id $self instvar actfl incr actfl; if { [info exists logfile1] } { 197
- 220. TCP em Redesde Elevado Débito puts $logfile1 "flow_stats: [$ns now] gid $group_id actfl $actfl" } #puts "start_notify Agent_Aggr_pair" } Agent_Aggr_pair instproc statistics {} { $self instvar stat_nr_finflow ;# statistics nr of finished flows $self instvar stat_sum_fldur ;# statistics sum of finished flow durations $self instvar fid ;# current flow id of this group $self instvar last_arrival_time ;# last flow arrival time $self instvar actfl ;# nr of current active flow $self instvar stat_nr_arrflow ;# statistics nr of arrived flows $self instvar stat_nr_arrpkts ;# statistics nr of arrived packets puts "Aggr_pair statistics1: $self arrflows $stat_nr_arrflow finflow $stat_nr_finflow remain [expr $stat_nr_arrflow - $stat_nr_finflow]" puts "Aggr_pair statistics2: $self arrpkts $stat_nr_arrpkts avg_flowsize [expr $stat_nr_arrpkts/$stat_nr_arrflow]" #puts "statistics Agent_Aggr_pair" } #add/remove packet headers as required #this must be done before create simulator, i.e., [new Simulator] remove-all-packet-headers ;# removes all except common add-packet-header Flags IP TCP ;# hdrs reqd for TCP (Do not remove "Flags") set ns [new Simulator] puts "Date: [clock format [clock seconds]]" set sim_start [clock seconds] puts "Host: [exec uname -a]" 198
- 221. TAnexos #set tf [opentraceall.tr w] #$ns trace-all $tf #set nf [open out.nam w] #t$ns namtrace-all $nf if {$argc != 8} { puts "usage: ns xxx.tcl numflows link_rate(Gbps) RTT(per hop,sec) load numbneck init_nr_flows meanFlowSize pareto_shape" exit 0 } set numflows [lindex $argv 0] set link_rate [lindex $argv 1] set mean_link_delay [expr [lindex $argv 2] / 2.0] set load [lindex $argv 3] set numbneck 1 set init_nr_flow [lindex $argv 5] set mean_npkts [lindex $argv 6] set pareto_shape [lindex $argv 7] puts "Simulation input:" puts "TCP Single bottleneck" puts "numflows $numflows" puts "link_rate $link_rate Gbps" puts "RTT [expr $mean_link_delay * 2.0] sec" puts "load $load" puts "numbneck $numbneck" puts "init_nr_flow $init_nr_flow" puts "mean flow size $mean_npkts pkts" puts "pareto shape $pareto_shape" puts " " #packet size is in bytes. 199
- 222. TCP em Redesde Elevado Débito set pktSize 1460 puts "pktSize(payload) $pktSize Bytes" puts "pktSize(include header) [expr $pktSize + 40] Bytes" #Random Seed set arrseed 4 set pktseed 7 puts "arrseed $arrseed pktseed $pktseed" set lambda [expr ($link_rate*$load*1000000000)/($mean_npkts*($pktSize+40)*8.0)] puts "Arrival: Poisson with lambda $lambda, FlowSize: Pareto with avg $mean_npkts pkts shape $pareto_shape" set sim_end 200 puts "sim_end $sim_end sec (may not be reached)" #Only for TCP Agent/TCP/Reno set packetSize_ $pktSize #Agent/TCP set packetSize_ $pktSize set tcpwin_ [expr 4 * int (ceil (($mean_link_delay * 2.0 * $link_rate * 1000000000.0/8.0) / ($pktSize+40.0)))] Agent/TCP/Reno set window_ $tcpwin_ #Agent/TCP set window_ $tcpwin_ puts "Agent/TCP/Reno/CTN set window_ $tcpwin_" ############ Buffer SIZE ###################### #In case TCP , BWxRTT set queueSize [expr int (ceil (($mean_link_delay * 2.0 * $link_rate * 1000000000.0/8.0) / ($pktSize+40.0)))] Queue set limit_ $queueSize puts "queueSize $queueSize packets" 200
- 223. TAnexos ############# Topoplgy ######################### setn0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] $ns duplex-link $n0 $n1 [set link_rate]Gb 90ms DropTail $ns duplex-link $n2 $n0 [expr $link_rate*2]Gb 5ms DropTail $ns duplex-link $n1 $n3 [expr $link_rate*2]Gb 5ms DropTail $ns queue-limit $n1 $n0 $queueSize $ns queue-limit $n0 $n1 $queueSize set bnecklink [$ns link $n0 $n1] ############# Agents ######################### set agtagr0 [new Agent_Aggr_pair] puts "Creating initial $init_nr_flow agents ..."; flush stdout $agtagr0 setup $n2 $n3 0 $init_nr_flow "TCP_pair" #$agtagr0 setup $n0 $n1 0 $init_nr_flow "TCP_pair" set flowlog [open flow.tr w] set flowlog1 [open start.tr w] $agtagr0 attach-logfile $flowlog $flowlog1 puts "Initial agent creation done";flush stdout #For Poisson/Pareto $agtagr0 set_PParrival_process $lambda $mean_npkts $pareto_shape $arrseed $pktseed $agtagr0 init_schedule 201
- 224. TCP em Redesde Elevado Débito $agtagr0 statistics puts "Simulation started!" $ns at 0.0 "check_fin" proc check_fin {} { global ns agtagr0 numflows set nrf [$agtagr0 set stat_nr_finflow] if { $nrf > $numflows } { $agtagr0 statistics finish } #puts "nr_finflow $nrf" $ns after 1 "check_fin" } ############# Queue Monitor ######################### set qf [open queue.tr w] set qm [$ns monitor-queue $n0 $n1 $qf 0.1] $bnecklink queue-sample-timeout #$bnecklink start-tracing $ns at $sim_end "finish" proc finish {} { global ns qf flowlog global sim_start $ns flush-trace close $qf close $flowlog 202
- 225. TAnexos set t [clockseconds] puts "Simulation Finished!" puts "Time [expr $t - $sim_start] sec" puts "Date [clock format [clock seconds]]" exit 0 } $ns run Para analisar os ficheiros criados pelo script run.pl deve usar-se o ficheiro average.pl para este retirar os resultados. O ficheiro encontra-se a seguir: #!/usr/bin/perl -w @fNameIn = ("flow-pareto-sh1.6.tr"); @fNameOut = ("flowSizeVsDelay-sh1.6"); $maximum = 0; for ($i=0; $i<=$#fNameIn; $i++) { for ($j=0; $j< 10000000; $j++) { $sumDur[$j] = 0; $avgDur[$j] = 0; $maxDur[$j] = 0; $numFlows[$j] = 0; } open(fileOut, ">$fNameOut[$i]") or die("Can't open $fNameOut[$i] for writing: $!"); open(fileIn, "$fNameIn[$i]") or die ("Can't open $fNameIn[$i]: $!"); $maximum = 0; $simTime = 0; 203
- 226. TCP em Redesde Elevado Débito while (<fileIn>) { chomp; @items = split; if ($items[7] > $maximum) { $maximum = $items[7]; } $sumDur[$items[7]] += $items[9]; if ($items[9] > $maxDur[$items[7]]) { $maxDur[$items[7]] = $items[9]; } $numFlows[$items[7]] += 1; $avgDur[$items[7]] = $sumDur[$items[7]] / $numFlows[$items[7]]; } for ($j=1; $j<= $maximum; $j++) { if ($avgDur[$j] != 0) { printf fileOut "$j sum_ $sumDur[$j] numFlows_ $numFlows[$j] avg_ $avgDur[$j] max_ $maxDur[$j] n"; } } close(fileIn); close(fileOut); } Para fazer o gráfico através dos ficheiros gerados pelo average.pl deve usar-se a seguinte linha: cut -f1,7 -d" " flowSizeVsDelay-sh1.6 > grafico A.4. Código EIC TCP Nesta secção encontra-se o código alterado do protocolo. 204
- 227. TAnexos A.4.1. Ficheiro eic-end.cc #ifndeflint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/xcp/xcp-end-sys.cc,v 1.7 2005/02/03 18:27:12 haldar Exp $"; #endif #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include "ip.h" #include "tcp.h" #include "flags.h" #include "agent.h" #include "packet.h" #include "flags.h" #include "tcp-sink.h" #include "eic-end.h" #include "random.h" #include "hdr_qs.h" #define TRACE 0 // when 0, we don't print any debugging info. static class EicRenoTcpClass : public TclClass { public: EicRenoTcpClass() : TclClass("Agent/TCP/Reno/EIC") {} TclObject* create(int, const char*const*) { return (new EicAgent()); 205
- 228. TCP em Redesde Elevado Débito } } class_eic; EicAgent::EicAgent(): RenoTcpAgent() { max_cwnd_= 0; temp_max_cwnd_ = 1; max_cwnd_decreased_ = 0; } void EicAgent::reset() { /* Faz reset das variáveis do novo algoritmo e do TCP */ reset_variables(); TcpAgent::reset(); } /* Try to send as much data as the window will allow. The link layer will do the buffering; we ask the application layer for the size of the packets.*/ void EicAgent::send_much(int force, int reason, int maxburst) { /* Verifica se se está a utilizar o novo algoritmo e se todas as variáveis de controlo desactivas o que significa que se pode atribuir novo pacotes para serem bp e lp */ if(probe_algorithm_ == 1 && bp_seqno_ == -1 && lp_seqno_ == -1 && bp_rtt_ == -1 && lp_rtt_ == -1) { /* Calcula o tamanho do burst */ int burst_size = int(cwnd_*BURST_PERCENTAGE); /* memoriza o primeiro pacote do burst */ 206
- 229. TAnexos first_seqno_burst_ = t_seqno_; /*memoriza o pacote bp */ if(burst_size > MAX_BURST_PACKETS) bp_seqno_ t_seqno_ + MAX_BURST_PACKETS; else bp_seqno_ = t_seqno_ + burst_size; /* memoriza o pacote lp, caso seja menor ou igual ao pacote bp igual o lp ao pacote bp mais dois pacotes para o lp não fique antes do bp */ lp_seqno_ = t_seqno_ + int(cwnd_ * (1 - BURST_PERCENTAGE)/2); if(lp_seqno_ <= bp_seqno_) lp_seqno_ = bp_seqno_ + 2; } send_idle_helper(); int win = window(); int npackets = 0; if (!force && delsnd_timer_.status() == TIMER_PENDING) return; /* Save time when first packet was sent, for newreno --Allman */ if (t_seqno_ == 0) firstsent_ = Scheduler::instance().clock(); if (burstsnd_timer_.status() == TIMER_PENDING) return; while (t_seqno_ <= highest_ack_ + win && t_seqno_ < curseq_) { if (overhead_ == 0 || force || qs_approved_) { output(t_seqno_, reason); npackets++; if (QOption_) 207
- 230. TCP em Redesde Elevado Débito process_qoption_after_send () ; t_seqno_ ++ ; if (qs_approved_ == 1) { // delay = effective RTT / window double delay = (double) t_rtt_ * tcp_tick_ / win; if (overhead_) { delsnd_timer_.resched(delay + Random::uniform(overhead_)); } else { delsnd_timer_.resched(delay); } return; } } else if (!(delsnd_timer_.status() == TIMER_PENDING)) { /* * Set a delayed send timeout. */ delsnd_timer_.resched(Random::uniform(overhead_)); return; } win = window(); if (maxburst && npackets == maxburst) break; } /* call helper function */ send_helper(maxburst); } 208
- 231. TAnexos /* * open upthe congestion window */ void EicAgent::opencwnd() { double increment; /* Entra em na fase slowstart só se a janela for menor que o mínimo de pacotes */ if (cwnd_ < ssthresh_ && cwnd_ < MIN_PACKETS) { /* slow-start (exponential) */ cwnd_ += 1; /* Executa o código do Reno caso não se esteja a executar o novo algoritmo */ } else if(probe_algorithm_ == 0) { /* linear */ double f; switch (wnd_option_) { case 0: if (++count_ >= cwnd_) { count_ = 0; ++cwnd_; } break; case 1: /* This is the standard algorithm. */ increment = increase_num_ / cwnd_; if ((last_cwnd_action_ == 0 || last_cwnd_action_ == CWND_ACTION_TIMEOUT) && max_ssthresh_ > 0) { increment = limited_slow_start(cwnd_, 209
- 232. TCP em Redesde Elevado Débito max_ssthresh_, increment); } cwnd_ += increment; break; case 2: /* These are window increase algorithms * for experimental purposes only. */ /* This is the Constant-Rate increase algorithm * from the 1991 paper by S. Floyd on "Connections * with Multiple Congested Gateways". * The window is increased by roughly * wnd_const_*RTT^2 packets per round- trip time. */ f = (t_srtt_ >> T_SRTT_BITS) * tcp_tick_; f *= f; f *= wnd_const_; /* f = wnd_const_ * RTT^2 */ f += fcnt_; if (f > cwnd_) { fcnt_ = 0; ++cwnd_; } else fcnt_ = f; break; case 3: /* The window is increased by roughly * awnd_^2 * wnd_const_ packets per RTT, * for awnd_ the average congestion window. */ 210
- 233. TAnexos f = awnd_; f*= f; f *= wnd_const_; f += fcnt_; if (f > cwnd_) { fcnt_ = 0; ++cwnd_; } else fcnt_ = f; break; case 4: /* The window is increased by roughly * awnd_ * wnd_const_ packets per RTT, * for awnd_ the average congestion window. */ f = awnd_; f *= wnd_const_; f += fcnt_; if (f > cwnd_) { fcnt_ = 0; ++cwnd_; } else fcnt_ = f; break; case 5: /* The window is increased by roughly wnd_const_*RTT * packets per round-trip time, as discussed in * the 1992 paper by S. Floyd on "On Traffic * Phase Effects in Packet-Switched Gateways". */ 211
- 234. TCP em Redesde Elevado Débito f = (t_srtt_ >> T_SRTT_BITS) * tcp_tick_; f *= wnd_const_; f += fcnt_; if (f > cwnd_) { fcnt_ = 0; ++cwnd_; } else fcnt_ = f; break; case 6: /* binomial controls */ cwnd_ += increase_num_ / (cwnd_*pow(cwnd_,k_parameter_)); break; case 8: /* high-speed TCP, RFC 3649 */ increment = increase_param(); if ((last_cwnd_action_ == 0 || last_cwnd_action_ == CWND_ACTION_TIMEOUT) && max_ssthresh_ > 0) { increment = limited_slow_start(cwnd_, max_ssthresh_, increment); } cwnd_ += increment; break; default: #ifdef notdef /*XXX*/ error("illegal window option %d", wnd_option_); #endif abort(); 212
- 235. TAnexos } /* Executa ocódigo para aumentar a janela de congestão caso as variáveis lp_rtt_ e bp_rtt_ contenham os RTT calculados */ } else if(lp_rtt_ > -1 && bp_rtt_ > -1) { int burst_size = 0, loose_packets = 0; double rtt_diference = lp_rtt_/bp_rtt_; /* Aumenta a janela de congestão de acordo com o valor da diferença dos RTT lp por bp */ if(rtt_diference < 0.9972847) { cwnd_ = cwnd_ * 3; if(cwnd_ > max_cwnd_ && temp_max_cwnd_ == 0) { cwnd_ = max_cwnd_; temp_max_cwnd_ = 1; } } else if(rtt_diference <= 1) { cwnd_ = cwnd_ * 2; if(cwnd_ > max_cwnd_ && temp_max_cwnd_ == 0) { cwnd_ = max_cwnd_; temp_max_cwnd_ = 1; } } else if(rtt_diference < 1.05) 213
- 236. TCP em Redesde Elevado Débito cwnd_ = cwnd_ * 1.1; else if(rtt_diference < 1.115) cwnd_ = cwnd_ * 1.01; else cwnd_++; /* Indica que já se pode calcular um novo máximo caso haja perdas de pacotes e se a cwnd_ já tenha sido passada altera a temp_max_cwnd_ a indicar que o máximo já foi passado */ max_cwnd_decreased_ = 0; if(temp_max_cwnd_ == 0 && cwnd_ > max_cwnd_) temp_max_cwnd_ = 1; /* Bloco de código para calcular o número de pacotes a serem enviados mais espaçados */ if((burst_size = int(cwnd_*BURST_PERCENTAGE)) > MAX_BURST_PACKETS) loose_packets = int(cwnd_) - MAX_BURST_PACKETS; else loose_packets = int(cwnd_) - burst_size; /* Bloco de código que determina o espaçamento em tempo entre pacotes enviados mais espaçados */ if(lp_rtt_ > bp_rtt_) packet_delay_ = lp_rtt_/loose_packets; else packet_delay_ = bp_rtt_/loose_packets; 214
- 237. TAnexos /* reinicia asvariaveis lp_rtt_ e bp_rtt_ */ lp_rtt_ = -1; bp_rtt_ = -1; } // if maxcwnd_ is set (nonzero), make it the cwnd limit if (maxcwnd_ && (int(cwnd_) > maxcwnd_)) cwnd_ = maxcwnd_; return; } void EicAgent::recv(Packet *pkt, Handler*a) { hdr_tcp *tcph = hdr_tcp::access(pkt); int valid_ack = 0; if (qs_approved_ == 1 && tcph->seqno() > last_ack_) endQuickStart(); if (qs_requested_ == 1) processQuickStart(pkt); #ifdef notdef if (pkt->type_ != PT_ACK) { fprintf(stderr, "ns: confiuration error: tcp received non-ackn"); exit(1); } #endif /* W.N.: check if this is from a previous incarnation */ if (tcph->ts() < lastreset_) { // Remove packet and do nothing 215
- 238. TCP em Redesde Elevado Débito Packet::free(pkt); return; } ++nackpack_; ts_peer_ = tcph->ts(); if (hdr_flags::access(pkt)->ecnecho() && ecn_) ecn(tcph->seqno()); recv_helper(pkt); recv_frto_helper(pkt); if (tcph->seqno() > last_ack_) { if (last_cwnd_action_ == CWND_ACTION_DUPACK) last_cwnd_action_ = CWND_ACTION_EXITED; dupwnd_ = 0; recv_newack_helper(pkt); if (last_ack_ == 0 && delay_growth_) { cwnd_ = initial_window(); } } else if (tcph->seqno() == last_ack_) { if (hdr_flags::access(pkt)->eln_ && eln_) { tcp_eln(pkt); return; } if (++dupacks_ == numdupacks_) { dupack_action(); if (!exitFastRetrans_) dupwnd_ = numdupacks_; } else if (dupacks_ > numdupacks_ && (!exitFastRetrans_ || last_cwnd_action_ == CWND_ACTION_DUPACK )) { ++dupwnd_; // fast recovery } else if (dupacks_ < numdupacks_ && singledup_ ) { send_one(); } 216
- 239. TAnexos } if (tcph->seqno() >=last_ack_) // Check if ACK is valid. Suggestion by Mark Allman. valid_ack = 1; /* Se houver acks duplicados ou a cwnd_ for demasiado pequena faz-se reset das variaveis que indica que não se está a usar o algoritmo e permite-se transmitir, senão se não se estiver a utilizar o novo algoritmo indica-se que se deve entrar no algoritmo */ if(dupacks_ == numdupacks_ || cwnd_ < MIN_PACKETS) { reset_variables(); transmit_ = 1; } else if(probe_algorithm_ == 0) { enter_probe_algorithm_ = 1; transmit_ = 0; } /* Entra-se no algoritmo se o código imediatamente acima indicar para entrar no novo algoritmo e se o último ack for recebido ou então se se já estiver a correr o novo algoritmo */ if((enter_probe_algorithm_ == 1 && t_seqno_ == highest_ack_+1) || probe_algorithm_ == 1){ /* Muda a variavel que indica que se está no novo algoritmo e permite-se a transmição */ probe_algorithm_ = 1; transmit_ = 1; /* So executa este bocado de código se a variável lp_seqno_ estiver desactivada */ 217
- 240. TCP em Redesde Elevado Débito if(lp_seqno_ > -1) { /* Se o número de sequência do pacote recebido for maior ou igual do que o número de sequência do primeiro pacote enviado em burst pára de enviar pacotes para a rede e entra na fase de burst */ if(tcph->seqno() >= first_seqno_burst_) { transmit_ = 0; burst_phase_ = 1; } /* Verifica se a variável bp_seqno_ está desactiva e se o número de sequência do pacote recebido é o pacote bp, se isto se verificar calcula o RTT deste pacote e desactiva a variável bp_seqno_ */ if(bp_seqno_ > -1 && tcph->seqno() >= bp_seqno_) { bp_rtt_ = time_now() - tcph->ts_echo(); bp_seqno_ = -1; } /* Se o número de sequência do pacote recebido for maior ou igual ao número de sequência do lp calcula o RTT do lp, reinicia as variàveis que controlam a fase de burst para voltar a enviar pacotes espassados e chama a função que aumenta a janela de congestão */ if(tcph->seqno() >= lp_seqno_) { lp_rtt_ = time_now() - tcph->ts_echo(); lp_seqno_ = -1; 218
- 241. TAnexos first_seqno_burst_ = - 1; burst_phase_= 1; opencwnd(); } } } Packet::free(pkt); #ifdef notyet if (trace_) plot(); #endif /* * Try to send more data */ if (valid_ack || aggressive_maxburst_) if (dupacks_ == 0 || dupacks_ > numdupacks_ - 1) /* Só transmite caso o algoritmo permita, pois pode estar na fase de burst e ai não pode enviar */ if(transmit_ == 1) send_much(0, 0, maxburst_); } void EicAgent::timeout(int tno) { reset_variables(); RenoTcpAgent::timeout(tno); } 219
- 242. TCP em Redesde Elevado Débito void EicAgent::output(int seqno, int reason) { int force_set_rtx_timer = 0; Packet* p = allocpkt(); hdr_tcp *tcph = hdr_tcp::access(p); hdr_flags* hf = hdr_flags::access(p); hdr_ip *iph = hdr_ip::access(p); int databytes = hdr_cmn::access(p)->size(); tcph->seqno() = seqno; tcph->ts() = Scheduler::instance().clock(); int is_retransmit = (seqno < maxseq_); // Mark packet for diagnosis purposes if we are in Quick-Start Phase if (qs_approved_) { hf->qs() = 1; } // store timestamps, with bugfix_ts_. From Andrei Gurtov. // (A real TCP would use scoreboard for this.) if (bugfix_ts_ && tss==NULL) { tss = (double*) calloc(tss_size_, sizeof(double)); if (tss==NULL) exit(1); } //dynamically grow the timestamp array if it's getting full if (bugfix_ts_ && window() > tss_size_* 0.9) { double *ntss; ntss = (double*) calloc(tss_size_*2, sizeof(double)); printf("resizing timestamp tablen"); if (ntss == NULL) exit(1); for (int i=0; i<tss_size_; i++) ntss[(highest_ack_ + i) % (tss_size_ * 2)] = 220
- 243. TAnexos tss[(highest_ack_ + i)% tss_size_]; free(tss); tss_size_ *= 2; tss = ntss; } if (tss!=NULL) tss[seqno % tss_size_] = tcph->ts(); tcph->ts_echo() = ts_peer_; tcph->reason() = reason; tcph->last_rtt() = int(int(t_rtt_)*tcp_tick_*1000); if (ecn_) { hf->ect() = 1; // ECN-capable transport } if (cong_action_ && (!is_retransmit || SetCWRonRetransmit_)) { hf->cong_action() = TRUE; // Congestion action. cong_action_ = FALSE; } /* Check if this is the initial SYN packet. */ if (seqno == 0) { if (syn_) { databytes = 0; curseq_ += 1; hdr_cmn::access(p)->size() = tcpip_base_hdr_size_; } if (ecn_) { hf->ecnecho() = 1; // hf->cong_action() = 1; hf->ect() = 0; } 221
- 244. TCP em Redesde Elevado Débito if (qs_enabled_) { hdr_qs *qsh = hdr_qs::access(p); // dataout is kilobytes queued for sending int dataout = (curseq_ - maxseq_ - 1) * (size_ + headersize()) / 1024; int qs_rr = rate_request_; if (qs_request_mode_ == 1) { // PS: Avoid making unnecessary QS requests // use a rough estimation of RTT in qs_rtt_ // to calculate the desired rate from dataout. if (dataout * 1000 / qs_rtt_ < qs_rr) { qs_rr = dataout * 1000 / qs_rtt_; } // qs_thresh_ is minimum number of unsent // segments needed to activate QS request if ((curseq_ - maxseq_ - 1) < qs_thresh_) { qs_rr = 0; } } if (qs_rr > 0) { // QuickStart code from Srikanth Sundarrajan. qsh->flag() = QS_REQUEST; 222
- 245. TAnexos qsh->ttl() = Random::integer(256); ttl_diff_ =(iph->ttl() - qsh->ttl()) % 256; qsh->rate() = hdr_qs::Bps_to_rate(qs_rr * 1024); qs_requested_ = 1; } else { qsh->flag() = QS_DISABLE; } } } else if (useHeaders_ == true) { hdr_cmn::access(p)->size() += headersize(); } hdr_cmn::access(p)->size(); /* if no outstanding data, be sure to set rtx timer again */ if (highest_ack_ == maxseq_) force_set_rtx_timer = 1; /* call helper function to fill in additional fields */ output_helper(p); ++ndatapack_; ndatabytes_ += databytes; double delay = 0; /* Variavel que vai guardar o tempo que o pacote terá de esperar ate ser novamente enviado */ /* Se a variavel packet_delay_ for maior que 0 e se se não estiver na fase de burst significa que ter-se-á de calcular o tempo que se deve adiar o envio do pacote */ 223
- 246. TCP em Redesde Elevado Débito if(packet_delay_ > 0 && burst_phase_ == 0) { /* O tempo do adiamento do pacote é igual ao tempo em que o pacote BP foi enviado mais o atraso entre pacotes menos o tamanho do burst menos o tempo actual */ delay = (bp_sent_time_ + (packet_delay_ * (t_seqno_ - bp_seqno_))) - time_now(); /* Se o atraso for negativo significa que o tempo de enviar o pacote já passou então deve-se mandar o pacote imediatamente */ if(delay < 0) delay = 0; } /* Se o atraso for igual a 0 ou se se estiver em fase de busr deve-se enviar imediatamente o pacote, senão introduz-se no pacote TCP no campo ts o tempo em que o pacote vai ser enviado e agenda-se o pacote para ser enviado nessa altura */ if(delay == 0 || burst_phase_ == 1) { /* Se o pacote a enviar for o pacote bp acaba-se a fase de busrt e guarda-se o tempo actual */ if(t_seqno_ == bp_seqno_) { burst_phase_ = 0; bp_sent_time_ = time_now(); } send(p, 0); } else if(delay > 0) { tcph->ts() = time_now() + delay; Scheduler::instance().schedule(target_, p, delay); } 224
- 247. TAnexos if (seqno ==curseq_ && seqno > maxseq_) idle(); // Tell application I have sent everything so far if (seqno > maxseq_) { maxseq_ = seqno; if (!rtt_active_) { rtt_active_ = 1; if (seqno > rtt_seq_) { rtt_seq_ = seqno; rtt_ts_ = Scheduler::instance().clock(); } } } else { ++nrexmitpack_; nrexmitbytes_ += databytes; } if (!(rtx_timer_.status() == TIMER_PENDING) || force_set_rtx_timer) /* No timer pending. Schedule one. */ set_rtx_timer(); } /* * Dupack-action: what to do on a DUP ACK. After the initial check * of 'recover' below, this function implements the following truth * table: * * bugfix ecn last-cwnd == ecn action * 225
- 248. TCP em Redesde Elevado Débito * 0 0 0 reno_action * 0 0 1 reno_action [impossible] * 0 1 0 reno_action * 0 1 1 retransmit, return * 1 0 0 nothing * 1 0 1 nothing [impossible] * 1 1 0 nothing * 1 1 1 retransmit, return */ void EicAgent::dupack_action() { /* Executa se a janela tiver aumentado, estipulando o máximo que a janela de congetão pode crescer para não aumentar demasiado rápido transmitindo mais que a capacidade da rede */ if(max_cwnd_decreased_ == 0) { max_cwnd_ = cwnd_*2/3; temp_max_cwnd_ = 0; max_cwnd_decreased_ = 1; } int recovered = (highest_ack_ > recover_); int allowFastRetransmit = allow_fast_retransmit(last_cwnd_action_); if (recovered || (!bug_fix_ && !ecn_) || allowFastRetransmit || (bugfix_ss_ && highest_ack_ == 0)) { // (highest_ack_ == 0) added to allow Fast Retransmit // when the first data packet is dropped. // From bugreport from Mark Allman. goto reno_action; } 226
- 249. TAnexos if (ecn_ &&last_cwnd_action_ == CWND_ACTION_ECN) { last_cwnd_action_ = CWND_ACTION_DUPACK; /* * What if there is a DUPACK action followed closely by ECN * followed closely by a DUPACK action? * The optimal thing to do would be to remember all * congestion actions from the most recent window * of data. Otherwise "bugfix" might not prevent * all unnecessary Fast Retransmits. */ reset_rtx_timer(1,0); output(last_ack_ + 1, TCP_REASON_DUPACK); dupwnd_ = numdupacks_; return; } if (bug_fix_) { /* * The line below, for "bug_fix_" true, avoids * problems with multiple fast retransmits in one * window of data. */ return; } reno_action: // we are now going to fast-retransmit and will trace that event trace_event("RENO_FAST_RETX"); recover_ = maxseq_; last_cwnd_action_ = CWND_ACTION_DUPACK; slowdown(CLOSE_SSTHRESH_HALF|CLOSE_CWND_HALF); 227
- 250. TCP em Redesde Elevado Débito reset_rtx_timer(1,0); output(last_ack_ + 1, TCP_REASON_DUPACK); // from top dupwnd_ = numdupacks_; return; } /** Função que reinicia todas as variaveis utilizadas para fazer o controlo do algoritmo */ void EicAgent::reset_variables() { bp_rtt_ = -1; bp_seqno_ = -1; first_seqno_burst_ = -1; lp_rtt_ = -1; lp_seqno_ = -1; packet_delay_ = 0; transmit_ = 0; probe_algorithm_ = 0; enter_probe_algorithm_ = 0; burst_phase_ = 0; bp_sent_time_ = 0; } A.4.2. Ficheiro eic-end.h #ifndef ns_eic_end_h #define ns_eic_end_h 228
- 251. TAnexos #include <stdio.h> #include <stdlib.h> #include<sys/types.h> #include "ip.h" #include "tcp.h" #include "flags.h" #include "agent.h" #include "packet.h" #include "flags.h" #include "tcp-sink.h" class EicAgent; class EicAgent : public RenoTcpAgent { public: EicAgent(); protected: double bp_rtt_; /* (bp = burst probe) RTT measured from the probe sent in burst */ int bp_seqno_; /* (bp = burst probe) sequence number of the probe sent in burst */ int first_seqno_burst_; /* primeiro pacote enviado em burst */ double lp_rtt_; /* (lp = loose probe) RTT measured from the probe sent more loosly */ int lp_seqno_; /* (lp = loose probe) sequence number of the probe sent more loosly */ 229
- 252. TCP em Redesde Elevado Débito #define BURST_PERCENTAGE 0.3 /* Percentagem de pacotes sent in burst */ #define MAX_BURST_PACKETS 8 /* Percentagem de pacotes sent more loosly */ #define LP_PACKET 100 /* Percentagem de pacotes sent more loosly */ #define MIN_PACKETS 5 /* Minimo de pacotes para iniciar o novo algoritmo */ double packet_delay_; /* delay betwen loosly sent packets */ int transmit_; /* Valores 0 ou 1 a indicar se se pode transmitir pacotes ou se está a chegar o burst */ int probe_algorithm_; /* Valores 0 ou 1 a indicar se se usa o novo algoritmo */ int enter_probe_algorithm_; /* Valores 0 ou 1 a indicar se se pode entrar no algoritmo */ int burst_phase_; /* Valores 0 ou 1 a indicar se se está na fase de burst */ double bp_sent_time_; /* instante de tempo em que a sonda de burst foi enviada */ double max_cwnd_; /* Variavel que guarda o maximo que a cwnd_ atingiu antes de haver uma perda */ int temp_max_cwnd_; /* Variavel 0 ou 1 e indica se o maximo já foi usado */ int max_cwnd_decreased_; /* Variavel 0 ou 1 e indica se se pode recalcular o maximo */ /* Função que faz reset das variáveis do novo algoritmo e TCP */ virtual void reset(); /* Função que devolve o tempo actual */ double time_now() { return Scheduler::instance().clock(); }; /* Função que controla como enviar os pacotes para a rede */ virtual void output(int seqno, int reason = 0); /* Função que determina as sondas e verifica até que pacote se pode enviar */ 230
- 253. TAnexos virtual void send_much(intforce, int reason, int maxburst); /* Função onde se calcula o máximo sempre que há necessidade de calcular o máximo actual da rede */ virtual void dupack_action(); /* Função que ao receber os pacotes verifica se se trata dos segmentos lp ou bp e em caso afirmativo calcula os rtts */ virtual void recv(Packet *pkt, Handler*); /* Função que contem o codigo do Reno e do novo algoritmo para aumentar a janela */ virtual void opencwnd(); /* Função que ao ocurrer timeout reinicia as variaveis do novo algoritmo */ virtual void timeout(int tno); /* Função que reinicia as variáveis */ void reset_variables(); }; #endif /* ns_eic_end_h */ 231