Trabalho de Conclusão de Curso...Trabalho de Conclusão de Curso: Um estudo sobre os impactos do delay e da perda de pacotes no throughput de Redes Definidas por Software Natal/RN,

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

DEPARTAMENTO DE ENGENHARIA DE COMUNICAÇÕES

BACHARELADO EM ENGENHARIA DE TELECOMUNICAÇÕES

Trabalho de Conclusão de Curso:

Um estudo sobre os impactos do delay e da perda de pacotes no throughput de

Redes Definidas por Software

Natal/RN, 17 de dezembro de 2018

1

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

DEPARTAMENTO DE ENGENHARIA DE COMUNICAÇÕES

BACHARELADO EM ENGENHARIA DE TELECOMUNICAÇÕES

PRISCILA DA SILVA ALVES

[email protected]

Trabalho de Conclusão de Curso:

Um estudo sobre os impactos do delay e da perda de pacotes no throughput de

Redes Definidas por Software

Trabalho de Conclusão de Curso apresentado

ao Departamento de Engenharia de

Comunicações da UFRN, como requisito para

obtenção do título de Bacharela em

Engenharia de Telecomunicações.

Orientador: Prof. Dr. Gutembergue Soares da Silva.

____________________________________________________

Gutembergue Soares da Silva (matrícula 3466053)

____________________________________________________

Priscila da Silva Alves (matrícula 2016008783)

Natal/RN, 17 de dezembro de 2018

2

RESUMO

O delay e a perda de pacotes são parâmetros que não são levados em consideração

durante o cálculo do throughput do frame Ethernet. No entanto, eles tem forte influência na

largura de banda da janela TCP e isso acaba influenciando no resultado do throughput obtido

durante a transmissão da informação entre as aplicações. Ao analisar a forma como esses

dois elementos interferem na qualidade da conexão de uma rede é possível avaliar o que

isso reflete nas aplicações que fazem uso do ambiente. Sabe-se que as tecnologias e os

paradigmas associados ao ambiente de redes de computadores estão em constante

evolução, nesse contexto surgiram as Redes Definidas por Software (SDN, do inglês

Software-Defined Networking), que é um paradigma de comunicação onde a função de

controle é retirada da camada de rede e vai para a camada de aplicação, passando a ser de

responsabilidade do controlador da rede. Neste trabalho, foram analisados os impactos do

delay e da perda de pacotes em um cenário constituído por um controlador POX, utilizando o

protocolo OpenFlow 1.0. O ambiente de emulação utilizado foi o Mininet, onde é possível

definir a largura de banda, o delay e a perda de pacotes do canal de comunicação. Foram

realizados testes de throughput para diferentes valores de delay e perda de pacotes, de

modo a analisar o quanto cada um desses elementos pode influenciar o throughput de uma

rede SDN.

Palavras-chave: SDN, OpenFlow, POX, throughput, delay, perda de pacotes.

3

Lista de Figuras

Figura 1: frame Ethernet. 14

Figura 2: cabeçalho TCP. 15

Figura 3: uma visão esquemática de SDN implementado com OpenFlow. 16

Figura 4: arquitetura do cenário implementado durante o experimento. 26

Figura 5: exemplo de inicialização de uma rede customizada junto ao controlador

POX. 28

Figura 6: consulta à tabela de fluxos dos switches, após um pingall ser realizado no

cenário de teste. 29

Figura 7: fluxos de protocolos utilizados no cenário de teste. 29

Figura 8: Throughput simulado para diferentes valores de delay. 31

Figura 9: Throughput simulado para diferentes valores de perda de pacotes. 33

Figura 10: exemplo de saída de um teste de throughput TCP com o iPerf. 39

Figura 11: conteúdo da mensagem OFPT_HELLO. 44

Figura 12: conteúdo da mensagem OFPT_FEATURES_REQUEST. 44

Figura 13: conteúdo da mensagem OFPT_FEATURES_REPLY. 45

Figura 14: conteúdo da mensagem OFPT_SET_CONFIG. 45

Figura 15: conteúdo da mensagem OFPT_BARRIER_REQUEST. 46

Figura 16: conteúdo da mensagem OFPT_BARRIER_REPLY. 46

Figura 17: conteúdo da mensagem OFPT_FLOW_MOD. 47

Figura 18: conteúdo da mensagem OFPT_PORT_STATUS. 48

Figura 19: conteúdo da mensagem OFPT_PORT_MOD. 48

Figura 20: conteúdo da mensagem OFPT_PACKET_OUT. 49

Figura 21: conteúdo do campo Ethernet, da mensagem OFPT_PACKET_OUT. 49

Figura 22: conteúdo do campo LLDP, da mensagem OFPT_PACKET_OUT. 50

Figura 23: conteúdo da mensagem OFPT_PACKET_IN. 50

Figura 24: conteúdo do campo Ethernet, da mensagem OFPT_PACKET_IN. 51

Figura 25: conteúdo do campo LLDP, da mensagem OFPT_PACKET_IN. 51

4

Lista de Tabelas

Tabela 1: variação do throughput em função da variação do delay. 33

Tabela 2: variação do throughput em função da variação da perda de pacotes. 35

Tabela 3: variação do RTO em função da variação do delay 37

Tabela 4: Largura de Banda da janela TCP, para diferentes valores de RTT, RTO,

taxa de perda de pacotes, b e largura da janela TCP. 39

5

Lista de Abreviaturas e Siglas

• SDN: Software-Defined Networking.

• OSI: Open System Intercommunication.

• ISO: International Organization of Standardization.

• TCP: Transmission Control Protocol.

• UDP: User Datagram Protocol.

• MAC: Media Access Control

• IPv4: Internet Protocol version 4.

• RDT: Reliable Data Transfer.

• TC: Traffic Control.

• RTT: Round Trip Time.

• ACK: Acknowledgement.

6

SUMÁRIO

1. INTRODUÇÃO 09

2. MÉTODOS 11

3. OBJETIVOS 12

4. FUNDAMENTAÇÃO TEÓRICA 13

4.1 Modelo OSI 13

4.2 Redes Definidas por Software 15

4.3 Protocolo OpenFlow 17

4.4 Controlador POX 18

4.4.1 openflow.discovery 19

4.4.2 openflow.spanning_tree 19

4.4.6 forwarding.l2_pairs 20

4.5 Largura de Banda 20

4.6 Largura de banda da janela TCP 20

4.7 Throughput 21

4.8 Throughput do frame Ethernet 21

4.9 Throughput TCP 22

4.10 Latência 24

4.11 RTT e RTO do protocolo TCP 24

4.9 Comando TC 26

4.10 Mininet 27

4.11 iPerf 27

5. CENÁRIO 29

5.1 Descrição do cenário 29

5.2 Algoritmo customizado utilizado para construir a rede 30

5.3 Controlador POX 31

5.4 Tabela de fluxos e pacotes transmitidos 32

6. EXPERIMENTOS 33

6.1 Influências do delay 33

6.2 Influências da perda de pacotes 35

7

7. ANÁLISE DOS RESULTADOS 37

7.1 Largura de banda da Janela TCP 39

7.2 Throughput do Jumbo Frame 40

7.3 Considerações sobre o uso de Redes Definidas por Software 41

7.4 Considerações sobre os impactos do delay e da perda de pacotes na voz 41

8. CONCLUSÕES 43

ANEXO 1 44

REFERÊNCIAS 52

8

1. INTRODUÇÃO

O throughput (ou a vazão, em português) de uma rede de computadores, quando

medido na camada de transporte, representa a velocidade com que a aplicação de origem

conseguirá transmitir informações pela rede até a aplicação de destino.

Ao se medir o throughput de uma rede de computadores, pode-se estimar como a

aplicação que fará uso daquela rede irá se comportar ao ser transmitida. Por exemplo, se

obtemos vazões menores em uma rede com alta taxa de perda de pacotes, sabemos que as

aplicações sensíveis a perda de pacotes sofrerão impacto durante a sua execução.

Como poderá ser observado no decorrer deste trabalho, analisando-se a rede em

nível de aplicação, ao se transmitir dados utilizando o protocolo TCP, os principais elementos

presentes no canal de comunicação que influenciarão na velocidade com que a informação é

transmitida são o delay e a perda de pacotes.

Aliado ao fato de que, como engenheiros, precisamos conhecer o canal de

comunicação e os fenômenos que influenciarão na qualidade com que a informação é

transmitida, precisamos também saber utilizar as tecnologias mais atuais que permitam fazer

o melhor uso dos recursos disponíveis.

Software-Defined Networking (SDN) é um novo paradigma de arquitetura para as

