Um estudo sobre o controle de congestionamento na arquitetura RINA

(1)

Kleber Alves Leal

UM ESTUDO SOBRE O CONTROLE DE CONGESTIONAMENTO NA

ARQUITETURA RINA

Dissertação de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE 2017

(2)

Kleber Alves Leal

UM ESTUDO SOBRE O CONTROLE DE CONGESTIONAMENTO NA

ARQUITETURA RINA

Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientador: José Augusto Suruagy Monteiro

RECIFE 2017

(3)

Catalogação na fonte

Bibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758

L435e Leal, Kleber Alves.

Um estudo sobre o controle de congestionamento na arquitetura RINA / Kleber Alves Leal . – 2017.

81f.: fig., tab.

Orientador: José Augusto Suruagy Monteiro.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2017.

Inclui referências.

1. Rede de computadores. 2. Arquitetura da informação. 3. Internet do futuro. I. Monteiro, José Augusto Suruagy. (Orientador). II. Titulo.

(4)

Kleber Alves Leal

"Um Estudo Sobre o Controle de Congestionamento na Arquitetura RINA"

Dissertação de Mestrado apresentada ao pro-grama de Pós-Graduação em Ciência da Compu-tação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação

Aprovado em: 31/08/2017.

BANCA EXAMINADORA

———————————————————————– Prof. Dr. Divanilson Rodrigo de Sousa Campelo

Centro de Informática / UFPE

———————————————————————– Prof. Dr. Glauco Estácio Gonçalves

Departamento de Estatística e Informática / UFRPE

———————————————————————– Prof. Dr. José Augusto Suruagy Monteiro

Centro de Informática / UFPE (Orientador)

(5)

Dedico esta dissertação à minha família e os professores que me ajudaram a chegar até aqui.

(6)

Agradecimentos

Eu gostaria de utilizar este espaço para agradecer a todos aqueles que de alguma forma contribuíram com o desenvolvimento deste trabalho. Quando pensei nesta lista vi que seria impossível citá-los todos aqui, pois as contribuições ocorrem nas mais diversas formas e tornaria esta seção um tanto grande.

Primeiramente gostaria de agradecer a Deus por me permitir estar saudável e em plena conciência do meu papel neste caminho. À minha esposa, Suelane Maria por estar sempre me apoiando, mesmos nos momentos mais difíceis do projeto, quando era muito difícil enxergar o fim do túnel. Aos meus filhos Kleber Filho e Camila Costa que foram meu oásis nos momentos que o desespero batia à minha porta. Aos meus pais, José Cândido e Felícia Leal, por compreender minha ausência nestes muitos meses que antecederam a defesa da dissertação. Ao professor Suruagy, que teve um papel fundamental na orientação do meu trabalho. Sem ele a escrita da dissertação não passaria de um desejo. Aos meus amigos que excederam os limites do trabalho que deram ouvidos às minhas histórias sobre o andamento do projeto e me deram força para seguir em frente.

Também não poderia deixar de agradecer às pessoas que mesmo de muito longe tiveram uma contribuição imensa na construção do meu conhecimento sobre a arquitetura RINA e o simulador.

I would like to thank the professor Vladimír Veselý, who gave me lots of tips about the simulator internals when I was stuck trying to understand it by my own. He knows how long it was the road to build my work. Marcel Marek, who even working on another project gave me several instructions to turn my project real. And a huge thank to Sergion León Gaixas, whose availabity to discuss about the problems I was facing with the simulador showed how big he is.

(7)

O que sabemos é uma gota; o que ignoramos é um oceano. —ISAAC NEWTON

(8)

Resumo

RINA – Recursive InterNetwork Architecture é uma proposta de arquitetura para a Inter-net do Futuro construída sobre o conceito de que a comunicação de rede é apenas comunicação entre processos. Ela possui uma pilha com número variável de camadas em um modelo recursivo, no qual mecanismos contendo um conjunto fixo de funcionalidades são conectados e têm o seu funcionamento definido por um conjunto de uma ou mais políticas. Esta programabilidade permite a evolução da rede ao longo do tempo, sem a necessidade de sofrer modificações na sua estrutura, possibilitando assim o surgimento de novos serviços e protocolos. Este trabalho tem como objetivo estudar o controle de congestionamento nesta nova arquitetura, tomando como base os problemas enfrentados pela arquitetura atual da Internet. Foi feita uma investigação sobre os algoritmos clássicos de controle de congestionamento da Internet, seus problemas e so-luções propostas. O estudo foi conduzido por meio de simulação de algoritmos propostos para a arquitetura atual, levando-se em consideração as características e funcionalidades disponíveis na arquitetura RINA. Foram analisadas as métricas de goodput, atraso e a justiça na distribuição da banda entre os fluxos concorrentes. Os resultados dos experimentos mostraram que o mecanismo FAST teve um melhor desempenho na métrica goodput. Os fatores que mais impactaram na variação observada no goodput foram o tamanho da PDU (32,1%), o efeito combinado da escolha do mecanismo de controle de congestionamento e o atraso de propagação (12,5%) e apenas a seleção do mecanismo de controle de congestionamento (12,3%). Para o atraso o mecanismo CUBIC teve um desempenho superior, apresentando menores valores para a métrica quando comparada ao mecanismo FAST. Os fatores que mais influenciaram a variação observada foi o atraso de propagação (81,5%) e o mecanismo de controle de congestionamento (6,5%). Para a justiça na divisão das banda entre os fluxos concorrentes o fatores que mais influenciaram foram a influência combinada do mecanismo de controle de congestionamento e atraso de propagação (32,3%) e apenas o atraso de propagação (26,5%). Os demais fatores e suas combinações não tiveram influência significativa. O FAST apresentou melhor índice de justiça nos momentos cujo atraso de propagação foi maior. Apesar de ter obtido um resultado superior ao do CUBIC, problemas relacionados à justiça na divisão da banda entre os fluxos concorrentes também ficaram evidentes no mecanismo FAST, especialmente quando novos fluxos são iniciados em um canal já congestionado. De posse dos resultados obtidos nos experimentos executados ao longo deste trabalho, concluímos que os mecanismos de controle de congestionamento projetados para a Internet são aplicáveis na arquitetura RINA.

(9)

Abstract

RINA — Recursive InterNetwork Architecture is an architectural proposition for the Future Internet built on the concept that network communication is just Inter-process Commu-nication (IPC). It has a stack with a variable number of layers in a recursive model, in which mechanisms containing a fixed set of functionalities are connected and have their operation defined by a set of one or more policies. This programmability allows the evolution of the network over time, without the need to undergo modifications in its structure, thus allowing the emergence of new services and protocols. Congestion is the state where demand for resources is greater than the network capacity. Congestion control is the application of measures to prevent or eliminate congestion in computer networks. This work aims to study the congestion control in this new architecture, based on the problems faced by the current Internet architecture. An investigation was made on the classical Internet congestion control algorithms, their problems, and proposed solutions. The study was conducted by simulation of algorithms proposed for the current architecture, taking into account the characteristics and functionalities available in the RINA architecture. Goodput, delay, and fairness in bandwidth allocation were computed between competing flows. The results of the experiments showed that the FAST mechanism performed better in the goodput metric. The factors that most impacted in goodput were the PDU size (32.1%), the combined effect of the congestion control mechanism and propagation delay (12.5%), and only the selection of the control mechanism congestion (12.3%). For the delay, the CUBIC mechanism performed better, presenting lower values for the metric when compared to the FAST mechanism. The factors that most influenced the variation observed were the propagation delay (81.5%) and the congestion control mechanism (6.5%). The influence of the congestion control mechanism and the propagation delay (32.3%) and only the propagation delay (26.5%) were the most influential factors for the adjustment of the bandwidth among competing flows. The other factors and their combinations had no significant influence. The FAST presented a better justice index in the moments whose propagation delay was greater. Despite having achieved a better result than CUBIC, problems related to fairness in the division of the bandwith between competing flows were also evident in the FAST mechanism, especially when new flows are initiated in an already congested channel. Based on the results obtained in the experiments carried out in this work, we conclude that the congestion control mechanisms designed for the Internet are applicable in the RINA architecture.

(10)

Lista de Figuras

2.1 Janela de congestionamento CUBIC . . . 29

2.2 Gráfico da função cúbica . . . 30

2.3 Janela de congestionamento FAST . . . 32

3.1 Máquina de protocolo . . . 35

3.2 Mecanismo e políticas . . . 35

3.3 Janela deslizante . . . 36

