Análise de Desempenho de Algoritmos de Controle de Congestionamento TCP utilizando o simulador NS-2
-
Upload
felipe-alex -
Category
Internet
-
view
236 -
download
4
description
Transcript of Análise de Desempenho de Algoritmos de Controle de Congestionamento TCP utilizando o simulador NS-2
ALUNO: FELIPE ALEX MARTINS DE SOUZA ORIENTADOR: PROF. MARCOS DANTAS ORTIZ
Motivação Introdução Objetivos (Geral e especifico) Referencial Teórico Procedimentos Metodológicos Configuração dos Cenários Análise dos cenários Conclusão Referências
2
Auxiliará um administrador de rede na escolha de qual algoritmo de controle de congestionamento utilizar.
melhor desempenho para cada tipo de congestionamento identificado.
3
Aumento de dispositivos = Aumento de demanda
Criação de protocolos mais sofisticados
Envio de dados > capacidade de processamento
Congestionamento ▪ Camada de Rede e Transporte (TCP)
4
Identificar entre os algoritmos de congestionamento TCP qual algoritmo apresenta melhor desempenho no controle de congestionamento em diferentes cenários.
5
Criar cenários de rede com aspectos que podem afetar ou não a avaliação de desempenho (fatores) e valores usados para cada um dos fatores (níveis) diferentes.
Implantar, configurar e utilizar o ambiente do simulador NS2 para a execução dos cenários de rede.
Avaliar os algoritmos de congestionamento TCP
através dos resultados obtidos das simulações.
6
PROTOCOLO TCP
CONTROLE DE CONGESTIONAMENTO Algoritmos de controle de congestionamento TCP
▪ TCP TAHOE ▪ TCP RENO ▪ TCP VEGAS ▪ TCP NEWRENO ▪ TCP SACK ▪ TCP FACK
SIMULAÇÃO Simulador Network Simulator (NS-2)
7
Orientado a conexão Entrega confiável
8
Envio de dados > capacidade de processamento Timeout, ACKs Duplicados.
Limitar o Envio de dados pelo emissor diminuindo a sua taxa de transmissão;
Criação de Algoritmos de Congestionamento
TCP Tahoe, TCP Reno, TCP Vegas, TCP NewReno, TCP Sack, TCP Fack.
9
Primeiro algoritmo de congestionamento.
Slow Start(Inicialização Lenta)
Janela de Congestionamento CWND
Congestionamento detectado = Slow Start e Congestion Avoidance
10
Resolver problema de desempenho do Tahoe.
Slow Start, Congestion Avoidance, Fast Retrasmit e Fast Recovery.
11
Evita congestionamento de forma pró ativa; Reenvio no primeiro ACK Duplicado
Aumento exponencial após dois segmentos;
Utiliza dois temporizadores;
Primeiro temporizador = fazer calculo do fluxo da rede para saber a capacidade disponível
VazãoReal(Valor CWND/tempo. atual) e VazãoEsperada(Valor CWND/
menor temporizador); Calculo da diferença das variáveis de forma pró-ativa, depois ajusta janela
CWND pelas mudanças do temporizador
Temporizador pequeno = aumento da CWND;
Temporizador grande = rede congestionada e diminui a CWND;
12
Segmento é enviado: Leitura de relógio interno e armazena instante de tempo
Recebimento do ACK: Leitura de relógio interno = calcula o tempo estimado do
temporizador usando a vazão real e a vazão esperada Valor registrado na timestamp
Utiliza a timestamp, para decisão de retransmissão em duas situações: Quando um ACK duplicado chegar:
▪ Se (tempo atual - tempo armazenado) > timeout ▪ O segmento é retransmitido sem ter que esperar pelo terceiro ACK duplicado ou pelo estouro
de tempo de retransmissão.
Se um ACK que não é duplicado é reconhecido e se ele for o primeiro ou o segundo após uma retransmissão: ▪ checa se o tempo desde que ele foi enviado é maior que o tempo do timeout. Se
for maior, o segmento é retransmitido.
13
Otimizar o TCP Reno Reno com reconhecimentos parciais em uma única janela
CWND = Utiliza muito o Congestion Avoidance. Reduzindo a transmissão seguidas vezes
Reconhecimentos Parciais = pacote perdido Retransmissão.
NewReno Utiliza Fast Recovery de forma diferenciada:
não espera um estouro de timeout no caso de reconhecimentos parciais
Se mantém no Fast Retransmit (reconhecimentos parciais) Retransmite todos os pacotes por RTT
14
15
TCP New Reno só sai da fase Fast Recovery quando recebe a confirmação de todos os pacotes que foram enviados nesta fase.
Otimizar o Reno Perdas de vários segmentos Retransmissão fica lenta, muitos reenvios.
Objetivo de recuperar múltiplos segmentos perdidos em um RTT.
Receptor envia no ACK a informação dos segmentos já recebidos. Transmissor sabe exatamente que segmentos foram
perdidos, podendo retransmiti-los.
Melhora da largura de banda disponível 16
O SACK utiliza o campo "Options" do cabeçalho TCP para transportar as informações sobre os segmentos recebidos.
SACK estará em funcionamento apenas em ACKs Duplicados ou reconhecimentos parciais
Caso receba um segmento fora de ordem, armazenará os segmentos em um bloco contíguo e informará ao emissor o sequencial desses dados pelo campo Options do TCP.
No campo Acknowledgement Number envia o número de sequencia recebido + 1, ou seja, o TCP Sack não altera o valor desse campo no TCP.
17
Utiliza informações adicionais do TCP Sack Medida do número de dados circulando a rede
Objetivo é utilizar as informações do TCP Sack para
ter um controle mais preciso para injetar dados na rede
TCP Reno e TCP Sack Cada Ack duplicado é um segmento perdido
Já o TCP Fack faz a estimativa utilizando duas
variaveis snd.fack e retran_data
18
snd.fack é atualizada para refletir os dados mantidos pelo receptor Atualização é feita pelo número de confirmações no cabeçalho TCP e é o mesmo que a
variável snd.una (indica o número de sequencia do primeiro byte do pacote enviado e ainda não reconhecido.). Algoritmos remetente que tratam de transporte confiável, continuam a usar a variável
snd.una de estado existente. Algoritmos remetente que abordam a gestão dos congestionamentos são alteradas para usar
snd.fack, que fornece uma visão mais precisa para o estado da rede
Durante a recuperação; Remetente continua atualizando a variável snd.una do numero de confirmação do cabeçalho TCP No mesmo tempo, utiliza-se as informações contidas no TCP Sack para atualizar snd.fack. Quando um bloco do Sack é recebido, e os reconhecimentos de dados com um número de sequencia mais alto do que o valor atual de snd.fack, snd.fack é atualizado para refletir o número de sequencia mais alto conhecido
A variável awnd é a estimativa do remetente da quantidade real de dados em circulação na rede(Se todos os seg. não confirmados não deixaram a rede).
awnd = snd.nxt - snd.fack
snd.nxt contém o sequence number do próximo dado a ser transmitido.
19
Durante a recuperação(retransmissão de dados)
Calcula retran_data, que reflete a quantidade de circulação de dados retransmitidos na rede.
Segmento Retransmitido = atualiza retran_data, que é aumentada pelo valor do segmento.
Segmento Deixando a rede = atualiza retran_data, que é diminuída pelo valor do segmento
Portanto estimativa TCP da quantidade de dados pendentes na rede durante a recuperação é dada por:
awnd = snd.nxt - snd.fack + retran_data
20
Reno invoca o Fast Recovery com 3 segmentos duplicados Atraso desnecessário(segmentos perdidos antes dos 3 reconhecimentos duplicados)
TCP Fack o ajuste da cwnd e retransmissão são acionados receptor informando que a fila de remontagem é maior que 3 segmentos
if ((snd.fack - snd.una) > (3 * MSS) ||(dupacks == 3)) { ... }
Se exatamente um segmento é perdido, os dois algoritmos
desencadeiam recuperação exatamente no mesmo reconhecimento duplicado
21
Importante elemento para experimentos em redes.
Custo baixo;
Imita características de redes reais; Prevê desempenho, comparação de
arquiteturas;
Execução em tempo de máquina.
22
Código aberto; Utilizado em pesquisas acadêmicas; Eventos discretos e orientado a objetos; Suporte a protocolos de comunicação, como TCP e
UDP, modelos de tráfego, como CBR e VBR; algoritmos de roteamento, como DSR e AODV; alguns protocolos da camada MAC, etc.
23
24
25
26
8 passos citados por Hassan e Jain(2004). Definição do Objetivo de estudo; Modelo de rede e seleção de parâmetros fixos;
▪ Rede RNP; parâmetros fixos:capacidade dos enlaces, retardos.
Seleção de Métricas de Desempenho; ▪ Descartes, Pacotes Recebidos e Utilização de link.
Parâmetros variáveis; ▪ Percentual de geradores de tráfego.
Escolha da técnica de simulação e análise; Configurar o software de simulação; Executar o programa e coletar os dados; Apresentar e interpretar os resultados.
27
28
29
Modelos
Parâmetros de Rede
30
Cenários de rede que simulam as conexões das topologias da RNP.
Todos os enlaces das topologias possuem: buffer finito, com pequena capacidade.
Os enlaces são Full-Duplex e utilizam a disciplina de fila FIFO (First-In First-Out).
Executados em simulações de 10 segundos
cada.
31
Parâmetros fixos:
Capacidade dos enlaces
Retardos
Parâmetro variável:
Percentual de geradores de tráfego
32
Capacidade dos enlaces 5Mb e 2Mb com exceção das ligações entre (1) Ceará e Roraima e
(2) Pará e Amapá, que tem capacidade inferior.
Retardos De acordo com as distancias físicas dos enlaces
▪ Ceará e Minas Gerais com 20ms de retardo.
▪ Ceará e Rio Grande do Norte com 10ms de retardo.
Percentual de geradores de tráfego Número de enlaces da topologia (50%, 70%, 80%)
33
Rede RNP Antiga 34 enlaces:
▪ 50% = 17 geradores de tráfego (9 FTP e 8 CBR)
▪ 70 % = 25 geradores de tráfego (13 FTP e 12 CBR)
▪ 80% = 27 geradores de tráfego (14 FTP e 13 CBR)
Rede RNP ATUAL 36 enlaces (Ceará com Rio de Janeiro e Ceará com Brasília):
▪ 50% = 18 geradores de tráfego(9 FTP e 9 CBR)
▪ 70% = 25 geradores de tráfego (13 FTP e 12 CBR)
▪ 80% = 29 geradores de tráfego (15 FTP e 14 CBR)
34
De acordo com o número de algoritmos de congestionamento utilizados e o número de parâmetros variáveis, foram criados 36 cenários de rede (18 cenários na topologia antiga da RNP e 18 cenários na topologia atual).
Os Geradores de tráfego FTP começam a transmitir com 0,1 segundo e os tráfegos CBR começam com 0,5 segundos
35
Criação de Scripts em Shell: Para Descartes, foi criado um script que foi verificado a quantidade de
pacotes que foram descartados durante os 10 segundos de simulação, em períodos de 0,5 segundos, verificando os pacotes FTP perdidos.
Para a taxa de Pacotes Recebidos, script com características parecidas com o script de descartes
Para a Utilização do Canal, script para analisar o link entre os nós Goiás e Distrito Federal, link com 5Mb de capacidade, trafegando dados FTP e CBR simultaneamente ocorrendo congestionamento mas com poucos descartes.
36
Rede RNP Antiga
Descartes
Pacotes Recebidos
Utilização do link
Rede RNP Atual
Descartes
Pacotes Recebidos
Utilização do link
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
Algoritmos de Controle de Congestionamento TCP trazem vantagens para o protocolo mais utilizado na Internet - TCP.
TCP Vegas tem o melhor desempenho comparado aos outros algoritmos nas três métricas analisadas, tanto na rede antiga da RNP quanto na rede atualmente utilizada. Isso se deve a sua pró-atividade em monitorar o estado da rede, utilizando as variáveis vazão real e vazão esperada, controlando o congestionamento na rede.
TCP Tahoe e os outros algoritmos que se baseiam em alguns mecanismos desta implementação tiveram um desempenho pior quando comparado ao TCP Vegas. Isso comprova a importância da criação de um algoritmo de controle de congestionamento que não se baseia na perda de dados para diminuir o envio de dados, mas sim um algoritmo de controle de congestionamento que se baseia no resultado de variáveis que informam a situação da rede.
Melhora na topologia da RNP com sua atualização, que suporta o envio de mais dados na rede e tem mais opções de redundância com o aumento do número de links.
62
ABED, G. A., ISMAIL, M., & JUMARI, K. A Survey on Performance of Congestion Control Mechanisms for Standard TCP Versions. Australian Journal of Basic & Applied Sciences, 5(12), 2011.
ALLMAN M.; PAXSON V.; STEVENS W. TCP Congestion Control. IETF Request for Comments (RFC) 2581, 1999.
BENÍTEZ, CÁCERES, D.B. Aplicação de Algoritmos de Controle para o
tratamento de congestionamento em Redes de Computadores. 2010. 159 f. Tese de Doutorado (Pós-Graduação em Engenharia Elétrica) – Universidade do Rio de Janeiro, Rio de Janeiro, 2010.
CAVALCANTI, J.L Análise comparativa dos algoritmos de controle de
congestionamento do TCP. 2005. 62 f. Trabalho de Conclusão de Curso (Bacharelado em Engenharia da Computação) - Universidade Federal de Pernambuco, Recife, 2005.
FALL, Kevin; VARADHAN, Kannan. The ns Manual (formerly ns Notes and Documentation), 2013. Disponível em <http://www.isi.edu/nsnam/ns/doc/index.html>. Último acesso em 30/10/2013.
63
HASSAN, M.; JAIN, R. High Performance TCP/IP Networking. 1ª.ed. India: Pearson, 2004.
KUROSE, J. F; ROSS, K. W. Redes de computadores e a internet: uma abordagem top-down. 5ª. ed. São Paulo: Addison-Wesley, 2010.
MATHIS, M.; MAHDAVI, J. Forward acknowledgement: Refining
TCP congestion control. ACM SIGCOMM Computer Communication Review, v. 26, n. 4, p. 281-291, 1996.
OLIFER, N. Redes de computadores: princípios, tecnologias e protocolos para o projeto de redes. 1ª. ed. Rio de Janeiro: LTC, 2008.
PORTNOI, M.; ARAÚJO, R. Network Simulator – Visão Geral da
Ferramenta de Simulação de Redes. Salvador: UNIFACS, 2003.
64
PRETE, L. R; SHINODA, A. A. Análise do Comportamento das Variações do Protocolo TCP. In: Congresso Nacional de Matemática Aplicada e Computacional, 32. 2009, Cuiabá. Anais do CNMAC, Cuiabá: Editora Cubo, 2009. p. 7-6.
TANENBAUM, A. S. Redes de Computadores. 5ª. ed. São Paulo:
Campus, 2011
65
FIM
66