redes de computadores. Nele, se remove a responsabilidade pelo controle e o

encaminhamento dos pacotes da camada de rede, levando-o para a camada de aplicação. O

que torna a rede centralizada e mais programável.

O uso de SDN permite otimizar o roteamento das redes, tendo em vista que ele da

mais flexibilidade ao administrador da rede, que passa a ter a opção de criar os seus próprios

módulos. Por exemplo, caso se perceba que uma rota está com muita peda de pacotes,

pode-se programar a tabela de fluxo dos switches para que encaminhem os pacotes por

outra rota. Ou, pode construir um módulo que faça automaticamente medições periódicas

nas rotas existentes entre dois pontos, para programar a tabela de fluxo dos switches de

modo que os pacotes sempre sigam o melhor caminho.

Assim, viu-se nas SDN um bom ambiente de estudos, pois esta é uma tecnologia atual

e que permite ao administrador da rede fazer o melhor uso dos recursos existentes. Logo,

este foi o ambiente de estudos escolhido para esta pesquisa.

9

O principal objetivo visado ao longo desta trabalho foi conhecer melhor os elementos

que impactarão na qualidade com que a informação é transmitida entre as aplicações. Não

se teve a ambição de analisar as influências do espectro eletromagnético neste cenário, pois

este é um tópico muito extenso e que seria melhor abordado em uma pesquisa focada a isso.

O segundo objetivo deste trabalho foi conhecer uma tecnologia que permita ao

administrador da rede fazer o melhor uso dos recursos disponíveis, de modo a tornar a

administração da rede mais maleável.

Este trabalho foi iniciado através de uma pesquisa bibliográfica, que está disponível no

capítulo quatro. Após a pesquisa bibliográfica, foi definido o melhor cenário a ser utilizado

durante os estudos e foram realizadas medições para analisar a qualidade com que os dados

são transmitidos em cada cenário. Por fim, foram analisados os resultados obtidos durante

os experimentos e pensados em trabalhos futuros que poderão ser desenvolvidos

posteriormente.

10

2. MÉTODOS

Essa pesquisa foi executada a partir da implantação de uma Rede Definida por

Software em ambiente virtualizado, utilizando a ferramenta de emulação Mininet versão

2.2.1. Foi utilizado o controlador POX e implantado um cenário simples, com dois hosts se

comunicando através de dois switches, conectados entre si através de um link Ethernet com

largura de banda de 1 Gbps. O objetivo neste cenário foi observar as influências que o delay

e a perda de pacotes podem causar no canal de comunicação.

Foram realizados dois experimentos neste mesmo cenário, onde foram alterados os

valores do delay e da perda de pacotes no link Ethernet existente entre os dois switches

criados durante os experimentos.

O primeiro experimento foi realizando alterando-se os valores do delay e mantendo-se

a perda de pacotes aproximada igual a 0%. Começou-se utilizando um delay igual 0.5 ms e

esse valor foi dobrado até chegar ao valor final de 512 ms. Para cada valor de delay

selecionado, foi realizado um teste de throughput TCP de 60 segundos. Os valores de delay

utilizados durante os testes foram: 0.5 ms, 1 ms, 2 ms, 4 ms, 8 ms, 16 ms, 32 ms, 64 ms, 128

ms, 256 ms, 512 ms.

O segundo experimento foi realizado configurando-se o canal entre os dois swtiches

com uma taxa de perda de pacotes inicial igual a 0.06% e mantendo-se o delay

aproximadamente igual a 0.1 ms. Foi realizado um teste de throughput TCP de 60 segundos

entre os dois hosts. O experimento seguiu dobrando-se o percentual de perda de pacotes,

mantendo-se o delay fixo e realizando-se os testes de throughput de 60 segundos até chegar

a 64% de perda de pacotes. Os valores de perda de pacotes utilizados foram: 0.06 %, 0.12

%, 0.25 %, 0.5 %, 1 %, 2 %, 4 %, 8 %, 16 %, 32 % e 64 %.

11

3. OBJETIVOS

Os objetivos gerais desta pesquisa foram:

• Estudar os elementos que impactam na qualidade com que a informação é transmitida

entre as aplicações.

• Estudar uma tecnologia que permita ao administrador da rede fazer o melhor uso dos

recursos disponíveis, de modo a tornar a administração da rede mais flexível.

Os objetivos específicos adotados durante a pesquisa foram:

• Implementar um cenário de estudos emulado com o software Mininet;

• Utilizar o paradigma de Redes Definidas por Software para o cenário emulado;

• Realizar medições de throughput utilizando o software iPerf;

• Realizar experimentos com valores de largura de banda e perda de pacotes fixos,

para diferentes valores de delay;

• Realizar experimentos com valores de largura de banda e delay fixos, para diferentes

valores de perda de pacotes;

• Estudar os impactos do delay e da perda de pacotes no throughput de uma rede de

computadores que utiliza o paradigma SDN.

12

4. FUNDAMENTAÇÃO TEÓRICA

4.1 Modelo OSI

Durante a evolução dos sistemas de comunicações modernos, de modo a facilitar a

comunicação e a inter-operabilidade da rede, foram definidos padrões a ser seguidos por

diferentes fabricantes. No âmbito das redes de computadores, utiliza-se uma hierarquia de

protocolos, que obedece a um modelo de transmissão de dados de referência.

O modelo OSI (Open System Intercommunication) [18] é o modelo de referência da

ISO (International Organization of Standardization) [19], ele é composto por 7 camadas [20]:

a camada física, a camada de enlace de dados, a camada de rede, a camada de transporte,

a camada de sessão, a camada de apresentação e a camada de aplicação. Neste trabalho,

nos concentraremos nas camadas de enlace de dados, rede e transporte.

A camada física é formada pelos elementos de hardware da rede, como cabos GigaBit

Ethernet, fibra óptica etc.

Na camada de enlace de dados se trabalha com a informação codificada de forma

binária, os protocolos mais conhecidos dessa camada são o MAC (Media Access Control)

[21] e o protocolo Ethernet, que realizam o endereçamento e estabelecem uma arquitetura

para interconexão de redes locais, respectivamente. A camada de enlace também é a

responsável pela função de comutação, realizada através dos switches.

Na camada de rede o protocolo mais conhecido é o IPv4 (Internet Protocol version 4)

[22], que é utilizado para realizar o endereçamento dos dados entre redes IP distintas. É na

camada de rede que é realizado o controle e o encaminhamento dos pacotes, utilizando os

roteadores.

Os principais protocolos da camada de transporte são o Transmission Control Protocol

(TCP) [2] e o User Datagram Protocol (UDP) [3]. O procedimento de abertura e encerramento

de sessão do protocolo TCP é baseado no protocolo RDT (Reliable Data Transfer) [23]. Ele

utiliza verificação de erros de bits, através do checksum, para garantir que não houveram

erros durante a transmissão dos bits do pacote. Também utilizam a confirmação positiva

(ACK) ou negativa (NAK) de entrega, para que o remetente saiba se o destinatário recebeu

as informações. Ao enviar um pacote o remetente inicia um timmer para esperar a

13

mensagem de confirmação positiva ou negativa, se essa mensagem não chegar o remetente

reenvia o pacote.

Para otimizar o uso do canal de comunicação e não desperdiçar a banda, o protocolo

TCP utiliza o conceito de paralelismo. Ele estabelece janelas de comprimento N e envia a

quantidade de pacotes que couberem na janela, sem necessariamente precisar receber a

confirmação de recebimento de cada pacote antes de enviar o próximo. Todo esse

procedimento utiliza uma quantidade de pacotes muito maior que a do protocolo UDP, que

apenas realiza verificação de erros de bits através do checksum.

Por padrão, quando se envia um frame Ethernet [12], seu cabeçalho ocupa a banda

de 64 Bytes, pois junto ao cabeçalho vão encapsulados o cabeçalho dos protocolos TCP e

IP. 20 Bytes são utilizados pelo cabeçalho do protocolo TCP, 20 Bytes são utilizados pelo

cabeçalho do protocolo IP, 6 Bytes são utilizados pelo campo MAC de Destino, 6 Bytes pelo

campo MAC de Origem, 2 Bytes pelo campo Type, 4 Bytes pelo CRC e, usualmente, 6 Bytes

com o Payload do pacote IPv4. Nas imagens a seguir pode ser observada uma ilustração do

quadro Ethernet e dos campos do cabeçalho TCP.

Figura 1: frame Ethernet. Disponível na URL: https://bit.ly/2rlEPwt. Acessado em 5 de dezembro de 2018.

14