3.4 Exemplo de uma rede básica no OMNeT++ . . . 40

3.5 Projeto RINASim . . . 42

3.6 Exemplo de política . . . 42

4.1 Topologia de rede em estudo . . . 46

4.2 Goodput medido na primeira execução do experimento 1 . . . 51

4.3 Justiça entre os fluxos no experimento 1 . . . 52

4.4 ECN recebidas por RTT no experimento 1 . . . 52

4.5 Atraso e CWND - experimento 1 . . . 53

4.22 BaseRTT observado durante o fluxo . . . 64

(11)

4.26 BaseRTT observado durante o fluxo . . . 66

(12)

Lista de Tabelas

3.1 Políticas do módulo EFCP . . . 43

3.2 Políticas do módulo RMT . . . 43

4.1 Políticas necessárias para implementar o CUBIC no RINASim . . . 49

4.2 Políticas necessárias para implementar o FAST no RINASim . . . 49

4.3 Instante de início e término dos fluxos . . . 50

4.4 Desenho do experimento. . . 50

4.5 Análise de influência dos fatores no goodput do sistema . . . 70

4.6 Efeitos e influências no goodput . . . 71

4.7 Análise de influências dos fatores no atraso . . . 71

4.8 Efeitos e influências no atraso . . . 72

4.9 Análise de influência dos fatores no justiça . . . 72

4.10 Efeitos e influências na justiça . . . 73

(13)

Lista de Acrônimos

ACC Controle de Congestionamento Agregado - Aggregated Congestion Control . . 38

ACK acknowledgment. . . 23

AE Application Entity. . . 35

BDP Produto largura de banda-atraso — Bandwidth-Delay Product . . . 18

bps bits por segundo - bits per second . . . 46

CWND janela de congestionamento — Congestion Window . . . 22

CWQ Closed Window Queue. . . 37

DA DIF Allocator . . . 42

DAF Distributed Application Facility . . . 35

DIF Distributed IPC Facility. . . 18

DTCP Data Transfer Control Protocol. . . 37

DT-PDU Data Transfer PDU . . . 37

DTP Data Transfer Protocol . . . 37

ECN Explicit Congestion Notification. . . 53

EFCP Error and Flow Control Protocol. . . 37

EFCPI Error and Flow Control Protocol Instance. . . 37

FA Flow Allocator. . . 37

FAI Flow Allocator Instance . . . 37

HB Higher is Better. . . 46

IPC Comunicação entre processos - Inter-Process Communication . . . 37

LB Less is Better. . . 46

LB-DAF Load Balancing Distributed Application Facility. . . 39

LFN Long Fat Network. . . 22

MAN Metropolitan Area Network. . . 45

NED Network Description . . . 40

NSF National Science Foundation. . . 17

NSM Name Space Manager. . . 39

(14)

RED Random Early Detection. . . 26

RINA Recursive InterNetwork Architecture. . . 18

rLWE Borda esquerda da janela do receptor — Receiver Left Window Edge . . . 37

RMT Relaying and Multiplexing Task. . . 37

RNP Rede Nacional de Ensino e Pesquisa . . . 48

RTPD Round-trip Propagation Delay. . . 25

RTT Round Trip Time. . . 18

rRWE Borda Direita da Janela do Receptor — Receiver Right Window Edge . . . 37

SDN Software Defined Network. . . 17

SDU Service Data Unit. . . 34

SDK Software Development Kit . . . 39

SDRED Stabilized DynamicRED . . . 33

sLWE Borda Esquerda da Janela do Emissor — Sender Left Window Edge . . . 36

sRWE Borda Direita da Janela do Emissor — Sender Right Window Edge . . . 36

TCP Transmission Control Protocol . . . 16

UDP User Datagram Protocol. . . 16

VTN Virtual Transport Networks . . . 39

(15)

Sumário

1 INTRODUÇÃO 16 1.1 OBJETIVOS . . . 19 1.2 METODOLOGIA . . . 19 1.3 CONTRIBUIÇÕES . . . 19 1.4 ESTRUTURA DA DISSERTAÇÃO . . . 20 2 CONTROLE DE CONGESTIONAMENTO 21 2.1 INTRODUÇÃO . . . 21

2.2 CONTROLE DE CONGESTIONAMENTO BASEADO EM ORIGEM . . . 22

2.2.1 Abordagens baseadas em perdas . . . 22

2.2.2 Abordagens baseadas em atraso . . . 24

2.2.3 Abordagens híbridas . . . 27

2.3 CONTROLE DE CONGESTIONAMENTO BASEADO EM ROTEADOR . . . . 28

2.4 MECANISMOS DE CONTROLE DE CONGESTIONAMENTO . . . 28

2.4.1 CUBIC . . . 28

2.4.2 FAST TCP . . . 31

2.4.3 RED — Random Early Detection . . . 32

2.5 CONSIDERAÇÕES FINAIS . . . 33

3 A ARQUITETURA INTER-REDES RECURSIVA 34 3.1 UMA BREVE VISÃO SOBRE A ARQUITETURA RINA . . . 34

3.2 O CONTROLE DE FLUXO . . . 36 3.3 O CONTROLE DE CONGESTIONAMENTO . . . 37 3.4 PROTÓTIPOS E SIMULADOR . . . 38 3.4.1 ProtoRINA . . . 38 3.4.2 IRATI . . . 39 3.4.3 RINASim . . . 39 3.5 CONSIDERAÇÕES FINAIS . . . 43

4 DEFINIÇÃO E EXECUÇÃO DOS EXPERIMENTOS E ANÁLISE DOS RE-SULTADOS 45 4.1 DESCRIÇÃO DO CENÁRIO . . . 45

4.2 MÉTRICAS . . . 46

4.3 PARÂMETROS . . . 47

4.4 FATORES . . . 48

(16)

15

4.6 EXECUÇÃO DOS EXPERIMENTOS . . . 50

4.7 ANÁLISE E INTERPRETAÇÃO DE RESULTADOS . . . 51

4.7.1 Experimento 1 — CUBIC com atraso de 0,05 ms e PDU de 536 B . . . 51

4.7.2 Experimento 2 — CUBIC com atraso de 0,05 ms e PDU de 1500 B . . . 54

4.7.3 Experimento 3 — CUBIC com atraso de 17 ms e PDU de 536 B . . . 56

4.7.4 Experimento 4 — CUBIC com atraso de 17 ms e PDU de 1500 B . . . 58

4.7.5 Experimento 5 — FAST com atraso de 0,05 ms e PDU de 536 B . . . 60

4.7.6 Experimento 6 — FAST com atraso de 0,05 ms e PDU de 1500 B . . . 63

4.7.7 Experimento 7 — FAST com atraso de 17 ms e PDU de 536 B . . . 65

4.7.8 Experimento 8 — FAST com atraso de 17 ms e PDU de 1500 B . . . 68

4.8 ANÁLISE DE INFLUÊNCIA DOS FATORES . . . 68

4.8.1 Análise do goodput . . . 70

4.8.2 Análise do atraso . . . 70

4.8.3 Análise da justiça na distribuição da banda . . . 71

4.9 CONSIDERAÇÕES FINAIS . . . 74

5 CONCLUSÕES E TRABALHOS FUTUROS 76

(17)

16 16 16

1

INTRODUÇÃO

A Internet tomou proporções que a forçaram a evoluir adicionando “remendos” ao longo dos últimos anos. A demanda por segurança, a necessidade do aumento no espaço de endereçamento ocasionado pelo crescimento na quantidade de dispositivos conectados e a demanda por serviços criou a necessidade de se pensar em uma Internet do Futuro.

SegundoDAY(2008), a Internet atual tem várias lacunas que são inerentes à sua arquite-tura atual e estão presentes desde o seu início. Muitos destes problemas ficaram mais evidentes com o crescimento da Internet e o surgimento de novos serviços. A seguir são apresentadas algumas fraquezas da arquitetura atual de acordo com o autor:

Nomes e endereços: Devido à simplicidade e às pequenas dimensões das primeiras redes de computadores, a nomeação e o endereçamento dos dispositivos não era encarado como um problema. Assim, os pesquisadores priorizaram problemas mais urgentes, como o roteamento. Como resultado, não há uma separação entre o nome do recurso e o endereço onde o recurso está disponível;

Roteamento, mobilidade e multihoming: Os serviços são acessados por meio dos endereços das interfaces de rede onde o serviço executa, aliado ao número da porta do protocolo de transporte para identificar individualmente cada aplicação. Esta asso-ciação direta entre os serviços e a interface de rede gera ineficiência no roteamento, mobilidade e multihoming;