Figura 2: cabeçalho TCP. Disponível no link: https://bit.ly/2EdJk4I. Acessado em 5 de dezembro de 2018.

4.2 Redes Definidas por Software

As Redes Definidas por Software [14] definem a forma como os elementos da camada

de rede e de enlace vão se comunicar. É um conceito criado com o objetivo de tornar

programáveis os elementos responsáveis pela interface de controle em uma rede de

computadores. Se em redes tradicionais os roteadores são responsáveis pelo controle e

encaminhamento dos pacotes, em uma SDN o controlador será responsável pelo plano de

controle e os dispositivos da rede apenas serão responsáveis por executar as tabelas de

fluxos recebidas do controlador. Isso faz com que os elementos da rede percam a

capacidade de tomar decisões e passem essa função para o controlador, que centralizará

essa tarefa. Na Figura 3, pode-se observar uma visão esquemática de uma SDN onde a

comunicação entre o controlador e os switches funcionam através do protocolo OpenFlow.

Uma SDN é composta tradicionalmente por um controlador, comutadores OpenFlow e

opcionalmente divisores de recursos [4]. Os divisores de recursos permitem classificar o fluxo

dos pacotes em categorias e aplicar comportamentos diferentes para cada categoria. O

controlador pode ser implementado de forma centralizada ou podem existir servidores

secundários executando a função de controle, para que a rede não pare de funcionar caso o

controlador primário fique indisponível.

15

A aplicação de SDN em ambientes de Data Center, campus ou LAN implica relevar a

estrutura tradicional estabelecida pelo modelo OSI para a organização das redes de

computadores.

Durante as pesquisas iniciais, pôde-se perceber que o uso de SDN ainda se apresenta

em fase de estudo em algumas universidades do país. A USP, por exemplo, possui um grupo

de pesquisa em SDN incubado no LARC (Laboratory of Computer Networks and

Architecture) [1] que funciona em parceria com a RNP (Rede Nacional de Ensino e

Pesquisa).

A Google é um exemplo de empresa que já implementou SDN em seus Data Centers

[16]. A Cisco, IBM, Extreme, Datacom, Dell e HP são fabricantes que vendem soluções para

Redes Definidas por Software.

Figura 3: uma visão esquemática de SDN implementado com OpenFlow. Disponível no link:

https://bit.ly/2QBG4Xe. Acessado em 16 de dezembro de 2018.

16

4.3 Protocolo OpenFlow

O protocolo OpenFlow determina como se dará a comunicação entre o controlador e

os switches em redes SDN. Ele é um padrão aberto, definido pela Open Network Fundation

[5], então pode ser utilizado por diversos fabricantes.

Se trata de um protocolo que é encapsulado na camada de transporte e define,

através de mensagens, como os dispositivos de uma rede SDN irão se comunicar. O

protocolo OpenFlow dispões dos seguintes tipos de mensagens [6]:

• Mensagens Características: trocadas após iniciar a comunicação entre controlador e

switch, elas são utilizadas para definir quais são as características do canal de

comunicação e quais ações o controlador pode tomar para melhorar gerenciar a rede.

• Mensagens de Configuração: são enviadas do controlador ao switch a fim de

consultar e definir parâmetros de configuração entre eles.

• Mensagens de Modificação de Estado: são mensagens enviadas do controlador

para o comutador com o objetivo de consultar o estado do comutador, para adicionar

ou remover regras na tabela de fluxos.

• Mensagem de leitura do estado: são mensagens enviadas pelo controlador para ler

o estado do comutador e coletar estatísticas.

• Mensagens de packet-out: são enviadas pelo controlador quando não há entradas

na tabela de fluxos associadas a algum pacote na entrada do comutador. Nesse caso

o switch envia o pacote completo para o controlador através de uma mensagem de

packet-in. A resposta é o packet-out enviado junto ao mesmo pacote e o conjunto de

instruções que são associadas a ele.

• Mensagens de barreira: utilizadas pelo controlador para saber se suas instruções

foram cumpridas ou para receber notificações de operações concluídas.

O OpenFlow fornece módulos ao controlador que podem ser utilizados durante o

funcionamento da rede, fornecendo funcionalidades específicas. Ao projetar uma rede SDN

são selecionados os módulos necessários para o seu correto funcionamento. O

desenvolvedor pode, então, escolher dentre os módulos fornecidos pelo padrão OpenFlow,

os módulos fornecidos pelo próprio controlador ou desenvolver seus próprios módulos.

17

4.4 Controlador POX

O controlador é um servidor que normalmente roda em cima de um sistema

operacional linux. Nele são programados os algoritmos que definirão a rota tomada pelos

pacotes, os elementos da rede apenas executarão essa tarefa. Ele é responsável,

basicamente, por criar as tabelas de fluxos da rede e enviá-las aos switches. Os switches por

sua vez utilizarão as tabelas de fluxo para direcionar os dados das portas de entrada para

suas portas de saída adequadas.

O controlador SDN mais conhecido é o NOX, que foi projetado para funcionar

utilizando C++, embora também permita que o programador desenvolva em Python. O POX

[7] foi um controlador desenvolvido especificamente para se programar em Python. Por isso,

permite ter um desempenho melhor da rede quando comparado ao NOX utilizando Python.

Ele está disponível para instalação em sistemas Linux, Windows, MAC OS e necessita de

Python 2.5 ou superior previamente instalado no sistema.

O procedimento para inicializar o POX é simples, basta executar o arquivo pox.py que

está dentro do diretório de instalação do POX. Ele possui alguns comandos de inicialização:

• ./pox.py --verbose: comando para inicializar o controlador POX e exibir informações.

• ./pox.py --no-cli: comando para inicializar o controlador POX sem a interface interativa.

• ./pox.py --no-openflow: comando para inicializar o controlador POX e não iniciar o

protocolo openFlow automaticamente.

Os módulos do POX estão distribuidos em subdiretórios do /home/mininet/pox/pox,

eles são inicializados junto ao controlador e devem ser chamados durante a sua inicialização.

Os módulos utilizados neste trabalho se encontram nos subdiretórios /home/mininet/pox/pox/

openflow/ e /home/mininet/pox/pox/forwarding/. Ao inicializar um módulo, é informado o

subdiretório em que ele se encontra e o nome do módulo, separados por ponto. Se o nome

do módulo for duplo, a convenção utilizada é que as duas palavras devem ser separadas por

um underline. No comando “pox.openflow.discovery”, que chama o módulo Openflow

Discovery, pode-se deduzir que o nome do arquivo é discovery.py e esse arquivo fica dentro

do diretório /home/mininet/pox/pox/openflow/.

18

A partir da leitura dos comentários presentes no código dos módulos em python

presentes no Mininet, é possível verificar a forma como cada um dos módulos foi

implementada. Isso está descrito nos próximos tópicos.

4.4.1 openflow.discovery

O Discovery é um módulo utilizado para descobrir a conectividade entre os swithes

OpenFlow através do envio de pacotes LLDP (Link Layer Discovery Protocol). Pacotes LLDP

são pacotes enviados dentro do quadro Ethernet, na camada de enlace, utilizados pelos

dispositivos durante a descoberta da rede. Ele fornece informações a respeito de endereço

MAC, versão do sistema etc. No Mininet o módulo Discovery funciona através de

mensagens de controle enviadas pelo controlador para os switches, com o objetivo de

realizar a descoberta da rede. Está disponível no diretório /home/mininet/pox/pox/openflow/.

4.4.2 openflow.spanning_tree

O spanning_tree.py, disponível dentro do mesmo diretório que o discovery.py, é um

módulo para resolver problemas de loops em redes SDN. No protocolo Spanning Tree, de

onde o módulo se baseia, as portas são ligadas ou desligadas de acordo com seu uso,

fazendo com que apenas as portas em uso fiquem ligadas. O protocolo cria uma topologia

em forma de árvore onde as portas são folhas e os links são os ramos da árvore. O cálculo

do Spanning Tree usa dois conceitos-chave quando cria uma topologia lógica livre de loops:

Bridge ID e Path Cost.

O Bridge ID é um cabeçalho de 8 Bytes que utiliza 6 Bytes para endereço MAC e 2

Bytes para o Bridge. O Path Cost é utilizado pelas pontes de rede para avaliar o quão perto

elas estão de outras pontes. É um parâmetro fixo para tipos diferentes de redes, quanto

maior a largura de banda da rede menor será o STP Cost. Por exemplo, em redes de 4 Mbps

o STP Cost vale 250 e em redes de 10 Gbps o STP Cost vale 2.

O módulo spanning_tree.py tenta executar a mesma função do protocolo, mas não

necessariamente da mesma forma. Ele primeiro calcula o atual parâmetro Spanning Tree