Protocolos: Transmission Control Protocol (TCP) e User Datagram Protocol (UDP) são protocolos de transporte da arquitetura atual da Internet. O TCP é um protocolo orientado a conexão e possui mecanismos que garantem a manutenção da sequência original dos dados, a checagem de erros, dentre tantas outras funcionalidades. Já o UDP é um protocolos simples e não orientado a conexão. Tais protocolos não podem ser facilmente modificados para prover serviços que possuem diferentes necessidades de controle;

Segurança: Como o endereçamento da Internet é global, cada dispositivo possui conectividade com qualquer outro dispositivo conectado. Além disso, os serviços

(18)

17

oferecidos através da rede possuem portas bem conhecidas, possibilitando ataques de negação de serviço e a descoberta de serviços em execução através do escaneamento de portas, dentre outros ataques. Com o objetivo de aumentar a segurança, novos protocolos foram desenvolvidos, adicionando criptografia fim-a-fim violando as camadas definidas na arquitetura de Internet;

Arquitetura: Na arquitetura atual da Internet os escopos são limitados ao local e global. Esta limitação é ocasionada pelo número fixo de camadas oferecidas pela arquitetura, onde a camada de acesso a rede possibilita a comunicação local e a camadas de inter-redes e transporte possibilitam conectividade fim-a-fim. Além disso, na arquitetura atual a perda de segmento é interpretada como notificação implícita de congestionamento, causando subutilização dos recursos em redes onde a perda de pacotes é característica do meio de transmissão, a exemplo das redes sem fio;

Qualidade de Serviço: A qualidade de serviço oferecida na Internet atual limita-se à escolha do protocolo de transporte e a prioridade dos pacotes das filas de saída dos roteadores. Serviços que necessitam de requisitos diferentes dos serviços oferecidos pelos atuais protocolos de transporte precisam optar entre as opções disponíveis.

Para lidar com tais problemas surgiram várias propostas para a construção de uma arquitetura para a Internet do Futuro. As propostas evolucionárias partem do princípio de que a Internet, após ajustes pontuais em suas fragilidades, pode atender a demanda dos novos serviços e ao mesmo tempo manter compatibilidade com o legado. Por outro lado, as propostas clean slate, partem do pressuposto que para se obter uma solução definitiva para os problemas da Internet é necessário voltar aos fundamentos e construir uma arquitetura sem levar em consideração as limitações existentes na Internet atual.

PAN; PAUL; JAIN(2011) apresentam um survey em Internet do Futuro. Os autores

apresentam as iniciativas de construção de uma nova arquitetura clean slate para Internet fomentadas pela National Science Foundation (NSF)1. Os projetos apresentados têm o foco na virtualização, roteamento em alta velocidade, nomeação, segurança, gerenciamento e no controle. Os autores acrescentam ainda que para ter sucesso uma nova arquitetura para a Internet deve ser compatível com as aplicações atuais.

Software Defined Network (SDN) é apresentada por OLIVEIRA SILVA et al.(2012) como uma tecnologia que permite a implementação de novas arquiteturas para Internet do Futuro sobre a Internet atual. OpenFlow (MCKEOWN et al.,2008) é uma materialização do SDN, que age separando o plano de controle do plano de dados, permitindo então que a rede seja programada com o objetivo de implementar e testar novas arquiteturas. Diversos testbeds para Internet do Futuro fazem uso de SDN e Openflow, a exemplo do GENI (ELLIOTT, 2010), OFELIA (SUÑÉ et al.,2014) e FIBRE (SALLENT et al.,2012).

(19)

18

A Recursive InterNetwork Architecture (RINA) é uma arquitetura de rede recursiva clean slateconstruída sobre a premissa de que rede é apenas comunicação entre processos (IPC — Inter-Process Communication) (DAY,2008). Ao invés de apresentar um conjunto rígido de mecanismos com comportamento predefinidos, na arquitetura RINA a rede é vista com um conjunto reduzido de mecanismos que se repetem tantas vezes quantas forem necessárias. Estes mecanismos têm seu comportamento definido por meio de um conjunto de uma ou mais políticas. Diversos esforços foram feitos para validar os conceitos que cercam a arquitetura. A publicação do simulador RINASim (VESELY et al.,2015), dentre outras ferramentas, permitiu o estudo da arquitetura em maiores detalhes.

Segundo PAPADIMITRIOU et al. (2011), congestionamento pode ser definido pelo estado da rede onde a demanda por recursos é maior que sua capacidade, resultando na perda ou atraso na entrega da informação. O controle do congestionamento refere-se a técnicas e mecanismos que visam prevenir a rede da ocorrência de congestionamento ou solucionar o congestionamento após a sua ocorrência.

Devido ao atraso de propagação enfrentado pelos segmentos de dados enviados do emissor ao receptor, é necessário manter uma certa quantidade de dados em trânsito para se obtenha uma completa utilização da banda disponível no meio de transmissão. O Produto largura de banda-atraso — Bandwidth-Delay Product (BDP) é o produto entre a banda e o atraso de propagação de ida e volta (RTT) e é tido como a quantidade ideal de bits a serem mantidos em trânsito. Algoritmos clássicos de controle de congestionamento como o Tahoe e o Reno, quando operam no regime de prevenção de congestionamento, aumentam a quantidade de dados em trânsito em 1 segmento de dados por Round Trip Time (RTT). Este crescimento lento tornou-se um problema com o avanço das redes de alta velocidade e longos atrasos de propagação. Manter a quantidade de bits em trânsito menor que o BDP significa subutilizar os recursos da rede.

O controle de congestionamento é um dos problemas em aberto da arquitetura RINA citados no livro deDAY(2008). Na arquitetura RINA o controle de congestionamento é definido como um dos parâmetros da camada, chamada de Distributed IPC Facility (DIF). Assim, um mecanismo de controle de congestionamento pode ser definido em diversos escopos diferentes ao longo da rede. Por se tratar de uma nova arquitetura e devido à recursividade inerente, não estava claro qual seria a melhor estratégia de controle de congestionamento a ser adotada e, dentre as alternativas propostas para o TCP, quais delas seriam as mais indicadas.

A divisão entre mecanismos e políticas possibilita à arquitetura RINA ter o comporta-mento dos seus mecanismos modificado a fim de implementar os algoritmos de controle de congestionamento até então utilizados na Internet. TEYMOORI et al. (2016) realizaram o primeiro estudo sobre o controle de congestionamento na arquitetura RINA e apresentaram o controle de congestionamento agregado. Ele age convergindo os fluxos das camadas superiores que têm o mesmo IPC de destino e que possuem os mesmos requisitos de qualidade de serviço em um único fluxo nas camadas inferiores. Ainda há muito a ser estudado sobre o controle de congestionamento na arquitetura RINA. Esta dissertação reserva-se a estudar os mecanismos de

(20)

1.1. OBJETIVOS 19

controle de congestionamento nesta nova arquitetura.

1.1 OBJETIVOS

Abaixo são apresentados os objetivos geral e específicos desta dissertação.

Objetivo Geral

Avaliar a eficácia do uso de mecanismos de controle de congestionamento na arquitetura RINA através de métricas de goodput, atraso e justiça na distribuição da banda por meio de simulação.

Objetivos Específicos

Para atingir o objetivo geral é necessário primeiramente atingir os seguintes objetivos específicos:

Implementar os mecanismos de controle de congestionamento projetados para a Internet;

Avaliar o desempenho do RINA com o uso do mecanismo de controle de congestio-namento CUBIC;

Avaliar o desempenho do RINA com o uso do mecanismo de controle de congestio-namento FAST;

Comparar o desempenho dos mecanismos de controle de congestionamento CUBIC e FAST na arquitetura RINA.

1.2 METODOLOGIA

Para avaliar o uso dos mecanismos de controle de congestionamento na arquitetura RINA será utilizada a metodologia proposta porJAIN(1990). A metodologia define os passos necessários para planejar, executar, coletar dados e analisar os resultados em um projeto de análise de desempenho de um sistema computacional para finalmente quantificar as influências dos fatores neste desempenho.

1.3 CONTRIBUIÇÕES

Este projeto tem como objetivo alcançar as contribuições científicas e educacionais descritas a seguir:

(21)

1.4. ESTRUTURA DA DISSERTAÇÃO 20

A contribuição científica deste projeto é realizar a avaliação de mecanismos de controle de congestionamento na arquitetura RINA por meio de simulação;