através do comando def _calc_spanning_tree (), para depois adicionar links entre os

19

switches. Ele também reforma os links para ter apenas um link simétrico conectando os

hosts e mantém uma lista de estados de portas, para poder ignorar os modos necessários.

Quando um novo switch é conectado o algoritmo esquece os estados anteriores das portas.

Quando links mudam ele atualiza o parâmetro Spanning Tree. Por fim, ele atualiza as portas

que forem necessárias.

4.4.6 forwarding.l2_pairs

O módulo l2_pairs cria switches de aprendizado OpenFlow que adiciona regras para

cada par de endereços L2. O algoritmo inicializa realizando o mapeamento entre os pares

endereço MAC e switch, para as portas ligadas dos switches que tem entradas de pacotes

com endereço MAC, através da função “table = {}”. Para enviar um pacote para todas as

portas do switch o algoritmo usa o método as portas especiais OFPP_FLOOD ou

OFPP_ALL, através do método “all_ports = of.OFPP_FLOOD”.

Quando chega alguma solicitação referente a uma entrada inexistente nas tabelas de

fluxo dos switches o algoritmo utiliza a função “_handle_PacketIn”, que envia para o

controlador uma entrada na tabela de fluxos referente aquela solicitação. Este módulo é

necessário ao se utilizar redes em loop, quando se deseja que os switches se comportem

como dispositivos OpenFlow.

4.5 Largura de Banda

Em sistemas de comunicações digitais, a largura de banda [24] representa taxa de

transmissão, ou taxa de símbolos, do canal. Ela expressa a quantidade de símbolos por

segundo que podem ser transmitidos em determinado canal, sendo representada em bits por

segundo.

4.6 Largura de banda da janela TCP

Existem aproximações teóricas para o cálculo da largura de banda da janela TCP.

KUROSE [8] mostra, em um artigo publicado através da Universidade de Massachusetts, um

20

modelo para o cálculo da largura de banda da janela TCP obtido através de uma validação

empírica. No modelo, é observado que a taxa de transmissão (B(p)) da janela TCP varia de

acordo com o tamanho do Maximum Windows Size, do RTT (Round Trip Time), do tempo

máximo (T0) que o transmissor espera para receber o ACK sem que ocorra retransmissão,

da perda de pacotes (p) e da quandidade de janelas TCP que podem ser aberta de forma

seguida (b) antes de se receber uma resposta (ACK) do receptor. Ao final do artigo, os

autores chegam à seguinte aprioximação:

B(p)=min( ( Wmax/RTT ) , ( 1/RTT*sqrt(2bp/3) + T0 *min(1,3*sqrt(3bp/8) *p*(1 + 32*p2) ) ) )

4.7 Throughput

Throughput [24], ou vazão, em português, é um parâmetro medido em bits por

segundo e que representa a quantidade de informação que pode ser transmitida no canal de

comunicação em um intervalo de tempo. Sabe-se que um símbolo compreende não apenas

bits úteis (informação), como também bits de controle e sincronismo, então podemos dizer

que o conceito de throughput difere do conceito de taxa de transmissão, pois a taxa de

transmissão é calculada considerando todos os bits transmitidos pelo canal. A vazão é

calculada considerando-se somente a informação que será transmitida.

4.8 Throughput do frame Ethernet

Como pode ser observado em [31], o frame ethernet é composto pelo endereço MAC

do originador (6 Bytes), pelo endereço MAC de destino (6 Bytes), pelo campo MAC Type (2

Bytes), pelo campo de verificação de sequência CRC (4 Bytes) e pelo payload (pacote IPv4)

da camada de rede, contendo todos os elementos das camadas superiores que são

encapsulados no frame Ethernet.

O throughput de uma rede Ethernet varia de acordo com o tamanho do payload da

camada de rede. Em uma rede LAN Ethernet, o payload da camada de rede será igual a 46

Bytes. Logo, o frame Ethernet será igual a 64 Bytes. No entanto, se for calculado o

21

throughput do serviço provido por um link Ethernet, com payload igual a 1500 Bytes, o

throughput será bem maior, pois o frame Ethernet será igual a 1518 Bytes.

Para se calcular o throughput de uma rede Ethernet [11][15], deve-se considerar o

tamanho do frame utilizado e a largura de banda perdida obtido pela transmissão do

preâmbulo e do inter-frame gap. O cálculo do throughput de um nó LAN Ethernet,

desconsiderando-se a largura de banda perdida com os cabeçalhos TCP e IP, utilizando-se

um frame igual a 64 Bytes, pode ser observado a seguir:

• Total de Bytes transmitidos pelo canal para cada frame enviado: 64 Bytes do frame

Ethernet + 8 Bytes referentes ao preâmbulo + 8 Bytes referentes ao inter-frame gap.

Essa soma é igual a 84 Bytes.

• Total de bits transmitidos pelo canal para cada frame enviado: 84 Bytes x 8 = 672 bits.

• Número de frames transmitidos por segundo: Taxa de Transmissão / Total de bits

transmitidos pelo canal para cada frame enviado = 1 Gbps / 672 bit = 1488 frames/s.

• Throughput teórico máximo da rede: [frames/s] x frame size = 1488 [frames/s] x 64

[Bytes] x 8 = 761 Mbps.

• Largura de banda perdida com o overhead do preâmbulo: rate = 1488 [frames/s] x 8

[Bytes] x 8 = 95Mbps.

• Largura de banda perdida com o overhead do inter-frame gap = 1488 [frames/s] x 12

[Bytes] x 8 = 143 Mbps.

• Throughput teórico considerando o overhead: 761 Mbps – 143 Mbps – 94 Mbps = 523

Mbps.

4.9 Throughput TCP

O throughput teórico do protocolo TCP pode ser calculado conforme é mostrado na

RFC 6349 [26], em função do TCP RCWD (TCP Receive Windows, ou, em portugês, o

tamanho da janela do receptor) do receptor e do RTT:

Throughput TCP = (TCP RWND * 8)/RTT

22

Logo, para uma rede onde o tamanho da janela do receptor é igual a 85,3 kBytes e o

RTT é igual a 1 ms, teremos que o Throughput TCP será igual a:

Throughput TCP = (85300x8)/0.001 = 682,4 Mbps

A mesma RFC também fornece a fórmula para o cálculo do máximo throughput TCP

realizável, que é igual a:

FPS = BW/(MTU + PPP + Flag + CRC16)x8

Throughput L4 = (MTU-40)x8xFPS

Logo, para uma rede LAN com largura de banda de 1 Gbps, payload igual a 46 Bytes,

cabeçalho TCP igual a 20 bytes, cabeçalho IP igual a 20 Bytes, PPP igual a 4 Bytes, Flag

igual a 2 Bytes e CEC16 igual a 2 Bytes, teremos:

FPS=1.000.000.000 / (46+4+2+2)x8 = 1.000.000.000 / 432 = 2.314.814

Throughput L4 = (46-40) x 8 x FPS = 6x8x2314814 = 111,111 Mbps

No entanto, o throughput TCP é limitado pelo frame Ethernet, então o FPS será

calculado da seguinte maneira:

FPS = BW / (MTU + Ethernet + CRC16 + IFG + Preâmbulo + SFD (Start of Frame

Delimiter))x8

FPS = BW / (46 + 14 + 4 + 12 + 7 + 1)x8 = BW / 672

Logo, para uma rede LAN com largura de banda de 1 Gbps e payload igual a 46

Bytes, teremos:

FPS = 1.000.000.000 / 672 = 1.488.095

Througuput L2 = (46-40) x 8 x 1488095 = 71, 428 Mbps

No mesmo cenário do cálculo anterior, considerando-se o MTU da rede como sendo

igual a 1500 Bytes, temos que o throughput da camada 2 será igual a:

23

FPS = BW / (1500 + 14 + 4 + 12 + 7 + 1)x8

FPS = 1.000.000.000 / 12304 = 81274

Throughput L2 = (1500 – 40) x 8 x 81274 = 949,280 Mbps

Logo, a menor vazão de transmissão que se conseguirá ter na rede será de 71,428

Mbps, com MTU igual a 48 Bytes. Já a maior vazão que se conseguirá será de 949,280

Mbps, utilizando o MTU igual a 1500 Bytes.

4.10 Latência

A latência [24] (delay) representa o atraso que o sinal sofre para ser transmitido entre

a origem e o destino, sendo representada em segundos. Os elementos que influenciam no

cálculo do delay são a distância geográfica, em metros, e a distância lógica, contada através

do número de pontos de comutação entre a origem e o destino.

4.11 RTT e RTO do protocolo TCP

O RTT [25] considerado durante o cálculo do throughput de redes TCP/IP pode ser

aproximado como sendo duas vezes do delay, pois é o tempo que o TCP demora para enviar

um pacote e receber o ACK do computador de destino. O RTO (Retransmission Time Out) é

o tempo que o pacote levará para ser retransmitido, esse parâmetro pode ser calculado

segundo alguns algoritmos.

Na RFC 2988 [30] é apresentado um algoritmo básico para o cálculo do time out do

protocolo TCP. Conforme pode ser observado na RFC 2988, para calcular o RTO o

transmissor da janela TCP mantém duas variáveis de estado, o SRTT (Smoothed Round-Trip

Time, ou, em portugês, Tempo de Ida e Volta Suavizado) e o RTTVAR (Round-Trip Time

Variation, ou, em portuês, Variação de Tempo de Ida e Volta). Além disso, assume-se que o

clock tem uma granularidade igual a G segundos, estudos mostram que é interessante

utilizar uma granularidade próxima a 100 ms.

24

Até que uma medição RTT tenha sido feita para um segmento enviado entre o emissor

e o receptor, o remetente deve definir o RTO inicial igual a 3 segundos. Caso o pacote inicial

não seja recebido dentro de três segundos, poderá haver até 3 retransmissões desse mesmo

pacote, para que o TCP obtenha o valor para o RTT.

Quando a primeira medição RTT é feita, o host deve ter os seguintes valores:

SRTT = RTT

RTTVAR = RTT / 2

RTO = SRTT + max (G, K * RTTVAR)

Onde, K = 4.

Quando a segunda medição de RTT’ é feita, o host deve ter os seguintes valores:

RTTVAR = (1 - beta) * RTTVAR + beta * |SRTT – RTT'|

SRTT = (1 - alfa) * SRTT + alfa * RTT'

Onde, alfa = 1/8 e beta = 1/4 (como sugerido em [JK88]).

O valor do SRTT usado na atualização do RTTVAR é seu valor antes de atualizar o

próprio SRTT usando a segunda atribuição. Ou seja, a atualização do RTTVAR e do SRTT

DEVE ser calculada na ordem acima.

Após o cálculo, o valor do RTO do host deve ser atualizado para:

RTO = SRTT + max (G, K * RTTVAR)

Sempre que o RTO for calculado, se for inferior a 1 segundo, o RTO deve ser

arredondado para 1 segundo.

Tradicionalmente, as implementações TCP usam relógios de granularidade grossa

para medir o RTT e acionar o RTO, o que impõe um valor mínimo grande no RTO. A

pesquisa sugere que um RTO mínimo é necessário para manter o TCP conservador e evitar

retransmissões espúrias [AP99]. Portanto, essa especificação requer um RTO mínimo

grande como uma abordagem conservadora, enquanto, ao mesmo tempo, reconhece que,

25

em algum momento futuro, a pesquisa pode mostrar que um RTO mínimo menor é aceitável

ou superior.

Um valor máximo pode ser colocado no RTO, desde que seja pelo menos 60

segundos.

4.12 Comando TC

O comando TC (Traffic Control) [17] é uma ferramenta disponível por padrão em

sistemas linux, que permite simular variações de delay e de perda de pacotes durante a

transmissão dos dados entre dois computadores.

Para simular um aumento da perda de pacotes, o comando faz com que a placa de

rede discarte os pacotes antes deles serem transmitidos. Para simular o aumento do delay, o

comando faz com que a placa de rede demore mais tempo para transmitir os pacotes.

Um exemplo de utilização do comando tc para se adicionar delay, jitter e perda de

pacotes na rede pode ser visto a seguir:

tc qdisc add dev s3-eth1 root netem delay 100ms 50ms loss 5%

Onde, s3-eth1 é a interface de rede onde o delay, o jitter e a perda de pacotes foram

adicionados. 100ms é o valor do delay, 50ms é a variação do delay e 5% é a taxa de perda

de pacotes. Após aplicar esse comando, é necessário utilizar o seguinte comando para

desfazer as alterações:

tc qdisc del dev s3-eth1 root netem

Caso se aplique o comando “tc qdisc add” duas vezes seguidas, os valores de delay e

perda de pacotes adicionados em cada um desses comandos serão somados. Então, caso

se deseje alterar os valores de delay e perda de pacotes já aplicados, deve-se limpar o

cenário com o comando “tc qdisc del”.

26

4.13 Mininet

Para os testes de virtualização de Redes Definidas por Software foi utilizada uma

máquina virtual pronta que existe disponível no website do projeto Mininet. Foi utilizado o

Mininet 2.2.1 que funciona rodando no Ubuntu 14.04. Na página do projeto Mininet é

possível verificar as principais configurações necessárias para fazer o serviço de

virtualização de redes funcionar. Em mininet.org/walkthrough são exibidos os principais

comandos de configuração necessários para trabalhar com o sistema.

4.14 iPerf

O iPerf [27] é uma ferramenta que permite medir throughput e jitter, podendo ser

utilizado com os protocolos TCP, UDP e SCTP em redes que utilizam tanto IPv4 quanto IPv6.

Ele foi desenvolvido em C++ pela DAST (Distributed Applications Support Team) e pelo

NLANR (National Laboratory for Applied Network Research), seus autores são Jon Dugan,

Seth Elliott, Bruce A. Mah, Jef Poskanzer, Kaustubh Prabhu.

Hoje o iPerf está em sua versão 3 e pode ser baixado através do site iperf.fr. É uma

ferramenta simples de ser instalada e utilizada, roda um teste fim-a-fim e deve ser instalado

nos dois pontos da medição.

Para realizar o teste com o iPerf é primeiro inicializado o serviço no servidor e depois

enviada uma solicitação da máquina do cliente. Estes são exemplos dos comandos que

podem ser rodados no cliente o no servidor para executar testes TCP:

• Servidor: iperf -s -f M -i 1 -p 5001 -T 1 >>/home/mininet/iperfTCP.txt.

• Cliente: iperf -c 10.0.2.2 -f M -i 1 -p 5001 -t 60 -T 1.

Em testes UDP os comandos utilizados são:

• iperf -s -u -f M -i 1 -p 5001 -T 1 >>/home/mininet/iperfUDP.txt.

• iperf -c 10.0.2.2 -u -f M -i 1 -p 5001 -t 60 -T 1 -b 1000M.

27

O “-i” é um parâmetro para informar o intervalo de tempo em que o retorno do teste

será exibido na tela, o “-f” é um parâmetro que informa a unidade de exibição dos resultados

(Kbytes, MBytes etc). O tempo de execução do teste “-t” é um parâmetro do cliente e deve

ser informado em segundos. O “-T” informa o time-to-live (TTL), também em segundos. O “-

P” é um parâmetro do servidor para informar a porta que ele utilizará para os testes.

Enquanto o teste estiver rodando ele retornará os resultados na tela para o usuário.

Por padrão o iPerf realiza um teste TCP entre o Cliente e o Servidor, para realizar um teste

UDP é necessário adicionar o parâmetro “-u” É possível salvar os resultados dos testes em

um arquivo .txt para posteriormente utilizá-lo em relatórios que serão enviados às

operadoras. Isso é feito no servidor adicionando ao comando “>> /home/user/exemplo.txt” ou

criando um script que também optimizará a tarefa.

28

5. CENÁRIO

5.1 Descrição do cenário

O cenário utilizado foi uma rede Ethernet, utilizando o paradigma SDN, emulada

através do Mininet 2.2.1, com um controlador POX, dois switches e dois hosts. A largura de

banda utilizada foi de 1 Gbps.

Foram realizados dois experimentos neste mesmo cenário, onde foram alterados os

valores do delay e da perda de pacotes no canal de comunicação entre os dois switches.

Isso foi feito se aplicando o comando tc à placa de rede s3-eth1, que pode ser observada na

Figura 4. O link entre os switches e os hosts não foi manipulado, pois, caso se adicione o

mesmo delay ou a mesma perda de pacotes nos três links, o delay ou a perda de pacotes

resultante será multiplicado por três.

Figura 4: arquitetura do cenário implementado durante o experimento. Fonte: autoria própria.

29

5.2 Algoritmo customizado utilizado para construir a rede

A API Python utilizada para criar os dispositivos de rede pode ser observada a seguir:

from mininet.topo import Topo

class MyTopo ( Topo ):

def __init__ ( self ):

# Inicializando topologia

Topo.__init__( self )

# Adicionando hosts e switches

leftHost = self.addHost ( ‘h1’ )

rightHost = self.addHost ( ‘h2’ )