A contribuição educacional está no apoio ao projeto de construção e manutenção do RINASim, com a implementação dos mecanismos de controle de congestionamento utilizados durante o estudo e torná-los públicos por meio do repositório oficial do projeto RINASim.

1.4 ESTRUTURA DA DISSERTAÇÃO

O restante desta dissertação está organizada da seguinte maneira: o Capítulo 2 apresenta um estudo sobre o controle de congestionamento da Internet. O Capítulo 3 apresenta conceitos acerca da arquitetura RINA, em especial aqueles relacionados ao controle de congestionamento na arquitetura. O Capítulo 4 apresenta os experimentos realizados e os resultados obtidos na avaliação dos mecanismos de controle de congestionamento. Finalmente, o Capítulo 5 apresenta as conclusões e sugestões para trabalhos futuros.

(22)

21 21 21

2

CONTROLE DE CONGESTIONAMENTO

Neste capítulo são apresentados conceitos acerca do controle de congestionamento na Internet. São apresentados os diferentes modos de controle de congestionamento baseados na origem e nos roteadores e suas subclasses. São apresentados também em detalhes os mecanismos de controle de congestionamento CUBIC, FAST e RED. Tais mecanismos serão utilizados no capítulo 4 para avaliação dos mecanismos de controle de congestionamento.

2.1 INTRODUÇÃO

O controle de congestionamento é um tema que vem sendo investigado desde o primeiro colapso gerado por congestionamento ocorrido na Internet e tem tomado notoriedade desde o avanço das redes de alta velocidade. SegundoPAPADIMITRIOU et al.(2011), congestionamento pode ser definido pelo estado da rede onde a demanda por recursos é maior que sua capacidade, resultando na perda ou atraso na entrega da informação. O controle do congestionamento refere-se a técnicas e mecanismos quem visam prevenir a rede da ocorrência de congestionamento ou solucionar o congestionamento após a sua ocorrência.

KUSHWAHA; GUPTA (2014) apresentam uma revisão sistemática sobre o controle

de congestionamento em redes de alta velocidade. O estudo mostrou a relevância do tema, apresentou os métodos de controle de congestionamento, realizou uma comparação entre os mecanismos baseados na origem e baseados em roteadores e como estes podem ser utilizados em cooperação. Além do mais, efetuou uma comparação entre os métodos usando diferentes métricas e trouxe uma visão sobre as ferramentas existentes para análise de algoritmos de controle de congestionamento.

O controle de congestionamento baseado em origem atua por meio da aplicação de mecanismos de controle de congestionamento nas extremidades da comunicação (hosts), sendo estes responsáveis pela sua detecção e reação. Já o controle de congestionamento baseado em roteadores, também conhecido na literatura como controle de congestionamento assistido pela rede, aplica mecanismos nos roteadores intermediários para este fim. Dado que uma rede é um sistema distribuído,XU et al.(2011) afirmam que para resolver o problema do congestionamento

(23)

2.2. CONTROLE DE CONGESTIONAMENTO BASEADO EM ORIGEM 22

neste sistema é necessária aplicação de uma solução distribuída. Tal solução passa pela aplicação de mecanismos de controle de congestionamento baseados na origem e também nos roteadores intermediários.

Um evento de congestionamento afeta em diversas maneiras o tráfego de informações pela rede. As perdas de pacotes causadas por descartes e o enchimento de filas nos roteadores ao longo do caminho afetam a taxa de transferência, o atraso, a justiça entre os fluxos e tantas outras métricas consideradas na avaliação de desempenho de uma rede.

A taxa de transferência representa a quantidade de dados transferida por unidade de tempo. O atraso representa o tempo que a informação leva para seguir do emissor ao receptor e a chegada da respectiva confirmação de recebimento. A justiça define quão igualitária é a distribuição dos recursos entre os fluxos concorrentes.

Algoritmos clássicos de controle de congestionamento como o Tahoe e o Reno, quando operam no regime de prevenção de congestionamento, aumentam sua janela de congestionamento — Congestion Window (CWND) em 1 segmento de dados por RTT. Este crescimento lento

tornou-se um problema com o avanço das redes de alta velocidade e longos atrasos de propagação, as chamadas Long Fat Networks (LFNs). O BDP é o produto entre a banda e o atraso de propagação de ida e volta. Ele representa a quantidade de bits em trânsito (in-flight) para a completa utilização da banda. Assim, a grosso modo, para ter a utilização integral de um canal de comunicação Ethernetcom 1 Gbps de largura de banda e 100 ms de atraso seriam necessários 100 milhões de bitsem trânsito. Considerando um quadro Ethernet de 1518 Bytes, que corresponde a 12.144 bits, seria necessária uma janela de congestionamento de 8.234 pacotes para se atingir a completa utilização do canal.

2.2 CONTROLE DE CONGESTIONAMENTO BASEADO EM

ORIGEM

O controle de congestionamento baseado na origem refere-se a um conjunto de um ou mais mecanismos que agem nas extremidades da comunicação com o objetivo de prevenir ou reagir a um evento de congestionamento. Para atingir tal objetivo temos abordagens baseadas em perdas e as baseadas em atraso.

2.2.1 Abordagens baseadas em perdas

No controle de congestionamento baseado em perdas, o emissor aumenta o valor da janela de congestionamento até que um pacote seja perdido. A perda do pacote é interpretada como sinal de congestionamento. Desconsiderando a perda de pacotes por falhas no meio de transmissão, ela é ocasionada pelo transbordo das filas nos roteadores ao longo do caminho

(24)

Algoritmos clássicos de controle de congestionamento, como o Reno, aplicam algoritmos diferentes em cada fase da transferência de dados.ALLMAN; PAXSON; BLANTON(2009) definem quatro algoritmos de controle de congestionamento fortemente interligados que são utilizados em fases distintas da transmissão: inicialização lenta (slow-start), prevenção de congestionamento (congestion avoidance), retransmissão rápida (fast retransmit) e recuperação rápida (fast recovery).

No início da transmissão, o emissor desconhece a capacidade e as condições da rede. O algoritmo de inicialização lenta tem o papel de iniciar a transmissão enviando uma pequena quantidade de dados e aumentando-a gradativamente até que seja atingida a sua capacidade máxima. Nos algoritmos baseados em janela, como o TCP, para cada segmento enviado é esperada uma confirmação de recebimento, acknowledgment (ACK). Nesta fase da transmissão, para cada novo ACK recebido, o tamanho da janela de congestionamento é incrementado em 1, fazendo um crescimento exponencial, duplicando o tamanho da janela a cada RTT.

Após o tamanho da janela atingir a capacidade máxima de transmissão na fase de inicialização lenta, a rede entrará em estado de congestionamento e segmentos serão perdidos. Após o evento de perda, o valor do limiar ssthresh é definido para a metade do tamanho atual da janela de congestionamento e, em seguida, o tamanho da janela é reiniciado. O mecanismo continuará no estado de inicialização lenta e crescerá o tamanho da janela de congestionamento em 1 segmento a cada ACK recebido até que o valor de ssthresh seja ultrapassado. Após o tamanho da janela ultrapassar o valor definido para ssthresh, o mecanismo irá mudar para o estado de prevenção de congestionamento. Enquanto estiver neste estado, o tamanho da janela de congestionamento crescerá em 1 segmento a cada RTT, reduzindo o ritmo de crescimento. Após um novo evento de perda, o mecanismo registra o valor de ssthresh novamente, reinicia o valor de cwnd e comuta para o algoritmo de inicialização lenta novamente.

Para cada segmento enviado, um timer é iniciado com a função de identificar a perda do segmento. Caso não seja recebido o ACK correspondente antes da expiração do timer, este segmento é considerado perdido e é então reenviado. Aguardar pela expiração do timer pode causar o congelamento da rede, pois a janela de congestionamento não progride além desse segmento perdido até que o ACK correspondente seja recebido. Dado que ao receberem um segmento fora de sequência, os receptores reagem confirmando o recebimento do último recebido em sequência, o algoritmo de retransmissão rápida age reenviando os segmentos possivelmente perdidos antes mesmo da expiração do timer na ocorrência do recebimento de ACKs duplicados.

Após a redução da janela de congestionamento em decorrência da detecção do conges-tionamento, é necessário que o tamanho da janela de congestionamento volte a crescer para encontrar o maior valor possível e assim obter a melhor taxa de transmissão. A busca pela recuperação do valor máximo da janela de congestionamento após a redução é denominada recuperação rápida.

Vários problemas relacionados aos algoritmos baseados em perdas estão citados na literatura. De acordo comMO et al.(1999) o mecanismo de prevenção de congestionamento

(25)

adotado pelo Reno causa oscilações periódicas no tamanho da janela de congestionamento, dada a atualização constante do seu tamanho. A oscilação frequente no tamanho da janela também acarreta em variações constantes no RTT (jitter) e ineficiência no uso total da banda disponível em decorrência de frequentes retransmissões.

HighSpeed TCP foi a primeira proposta para modificação do controle de congestiona-mento baseado em perda para redes de alto BDP proposta porFLOYD(2003). Ela observou que em ambientes estáveis, seguindo as taxas de crescimento dos algoritmos de controle de congestionamento clássicos, o tamanho da janela de congestionamento é aproximadamente 1, 2/√psegmentos, onde p é a taxa de perda de pacotes. Tal limite impõe restrições ao uso dos algoritmos clássicos em redes de alta velocidade. HighSeep TCP é apresentado como alterativa com uma abordagem para definição do tamanho da janela de congestionamento em função da taxa de perda de pacotes.

HA; RHEE(2011) afirmam que o crescimento exponencial da janela de

congestiona-mento na fase de inicialização lenta resulta em uma rajada de perda de pacotes. Eles observaram também que em redes com alto BDP, a sobrecarga gerada na rede em decorrência destas rajadas resulta em rupturas da rede, ocasionando períodos de inatividade, gerando baixa utilização da banda. Hybrid Slow Start (HyStart) (HA; RHEE,2008) é um algoritmo de inicialização lenta que mantém o crescimento exponencial do algoritmo clássico, mas comuta para a fase de prevenção de congestionamento antes que a rede seja sobrecarregada. Para isso ele monitora tamanhos dos trens de ACKs, uma grande quantidade de ACKs recebidos em um curto intervalo de tempo, e o aumento do RTT.

Outras abordagens substituíram o crescimento linear da janela de congestionamento durante a fase de prevenção de congestionamento por curvas mais agressivas a fim de recuperar mais rapidamente o patamar atingido antes do evento de congestionamento, bem como sondar nova banda disponível. O CUBIC (HA; RHEE; XU, 2008), que surgiu como uma versão melhorada do BIC-TCP (XU; HARFOUSH; RHEE,2004), apresenta o crescimento da janela de congestionamento definido por uma função cúbica. Mais detalhes sobre o mecanismo CUBIC serão vistos na seção 2.4.1.

2.2.2 Abordagens baseadas em atraso

Os algoritmos de controle de congestionamento baseados em atraso utilizam a medida do RTT para estimar a capacidade e identificar congestionamentos na rede. O uso do atraso em detrimento da perda visa agir preventivamente à ocorrência do congestionamento ao invés de reagir após a sua ocorrência, como acontece na abordagem por perdas. Nos eventos de congestionamento as filas dos roteador tendem a aumentar, visto que a taxa de chegada de pacotes é maior do que a taxa de saída.

O Vegas (BRAKMO; PETERSON,1995) é um algoritmo clássico de controle de conges-tionamento para a Internet que faz uso do RTT para estimativa da capacidade de transmissão

(26)

da rede. Para estimar a capacidade ele calcula o BDP esperado, dividindo o tamanho atual da janela de congestionamento cwnd pela estimativa do tempo de propagação da rede – Round-trip Propagation Delay(RTPD). O menor valor do RTT observado durante todo o período do fluxo é tomado como estimativa do tempo de propagação.

BDP_esperado= cwnd BaseRT T 2.1

Calculado o BDP esperado, o próximo passo é verificar a quantidade de dados em trânsito. Para isso o Vegas mede a quantidade de dados enviados entre um pacote qualquer até a chegada do seu respectivo ACK. A diferença ∆ entre a quantidade de dados mantida em trânsito e a estimativa do BDP é a quantidade de dados armazenada nos buffers ao longo da rede. O Vegas define dois limites para a quantidade de dados armazenadas em buffers, sendo α o limite inferior e β o limite superior. Quando a diferença entre a quantidade de dados armazenada nos buffers é inferior a α indica que poucos dados acima do BDP estimado estão em trânsito, podendo haver subutilização da banda disponível. Neste caso o tamanho da janela é incrementado. Já quando é superior a β há muitos dados em buffers gerando congestionamento na rede. Neste caso, o tamanho da janela é reduzido. Quando o valor de ∆ encontra-se entre α e β , o valor de cwnd é mantido. Como os efeitos do aumento ou redução do tamanho da janela demoram pelo menos um RTT para serem notados, o cálculo do novo valor de cwnd é realizado a cada dois RTTs. A Equação 2.2 resume o comportamento de cwnd em reposta às variações de ∆.

cwnd=          cwnd+ +, se ∆ < α cwnd, se α6 ∆ 6 β cwnd− −, se ∆ > β 2.2

Dentre os problemas conhecidos dos algoritmos de controle de congestionamento baseado em atraso está o impacto da estimativa errada do tempo de propagação - RTPD. O BaseRTT (Equação 2.3), tomado como estimativa do tempo de propagação, na verdade é a soma do tempo de propagação tp, acrescido do tempo de fila tq. Assim, aqueles fluxos que são iniciados em

estados de ocupação diferentes têm uma percepção diferente do estado da rede. Fluxos iniciados quando a taxa de ocupação do canal está baixa (menor tempo de fila), possuem uma menor estimativa do tempo de propagação RTPD. Já aqueles iniciados com a taxa de ocupação alta (maior tempo de fila), possuem uma estimativa maior.

BaseRT T = tp+ tq. 2.3

O impacto da estimativa incorreta do tempo de propagação incorre na redução da justiça na divisão da banda entre os fluxos. Por terem uma estimativa maior do tempo de propagação, aqueles fluxos iniciados em momentos de maior carga possuem uma estimativa menor do tempo de fila. Esta discrepância na visão acaba por privilegiar aqueles fluxos que iniciaram em

(27)

momentos de maior carga.

MO et al.(1999) apresentaram um estudo que demonstrou a existência de um cenário

ao qual chamaram de congestionamento persistente no Vegas. Segundo os autores, o erro de estimativa do RTPD leva a um crescimento das filas nos roteadores e o problema se repete sucessivas vezes à medida que novos fluxos são iniciados em um canal já congestionado, levando a rede a um estado de congestionamento persistente. Os autores, por considerarem que o Random Early Detection(RED) é um algoritmo amplamente difundido nos roteadores da Internet, sugerem uma modificação no Vegas para que após terem seus pacotes descartados, reajam de forma a fazer uma nova estimativa do BaseRTT e reiniciar sua janela de congestionamento. Assim, esperam que os fluxos mais antigos passam ter a mesma percepção de congestionamento dos fluxos mais recentes.

LOW; PETERSON; WANG(2002) minimizam o problema justificando que a natureza

dos fluxos da Internet não é o de início de fluxos em série, e que os fluxos são iniciados e finalizados continuamente.TAN; YUAN; ZUKERMAN(2005) apresentam uma proposta para solução do problema por meio da marcação de prioridade no primeiro pacote de caxa fluxo. Assim, a estimativa do BaseRTT estaria isenta do atraso de fila.

MO et al.(1999) também relatam incompatibilidades entre o algoritmo Vegas e o Reno. O Reno, por ser um algoritmo baseado em perda, age congestionando e descongestionando repetidas vezes o canal de comunicação, crescendo a janela de congestionamento até que um pacote seja perdido. Como o Vegas age de forma preventiva, reduzindo sua janela de congestionamento ao observar um aumento no tempo de fila, ao perceber o crescimento causado pelo fluxo Reno, reduz o tamanho da sua janela, acarretando assim em uma divisão desigual da banda em favor do fluxo que utiliza o algoritmo Reno.

Outro problema conhecido é que o algoritmo não é capaz de identificar mudanças de rotas devido às mudanças no RTT em decorrência da diferença entre o tempo de propagação existente no canal de origem e destino (MO et al.,1999). A solução proposta pelos autores seria atualizar o BaseRTT apenas nos K primeiros pacotes e não ao longo de todo o ciclo de vida do fluxo. Ao perceber um grande aumento no RTT o algoritmo interpretaria tal crescimento como mudança de rota. O algoritmo faria então uma nova estimativa do BaseRTT e reiniciaria sua janela de congestionamento. SegundoLOW; PETERSON; WANG(2002) quando a mudança ocorre para um canal de comunicação com o tempo de propagação menor, o problema causa menos transtornos, visto que o BaseRTT é rapidamente corrigido para o novo valor do RTT medido. Para casos onde a mudança ocorre para um canal de comunicação com o RTPD maior o algoritmo considera que a rede está congestionada, impedindo o uso efetivo da banda disponível.