leftSwitch = self.addSwitch ( ‘s3’ )

rightSwitch = self.addSwitch ( ‘s4’ )

#Adicionando links

self.addLink( leftHost, leftSwitch )

self.addLink( leftSwitch, rightSwitch )

self.addLink( rightSwitch, rightHost )

topos = { ‘mytopo’: ( lambda: MyTopo() ) }

Pode-se perceber através do algoritmo que no Mininet os hosts e switches são

tratados como objetos e que existem os métodos para adicionar hosts e links entre

dispositivos.

30

5.3 Controlador POX

Durante os dois experimentos realizados neste trabalho, não foi necessário inicializar

o controlador POX junto a muitos módulos, tendo em vista que se tratava de um cenário

simples. Os módulos utilizados foram o pox.openflow.discovery e o pox.forwarding.l2_pairs.

Na Figura 5 pode ser observado um exemplo de rede sendo inicializada. Em um

terminal se inicializa o controlador junto aos módulos e no outro terminal se inicializa o

Mininet utilizando a topologia customizada em um link de 1000Mbps.

Figura 5: exemplo de inicialização de uma rede customizada junto ao controlador POX. Fonte: autoria

própria.

No momento da inicialização da rede é possível estabelecer o delay e a taxa de perda

de pacotes do canal, no entanto não foram atribuídos valores para esses parâmetros. Por

padrão o Mininet utiliza um valor baixo e aleatório para o delay, de modo a simular um canal

real, na ordem de 1 mili segundos.

31

5.4 Tabela de fluxos e pacotes transmitidos

A tabela de fluxos disponível nos switches após realizar um pigall na rede pode ser

observada na Figura 6, a seguir.

Figura 6: consulta à tabela de fluxos dos switches, após um pingall ser realizado no cenário de teste. Fonte:

autoria própria.

Figura 7: fluxos de protocolos utilizados no cenário de teste. Fonte: autoria própria.

Na Figura 7, obtida no Wireshark [28], é possível observar os protocolos utilizados

para a transmissão das mensagens no cenário de teste e a forma como seus cabeçalhos são

encapsulados.

32

6. EXPERIMENTOS

6.1 Influências do delay

No cenário 1 foram realizados testes de throughput TCP de 60 segundos com o iPerf

entre os dois hosts da rede. Durante os testes nesse cenário manteve-se fixa a largura de

banda da rede como sendo 1 Gbps e se usou uma perda de pacotes estimada em 0%. Os

dados obtidos nos testes realizados nesse cenário estão expostos na Tabela 1 e na Figura

21, a seguir:

TABELA 1: variação do throughput em função da variação do delay

Largura de Banda Delay Perda de Pacotes Throughput

1 Gbps 0.5 ms 0% 468 Mbps

1 Gbps 1 ms 0% 465 Mbps









1 Gbps 512 ms 0% 90.6 MbpsFONTE: autoria própria

33

Figura 8: Throughput simulado para diferentes valores de delay. Fonte: autoria própria.

34

6.2 Influências da perda de pacotes

No cenário 2 foram realizados testes de throughput TCP de 60 segundos com o iPerf

entre os dois hosts da rede. Durante os testes nesse cenário manteve-se fixa a largura de

banda da rede como sendo 1 Gbps e se usou um delay estimado igual a 0.1 ms. Os dados

obtidos nos testes realizados nesse cenário estão expostos na Tabela 2 e na Figura 22, a

seguir:

TABELA 2: variação do throughput em função da variação da perda de pacotes

Largura de Banda Delay Perda de Pacotes Throughput

1 Gbps 0.1 ms 0.06% 408 Mbps

1 Gbps 0.1 ms 0.012% 470 Mbps

1 Gbps 0.1 ms 0.25% 455 Mbps

1 Gbps 0.1 ms 0.5% 495 Mbps





1 Gbps 0.1 ms 16% 465 Mbps

1 Gbps 0.1 ms 32% 484 Mbps

1 Gbps 0.1 ms 64% 5.83 MbpsFONTE: autoria própria

35

Figura 9: Throughput simulado para diferentes valores de Packet Loss. Fonte: autoria própria.

36

7. ANÁLISE DOS RESULTADOS

Durante os experimentos foi alterado o parâmetro de delay e perda de pacotes para o

link entre os dois switches, o delay entre os switches e os hosts não foi alterado. Por padrão,

quando não se seleciona valores para delay e perda de pacotes ao inicializar o cenário, o

Mininet seta essas variáveis randomicamente, para que o canal se aproxime de um link real.

Observou-se durante os testes que a alteração tanto do delay como da perda de

pacotes do canal entre os dois switches influenciou no throughput TCP. No entanto, valores

pequenos de delay surtiram mais impacto na vazão da rede que os valores pequenos de

perda de pacotes. Isso pode ser explicado pela natureza do protocolo TCP, que é orientado à

conexão. Logo, os pacotes que são perdidos são retransmitidos.

A Tabela 3 mostra os valores para RTO que podem ser obtidos para os valores de

delay utilizados durante os experimentos, conforme mostra o cálculo explicado no ítem 4.9

deste documento:

Tabela 3: variação do RTO em função da variação do delay

Delay (ms) RTT (ms) RTO 1 (ms) RTO 2 (ms) RTO 3 (ms)

0,1 0,2 3000 100,2 100,2

0.5 1 3000 101 101

1 2 3000 102 102

2 4 3000 104 104

4 8 3000 108 108

8 16 3000 116 116

16 32 3000 132 132

32 64 3000 192 164

64 128 3000 384 320

128 256 3000 768 640

256 512 3000 1536 1280

512 1024 3000 3072 2560Fonte: autoria própria.

37

Para o cenário com perda de pacotes variável, tínhamos delay igual a 0.1 ms.

Observando a Tabela 3, vamos que o valor do RTO para esse delay é igual a 100.1 ms.

Logo, no cenário em que se variou a perda de pacotes, tinha-se um valor para o tempo de

retransmissão de um pacote TCP sempre igual a 100.1ms. Pelos resultados expostos na

Tabela 2, verifica-se que um time out de 100,1 ms é suficiente para retransmitir os pacotes

perdidos em causar impactos na vazão do protocolo TCP. No entanto, para a última medição,

com taxa de perda de pacotes igual a 64%, esse time out não foi suficiente para manter o

throughput da rede alto e pode-se observar a queda expressiva da vazão da rede nesse

experimento.

Para o cenário com perda de pacotes aproximadamente nula e delay variável, verifica-

se na Tabela 3 que o valor do RTO variou de 101 ms à 2560 ms. Ao observar os resultados

expostos na Tabela 1 pode-se verificar como os resultados do throughput da rede foram

sensíveis à variação do RTT. Como pode ser observado na Tabela 3, o RTO é sempre maior

que o RTT. Então, o valor do RTO, para o cenário em que não havia perda de pacotes na

rede não chegou a influenciar nos resultados do throughput TCP. No entanto, como o RTT

aumentava, o ACK do TCP demorava cada vez mais à chegar ao transmissor, o que atrasava

o envio do próximo pacote da janela TCP. Esse efeito provocou os resultados piores obtidos

para o primeiro experimento.

Pensando na perda de pacotes em uma transmissão TCP, sabe-se que se um pacote

for perdido o transmissor esperará o ACK até que ocorra time out e depois terá que

retransmitir o pacote perdido. Como se pôde observar no experimento 2, caso o RTO seja

pequeno, isso terá menos impacto no throughput da rede, pois a velocidade com que os

pacotes serão retransmitidos será grande o suficiente.

Já ao se pensar em uma transmissão UDP, é facil de imaginar que esse protocolo

esteja mais vulnerável aos efeitos da perda de pacotes, já que não é orientado à conexão e

os pacotes perdidos não são retransmitidos. Por outro lado, o UDP envia os pacotes sempre

a uma taxa constante, o que faz com que eles também cheguem no destino a uma taxa

constante, após algum tempo inicial de transmissão. Essa outra característica do protocolo

UDP faz com que ele seja menos vulnerável aos efeitos do delay que o TCP, que necessita

receber o ACK antes de prosseguir com a transmissão.

38

7.1 Largura de banda da janela TCP

Durante os testes de throughput com o iPerf ele informa o tamanho da janela TCP

utilizada. Na Figura 24 pode ser observado o exemplo de saída de um teste de throughput

TCP. O valor utilizado durante os testes foi igual a 85.3 kBytes, ou 682,4 kbits.

Figura 11: exemplo de saída de um teste de throughput TCP com o iPerf. Fonte: autoria própria.

Lembrando da fórmula para o cálculo da largura de banda da janela TCP, exposta no