BULLOT; LES COTTRELL; HUGHES-JONES(2003) publicaram um estudo onde é

identificado que os algoritmos baseados em atraso, como o Vegas e o FAST, estão sujeitos a interferências na ocorrência de congestionamento no sentido contrário do fluxo. Os atrasos enfrentados pelos ACKs enviados pelos receptores ao experimentarem filas no caminho até o emissor ocasionam o aumento do RTT. Para solucionar o problema, eles sugeriram a utilização

(28)

de timestamps no TCP para permitir a utilização do atraso unidirecional no cálculo das estimativa do BDP. Mais detalhes sobre o mecanismo FAST serão vistos na seção 2.4.2.

2.2.3 Abordagens híbridas

Dados os problemas relatados com a utilização das abordagens baseadas em perda e baseadas em atraso, os algoritmos híbridos procuram mitigar as desvantagens de cada tipo, utilizando técnicas presentes em ambos.

Sync TCP (WU et al.,2009) é um algoritmo híbrido que funciona em muitos aspectos de forma parecida com os demais algoritmos baseados em atraso. Para resolver o problema da justiça entre fluxos com estimativas diferentes do RTPD e o congestionamento persistente, o Sync posterga a redução do cwnd quando detecta um aumento significativo no tempo de fila e postega também o crescimento de cwnd após um evento de redução da janela em decorrência da detecção de congestionamento.

O motivo da postergação tanto da redução, quanto do crescimento de cwnd é utilizado para sincronizar a percepção de congestionamento na rede para todos os fluxos. Aqueles fluxos que inciaram depois, por terem uma estimativa maior do RTPD precisam de um aumento maior na fila para detectá-lo. Após detectado o congestionamento os fluxos reduzem sua janela de congestionamento e permanecem assim por um tempo suficiente para o esvaziamento das filas dos roteadores. Com as filas dos roteadores vazias, finalmente todos os fluxos ativos poderão atualizar suas estimativas do RTPD e todos terão uma visão igualitária na percepção do congestionamento. Por ser um algoritmo híbrido, o Sync também reage às perdas de pacotes. Na detecção de perda a janela de congestionamento é reduzida pelo fator de decrescimento β , assim como ocorre nos algoritmos baseados em perda. O que faz o Sync diferente neste aspecto, é que o Sync utiliza um valor de β dinâmico, em função do tempo de fila experimentado pelo fluxo. Este valor dinâmico atribuído a β permite controlar o quão rápido a janela irá diminuir em um evento de congestionamento.

Outras abordagens híbridas também foram propostas. Compound TCP (SONG; ZHANG;

SRIDHARAN,2006) é um mecanismo híbrido que adiciona um componente baseado em atraso

no mecanismo Reno com o objetivo de crescer rapidamente a janela de congestionamento quando houver banda disponível e reduzir de forma gradual durante a ocorrência de evento de congestionamento. CUBIC-FIT (WANG et al.,2013) é uma proposta para modificação do mecanismo CUBIC que utiliza o atraso fim-a-fim para definir os parâmetros C e β , a fim de controlar o crescimento e decrescimento da janela de congestionamento em função do atraso.

(29)

2.3. CONTROLE DE CONGESTIONAMENTO BASEADO EM ROTEADOR 28

2.3 CONTROLE DE CONGESTIONAMENTO BASEADO EM

ROTEADOR

Algoritmos de controle de congestionamento baseados em roteadores, ou gerenciamento ativo de filas, são métodos proativos de prevenção de congestionamento em redes de compu-tadores. Eles agem descartando preventivamente pacotes antes que os buffers fiquem cheios, causando perda em massa de pacotes e causando a perda de sincronismo dos algoritmos em execução nos hosts.

RED (FLOYD; JACOBSON,1993) age monitorando as filas de saída dos roteadores e medindo sua média. Após a média ultrapassar o valor pre-estabelecido os pacotes são descartados de forma aleatória. Dado que os fluxos com a maior parcela da banda têm uma probabilidade maior de descarte, ele acaba favorecendo a justiça na distribuição da banda entre os fluxos. Mais detalhes sobre o mecanismo RED serão vistos na seção 2.4.3.

2.4 MECANISMOS DE CONTROLE DE CONGESTIONAMENTO

A seguir apresentamos em mais detalhes alguns controles de congestionamentos que serão utilizados para avaliação do controle de congestionamento na arquitetura RINA. Foram escolhidos um mecanismo baseado em perda (CUBIC), um baseado em atraso (FAST), e um baseado em roteador (RED). A escolha do mecanismo CUBIC se deu pela sua presença nos sistemas Linux amplamente difundidos na Internet. Já o FAST, foi escolhido para representar os mecanismos de controle de congestionamento baseados em atraso por ter sido desenvolvido para canais de comunicação com alto BDP. O RED, por sua vez, foi escolhido por estar amplamente difundido nos roteadores da Internet.

2.4.1 CUBIC

O CUBIC é um mecanismo de controle de congestionamento baseado em perda proposto porHA; RHEE; XU(2008). Ele substitui o crescimento linear dos algoritmos de controle de congestionamento clássicos da Internet por uma função cúbica, que responde mais rapidamente em conexões de alta velocidade e longa distância, caracterizadas por um alto BDP.

No algoritmo Reno, após a detecção do congestionamento, o tamanho da janela de congestionamento é reduzido por um fator multiplicativo de 50%. Após a redução, o crescimento é realizado de forma aditiva, incrementando o tamanho da janela em 1 segmento por RTT. O CUBIC utiliza dois parâmetros que controlam o crescimento C e a redução β do tamanho da janela de congestionamento.

Durante a fase de inicialização lenta, o CUBIC aumenta a janela de congestionamento incrementando cwnd em 1 a cada ACK recebido, criando um crescimento exponencial, que também é observado nos algoritmos clássicos de controle de congestionamento baseados em

(30)

2.4. MECANISMOS DE CONTROLE DE CONGESTIONAMENTO 29

perda. Após a detecção do congestionamento por meio da perda de um pacote, o algoritmo comuta para a fase de prevenção de congestionamento. Nesta fase ele passa a utilizar uma função cúbica para definir o crescimento da janela. O crescimento exponencial é indicado na Figura 2.1 pela indicação 1 . 0 10 20 30 40 50 60 70 0 500 1000 1500 2000 2500 3000 3500

Janela de congestionamento CUBIC

tempo (s) CWND (PDUs) 1 2 3 4

Figura 2.1: Janela de congestionamento CUBIC Fonte: Do experimento.

A função cúbica promove o crescimento do tamanho da CWND de acordo com a curva mostrada na Figura 2.2. O crescimento do tamanho da janela segue um formato convexo até atingir o valor de saturação Wmax, reduzindo gradativamente sua taxa de crescimento até o valor

de saturação ser atingido. Após ultrapassar a barreira de saturação, o algoritmo inicia uma fase de sondagem, onde apresenta um formato côncavo.

O tamanho da CWND é dado pela Equação 2.4, onde W (t) representa o valor de CWND, Co fator da função cúbica, t o tempo desde o último evento de congestionamento, K o fator de tempo, e Wmax o valor registrado de CWND no último evento de congestionamento.

W(t) = C · (t − K)3+W_max 2.4 O fator de tempo K é dado pela Equação 2.5, onde β representa o fator de crescimento da função cúbica. K= 3 r W_max.β C 2.5

(31)

Wmax

Estado estacionário Sondagem

Figura 2.2: Gráfico da função cúbica

Fonte: Adaptado deHA; RHEE; XU(2008).

Após um evento de congestionamento, o tamanho atual da janela de congestionamento é registrado em Wmax e então reduzido por um fator de decrescimento β (cwnd = cwnd · (1 − β )).

Nesta fase, a de recuperação rápida, o tamanho da janela cresce rapidamente até atingir novamente o limiar de saturação, representado na Figura 2.1 pela indicação 2 .

A fim de detectar um possível aumento na banda disponível, após ultrapassar o limiar de saturação, o valor de CWND cresce de forma mais agressiva. Esta fase é chamada de sondagem e é apresentada na Figura 2.1, na indicação 3 .

Na ocorrência de um novo evento de congestionamento ainda na fase de recuperação rápida, ou seja, antes que o valor da janela atinja o definido em Wmax, o CUBIC entra na fase de

convergência rápida. Um evento de congestionamento antes que Wmax seja atingido sugere que

houve redução na banda disponível. A entrada na fase de convergência rápida é indicada por 4 na Figura 2.1. Na entrada da fase de convergência rápida, o valor de Wmax é dado pela Equação

2.6. Wmax = cwnd 2 − β 2 2.6

O crescimento do tamanho da janela de congestionamento no CUBIC tende a ser muito lento em casos cujo valor do RTT seja pequeno. Em alguns casos, a função cúbica resulta em um crescimento inferior ao registrado nos algoritmos clássicos. Para resolver este problema, o mecanismo possui um modo de compatibilidade TCP. Neste modo uma estimativa do tamanho da janela no algoritmo clássico é realizado e, caso este tamanho seja superior ao obtido por meio da função cúbica, este será utilizado para atualizar o valor da janela de congestionamento. A Equação 2.7 mostra como o tamanho da janela de congestionamento é calculado no modo de compatibilidade TCP.

(32)

2.4. MECANISMOS DE CONTROLE DE CONGESTIONAMENTO 31 W_tcp(t)= Wmax(1 − β ) + 3 β 2 − β t RT T 2.7

HA; RHEE; XU(2008) citam diversas características que renderam ao CUBIC a escolha como o mecanismo padrão de controle de congestionamento no kernel do Linux. Diversas modificações foram feitas desde a sua primeira versão com objetivo de deixá-lo rápido e estável. Abaixo são apresentadas características importantes encontradas no CUBIC:

Independência do RTT: Devido ao crescimento do tamanho da janela ser em função do tempo desde o último congestionamento ocorrido, o algoritmo cresce o tamanho da janela na mesma velocidade para fluxos com diferentes RTTs, evitando que a banda seja consumida de forma desproporcional por aqueles fluxos com menor RTT;

Estável: Após a detecção de um congestionamento, o tamanho da janela de congesti-onamento cresce rapidamente e estabiliza ao se aproximar do ponto de saturação;

Justiça: Na ocorrência de um congestionamento durante a fase de recuperação rápida, Wmax é decrescida a uma taxa maior em função de β com o objetivo de liberar banda

para os demais fluxos concorrentes, em virtude da redução da banda disponível;

Escalável: Após ultrapassar o ponto de saturação o algoritmo entra na fase de sondagem para identificar possíveis aumentos na banda disponível.

2.4.2 FAST TCP

O FAST TCP é um controle de congestionamento baseado em origem e RTT proposto porWEI et al.(2006) projetado para redes de alta velocidade e longa distância. Ele baseia-se no RTT para definir o tamanho da janela de congestionamento. Variações positivas do RTT são interpretadas pelo algoritmo como aumento do tamanho das filas ao longo do caminho, caracterizando congestionamento.

O tamanho da janela de congestionamento é calculado em intervalos regulares de 20 ms, como propõeWEI et al.(2006), de acordo com a Equação 2.8, onde w é o tamanho da janela de congestionamento, γ define o fator de peso, BaseRT T é o menor RTT observado durante o período do fluxo, RT T é o valor atual do RTT e α é a quantidade de pacotes esperada nas filas ao longo do caminho. Para evitar o crescimento demasiado em um curto intervalo de tempo, o FAST limita o crescimento da janela de congestionamento em até duas vezes o seu tamanho a cada recálculo. Esta medida visa dar estabilidade ao tamanho da janela de congestionamento.

w= min 2w; (1 − γ) · w + γ BaseRT T RT T · w + α 2.8

O fator γ define o peso entre o último valor registrado para o tamanho da janela e o valor a ser atribuído com base na estimativa do RTT atual. O valor de γ é definido no intervalo

(33)

(0,1]. Valores próximo a zero tendem a reduzir as mudanças causadas no tamanho da janela pela variação do RTT. Valores próximos a 1 tendem a reproduzir mais rapidamente no valor da janela de congestionamento as variações ocorridas na estimativa do RTT atual. O valor do fator α define a quantidade de pacotes aguardando nas filas dos roteadores ao longo do caminho.

A Figura 2.3 mostra a evolução do tamanho da janela deslizante durante o ciclo de vida do fluxo. No instante 1 podemos observar que o tamanho da janela mantém-se estável ao limite máximo obtido no experimento. No instante 2 temos a concorrência entre dois fluxos e podemos observar que houve uma redução no tamanho da janela. Após o instante 3 observamos a recuperação do valor anterior registrado para o tamanho da janela.

0 10 20 30 40 50 60 70 0 500 1000 1500 FAST tempo (s) CWND 1 2 3

Figura 2.3: Janela de congestionamento FAST Fonte: Do experimento.

O resultados dos experimentos realizados porWEI et al.(2006) mostraram que o FAST teve um bom desempenho em termos de vazão (throughput), justiça, estabilidade e responsivi-dade.

2.4.3 RED — Random Early Detection

RED é um mecanismo de controle de congestionamento baseado em roteador que detecta o congestionamento por meio do monitoramento do tamanho das filas. Ele age descartando prematuramente pacotes para sinalizar congestionamento antes que as filas se tornem comple-tamente cheias e haja o descarte em massa de pacotes. O algoritmo define um limiar para a

(34)

2.5. CONSIDERAÇÕES FINAIS 33

média do tamanho da fila que, ao ser ultrapassado, faz o descarte aleatório dos pacotes que ingressam. A probabilidade de descarte do pacote aumenta à medida que o tamanho médio da fila se aproxima da sua capacidade máxima. Dada à natureza aleatória do descarte, os fluxos com a maior fatia da largura de banda são mais propícios a terem seus pacotes descartados.

O cálculo da probabilidade de descarte de um pacote no RED é feito em etapas. Pri-meiramente calcula-se o tamanho médio de ocupação da fila avg, conforme a Equação 2.9. O peso wq, definido no intervalo (0, 1], determina o quão rápido a média irá refletir as variações no

tamanho instantâneo da fila q. Valores próximos a 0 tornam a reação do tamanho da fila mais lenta. Valores próximos a 1 tornam a reação mais rápida.

avg= (1 − wq)avg + wq.q 2.9

De posse da ocupação média da fila, calcula-se a probabilidade de marcar o pacote de acordo com a Equação 2.10, onde pbrepresenta a probabilidade temporária de marcação

do pacote, maxp o valor máximo de pb. As variáveis minth e maxth representam o limiar de

marcação de pacotes e a capacidade máxima da fila.

p_b= maxp(avg − minth) max_th− minth 2.10

Na última etapa calcula-se a probabilidade final de marcação do pacote. O objetivo desta etapa é não retardar muito o tempo de marcação de um pacote para descarte, aumentando a probabilidade à medida que a quantidade de pacotes marcados por pbcresce.

pa= p_b 1 − count.pb 2.11

Estudos em algoritmos de gerenciamento ativo de filas conduzidos por CHANDRA;

AGARWAL; VELMURUGAN(2010) mostraram um alto grau de variação no tamanho das filas

com o uso de RED. Os autores apresentaram o Stabilized Dynamic RED (SDRED), que segundo eles, é mais eficiente e mantém as filas mais estáveis.

2.5 CONSIDERAÇÕES FINAIS

Neste capítulo foram apresentados os mecanismos de controle de congestionamento para a Internet. Foram vistos em detalhes os mecanismos CUBIC, FAST e RED que serão utilizados no capítulo 4 para avaliação dos mecanismos de controle de congestionamento.

No próximo capítulo serão apresentados conceitos da arquitetura RINA, especialmente aqueles ligados ao controle de congestionamento. O próximo capítulo também apresenta o RINASim, o simulador de utilizado para avaliação dos mecanismos de controle congestionamento propostos nos objetivos deste trabalho.

(35)

34 34 34

3

A ARQUITETURA INTER-REDES

RECUR-SIVA

Neste capítulo são apresentados conceitos da arquitetura inter-redes recursiva (RINA — Recursive InterNetwork Architecture). São apresentados detalhes de como o controle de fluxo e o controle de congestionamento são propostos na arquitetura. Também são apresentados detalhes sobre o RINASim, o simulador utilizado na avaliação dos mecanismos de controle de congestionamento.

3.1 UMA BREVE VISÃO SOBRE A ARQUITETURA RINA

RINA é uma arquitetura de rede recursiva clean slate construída sobre a premissa de que rede é apenas comunicação entre processos (IPC — Inter-Process Communication) (DAY,

2008). A arquitetura possui um conjunto de especificações que definem o funcionamento dos mecanismos e um conjunto de políticas padrão. A Pouzin Society1é a organização responsável por manter as especificações da arquitetura. Ao invés de apresentar um conjunto rígido de mecanismos com comportamento predefinidos, na arquitetura RINA a rede é vista com um conjunto reduzido de mecanismos que se repetem tantas vezes quantas forem necessárias. Estes mecanismos têm seu comportamento definido por meio de políticas.