ítem 4.11 podemos obter diferentes valores de largura de banda da janela TCP, variando-se o

valor do RTT, do RTO, da taxa de perda de pacotes, do tamanho máximo da janela TCP e da

quantidade de pacotes que o TCP consegue enviar antes de receber o ACK.

Tabela 4: Largura de Banda da janela TCP, para diferentes valores de RTT, RTO, taxa de

perda de pacotes, b e largura da janela TCP.

Delay (ms) RTT (ms) RTO (ms) b p Wma (bits) Largura de Banda TCP

0,1 0,2 100,2 4 0.01 682400 136,48 bps

512 1024 2560 4 0.01 682400 4,089 bps

0,1 0,2 100,2 400 0.64 682400 136,48 bps

0,1 0,2 100,2 4 0.01 1364800 272,96 bps

Fonte: autoria própria

Para os cenários calculados na Tabela 4, podemos observar que a variação da taxa de

perda de pacotes e da quantidade de pacotes seguidos que podem ser enviados pelo

protocolo TCP, antes de receber o ACK, não influenciaram no tamanho da janela TCP.

39

No entanto, a variação do delay causou um grande impacto negativo na largura de

banda da janela TCP. Isso pode ser explicado, pois, ao se obter um RTT maior, o protocolo

TCP demorará mais tempo para enviar o próximo pacote da fila, o que fará com que o

protocolo consiga transmitir menos informação por unidade de tempo.

Ao se observar os dados do cálculo onde se manteve o delay e a perda de pacotes

iguais ao do cenário inicial, porém, dobrou-se o tamanho máximo da janela TCP, podemos

observar que a largura de banda da janela TCP sofreu uma alteração positiva. Ao se dobrar o

tamanho máximo da janela TCP, verificou-se que se conseguiu dobrar a largura de banda da

janela TCP.

7.2 Throughput do Jumbo frame

Uma das formas de aumentar o throughput de uma rede Ethernet, além de manter a

qualidade do enlace, é aumentar o tamanho do frame Ethernet utilizado. Em redes Gigabit

existe o Jumbo Frame [13], a seguir pode ser observado o cálculo do throughput utilizando

Jumbo Frames, com 9000 Bytes:

• Total de Bytes transmitidos pelo canal para cada frame enviado: 9000 Bytes do frame

Ethernet + 8 Bytes referentes ao preâmbulo + 12 Bytes referentes ao inter-frame gap.

Essa soma é igual a 9016 Bytes.

• Total de bits transmitidos pelo canal para cada frame enviado: 9020 Bytes x 8 = 72160

bits.

• Número de frames transmitidos por segundo: Taxa de Transmissão / Total de bits

transmitidos pelo canal para cada frame enviado = 1 Gbps / 72160 bits = 13.85

frames/s.

• Throughput teórico máximo da rede: [frames/s] x frame size = 13.85 [frames/s] x 9000

[Bytes] x 8 = 997,200 Mbps.

• Largura de banda perdida com o overhead do preâmbulo: rate = 13.85 [frames/s] x 8

[Bytes] x 8 = 886.04kbps.

• Largura de banda perdida com o overhead do inter-frame gap = 13.85 [frames/s] x 12

[Bytes] x 8 = 1,329 Mbps.

40

• Throughput teórico considerando o overhead: 997,2 Mbps – 0.886 Mbps – 1,329

Mbps = 994.985 Mbps.

7.3 Considerações sobre uso de Redes Definidas por Software

Mesmo os experimentos tendo sido realizados em ambiente de teste, durante os

experimentos, foi possível se ter mais contato com o paradigma das SDN e observar o fluxo

das mensagens OpenFlow trocadas entre o controlador e os switches.

Os maiores valores para o throughput obtido nos testes expostos na Tabela 1 e na

Tabela 2 foram de 505 Mbps, para a variação do delay, e 495 Mbps, para a variação da

perda de pacotes. Os resultados abaixo do máximo throughput realizável obtido pelo TCP no

ítem 4.9, onde, para um MTU de 1500 Bytes se obteve throughput de 949 Mbps e para MTU

de 46 Bytes se obteve throughput de 111 Mbps.

O uso de SDN e de um controlador POX não interfere no throughput se que poderá

obter no plano de dados, tendo em vista que o controlador só se comunica com os switches

para encaminhar a tabela de fluxos e configurar o comportamento dos mesmos. O cenário

dos experimentos foi um cenário muito simples, onde não foi necessário haver muita

interação com o controlador para que os swtiches OpenFlow conseguissem transmitir as

informações.

7.4 Considerações sobre o impacto do delay e da perda de pacotes

na voz

O tráfego de voz sobre IP é particularmente sensível, pois alterações na qualidade da

conexão podem afetar consideravelmente a experiência de utilização do usuário. Caso o link

esteja com uma taxa de perda de pacotes elevada, podem ocorrer picotes na voz dos

usuários.

Caso o link esteja com um delay elevado, ocorrerá atraso na entrega da voz e,

dependendo do quão grande seja o atraso, podem ocorrer longos períodos de silêncio entre

uma fala e outra, o que também causa um impacto negativo na experiência do usuário.

41

O jitter, variação do delay, afeta a comunicação mais que o delay em sí. Quando

ocorre jitter no canal, os usuários podem ter a percepção de que a voz está distorcida, devido

a forma aleatória e desordenada como os pacotes são entregues.

42

8. CONCLUSÕES

Durante o desenvolvimento dos estudos, foi possível aprender mais sobre redes

TCP/IP e os elementos que influenciam na transmissão dos dados. Observou-se que existem

alternativas acessíveis para o estudo de novas tecnologias, sem que haja a necessidade de

investir em hardware para isso.

Foi observado que o comportamento do OpenFlow e do controlador POX é estável e

imperceptíveis ao usuário final, pois não influenciam diretamente na comunicação ponto a

ponto, já que só trocam mensagens para com os switches. Também foi possível observar

como a qualidade do canal de comunicação é crítica para a forma como se dará a

comunicação. Por isso, é importante conhecer todos os elementos que podem influenciar no

estado do link ao se pensar em projetar uma rede.

Os resultados obtidos no cenário 1 e 2 validaram a hipótese inicial, de que embora o

delay e a perda de pacotes não sejam levados em consideração durante o cálculo do

throughput do frame Ethernet, eles impactam consideravelmente na qualidade da conexão e,

consequentemente, diminuem a velocidade com que os dados são transmitidos.

Embora o MTU teórico permitido por um computador linux seja de 1500 Bytes, não se

conseguiu atingir durante os experimentos o throughput teórico que se pode conseguir ao

utilizar o maior payload para a camada de rede. Os resultados não foram necessariamente

ruins, pois se afastaram muito dos piores valores para taxa de transmissão que se poderia

ter. Mas não foi possível transmitir as informações na maior taxa parmitida pela rede.

Tendo em vista que o POX é um controlador utilizado para ambientes acadêmicos,

pois é fácil de utilizar, para trabalhos futuros, vejo a necessidade de estudar um controlador

mais adequado para o ambiente profissional. Também acredito que seja interessante a ideia

de projetar um módulo que analise periodicamente a qualidade das rotas disponíveis para os

pacotes que trafegarão na rede. Isso pode evitar que os pacotes sejam transmitidos por

pontos de gargalo, otimizando o uso dos recursos disponíveis na rede.

Foi uma experiência gratificante, como aluna, ter tido a oportunidade de conhecer as

tecnologias abordadas neste estudo. Embora o uso de SDN ainda não esteja sendo feito em

grande escala hoje, acredito que num futuro próximo ele já se tornará mais disseminado,

devido à flexibilidade que traz para a rede.

43

ANEXO 1: Mensagens OpenFlow trocadas durante um teste de ping

Durante os experimentos realizados neste trabalho, foi observado o fluxo de dados em

uma rede utilizando o protocolo OpenFlow 1.0. A seguir, pode-se observar as principais

mensagens utilizadas pelo protocolo OpenFlow durante um teste de ping entre os dois hosts

criados durante o experimento. As imagens foram obtidas utilizadas o Wireshark.

• OFPT_HELLO: é trocada entre o switch e o controlador, ambos informam a sua

versão do protocolo OpenFlow e negocial qual a melhor versão a ser utilizada. A

menor versão disponível será escolhida.

Figura 12: conteúdo da mensagem OFPT_HELLO, campturado pelo Wireshark durante o experimento. Fonte:

autoria própria.

• OFPT_FEATURES_REQUEST: é uma mensagem de handshake usada pelo

controlador para verificar os recursos suportados pelo switch.