Os mecanismos são máquinas de protocolos que podem ser empilhadas para prover serviços para as camadas superiores por meio da utilização de serviços oferecidos pelas camadas inferiores. Na Figura 3.1, N-PM representa a máquina de protocolo em estudo, (N+1)-PM a máquina de protocolo superior e (N-1)-PM a máquina de protocolo inferior. As máquinas de protocolos trocam informações com as máquinas superiores e inferiores por meio da unidade de dados chamada Service Data Unit (SDU) e com a máquina de protocolo remota por meio de Protocol Data Units (PDUs).

Um mecanismo pode, por exemplo, definir o controle de fluxo por janela deslizante, enquanto que a política define como o tamanho da janela irá progredir ao longo do ciclo

(36)

3.1. UMA BREVE VISÃO SOBRE A ARQUITETURA RINA 35

de vida do fluxo. Um outro exemplo de política pode definir qual será a ação a ser tomada quando o mecanismo de monitoramento do tamanho das filas de saída detectar que um limite de ocupação pré determinado foi ultrapassado. Assim, as políticas são responsáveis por definir o comportamento de um determinado mecanismo, permitindo que um mesmo mecanismo seja utilizado sob vários contextos. Um único mecanismo pode ter seu comportamento definido por um conjunto de uma ou várias políticas. A Figura 3.2 mostra um exemplo genérico de um mecanismo e suas políticas (DAY; MATTA; MATTAR,2008).

Máquina de protocolo (N+1)-PM (N-1)-PM Máquina de protocolo (N+1)-PM (N-1)-PM Máquina de protocolo (N+1)-PM (N-1)-PM Interface superior Interface inferior SDU SDU PDU SDU SDU SDU SDU Máquina de protocolo (N+1)-PM (N-1)-PM Máquina de protocolo (N+1)-PM (N-1)-PM Interface superior Interface inferior SDU SDU PDU SDU SDU

Figura 3.1: Máquina de protocolo

Fonte: Adaptado deDAY(2008).

função mecanismo políticas função mecanismo políticas

Figura 3.2: Mecanismo e políticas

Fonte: Adaptado deDAY(2008).

Na arquitetura RINA, a comunicação entre processos de aplicação é vista como um IPC. Para uma aplicação cliente trocar informações com uma aplicação servidora é necessário que tanto a aplicação cliente, quanto a aplicação servidora estejam inscritas na mesma Distributed Application Facility(DAF). Os IPCs das camadas inferiores, ou seja, aqueles dedicados à

comu-nicação de rede, devem pertencer a um tipo especial de DAF denominada DIF. A Application Entity(AE) é a porção da aplicação responsável pela comunicação através da rede. Para que um AE de um cliente troque informações com um AE de um servidor, é necessário que seja

(37)

3.2. O CONTROLE DE FLUXO 36

estabelecido um fluxo entre as partes comunicantes. Diversos componentes da arquitetura estão envolvidos no estabelecimento de um fluxo para que, finalmente, os dois AEs sejam capazes de trocar informações. Neste trabalho iremos focar nos componentes que estão diretamente ligados ao controle de fluxo e congestionamento.

3.2 O CONTROLE DE FLUXO

O controle de fluxo pode ser realizado tanto baseado em janela, quanto em taxa. Neste trabalho nos limitamos a tratar do controle de fluxo baseado em janela. Na Figura 3.3 é apresentado um exemplo de janela deslizante. No topo temos a janela deslizante do emissor e na base a do receptor. Cada quadro refere-se a um pacote e os números representam seus números de sequência. As setas no sentido vertical para baixo indicam os pacotes enviados e as setas no sentido vertical para cima indicam os ACKs enviados pelo receptor. As setas com comprimento completo indicam que o pacote já chegou ao destino e as com comprimento menor indicam que o pacote está em trânsito.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1 2 3 4 5 6 7 8 9 10 11 12 LWE RWE LWE RWE EMISSOR RECEPTOR

Figura 3.3: Janela deslizante Fonte: Do autor.

As PDUs com número de sequência de 1 a 4 foram enviadas e os ACKs referentes a cada uma destas já foram recebidos. As PDUs 5 a 10 foram enviadas, mas ainda não houve o recebimento dos ACKs correspondentes, tais PDUs são tidas como em trânsito ou pendentes. A PDU no emissor com o número de sequência 5 é referida como Borda Esquerda da Janela do Emissor — Sender Left Window Edge (sLWE). PDUs com números de sequência inferiores ao sLWE são consideradas completamente transmitidas e são removidas da fila de retransmissão. A PDU de número de sequência 10 é a Borda Direita da Janela do Emissor — Sender Right Window Edge(sRWE), que representa a PDU de maior número de sequência que pode ser enviada. As PDUs com número de sequência 11 a 20 não podem ser enviadas por excederem o crédito e aguardam na fila de janela fechada - Closed Window Queue.

No receptor, as PDUs marcadas em vermelho, com número de sequência de 1 a 6, foram recebidas em sequência e são postas na fila de remontagem - Reassembly Queue para serem geradas as SDUs e entregues ao processo IPC da camada superior. A PDU com número de

(38)

3.3. O CONTROLE DE CONGESTIONAMENTO 37

sequência 7 indica a Borda esquerda da janela do receptor — Receiver Left Window Edge (rLWE). PDUs recebidas com o número de sequência inferiores à rLWE são consideradas duplicatas e são imediatamente descartadas. O receptor pode limitar a quantidade máxima de PDUs que está apto a receber por meio da definição da Borda Direita da Janela do Receptor — Receiver Right Window Edge(rRWE). PDUs com número de sequência superiores ao rRWE são descartadas.

3.3 O CONTROLE DE CONGESTIONAMENTO

Após a criação de um fluxo entre a origem e o destino, o Flow Allocator (FA), compo-nente responsável por localizar a aplicação de destino e estabelecer comunicação com a AE servidora, cria um nova instância do FA (Flow Allocator Instance (FAI)). A FAI é responsável por gerenciar o fluxo durante todo o seu ciclo de vida. A FAI cria então uma instância do Error and Flow Control Protocol(EFCP), chamada Error and Flow Control Protocol Instance (EFCPI). O EFCP é o mecanismo responsável pelo controle de fluxo entre os AEs de origem e de destino. Uma instância EFCPI é mantida durante todo o ciclo de vida do fluxo. Para a realização do controle de fluxo, ele possui uma instância do Data Transfer Protocol (DTP), um conjunto de mecanismos que estão fortemente ligados ao processamento das PDUs e, caso seja necessário o controle de fluxo, uma instância do Data Transfer Control Protocol (DTCP), um conjunto de mecanismos ligados ao controle de fluxo (DAY,2014).

No DTP, as Data Transfer PDUs (DT-PDUs) são criadas e inseridos o número de sequência, endereços do processo de aplicação de origem e de destino, bem como os dados provenientes do Comunicação entre processos - Inter-Process Communication (IPC) das camadas superiores, após a passagem pelo módulo de delimitação, que divide ou concatena SDUs recebidas a fim de adequá-las ao tamanho máximo da PDU a ser transmitida. Caso o controle de fluxo esteja ligado, as PDUs são postas na fila de PDUs geradas para serem processadas pelo módulo em coordenação com o mecanismo DTCP.

O módulo DTCP move quantas PDUs a janela permitir da fila de PDU geradas para a fila de PDUs postáveis (PostablePDUQ), ou seja, enquanto o número de sequência da PDU for menor ou igual ao sRWE. Caso o limite imposto pela sRWE seja ultrapassado, a janela de transmissão é fechada e as PDUs com número de sequência maior que sRWE serão postas na Closed Window Queue (CWQ) até que a janela deslizante desloque-se para a direita e seja novamente aberta. A fila CWQ também tem uma capacidade máxima. Ao atingir este limite a política de SndOverrun é executada.

Se a retransmissão estiver ligada, o DTCP faz uma cópia de cada PDU presente na fila PostablePDUe as coloca na fila de retransmissão juntamente com um timer, e envia as PDUs originais para o módulo Relaying and Multiplexing Task (RMT). A função do timer colocado junto com a PDU na fila de retransmissão tem a função de retransmitir a PDU caso expire. Os timerssão cancelados assim que uma configuração de recebimento ACK for recebida do receptor.