Figura 13: conteúdo da mensagem OFPT_FEATURES_REQUEST, campturado pelo Wireshark durante o

experimento. Fonte: autoria própria.

44

• OFPT_FEATURES_REPLY: o switch comunica ao controlador os recursos suportados

através dessa mensagem.

Figura 14: conteúdo da mensagem OFPT_FEATURES_REPLY, campturado pelo Wireshark durante o


• OFPT_SET_CONFIG: define e conlta os parâmetros de configuração do swith.

45

Figura 15: conteúdo da mensagem OFPT_SET_CONFIG, campturado pelo Wireshark durante o experimento.

Fonte: autoria própria.

• OFPT_BARRIER_REQUEST: O controlador envia essa mensagem deseja garantir

que as dependências de mensagem foram atendidas ou deseja receber notificações

para operações concluídas.

Figura 16: conteúdo da mensagem OFPT_BARRIER_REQUEST, campturado pelo Wireshark durante o


• OFPT_BARRIER_REPLY: resposta do switch ao BARRIER_REQUEST.

46

Figura 17: conteúdo da mensagem OFPT_BARRIER_REPLY, campturado pelo Wireshark durante o


• OFPT_FLOW_MOD: realiza modificações na tabela flow do controlador.

Figura 18: conteúdo da mensagem OFPT_FLOW_MOD, campturado pelo Wireshark durante o experimento.


• OFPT_PORT_STATUS: quando as flags são mudadas pelo protocolo STP, o switch

envia essa mensagem para notificar o controlador da mudança.

47

Figura 19: conteúdo da mensagem OFPT_PORT_STATUS, campturado pelo Wireshark durante o experimento.


• OFPT_PORT_MOD: o controlador usa essa mensagem para modificar o

comportamento de portas físicas.

Figura 20: conteúdo da mensagem OFPT_PORT_MOD, campturado pelo Wireshark durante o experimento.


• OFPT_PACKET_OUT: é utilizada pelo controlador para enviar um pacote através do

plano de dados. O seu conteúdo pode ser visto integralmente nas três imagens a

seguir.

48

Figura 21: conteúdo da mensagem OFPT_PACKET_OUT, campturado pelo Wireshark durante o experimento.


Figura 22: conteúdo do campo Ethernet, da mensagem OFPT_PACKET_OUT, campturado pelo Wireshark

durante o experimento. Fonte: autoria própria.

49

Figura 23: conteúdo do campo LLDP, da mensagem OFPT_PACKET_OUT, campturado pelo Wireshark


• OFPT_PACKET_IN: é utilizada quando um pacote é recebido pelo plano de dados e

enviado ao controlador.

Figura 24: conteúdo da mensagem OFPT_PACKET_IN, campturado pelo Wireshark durante o experimento.


50

Figura 25: conteúdo do campo Ethernet, da mensagem OFPT_PACKET_IN, campturado pelo Wireshark


Figura 26: conteúdo do campo LLDP, da mensagem OFPT_PACKET_IN, campturado pelo Wireshark durante

o experimento. Fonte: autoria própria.

51

REFERÊNCIAS

[1] Larc. Laboratory of Computer Networks and Architecture. Disponível em:

<https://bit.ly/2ryfxht/>. Acessado em 17 de maio de 2016.

[2] RFC 793. Transmission Control Protocol – Functional Specification. Disponível em:

<https://tools.ietf.org/html/rfc793>. Acessado em 19 de maio de 2016.

[3] RFC 768. User Datagram Protocol. Acessado em 1 de janeiro de 2015. Disponível em:<https://bit.ly/2B47c70>. Acessado em 12 de dezembro de 2018.

[4] GUEDES; VIEIRA; VIEIRA; RODRIGUES; NUNES. Redes Definidas por Software: uma

abordagem sistêmica para o desenvolvimento das pesquisas em Redes de

Computadores. Disponível em: <https://bit.ly/2Eca6tB>. Acessado em 23 de maio de 2016.

[5] Open Network Fundation. Open Switch Specification. Disponível em:

<https://bit.ly/2RIKbgK>. Acessado em 12 de dezembro de 2017.

[6] COSTA, Lucas R. Openflow e o paradigma das Redes Definidas por Software.

Universidade de Brasília, 2013. Disponível em: <https://bit.ly/2rsxkno>. Acessado em 18 de

maio de 2016.

[7] Controlador POX. Disponível em: <https://bit.ly/2j5VVJ9>. Acessado em 18 de maio de

2016.

[8] JITU, VROIU; TOWSLEY; KUROSE. Modeling TCP Throughput: A Simple Model and

its Empirical Validation. Disponível em: <https://bit.ly/2BWC9eK>. Acessado em 12 de

dezembro de 2018.

[9] MATHIS; SEMKE; MAHDAVI. The Macroscopic Behavior of the TCP Congestion

Avoidance Algorithm. Disponível em: <https://bit.ly/2Ek9wuz>. Acessado em 12 de

dezembro de 2018.

52

[10] RFC 792. Internet Control Message Protocol. Acessado em 1 de janeiro de 2015.Disponível em: <https://bit.ly/2Ql8Pay>.

[11] Maximum Throughput Gigabit Ethernet. Disponível em: <https://bit.ly/2SC0agN>.Acessado em 12 de dezembro de 2018.

[12] RFC 894. A Standard for the Transmission of IP Datagrams over Ethernet

Networks. Disponível em: <https://bit.ly/2RNSwQA>. Acessado em 12 de dezembro de 2018.

[13] Ethernet Alliance. Ethernet Jumbo Frames. Desponível em: <https://bit.ly/2RKABdm>.

Acessado em 12 de dezembro de 2018.

[14] XIA; WEN; FOH; NIYATO; XIE. A Survey on Software-Defined Networking. Disponível

em: <https://bit.ly/2UO9SOZ>. Acessado em 16 de dezembro de 2018.

[15] EXFO: Expertise Researching Out. Ethernet Reference Guide: Your everyday

Ethernet testing reference tool. Disponível em: <https://bit.ly/2UNWcn0>. Acessado em 16

de dezembro de 2018.

[16] Big Switch Networks. OpenFlow MythBusting by Google. Disponível em: <https://bit.ly/

2SQ4l8L>. Acessado em 16 de dezembro de 2018.

[17] HUBERT, Bert. TC: Linux Man Pages. Disponível em: <https://bit.ly/2rDpKGP>.


[18] RFC 1195. Use of OSI IS-IS for routing in TCP/IP and Dual Environments. Disponível

em: <https://tools.ietf.org/html/rfc1195>. Acessado em 16 de dezembro de 2018.

[19] ISO: Internacional Organization for Standardization. Disponível em: <https://www.iso.org/

home.html>. Acessado em 16 de dezembro de 2018.

[20] TANENBAUM, A. S. Redes de Computadores. 4ª Ed., Editora Campus (Elsevier), 2003.

53

[21] RFC 7769. Media Access Control (MAC) Address Withdrawal over Static

Pseudowire. Disponível em: <https://tools.ietf.org/html/rfc7769>. Acessado em 16 de

dezembro de 2018.

[22] RFC 791. Internet Protocol. Disponível em: <https://tools.ietf.org/html/rfc791>.


[23] RFC 908. Reliable Data Protocol. Disponível em: <https://tools.ietf.org/html/rfc908>.


[24] HAYKIN, Simon. Sistemas de Comunicação Analógicos e Digitais. 4ª Ed., Editora

Bookman, 2007.

[25] RFC 7982. Measurement of Round-Trip Time and Fractional Loss Using Session

Traversal Utilities for NAT (STUN). Disponível em: <https://tools.ietf.org/html/rfc7982>.


[26] RFC 6349. Framework for TCP Throughput Testing. Disponível em:

<https://tools.ietf.org/html/rfc6349>. Acessado em 16 de dezembro de 2018.

[27] iPerf. Disponível em: <https://iperf.fr/iperf-doc.php>. Acessado em 16 de dezembro de

2018.

[28] Wireshark. Disponível em: <https://www.wireshark.org/>. Acessado em 16 de dezembro

de 2018.

[29] Frame Ethernet. Disponível em:

<https://erg.abdn.ac.uk/users/gorry/eg3567/lan-pages/enet-calc.html>. Acessado em 16 de

dezembro de 2018.

54

[30] RFC 2988. Computing TCP's Retransmission Timer. Disponível em:

<https://tools.ietf.org/html/rfc2988>. Acessado em 16 de dezembro de 2018.

55

Documents

Trabalho de Conclusão de Curso...Trabalho de Conclusão de Curso: Um estudo sobre os impactos do delay e da perda de pacotes no throughput de Redes Definidas por Software Natal/RN,