David Carlos Pereira da Cunha...David Carlos Pereira da Cunha Proposta de suporte à qualidade de...

David Carlos Pereira da Cunha

PROPOSTA DE SUPORTE À QUALIDADE DE SERVIÇO BASEADA

EM SDN: UM ESTUDO DE CASO PARA INSTITUIÇÕES DE ENSINO

FEDERAL

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2017

www.cin.ufpe.br/~posgraduacao


PROPOSTA DE SUPORTE À QUALIDADE DE SERVIÇO BASEADAEM SDN: UM ESTUDO DE CASO PARA INSTITUIÇÕES DE ENSINO

FEDERAL

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: Kelvin Lopes Dias

RECIFE2017

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

C972p Cunha, David Carlos Pereira da

Proposta de suporte à qualidade de serviço baseada em SDN: um estudo de caso para instituições de ensino federal / David Carlos Pereira da Cunha. – 2017.

97 f.: il., fig., tab. Orientador: Kelvin Lopes Dias. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências e apêndice.

1. Redes de computadores. 2. Redes definidas por software. I. Dias, Kelvin Lopes (orientador). II. Título. 004.6 CDD (23. ed.) UFPE- MEI 2017-237


Proposta de suporte à qualidade de serviço baseada em SDN: um

estudo de caso para instituições de ensino federal.

Dissertação apresentada ao Programa de Pós-

Graduação em Ciência da Computação da

Universidade Federal de Pernambuco, como

requisito parcial para a obtenção do título de

Mestre Profissional em 12 de julho de 2017.

Aprovado em: 12 / 07 / 2017.

BANCA EXAMINADORA

__________________________________________

Prof. Carlos André Guimarães Ferraz

Centro de Informática / UFPE

__________________________________________

Prof. Andson Marreiros Balieiro

Universidade de Pernambuco

__________________________________________

Prof. Kelvin Lopes Dias

Centro de Informática / UFPE

(Orientador)

Dedico essa dissertação à minha família, em especial aos

meus pais, irmã, esposa, avó e madrinha. À minha avó Rosa

Pacheco (in memorian), tio Lamartine Bezerra (in

memorian) e padrinho Moacir Pessoa (in memorian).

AGRADECIMENTOS

Agradeço a Deus por ter me permitido realizar esse grande sonho, principalmente portê-lo feito com saúde e tendo compartilhado os mais nobres sentimentos com tantas pessoasqueridas.

Com amor, aos meus pais Juvita Pereira e João Carlos, à minha irmã Juliana Pereira,eles que sempre participaram ativamente da minha vida, me deram todo suporte familiar e sãoresponsáveis pela minha formação, pessoal e acadêmica. À minha amada esposa Silvia Kellyne,pelo incentivo e companheirismo em todos os dias dessa desafiadora jornada.

Ao professor Kelvin Lopes Dias pela confiança e orientação exemplar. Por tornar tudopossível, consequência natural de sua competência e disponibilidade em ajudar do início ao fim,sobretudo nas horas mais difíceis.

Aos familiares (tios, primos e sogra) pelo apoio e torcida. Aos amigos aqui representadospor Gabriel Vasconcelos, Edson Valença, Cláudio Bline, José Henrique, Péricles Gomes, MarcosRoberto, Denio Brasileiro e Pedro Chaves. A força da amizade, da ajuda e das palavras devocês teve o poder de renovar minha motivação para seguir em frente em vários momentos dessacaminhada.

Aos amigos conquistados de tantos lugares desse Brasil nessa turma de mestrado, emespecial a Danyel, Leonardo, Paula, Rony e Willamys, do nosso colaborativo e nordestino grupode tantos trabalhos apresentados. Ao pessoal do grupo "Os Originais", que seguiram sempreconsonantes com seu lema "ninguém fica pra trás". Ao pessoal do grupo de mensagens "SDN- MPROF", dos grandes parceiros Eric, Igor, Janiel e Johnathan. A troca de conhecimentos eculturas nessa turma foi uma experiência única.

No CIn, a todos os professores e equipe administrativa, todos foram fundamentais nessaformação. Tive a honrosa oportunidade de absorver um pouco do conhecimento e da experiênciade tantos profissionais de excelência em suas áreas.

Na UFPE, agradeço pelo auxílio de Edivaldo (atualmente na UFRN), ao amigo Lucindodo campus Caruaru, assim como Anderson e Adalberto do NTI em Recife. Também a todos osaconselhamentos dos estimados professores Décio Fonseca, Carlos Ferraz, Auxiliadora Padilha,Marcos Galindo e César Giusti.

Aos amigos do trabalho na Coordenação de EaD da UFPE, em especial a Georgina,Cynthia, Libório, Danilo, Silvio, Letícia, Haíra, Marco, Wanderson, Breno e Clóvis. Aos meuscoordenadores e colegas de todos os dias que acompanharam todo esse percurso, sem vocês seriaainda mais complicada essa difícil missão de conciliar pesquisa e trabalho.

Enfim, deixo minha cordial gratidão a todos que colaboraram direta ou indiretamentepara esta conquista!

Eu não tenho nenhum talento especial. Sou apenas apaixonadamente

curioso.

—ALBERT EINSTEIN

RESUMO

Um estudo especializado recente sobre tendências para 2021 mostra que o tráfego devídeo (ao vivo e sob demanda) na internet deve ultrapassar 80% do tráfego global IP e é esperadoum crescimento da qualidade dos vídeos devido ao aumento dos conteúdos em resoluçõesem ultra alta definição (4K ou 8K). Comportamento semelhante foi previsto para o cenáriocorporativo, que chegará a 70%. Motivados por essa tendência, também observamos, emespecial nas instituições de ensino, que nem sempre o consumo principal é conteúdo educacional.A concorrência de tráfego, algo comum nos sistemas multimídia, pode trazer prejuízo aodesempenho das aplicações educacionais. Nesse cenário, o grande desafio é, ao mesmo tempo,incentivar a utilização das aplicações institucionais e suportar o tráfego gerado por plataformascomo Youtube, Hangouts, Vimeo e Facebook live. O aumento da demanda e dos requisitosdos novos serviços críticos como vídeo monitoramento, telemedicina, videoconferência, VoIPe streaming, já não é suportado. E essas instituições têm concentrado esforços na melhoriadas redes de acesso e aumento de largura de banda, o que ainda é complexo e custoso. Aarquitetura tradicional das redes dificulta a distinção e priorização de serviços, além disso,outras necessidades surgem, como: controle de fluxo, processamento e controle de qualidade.As Software-defined Network (SDN) apresentam um novo paradigma de redes, fornecendocontrole centralizado e programável para tomada decisões de controle sob o tráfego. O objetivodesta pesquisa é propor uma solução baseada em SDN para melhorar a QoS e QoE no tráfegomultimídia educacional. Nos propusemos a estudar problemas relevantes e que são vivenciadosem infraestruturas, principalmente de instituições de ensino federal. Uma consequência esperadaé proporcionar uma melhoria qualitativa do conteúdo de vídeo disponibilizado, aumentando apresença institucional de aplicações avançadas como a telemedicina, monitoramento de campi ede sensores, videoconferências para EaD e streaming em tempo real. Desta forma, vislumbrandoo crescimento do tráfego de vídeo na UFPE, o nosso ambiente precisa avaliar as soluções deQuality of Service (QoS) e Quality of Experience (QoE) com atenção especial para a modalidadeEducação a Distância (EaD). Propusemos uma solução para classificação de tráfego priorizaçãode serviços e como prova de conceito, construímos um ambiente experimental e avaliamos aeficácia em termos das métricas de vazão, jitter, PSNR, VQM e SSIM para tráfego de vídeoem tempo real. Os resultados obtidos indicaram melhorias de até 49% em relação à perda dequadros, 85% em relação à variação de atraso e vazão mínima garantida e estável quando daadoção da proposta num cenário de alto congestionamento.

Palavras-chave: Qualidade de Serviço. Qualidade de Experiência. Open vSwitch. OpenFlow.Redes Definidas por Software.

ABSTRACT

A recent expert study on trends for 2021 shows that video traffic (live and on demand)on the Internet should exceed 80% of the global IP traffic and video quality growth is expecteddue to increased content in Ultra HD resolutions (4K). Similar behavior was predicted for thecorporate scenario that will reach 70%. Motivated by this tendency, we also observe, especiallyin educational institutions, that the main consumption is not always educational content. Trafficcompetition, which is common in multimedia systems, can adversely affect the performance ofeducational applications. In this scenario, the challenge is at the same time to encourage theuse of institutional applications and support the traffic generated by platforms such as Youtube,Hangouts, Vimeo and Facebook live. The increased demand and requirements of critical newservices such as video monitoring, telemedicine, videoconferencing, VoIP and streaming areno longer supported. And these institutions have concentrated on improving access networksand increasing bandwidth, which is still complex and costly. The traditional architecture ofthe networks makes it difficult to distinguish and prioritize services; in addition, other needsarise, such as: flow control, processing and quality control. Software-defined networks (SDN)present a new network paradigm, providing centralized and programmable control for makingcontrol decisions under traffic. The purpose of this research is to propose an SDN basedsolution to improve QoS and QoE in educational multimedia traffic. We set out to study relevantproblems that are experienced in infrastructures, mainly from federal educational institutions.An expected consequence is to provide a qualitative improvement of the video content madeavailable, increasing the institutional presence of advanced applications such as telemedicine,monitoring of campuses and sensors, videoconferences for EaD and real time streaming. Thus,with a view to the growth of video traffic in UFPE, our environment needs to evaluate QoSand QoE solutions with special attention to the E-learning. We proposed a solution for trafficclassification ande prioritization of services and as proof of concept, we built an experimentalenvironment and evaluated the effectiveness of throughput, jitter, PSNR, VQM and SSIM metricsfor real-time video traffic. The results obtained indicated improvements of up to 49% in relationto the frame loss, 85% in relation to the delay variation and minimum throughput guaranteedand stable when adopting the proposal in a scenario of high congestion.

Keywords: Quality of Service. Quality of experience. Open vSwitch. OpenFlow. SoftwareDefined Network.

LISTA DE FIGURAS

2.1 Arquitetura tradicional vs. SDN . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Arquitetura tradicional vs. SDN . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Arquitetura em camadas SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Arquitetura em 3 camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Componentes de um switch openflow . . . . . . . . . . . . . . . . . . . . . . . 292.6 Fluxo do pacote no pipeline de processamento . . . . . . . . . . . . . . . . . . 302.7 Fluxograma do pacote através do switch OF . . . . . . . . . . . . . . . . . . . 322.8 Sequência de mensagens de filas OF . . . . . . . . . . . . . . . . . . . . . . . 332.9 Estrutura das filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.10 Elementos e recursos do OvS . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.11 Arquitetura do Controlador Ryu . . . . . . . . . . . . . . . . . . . . . . . . . 382.12 Arquitetura baseada em eventos de uma aplicação Ryu . . . . . . . . . . . . . 39

3.1 Visão gera da proposta de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1 Visão geral da topologia do experimento . . . . . . . . . . . . . . . . . . . . . 644.2 Detalhes da topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3 Visão geral das filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1 Visão geral da rede real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Gráfico: Relação Configuração da vazão vs. Perda: Inter-campi . . . . . . . . . 765.3 Gráficos de RTT: Inter-campi . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4 Gráficos de Vazão: Inter-campi . . . . . . . . . . . . . . . . . . . . . . . . . . 775.5 Gráficos de Perdas (de Pacotes e de Quadros): Inter-campi . . . . . . . . . . . 785.6 Gráficos de jitter: Inter-campi . . . . . . . . . . . . . . . . . . . . . . . . . . 795.7 Gráfico de vazão (Mbps): Experimentos AEV . . . . . . . . . . . . . . . . . . 805.8 Gráficos de jitter: Experimentos AEV . . . . . . . . . . . . . . . . . . . . . . 815.9 Intervalos de jitter (95% IC): Experimentos AEV . . . . . . . . . . . . . . . . 815.10 Gráfico de Perdas: Experimentos AEV . . . . . . . . . . . . . . . . . . . . . . 825.11 Intervalos de Perda (95% IC): Experimentos AEV . . . . . . . . . . . . . . . . 825.12 Gráficos de Peak Signal-to-Noise Ratio (PSNR): Experimentos AEV . . . . . . 835.13 Gráficos Video Quality Metric (VQM): Experimentos AEV . . . . . . . . . . . 835.14 Gráficos de Structural Similarity (SSIM): Experimentos AEV . . . . . . . . . . 84

LISTA DE QUADROS

2.1 Componentes de um fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2 Controladores abertos populares . . . . . . . . . . . . . . . . . . . . . . . . . 372.3 Subclasses e probabilidades de descarte AF PHB . . . . . . . . . . . . . . . . 412.4 Detalhes dos trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . 43

3.1 Classes Per-hop behaviour (PHB) . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1 Experimentos dos trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . 634.2 Software nos servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3 Software nos clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4 Softwares nos switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.5 Softwares no Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.6 Redes virtuais Esxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.7 Especificações de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.8 Especificações de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.9 Configuração do tráfego de fundo: AEV . . . . . . . . . . . . . . . . . . . . . 684.10 Configuração do link: AEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Ferramentas utilizadas no cenário em produção . . . . . . . . . . . . . . . . . 75

LISTA DE ACRÔNIMOS

SDN Software-defined Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

QoS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

QoE Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ODL Opendaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

OvS Openvswitch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

OF Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

PSNR Peak Signal-to-Noise Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

VoD Video On Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

SSIM Structural Similarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

VQM Video Quality Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

FIFO First In, First Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

REST Representational State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

VM Voice over Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

VoIP Voz sobre IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ToS Type of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

DSCP Differentiated Services Code Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

RFC Request for Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

UDP User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

TCP Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

RTP Real-time Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

HTTP Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

AVI Audio Video Interleave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

OPEX Operational Expenditure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

CAPEX Capital Expenditure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

DoE Design of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

FTP File Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

HD High Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

UHD Ultra High Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3D Three-dimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

TE Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

AEV Ambiente Experimentação Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

UFPE Universidade Federal de Pernambuco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

TC Traffic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

EaD Educação a Distância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Diffserv Differentiated services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Intserv Integrated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

CDN Content Delivery Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

OTT Over The Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

RTT Round Trip Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

SVC Scalable Video Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DPI Deep Packet Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

RNP Rede Nacional de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Gbps Gigabits por segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Mbps Megabits por segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

PHB Per-hop behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

BE Best Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

EF Expedited Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

AF Assured Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

CS Class Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

CPU Central Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

GENI Global Environment for Network Innovations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ms Milissegundos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

FPS Frames per Second . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

ROIA Real-Time Online Interactive Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

DOL Opendaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

MOS Mean Opinion Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

ABR Average Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

POP Point of Presence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

OVSDB Open vSwitch Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Netem Network Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

TBF Token Bucket Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

HAS HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ICMP Internet Control Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

SUMÁRIO

1 INTRODUÇÃO 171.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3 PRESSUPOSTOS DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . 211.4 METODOLOGIA ADOTADA . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5 ORGANIZAÇÃO DO DOCUMENTO . . . . . . . . . . . . . . . . . . . . . . 23

2 REFERENCIAL TEÓRICO 242.1 CONCEITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.1 A Comutação Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 Os Planos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.3 Redes definidas por software . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.4 O protocolo Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.5 Tabelas e pipeline Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.6 As entradas de fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.7 Correspondência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.8 Recursos para QoS Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.1.8.1 Filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.1.8.2 Os Medidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.1.9 OpenvSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.1.10 O Controlador de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.10.1 O controlador de rede Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.1.11 Métricas de Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . 392.1.12 As Métricas de avaliação de Qualidade de Vídeo . . . . . . . . . . . . . . . . . 412.2 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . 422.3 QUALIDADE DE SERVIÇO (QOS) EM SDN . . . . . . . . . . . . . . . . . . 462.4 QOS E A QUALIDADE DE EXPERIÊNCIA (QOE) EM SDN . . . . . . . . . 492.5 DISCUSSÕES SOBRE OS TRABALHOS . . . . . . . . . . . . . . . . . . . . 51

3 PROPOSTA DE CONTROLE 533.1 PRIORIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2 PROCEDIMENTO DE ADMISSÃO NO CONTROLADOR . . . . . . . . . . 533.3 GARANTIA DE LARGURA DE BANDA NO SWITCH . . . . . . . . . . . . 543.4 AGREGAÇÃO DE TRÁFEGO . . . . . . . . . . . . . . . . . . . . . . . . . . 543.5 CLASSES DE SERVIÇO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.6 CLASSIFICAÇÃO DE TRÁFEGO . . . . . . . . . . . . . . . . . . . . . . . . 54

3.7 MÚLTIPLAS TABELAS DE FLUXO . . . . . . . . . . . . . . . . . . . . . . 553.8 MÓDULOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.8.1 Módulo de controle de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8.2 Módulo de Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8.3 Módulo de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.9 CONSIDERAÇÕES DE IMPLANTAÇÃO . . . . . . . . . . . . . . . . . . . . 573.10 DELIMITAÇÃO DO ESCOPO PARA TESTES . . . . . . . . . . . . . . . . . 583.10.1 Experimentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.10.2 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 AMBIENTE DE EXPERIMENTAÇÃO 614.1 VISÃO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2 OS CLIENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3 OS SERVIDORES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4 SWITCHES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5 O CONTROLADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.6 AS REDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.7 A VIRTUALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.8 O TRÁFEGO DE FUNDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.9 O TRÁFEGO PRIORITÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.10 O LINK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.11 OS CENÁRIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.11.1 As configurações de QoS e filas . . . . . . . . . . . . . . . . . . . . . . . . . . 714.12 AS FERRAMENTAS DE GERAÇÃO E COLETA . . . . . . . . . . . . . . . . 724.13 CONSIDERAÇÕES GERAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5 ANÁLISE E APRESENTAÇÃO DOS DADOS 745.1 CENÁRIO REAL INTER-CAMPI . . . . . . . . . . . . . . . . . . . . . . . . 745.1.1 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.1.2 Rede real inter-campi: Vazão . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.1.3 Rede real inter-campi: Perdas . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.1.4 Rede real inter-campi: jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2 CENÁRIOS DO AEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2.1 Comparação Cenários SQ vs. SQ: Vazão . . . . . . . . . . . . . . . . . . . . . 795.2.2 Comparação Cenários SQ vs. SQ: jitter . . . . . . . . . . . . . . . . . . . . . . 805.2.3 Comparação Cenários SQ vs. SQ: Perdas . . . . . . . . . . . . . . . . . . . . . 815.2.4 Comparação Cenários SQ vs. SQ: PSNR . . . . . . . . . . . . . . . . . . . . . 815.2.5 Comparação Cenários SQ vs. SQ: VQM . . . . . . . . . . . . . . . . . . . . . 825.2.6 Comparação Cenários SQ vs. SQ: SSIM . . . . . . . . . . . . . . . . . . . . . 83

6 CONCLUSÕES 856.1 PERGUNTAS DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . 866.2 OBJETIVOS ALCANÇADOS . . . . . . . . . . . . . . . . . . . . . . . . . . 866.3 LIMITAÇÕES DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . 876.4 DIFICULDADES ENCONTRADAS . . . . . . . . . . . . . . . . . . . . . . . 876.5 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

REFERÊNCIAS 90

APÊNDICE A — SCRIPTS DE CONFIGURAÇÃO 95

171717

1INTRODUÇÃO

As previsões apontam para um grande crescimento do tráfego de vídeo na internet nospróximos anos, que deve atingir volume superior a 80% do tráfego total até 2021 segundo CISCOAND AFFILIATES (2017a), tendo alcançado 73% em 2016. Sem o devido tratamento, duranteos picos de utilização da rede poderão ocorrer congestionamentos, reduzindo o desempenhogeral das aplicações. Por isso, várias técnicas têm sido propostas para tentar manter a taxade transferência de vídeo elevada e constante. Comportamento similar acontece nas redescorporativas, a parcela de tráfego de vídeo consumido na internet chega a 70% do tráfego,segundo CISCO AND AFFILIATES (2017b).

Nas redes corporativas, destacam-se dois tipos de transmissão de vídeo, o streaming devídeo sobre o Hypertext Transfer Protocol (HTTP), que utiliza a transmissão direta unicast, deum remetente para um destinatário; e a videoconferência, que é capaz de realizar a transmissãomulticast, de um para muitos destinatários. O tráfego de vídeo sobre HTTP também possuiforte presença nas principais aplicações na internet móvel. Em poucos anos, muitas aplicaçõesforam desenvolvidas o que fez aumentar também o tráfego médio por usuário, que segundo aCISCO, chegará aos 35 Gigabytes por pessoa por mês em 2021. Muito desse volume se deve àpopularização de aplicações de vídeo sobre HTTP disponíveis na internet, tais como YouTube1,Vimeo2, e Dailymotion3.

Na arquitetura tradicional de comunicação em redes de computadores utiliza-se o cha-mado paradigma do melhor esforço para transmitir dados. É importante destacar que nele,independentemente do tipo de informação contida, os dados recebem o mesmo tratamento darede. Segundo o modelo de comunicação em 4 camadas TCP/IP (SOCOLOFSKY; KALE,1991), as camadas superiores, mais próximas do usuário, leem as informações e classificamserviços como e-mail, HTTP e File Transfer Protocol (FTP). Uma rota entre origem e destino écriada utilizando-se a visão do próximo dispositivo na rede, ou seja, não há uma visão global darede, cada dispositivo utiliza um protocolo de roteamento para estabelecer a topologia da redee o algoritmo de roteamento calcula o próximo salto. Apesar de limitada, essa estrutura temfuncionado e facilitou a expansão da Internet.

1http://www.youtube.com2http://vimeo.com3http://www.dailymotion.com

CAPÍTULO 1. INTRODUÇÃO 18

Multimídia tem sido definida como a combinação digital entre um meio estático (textoe imagens) e outro meio dinâmico (vídeo, áudio, animação). Tais aplicações se tornaram asmais populares da Internet, o que trouxe um grande desafio devido ao grande volume de dados.Embora utilizando o roteamento tradicional não seja possível garantir largura de banda, nemlimitar o atraso dos pacotes, estas aplicações atendem uma grande quantidade de usuários. Odesempenho de aplicações de Streaming de vídeo nessa arquitetura tradicional é aceitável graçasàs técnicas avançadas de transmissão, principalmente as que reduzem o volume dos dadosusando Scalable Video Coding (SVC) e multicast, como em LAGA et al. (2014), TANG; HUA;WANG (2014) e TSUNG-FENG; WANG; HSU (2015); trazem o conteúdo para próximo docliente usando Content Delivery Network (CDN), caching e roteamento, como em LIU et al.(2013), NAM et al. (2014), WANG et al. (2014), II; DURRESI (2015) e GEORGOPOULOSet al. (2015); realizam adaptação dinâmica de taxas, Average Bit Rate (ABR) e HTTP AdaptiveStreaming (HAS), como utilizado em LAGA et al. (2014) e UZAKGIDER; CETINKAYA;SAYIT (2015).

A ampliação da gama de dispositivos conectados à Internet e o desenvolvimento denovos serviços como Voz sobre IP (VoIP), Streaming de vídeo, Internet das Coisas, Computaçãoem Nuvem, trouxeram consigo desafios para a arquitetura rígida atual. Aplicações diferentesdemandam requisitos diferentes da rede, que por sua vez deveria tratar especificamente cada tipo.

Nas redes tradicionais, os serviços requisitados têm sido integrados ao núcleo da rede pormeio de inúmeras tecnologias proprietárias, nas quais o acesso do administrador fica limitadoa poucas opções de configuração. Modificações adicionam complexidade aos dispositivos derede (memória, processamento e energia) e novos serviços podem requerer a reconfiguraçãoda rede ou troca de equipamentos em produção. Tais limitações revelam a necessidade de seflexibilizar a personalização das redes, é preciso permitir a adaptação às especificidades de cadacenário. Esse problema das redes tradicionais tem sido conhecido como ossificação, referindo-seao processo na vida humana de substituição das cartilagens (flexíveis) por ossos.

Software-defined Network (SDN) apresenta um novo paradigma para a comunicaçãoem redes de computadores, é uma arquitetura de rede que separa o plano de controle do planode dados. O plano de controle, das decisões, é centralizado em um elemento da rede chamadocontrolador SDN, que é executado em um servidor comum. O controlador possui um sistemaoperacional de rede onde são programadas e executadas as aplicações de rede, como Traffic En-gineering (TE), Quality of Service (QoS), Quality of Experience (QoE), segurança, virtualizaçãoe roteamento. O plano de dados, ou de encaminhamento, permanece na rede e é executado emsimples comutadores (switches), que executam o encaminhamento de pacotes e outras ações,baseadas em instruções do controlador.

SDN proporciona uma forma inovadora para permitir que os administradores de redetenham controle central e programável sobre tráfego global da rede. SDN fornece abstraçõespara construção de verdadeiros sistemas de redes. Assim, pode-se aproveitar uma ApplicationProgramming Interface (API) comum e os controladores para gerenciar fluxos de tráfego, o que


inclui aplicações de multimídia, e em especial o tráfego de vídeo.

1.1 MOTIVAÇÃO

Atualmente, observa-se o aumento constante da demanda e dos requisitos para transmis-são de vídeo em alta resolução, inclusive em aplicações educacionais. Isso já vem motivandoo aperfeiçoamento das técnicas de transmissão, compressão e codificação, além da melhoriana qualidade dos canais de comunicação e redes de acesso à Internet. Vários serviços críticosatuais como o videomonitoramento, telemedicina, videoconferência, streaming, vídeos em altaresolução (High Definition (HD), Three-dimensional (3D) e Ultra High Definition (UHD)), sãoresponsáveis por gerar essa demanda.

O desenho tradicional de redes de computadores não é capaz de atender às necessidadesdos serviços como controle do fluxo de tráfego, processamento de rede intermediário, QoS eQoE, requisitos comuns dos serviços de multimídia. A arquitetura de redes de computadoresprecisa ser completamente transformada para atender a essa Internet do futuro.

Já o tráfego de aplicações de streaming de vídeo tem dominando a internet. Sabe-seque, geralmente, o streaming de vídeo ao vivo precisa ser distribuído para vários usuários,quando seria ideal usar multicast. No entanto, multicast não é popular, já que exige o suportedos roteadores, e/ou equipamentos específicos, o que pode elevar principalmente o CapitalExpenditure (CAPEX) necessário para habilitar a tecnologia nas redes. Com o desenvolvimentodas redes móveis, de telecomunicações, internet e TV, as redes se tornaram ambientes maisheterogêneos e com a popularização dos laptops, tablets e smartphones, dispositivos com váriascapacidades de transmissão podem estar envolvidos numa mesma sessão de Streaming. Essaheterogeneidade torna mais complexo viabilizar a comunicação de streaming em multicast.

Skype4 e Google Hangouts5, por exemplo, já oferecem serviços de vídeo ao vivo viaHTTP em unicast, ainda que com limitações. Os principais desafios da transmissão de streaming

tem sido a interação em tempo real entre muitos usuários, já que a grande quantidade detráfego deve ocasionar problemas de largura de banda e congestionamento; e a escalabilidadee flexibilidade do serviço ao enviar sob demanda cada fluxo de vídeo por múltiplos caminhosde forma eficiente. Conclui-se que é necessário aumentar as taxas de transmissão de vídeo emantê-las constantes, e esses desafios seriam bem difíceis de superar sem SDN.

Este trabalho pretende mostrar factível e viável a resolução de problemas vivenciados nasorganizações. No âmbito das tecnologias educacionais, uma importante consequência deve sermotivar o desenvolvimento e a distribuição de conteúdo de vídeo para uso serviços como aulas,palestras, conferências, reuniões acadêmicas. Além disso, que o conteúdo e os recursos sejamcada vez mais utilizados e produzidos em melhor qualidade, estando presentes na rede através deaplicações como as de Telemedicina, Monitoramento de campi e de sensores, videoconferências

4https://www.skype.com5https://hangouts.google.com


para Educação a Distância (EaD) e streaming em tempo real.Para NUNES et al. (2014), as empresas executam grandes redes, e possuem requisitos

rigorosos de segurança e desempenho. As redes universitárias podem ser consideradas umcaso especial, pois em um ambiente, muitos dispositivos de conexão são temporários e nãocontrolados pela Universidade, além disso, necessitam maior segurança e alocação de recursos.As universidades muitas vezes precisam dar suporte a testes de pesquisa e protocolos externos.O gerenciamento adequado é extremamente importante e SDN pode ser usada para implementare ajustar políticas de rede, além de ajudar no monitoramento e ajustes de desempenho.

Desde análise inicial da infraestrutura da Universidade Federal de Pernambuco (UFPE),durante o planejamento e coleta de informações básicas, já percebemos a ausência de mecanismosde controle bem definidos e eficientes na instituição. Por exemplo, não foi possível coletarinformações de perfil de tráfego de aplicações na rede no dispositivo proprietário existente; nãofoi possível coletar métricas de experiência do usuário na aplicação institucional de conferênciasvia web. Percebemos um certo estágio de ossificação da rede, portanto qualquer que fosse asolução a ser abordada, teria que ser baseada na adoção de SDN, pois permitiria aproveitarbenefícios, descritos em XIA et al. (2015), como a visão global da rede, programabilidade,inteligência na rede, interface aberta de controle centralizado e padronizado, independente defabricantes e facilidade de inovação, o que é desejável numa instituição com missão de ensino epesquisa.

Percebemos na UFPE que os produtores de conteúdo não confiavam na rede, elesacabam optando por gerar conteúdo leve e de baixa qualidade. A EaD na universidade vemacompanhando uma tendência de crescimento mundial, também chegando a um estágio emque um novo passo qualitativo deve ser dado. A comunidade acadêmica deseja utilizar novasferramentas, como as de tempo real e conteúdo em UHD, deseja vivenciar uma nova experiênciaem termos da qualidade de conteúdo dos cursos. É uma demanda emergente e para que isso sejapossível, a instituição deverá se preparar para ter esse controle refinado sob o tráfego de rede.

Apesar da capacidade de 10 Gigabits por segundo (Gbps) de saída ao Point of Presence(POP), em Recife, a conexão inter-campi ainda está limitada a 100 Megabits por segundo(Mbps) para os Campi Vitória e Caruaru. Estes links são fornecidos pela Rede Nacional dePesquisa (RNP). Em princípio, o backbone do campus Recife possui capacidade suficiente parao crescimento da demanda de tráfego, contudo o suporte à QoS também precisa ser estruturadouma vez que sobreprovisionamento não necessariamente garante qualidade nas transmissões emmomentos de pico e com tráfego interferente. Para que alcancemos o objetivo de proporcionaruma qualidade equânime para todos os campi, é necessário utilizar mecanismos de controlecentralizados, que permitam o monitoramento voltado para a tomada de decisão.

E se levarmos em consideração a estrutura da EaD, as estruturas dos Polos de apoiopresencial aos cursos, localizados em cidades do interior do estado, ficando a até 800 Km dacapital, nesses pontos temos condições e experiência do usuário ainda piores. Tudo isso acabaimpactando na percepção de qualidade dos cursos da instituição, como um todo. Independente-


mente de ser polo, interior ou capital, é o acesso ao serviço prestado pela instituição que está emquestão. Supondo-se a definição de uma solução SDN institucional, através da implantação dedispositivos com suporte a Openflow (OF), tal solução institucional poderia ser incorporada aospolos. Na UFPE já houve iniciativas para se projetar uma estrutura de monitoramento das redesdos polos onde há cursos da UFPE, o que hoje já poderia ser feito baseado em SDN, mesmo queparcialmente.

1.2 OBJETIVOS

O objetivo geral da pesquisa é propor e analisar o desempenho de uma solução baseadano paradigma SDN e em recursos do protocolo OF que permita o desenvolvimento de umaaplicação para adaptação dinâmica da rede baseada no monitoramento de métricas e aplicaçãode políticas de QoS, para priorização de tráfego em redes corporativas.

Os objetivos específicos são:

� Construir um ambiente de experimentação específico, adequado a SDN e flexível osuficiente para permitir a criação de experimentos que utilizem: conteúdo e tráfegoreal, manipulação de tráfego concorrente não prioritário, análise distinta dos doistipos de tráfego, que seja facilmente replicado;

� Analisar características de transmissão de vídeo em tempo real inter-campi na UFPE,de modo a permitir a definição de parâmetros para emulação das características derede no experimento.

� Analisar as principais técnicas de transmissão e codificação, e métricas de QoS eQoE em fluxos de vídeo que sejam adequados à aplicação em ambientes SDN;

� Analisar as características objetivas da rede em transmissões de conteúdo real, uti-lizando uma aplicação real de streaming de Vídeo em tempo real, baseando-se emmétricas de QoS e QoE;

� Propor uma solução prática de controle de QoS, com maior compatibilidade possívelcom a rede atual;

� Verificar se a estratégia de enfileiramento por prioridade baseada em SDN melhoraas métricas de QoS e QoE do vídeo em tempo real.

1.3 PRESSUPOSTOS DE PESQUISA

Nesta pesquisa, e antes de definir a metodologia, a partir de conhecimento prévio e deproblemas detectados e vivenciados num ambiente institucional educacional, partiremos dosseguintes pressupostos teóricos:


� P1: é complexo ter um monitoramento efetivo e tratamento diferenciado de tráfegode missão crítica sem SDN;

� P2: é complexo avaliar as métricas de QoS para aplicações de vídeo em tempo real;

� P3: não há mecanismos na instituição para avaliar a QoE percebida pelos usuários;

� P4: é simples e eficaz construir um sistema de priorização de tráfego baseado emSDN.

E ao longo do trabalho testaremos as seguintes hipóteses:

� H1: Com um ambiente de experimentação baseado em virtualização é possívelavaliar o tráfego de vídeo em tempo real de redes em produção.

� H2: Com um sistema simples baseado em SDN e recursos do protocolo OF é possívelcontrolar as métricas de QoS e melhorar a QoE da rede.

Temos então uma pergunta pesquisa que buscaremos responder: é eficaz fornecer ocontrole de QoS, através de priorização de tráfego institucional em redes definidas por software,avaliando QoE em ambientes em produção?

1.4 METODOLOGIA ADOTADA

Para atingir os objetivos de pesquisa, foi adotada a metodologia descrita a seguir:Em primeiro lugar, para que as questões e definições sobre os métodos a serem adotados

fossem logo resolvidas, foi realizada uma pesquisa exploratória a respeito dos vários temasenvolvidos, e em seguida outra mais aprofundada sobre os principais e mais recentes trabalhosque abordam conceitos relacionados. Foi realizada uma análise crítica resumida sobre a essênciados principais e mais recentes artigos e técnicas empregadas, em partes: a) relacionados àsúltimas abordagens que utilizam SDN para resolver problemas gerais do tráfego de vídeo; b)focados nas técnicas de QoS em SDN; c) com foco nas métricas de QoS e o reflexo em QoE.

Em seguida foi concebida e demonstrada uma proposta para uma aplicação de classi-ficação e priorização de tráfego de forma dinâmica, em SDN. Tal proposta foi apresentadaem formato descritivo, mostrando especificações gerais de software e configurações para oControlador de rede.

Em seguida, foi realizada a coleta de dados de tráfego na rede em produção numacomunicação de vídeo em tempo real usando o protocolo Real-time Transport Protocol (RTP),cenário real que foi chamado de inter-campi. Foram coletados os dados e calculadas as métricasobjetivas. Foi feita então a caracterização básica da rede desse cenário real inter-campi.

De posse das características da rede, foi definido o Ambiente Experimentação Virtual(AEV) e cenários de teste. No planejamento dos experimentos, apenas para verificar a coerênciados testes, foram consultados conceitos básicos de Design of Experiments (DoE), expostos de


forma mais prática em COLEMAN (2014). Foram estabelecidos os recursos e softwares a seremutilizados em todo o processo, foi delimitado o escopo dos testes reais. O produto desta etapa é aseção de descrição e desenho do ambiente de experimentação.

Com a definição do ambiente, o mesmo foi construído e em seguida foi aplicada aolink virtual a modelagem baseada nos parâmetros obtidos da caracterização inter-campi. Todaa execução dos experimentos nos cenários foi programada em scripts de modo a armazenar osdados de forma organizada em diretórios.

O grande volume de arquivos contendo dados das medições foram tabulados, o queexigiu um processamento parcialmente manual dos arquivos e a criação de vários scripts paraautomatizar os cálculos. Em seguida, os dados foram analisados com o auxílio de mais scripts eferramentas específicas para cálculo estatístico e geração de gráficos. No final foram extraídas asmétricas de avaliação.

Na análise dos resultados, depois de tabulados, os dados coletados foram apresentados naforma de gráficos seriais baseado na sequência de experimentos, e em gráficos de intervalos deconfiança, com níveis de confiança de 95%. A análise e apresentação dos gráficos foi realizadapara cada métrica comparando a evolução entre os cenários. Os gráficos foram gerados e nasanálises foi realizada uma avaliação empírica e análise crítica dos reflexos das métricas nassituações reais de uso.

Por fim foi realizada uma análise geral da pesquisa e dos resultados. Foram respondidasas perguntas de pesquisa e justificado o alcance dos objetivos inicialmente propostos. Tambémforam mencionadas as limitações do trabalho e desafios em aberto.

1.5 ORGANIZAÇÃO DO DOCUMENTO

Este documento está organizado da seguinte forma:No primeiro capítulo é realizada uma introdução ao tema central e ao problema.O segundo capítulo aborda a teoria envolvida no trabalho, são descritas as principais

referências conceituais e analisados os principais trabalhos relacionados.No terceiro capítulo é apresentada uma proposta para classificação e priorização de

tráfego baseado em SDN.No quarto capítulo são descritos os detalhes do ambiente de experimentação e cená-

rios utilizados na prova de conceito. São abordados aqui todos os aspectos envolvidos noplanejamento, montagem e execução dos experimentos.

No quinto capítulo, os dados são apresentados graficamente e são analisados os experi-mentos em termos das métricas utilizadas.

No sexto e último capítulo são feitas as considerações finais. São descritas as conclusõessobre a pesquisa, sobre a proposta e sobre a análise de tráfego. São apresentadas as limitaçõesdo trabalho e trazidos à luz os desafios que permanecem em aberto.

242424

2REFERENCIAL TEÓRICO

Dada a quantidade de subtemas que permeiam o tema central e que são fundamentais paraa compreensão da abordagem proposta, é feita, a seguir, a fundamentação teórica e conceitual.Em seguida realizamos uma análise crítica e discussão comparativa dos principais trabalhosrelacionados e utilizados na pesquisa. Primeiro analisaremos os trabalhos relacionados àsabordagens que utilizam SDN para resolver problemas de QoS e QoE de vídeo, em seguida osdirigidos às técnicas de QoS em SDN, e por último os que têm foco nas métricas de QoS e oreflexo na qualidade de experiência do usuário.

2.1 CONCEITOS

GORANSSON; BLACK (2014) nos ajudam a entender os conceitos iniciais de SDNe planos. Inicialmente, confirmam que SDN representa uma nova abordagem que tenta atacaras fraquezas do paradigma tradicional de redes baseadas em melhor esforço, sendo uma novamaneira de programar os switches nas redes atuais. O movimento de SDN para uma arquiteturade controle de rede altamente escalável e centralizada é ainda mais eficiente em grandes redesonde prevalecem os centros de dados de larga escala. O interesse em SDN vai muito além dascomunidades de pesquisa e engenharia intrigadas com essa nova tecnologia de comutação paraInternet. Eles mencionam o potencial que as SDN possuem para proporcionar uma enormemudança na indústria de redes, já que os operadores históricos da indústria poderiam serdestituídos e despencariam os custos para o consumidor final. No entanto, o documento tambémalerta para a necessidade de se compreender as limitações desse modelo.

2.1.1 A Comutação Tradicional

Os autores explicam que as diversas funções de comutação são tradicionalmente separa-das em três categorias distintas. Como cada categoria pode realizar comunicação horizontal compares em entidades adjacentes, em uma topologia, e também pode realizar a comunicação verticalcom as outras categorias, tornou-se comum representar estas categorias como camadas ou planos.Comunicações em pares ocorrem no mesmo plano, e mensagens de categorias cruzadas ocorremem terceira dimensão, entre os planos. São definidos os planos de dados, controle e gerencia-

CAPÍTULO 2. REFERENCIAL TEÓRICO 25

mento, em switches tradicionais. A Figura 2.1 compara em alto nível as arquiteturas, tradicionale SDN. Percebe-se à esquerda um comutador rede que acumula funções, e à direita, em SDN,a presença de um controlador de rede que pode gerenciar vários comutadores. O sistema de

Figura 2.1: Arquitetura tradicional vs. SDN

Fonte: Adaptado de GORANSSON; BLACK (2014)

controle em redes tradicionais IP é distribuído, cada elemento de rede é uma entidade autônomaseparada com seus próprios planos de controle e de encaminhamento. Os operadores de redeprecisam acessar e configurar cada switch numa grande rede. As decisões de encaminhamentosão baseadas nas informações compartilhadas entre outros dispositivos.

2.1.2 Os Planos

É importante destacar que a grande maioria dos pacotes manipulados pelo switch sósão manipulados pelo plano de dados. O plano de dados é composto por várias portas que sãoutilizadas para a recepção e transmissão de pacotes, e uma tabela de encaminhamento com sualógica associada. O plano de dados assume a responsabilidade pelo buffering e agendamentode pacotes, modificação cabeçalho e encaminhamento. Se as informações do cabeçalho de umpacote de dados que chega são encontradas na tabela de encaminhamento (o que é chamadode correspondência ou match), ele pode sofrer modificações de campo em seu cabeçalho e, emseguida, será encaminhado sem qualquer intervenção dos outros dois planos. Mas nem todos os


pacotes serão manipulados no plano de dados, a informação do pacote pode não estar na tabela,ou ele pode pertencer a um protocolo de controle que será processado pelo plano de controle.

A Figura 2.2 dá uma visão geral do funcionamento da arquitetura de planos:

Figura 2.2: Arquitetura tradicional vs. SDN

Fonte: Adaptado de GORANSSON; BLACK (2014)

O plano de controle está envolvido em muitas atividades. O seu papel principal é mantera atualizada a informação da tabela de encaminhamento para que o plano de dados possa lidarde forma independente com a maior quantidade de tráfego possível. O plano de controle éresponsável pelo processamento de diferentes protocolos de controle que podem afetar a tabelade encaminhamento, dependendo da configuração e tipo do switch. Estes protocolos de controlesão corresponsáveis pelo gerenciamento da topologia ativa da rede. Eles são suficientementecomplexos para exigir o uso de microprocessadores e software de acompanhamento do plano decontrole.

O terceiro é o plano de Gerenciamento. Os administradores de rede configuram econtrolam os switches através deste plano, que por sua vez, extrai a informação ou modifica osplanos de controle e de dados de forma apropriada. Os administradores usam um sistema degerenciamento de rede para se comunicar com o plano de gerenciamento de um switch.

2.1.3 Redes definidas por software

Ainda tomando como base os conceitos de GORANSSON; BLACK (2014), pode-seresumir que em sua essência, SDN é uma arquitetura de rede inovadora que desacopla plano


de controle e plano de dados, abstraindo a função de controle para um controlador de rede,logicamente centralizado. O controlador SDN mantém uma visão global da rede e forneceaplicações e políticas, com visão de único comutador lógico. SDN simplifica muito o designe operação de rede já que as instruções são fornecidas pelo controlador SDN em vez de váriosdispositivos e protocolos de fornecedores. Atualmente, o protocolo OF (OPEN NETWORKINGFOUNDATION, 2015a) é o mais utilizado como protocolo de comunicação entre plano decontrole e de dados. O protocolo OF tem sido o responsável por viabilizar o suporte a SDN nosswitches.

Várias pesquisas procuram consolidar os conceitos de SDN, entre elas o Request forComments (RFC) do Internet Research Task Force (IRTF), da categoria informacional, HALE-PLIDIS et al. (2015) descreve as especificações de arquiteturas e camadas SDN. Ele defineSDN como um paradigma para programação em redes, que habilita a capacidade de inicializar,controlar, alterar e gerenciar o comportamento da rede dinamicamente através de interfacesabertas. A RFC confirma que um dos princípios fundamentais de SDN é a separação entre osPlanos de dados e controle, o que permite reduzir a complexidade e um ciclo de inovação maisrápido nos planos. Nesse conceito de separação, SDN estabelece uma relação entre uma entidadecontroladora e uma entidade controlada através de interfaces. A Figura 2.3 nos dá uma visãogeral da arquitetura em camadas de SDN. Percebe-se aqui a presença das API entre os planos,divididas em norte (para aplicações mais externas, normalmente aplicações de monitoramento,gerenciamento e orquestração) e sul (para atuação de protocolos internos, para aplicações decontrole, como OF).

Figura 2.3: Arquitetura em camadas SDN

Fonte: Adaptado de HALEPLIDIS et al. (2015)


Segundo OPEN NETWORKING FOUNDATION (2012), a arquitetura SDN tem algu-mas características mais importantes:

� Programabilidade direta: O controle está desacoplado das funções de encaminha-mento;

� Agilidade: o controle do encaminhamento permite aos administradores ajustar dina-micamente o fluxo da rede para atender necessidades específicas;

� Gerenciamento centralizado: a inteligência é centralizada em controladores baseadosem software que mantêm uma visão global da rede como único switch lógico;

� Configuração programática: SDN permite aos administradores configurar, gerenciar,proteger e otimizar recursos de rede rapidamente por meio de programas dinâmicos eautomatizados;

� Padronização aberta livre fornecedor: simplifica o projeto e operação da rede porqueas instruções são fornecidas pelos controladores SDN em vez de vários dispositivos eprotocolos de fornecedores.

A Figura 2.4 consegue ilustrar bem a arquitetura SDN em suas três camadas. A camadade aplicação é onde são executadas as aplicações comerciais diversas. Na de controle está oplano de controle com os serviços de rede. E na de infraestrutura temos o plano de dados nosswitches. Percebe-se na imagem as setas duplas que representam as API’s norte e sul (nesta seencontra o OF). OPEN NETWORKING FOUNDATION (2012) também mencionam OF comoprotocolo fundamental nas soluções SDN implementadas na atualidade.

Figura 2.4: Arquitetura em 3 camadas

Fonte: Adaptado de (OPEN NETWORKING FOUNDATION, 2012)


2.1.4 O protocolo Openflow

OF é um padrão aberto que permite a implementação de protocolos de rede inovadores. Osuporte ao protocolo vem sendo adicionado em switches comerciais. A especificação mais recentedo protocolo descreve componentes e funções básicas do OF, ilustrado na Figura 2.5, onde oswitch se comunica com um controlador através do protocolo OF. Segundo a especificação,um switch OF consiste em tabelas e grupos de tabelas para encaminhamento de pacotes, alémde canais OF que o conecta a um ou mais controladores externos. Usando o protocolo OF,o controlador pode manipular (adicionar, atualizar e excluir) entradas nas tabelas de fluxo,reativamente ou proativamente (OPEN NETWORKING FOUNDATION, 2015a).

Figura 2.5: Componentes de um switch openflow

Fonte: Adaptado de OPEN NETWORKING FOUNDATION (2015a)

Quando um novo fluxo chega, o switch verifica a sua tabela de fluxos, caso não encontreuma entrada correspondente a este fluxo em seus registros, ele envia o pacote para o controladoratravés de uma mensagem "packet_in". Baseado em sua aplicação, o controlador decide o quefazer com o fluxo (encaminhar, descartar, enviar de volta) e o controlador informa ao switch

instalando um novo fluxo em suas tabelas.A procura por correspondência começa na primeira tabela de fluxos (Tabela 0) e pode

continuar por tabelas adicionais formando um pipeline (conjunto de tabelas de fluxo logicamenteconectadas para prover correspondência, encaminhamento e modificação de pacotes num switch

OF). As entradas de fluxo testam a correspondência dos pacotes por ordem de prioridade, eutilizam a primeira entrada correspondente em cada tabela. Ao encontrar uma entrada correspon-dente, as instruções associadas a essa entrada são executadas. Se nenhuma correspondência forencontrada em uma tabela, o resultado depende da configuração da entrada de fluxo "table-miss",nesse caso o pacote pode ser encaminhado ao controlador pelo canal OF, descartado, ou podeseguir para a próxima tabela. As instruções de processamento do pipeline permitem que ospacotes sejam enviados por tabelas subsequentes. O processamento do pipeline encerra quando


as instruções não especificam mais uma próxima tabela, finalmente o pacote é modificado eencaminhado. Entradas de fluxos são encaminhados para uma porta do switch.

A Figura 2.6 mostra o processamento geral do pipeline. O pipeline OF de cada switch

possui uma ou mais tabelas de fluxo. O processamento de pipeline OF define como os pacotesinteragem com essas tabelas. Um switch OF precisa ter pelo menos uma tabela de ingresso, astabelas são sequencialmente numeradas começando por 0.

2.1.5 Tabelas e pipeline Openflow

Figura 2.6: Fluxo do pacote no pipeline de processamento


As instruções executadas quando ocorre uma correspondência podem direcionar explici-tamente o pacote para outra tabela usando uma instrução "goto", e o mesmo processo de teste decorrespondência vai se repetindo. Uma entrada de fluxo só pode direcionar um pacote para umatabela de número maior do que o seu, ou seja, o processamento do pipeline só pode avançar. E,logicamente, os fluxos da última tabela de um pipeline não possuem a instrução "goto". Se aentrada de fluxo correspondente não direcionar pacotes para outra tabela, o processamento depipeline finaliza nessa tabela, o pacote é processado com seu conjunto de ações associadas enormalmente transmitido.

2.1.6 As entradas de fluxo

Uma tabela de fluxos é composta de entradas de fluxos, o Quadro 2.1 exibe os camposde uma entrada de fluxo.

� Match fields: campos para corresponder com os pacotes. Estes consistem em portade ingresso e cabeçalhos de pacotes, e, opcionalmente, outros campos de pipeline,como os metadados especificados por uma tabela anterior.


Quadro 2.1: Componentes de um fluxo

Match Fields Priority Counters Instructions Timeouts Cookie FlagsFonte: OPEN NETWORKING FOUNDATION (2015a)

� Priority: precedência de correspondência de fluxo.

� Contadores: atualizados quando os pacotes são correspondidos.

� Instruções: para modificar um conjunto de ações ou processamento de pipeline.

� Timeouts: quantidade máxima de tempo ou tempo ocioso antes que o fluxo sejaexpirado pelo switch.

� Cookie: valor escolhido pelo controlador. Pode ser usado pelo controlador para filtrarentradas de fluxo afetadas por requisições de estatísticas, modificação e de exclusãode fluxos. Não é usado no processamento dos pacotes;

� Flags: alteram a forma como as entradas de fluxo são gerenciadas, por exemplo,a flag OFPFF_SEND_FLOW_REM gera mensagens de fluxo removido para essaentrada de fluxo.

Uma entrada na tabela de fluxo é identificada por seus campos de correspondência eprioridade. Os campos de correspondência e prioridade identificam uma entrada única em umatabela específica. A entrada de fluxo em que todos os campos são omitidos e tem prioridadeigual a 0 é chamada de entrada de fluxo "table-miss".

2.1.7 Correspondência

O pacote segue um fluxo básico através de um switch OF, como ilustra a Figura 2.7, norecebimento de um pacote (packet in), o switch executa um conjunto de ações. A primeira tabela(0) é inicialmente consultada e de acordo com o processamento do pipeline, pode consultaroutras tabelas.

Campos de correspondência são extraídos do pacote. Esses campos usados para consultasem tabelas, dependem do tipo de pacote e tipicamente incluem vários campos de cabeçalho,como endereço Ethernet de origem ou o endereço de destino IPv4. Os metadados também podemser usados para passar informações entre tabelas de um switch. Os campos de correspondênciarepresentam o pacote em seu estado atual, se as ações aplicadas em uma tabela anterior usandoa instrução apply-actions mudar os cabeçalhos de pacotes, essas alterações são refletidas noscampos de correspondência.


Figura 2.7: Fluxograma do pacote através do switch OF


2.1.8 Recursos para QoS Openflow

Falando-se em implementação prática de QoS em SDN é importante conhecer os princi-pais recursos disponibilizados nas versões do protocolo OF. As principais ferramentas são asFilas (Queues) e os Medidores (Meters). Tais recursos são formas simples de se obter QoS emSDN.

2.1.8.1 Filas

A especificação OF versão 1.0 já define o conceito de filas. Um switch OF fornece suportelimitado a QoS através de um mecanismo de enfileiramento simples. Uma ou mais filas podemser associadas a uma porta e podem ser usadas para mapear fluxos nelas. Fluxos mapeados paraum fila específica serão tratados de acordo com a configuração de fila (por exemplo, taxa mínima).Como mencionado, desde a versão inicial do OF que há suporte para filas, onde podem serconfigurados limites de taxa de saída de pacotes por uma porta do switch para a implementaçãode QoS. As filas são projetadas para fornecer uma garantia de taxa de fluxo de pacotes colocadosna fila. Assim, filas diferentes a taxas diferentes podem ser usadas para priorizar um tráfego"especial"sobre um tráfego "normal", ou limitar tráfegos "gananciosos". OF 1.0 e 1.1 suportamfilas com a propriedade de taxa mínima, enquanto OF 1.2 e superiores adicionam a configuraçãode taxa máxima. É possível implementar Filas com Openvswitch (OvS). Alguns switches legados(não SDN) também suportam a configuração de filas em nível de sistema operacional ou atravésde interfaces proprietárias.


As Filas não podem ser configuradas diretamente através do protocolo OF, o que pode serfeito através de outros protocolos de configuração do switch, como OF-Config ou Open vSwitchDatabase (OVSDB), no entanto, suas estatísticas podem ser consultadas pelo OF. O objetivodesta sequência de mensagens, ilustrada na Figura 2.8, é permitir ao controlador consultar oestado de filas associadas a várias portas no switch OF, na versão 1.3.

Figura 2.8: Sequência de mensagens de filas OF

Fonte: Adaptado do site Flowgramable1

A estrutura mostrada na Figura 2.9 começa com um identificador "queue_id", queidentifica unicamente uma fila. A estrutura primária termina com uma sequência de estruturasde propriedades. As propriedades vão indicar o tipo de carga útil presente nas propriedades.Inicialmente, existia apenas um tipo, a propriedade “MinRate”. OF 1.2 incluiu um identificador"port", que indica a porta da qual fila faz parte. Além disso, os tipos de propriedade foramaumentados com “Max Rate”, e “experimenter”. A carga útil do “experimenter” termina com umcampo de dados de comprimento variável, e que pode ser utilizado para recursos de aplicaçõesespecíficas.

Figura 2.9: Estrutura das filas

Fonte: Adaptado do site Flowgramable 2

2http://flowgrammable.org/sdn/openflow/message-layer/queue-1/


2.1.8.2 Os Medidores

A especificação do Openflow versão 1.3 já introduz o conceito de Medidor. OPENNETWORKING FOUNDATION (2015a) define uma tabela de medidor consiste em entradasde medidor, definindo medidores por fluxo. Isso permite que o OF implemente técnicas deQoS simples, restringindo um conjunto de fluxos a uma banda específica. Também permitemaplicação de políticas de QoS mais complexas, como a medição baseada em DifferentiatedServices Code Point (DSCP) que pode classificar um conjunto de pacotes em categorias combase na sua taxa. Medidores (por fluxo) podem ser combinadas com as filas (por porta) paraimplementar estruturas de QoS complexas, como Differentiated services (Diffserv).

Ainda com base no que diz OPEN NETWORKING FOUNDATION (2015a), pode-seconcluir que um Medidor é um elemento de comutação que pode medir o tráfego na entrada econtrolar a taxa de saída de pacotes. Cada medidor pode ter várias bandas de medidor que sãousadas para definir o comportamento dos medidores em vários intervalos de taxa. Uma banda demedidor é ativada se a taxa de pacotes ou de bytes passante exceder um limite pré-determinado.É possível realizar dois tipos de operações baseadas nas taxas de fluxo: o descarte (bandalimitadora de taxa); ou a remarcação de bits do campo DSCP dos pacotes. Desta forma, os fluxospodem orientar a execução de ações baseadas na taxa de pacotes recebidos.

É importante dizer que as estruturas de Medidores e Filas se complementam. Apesarde, por serem mais rígidas e necessitarem implementação pelo administrador da rede no switch

(usando comandos OvS) em modo "out-of-band", há uma certa diferença em relação aos Medido-res, que podem ser instalados, modificados e removidos, em tempo de execução usando OF. OsMedidores podem ser manipulados de modo semelhante aos fluxos: eles recebem pacotes comoentrada e podem enviar pacotes como saída. Atualmente, apenas no ofsoftswitch (CPqD; ERICS-SON INNOVATION CENTER, 2012) e outros switches de hardware proprietário suportammedidores OF completamente. O OvS não suporta medidores OF (PROJECT FLOODLIGHT,2016).

Em resumo, Medidores e filas permitem que as redes criem perfis de largura de banda,estabelecendo limites e garantias sobre o tráfego de classes específicas. Com SDN, esses limitesnão são fixos como parte de uma topologia estática, o provisionamento baseado em políticas podeser implantado de forma dinâmica, e o hardware flexível em SDN pode ajustar dinamicamenteassociações de Medidores e filas.

2.1.9 OpenvSwitch

Segundo LINUX FOUNDATION (2009), o OvS é uma plataforma aberta multicamada,de comutação virtual de qualidade para produção. OvS foi projetado para permitir automação derede em massa, mantendo compatibilidade com outros protocolos. Ele suporta gerenciamentopadrão das interfaces e abre as funções de encaminhamento para controle e extensão programática.O OvS é bem adequado para funcionar como um switch virtual em ambientes virtualizados.


Além disso ele foi projetado para suportar a distribuição através de múltiplos servidores físicos,ideal para hipervisores. Esses ambientes são caracterizados pelo comportamento dinâmicodos pontos; necessidade de manutenção das abstrações lógicas; necessidade de integração oudescarga para hardware de comutação especial. A Figura 2.10 ilustra recursos do OvS. Porquestões de desempenho, um dos objetivos do OvS é manter o código do seu núcleo o menorpossível e reaproveitar subsistemas existentes, (como QoS). Atualmente, o OvS e seus pacotesde utilitários para o espaço de usuário estão disponíveis nas distribuições Linux mais populares.O OvS, naturalmente, também é bastante utilizado na maioria dos experimentos que envolvemcomutação baseada em SDN, fazendo parte, inclusive, da instalação padrão do Mininet3.

Figura 2.10: Elementos e recursos do OvS

Fonte: Adaptado de LINUX FOUNDATION (2009)

Os principais componentes do OvS são:

� ovs-vswitchd: implementa um comutador junto com módulo de kernel (núcleo) Linuxpara comutação baseada em fluxos;

� ovsdb-server: um servidor de banco de dados leve que o ovs-vswitchd consulta paraobter sua configuração;

� ovs-dpctl: ferramenta para configurar o núcleo do switch;

� ovs-vsctl: consulta e atualização do ovs-vswitchd;4

� ovs-appctl: envio de comandos de execução de daemons (processo em plano defundo) OvS;

� ovs-ofctl: consulta e controle de switches e controladores;3http://mininet.org/4A maioria dos comandos de configuração de QoS foram feitos neste trabalho acessando diretamente a configu-

ração do ovs-vswitchd, ou utilizando o utilitário ovs-vsctl.


� ovs-pki: criar e gerenciar chaves públicas;

� ovs-testcontroller: simples controlador OF;

O suporte a QoS está disponível no OvS. Para o tráfego ingressante, o OvS suporta aaplicação de políticas de QoS. Quando o tráfego sai do switch, o OvS pode realizar a moldagemdo tráfego. A aplicação de políticas é uma forma simples de QoS, onde basicamente os pacotesque são recebidos em excesso (em relação a uma taxa geral configurada) são descartados. Poressa simplicidade, é geralmente realizado o controle de QoS na saída, onde os pacotes sãoenfileirados nas portas do switch.

Além do OvS, outras plataformas estão disponíveis para o padrão OF, com característicasespecíficas:

� Open vSwitch: implementado em C e Python, com foco em plataforma de comu-tação para ambientes de servidores virtuais. Suporta gerenciamento de interfacese programação das funções de encaminhamento. Pode ser instalado em switches

ASICs;

� Pantou/OpenWRT: escrito em C, transforma um roteador comercial ou Ponto deacesso, num switch OF;

� ofsoftswitch 1.3: implementação em C/C++ compatível com o protocolo 1.3 emespaço do usuário.

� Indigo: implementação em C aberta do OpenlFlow que roda em switches físicos eusa recursos de hardware dos switches Ethernet ASICs para rodar o OF.

2.1.10 O Controlador de rede

Para NUNES et al. (2014), o controlador é o elemento da rede SDN que fornece umainterface programável para a rede. Ele pode ser usado para implementar tarefas de gerenciamentoe fornecer novas funcionalidades. Com a lógica de controle separada, como um sistema opera-cional de rede, aplicações podem ser construídas para programar a rede. Esse modelo permiteque SDN atenda a uma gama de aplicações, tecnologias heterogêneas e meios de comunicaçãocomo ethernet, wifi, e redes óticas. As aplicações podem ser escritas em várias linguagens, adepender da implementação do controlador, como Java, C/C++, Python, podendo interagir comuma API do tipo Representational State Transfer (REST). Um controlador pode ter arquiteturascentralizadas ou distribuídas.

Tipicamente, a unidade básica em redes é o pacote, que por sua vez possui as informaçõespara a tomada de decisões de roteamento por um comutador. No entanto, as aplicações enviamdados em forma de fluxos de vários pacotes agregados por características comuns. Essa agregaçãopode ser baseada em informações como origem, destino, aplicação, ou por combinações destes.Uma rede pode fornecer QoS realizando o controle baseado em fluxo.


Ainda segundo NUNES et al. (2014), numa SDN, onde os elementos da rede sãocontrolados remotamente, uma sobrecarga é gerada pelo tráfego entre o plano de dados ede controle. Um controle granular no nível de pacote geraria um atraso importante, pois ocontrolador teria que tomar uma decisão para cada pacote ingressante. No controle por fluxos, adecisão tomada no primeiro pacote desse fluxo é aplicada aos subsequentes. A sobrecarga podeser ainda menor utilizando-se agrupamentos de fluxos.

Segundo LIU et al. (2015), um controlador pode trabalhar com implantação de regras emmodo reativo ou proativo.

� No modo reativo, os elementos de encaminhamento devem consultar o controlador,enviando eventos, sempre que uma decisão precise ser tomada, por exemplo, quandoum pacote de um novo fluxo chega ao switch. Haverá sempre uma pequena perdade desempenho na entrada do primeiro pacote de um fluxo, pois ele precisará serencaminhado ao controlador para tomar a decisão. O controlador cria e instala umaregra na entrada de fluxo para o pacote correspondente somente se requisitado.

Segundo MOSHREF et al. (2014), o modo reativo suporta aplicações mais dinâmicas,mas possui baixo desempenho devido à sobrecarga computacional significativa (CPU,memória), maior degradação da rede (atraso, vazão) e problemas de escalabilidadedevido ao canal de comunicação limitado entre controlador e switches.

� O controle proativo aborda a implantação de políticas do controlador para os switches.O controlador preenche as entradas de fluxo para todas as correspondências de tráfegopossíveis antes dos fluxos chegarem ao switch. Desta forma, o controlador raramenteprecisará ser consultado sobre novos fluxos e o tráfego é mantido no plano de dados.

O quadro 2.2 lista os controladores abertos mais populares:

Quadro 2.2: Controladores abertos populares

Controlador Linguagem DesenvolvedorPOX Python NiciraNOX Python/C++ NiciraMUL C KulcloudTrema Ruby/C NECBeacon Java StanfordFloodlight Java BigSwitchRyu Python NTT, OSGR groupNodeFlow Javascript Desenvolvedores independentesovs-controller C Desenvolvedores independentesRouteFlow C++ CPqDONOS Java Open Networking Lab (ON.LAB)Opendaylight Java Linux Foundation

Fonte: Adaptado de NUNES et al. (2014)


2.1.10.1 O controlador de rede Ryu

Ryu5 é um controlador SDN baseado em componentes. Ryu foi projetado para aumentara agilidade da rede e fornece componentes de software com API bem definida que facilitam acriação de novas aplicações de gerenciamento e controle de rede. Esta abordagem de compo-nentes auxilia as organizações e seus desenvolvedores a personalizar suas implementações paraatender necessidades específicas.

A Figura 2.11 ilustra os elementos da arquitetura. O Framework SDN Ryu disponibilizauma API bem definida e bibliotecas muito úteis para construção de aplicações para SDN. Escritototalmente em Python, o Ryu suporta vários protocolos de gerenciamento, como OF, além deNetconf e OF-config. Suporta totalmente as versões entre 1.0 e 1.5 do protocolo OF. Seu códigoestá disponível gratuitamente sob a licença aberta (RYU SDN FRAMEWORK COMMUNITY,2012).

Figura 2.11: Arquitetura do Controlador Ryu

Fonte: Adaptado do site SDX Central6

O controlador Ryu possui uma arquitetura orientada a eventos, cujo modelo básicode aplicação é ilustrado na Figura 2.12. A comunicação entre aplicações é realizada pelatransmissão e recebimento de eventos de forma assíncrona, sendo que também existem fontes deeventos internos que não são aplicações Ryu, como o controlador OF (caminho de dados). Cadaaplicação possui uma simples fila First In, First Out (FIFO) para receber eventos e uma thread

para processamento dos mesmos. A thread executa um loop de eventos, onde ela vai retirandoeventos da fila e chamando o manipulador de eventos apropriado a cada loop.

Como o Manipulador é chamado no contexto da thread de processamento de eventos, obloqueio da comunicação deve ser realizado. Enquanto o manipulador estiver bloqueado nenhumoutro evento para a aplicação Ryu será processado. Um evento pode conter eventos de objetosPython, não sendo recomendado passar eventos complexos entre aplicações Ryu.

5https://osrg.github.io/ryu


Figura 2.12: Arquitetura baseada em eventos de uma aplicação Ryu

Fonte: Adaptado de ryu book 7

2.1.11 Métricas de Qualidade de Serviço

Segundo KRISHNA (2016), QoS é um mecanismo para melhorar o desempenho dasredes. Um administrador pode gerenciar os seus recursos e prover elevados níveis de serviço semque haja sobrecarga. QoS é importante em aplicações que necessitam de garantias específicas.Aplicações de Streaming de vídeo, por exemplo, requerem baixos atrasos e pouca variação noatraso de chegada dos pacotes (jitter). Já a comunicação de dados é menos sensível a atrasos ejitter, sendo mais sensível à perda de pacotes. Sobre as principais métricas de QoS temos:

� Atraso: tempo que uma mensagem leva entre o envio por um remetente e a recepçãopelo destinatário. O atraso pode ser ocasionado por características do meio de trans-missão e pelo tempo de processamento dos dispositivos da rede. Atrasos altos, acimade 150 Milissegundos (ms) podem ocasionar causar interrupções numa comunicaçãocontínua e baixar percepção de qualidade em um vídeo.

� jitter: a variação do atraso causado pela diferença de tempos de chegada entre ospacotes que trafegam por rotas diferentes na rede. Ter taxas de jitter altas podecausar distorções no sinal recebido, podendo causar efeitos como intervalos de tempovazios, o que pode prejudicar a compreensão da informação. Segundo RAHRERet al. (2006), para vídeo em HD com codificação MPEG-4 o jitter deve ser abaixo de50 ms.

� perda de pacotes: durante o tráfego na rede, muitos pacotes podem ser perdidospelo caminho, acontece também quando se trabalha com tráfego com taxa acima dacapacidade do canal. O protocolo UDP, diferente do TCP, não realiza o controle eretransmissão dos quadros perdidos, o que pode ser crítico na transmissão multimídia.


� Vazão: quantidade máxima de dados que pode ser transmitida entre origem e destino,onde não há descarte de pacotes pelo dispositivo BRADNER; MCQUAID (1999).É medida em termos de número de operações por unidade de tempo (tipicamentequadros por segundo ou bits por segundo). Em transmissões de vídeo é necessárioque a vazão do tráfego seja maior ou igual à taxa de codificação (de referência) dovídeo. O alcance da vazão ideal, necessária para transmissão de um vídeo na rede vaidepender da capacidade e da ocupação do link no momento da transmissão.

Valores degradados destas métricas vão ocasionar uma baixa percepção de qualidade aousuário, a chamada QoE. As duas maiores arquiteturas de QoS são Integrated Services (Intserv)e Diffserv, em resumo:

� Intserv, descrito por BRADEN; CLARK; SHENKER (1994), foi a primeira tentativade controle de QoS em redes IP. Ele emula a alocação de recursos baseada no modelode comutação de circuitos. Ele força a alocação de recursos para um fluxo em todos osdispositivos de encaminhamento. Ele define três níveis de serviço: Serviço garantido(melhores garantias de atraso, vazão e perda); carga controlada; e Melhor esforço.Utiliza o Protocolo de reserva de recursos (RSVP) que realiza a função especificadapelo seu próprio. Intserv trata o fluxo do início ao fim e não é escalável, por isso nãotem sido usado na internet.

� Diffserv, definido em BLAKE et al. (1998), veio para simplificar o Intserv e resolvero problema da escalabilidade, Diffserv aplica sua política a cada salto usando ométodo Per-hop behaviour (PHB). Ele trabalha com agregação de fluxos em classes,portanto não atua nos fluxos individualmente. Os pacotes são classificados combase em seu Byte (8 bits) DSCP do cabeçalho IP, os pacotes de mesmo Byte DSCPrecebem tratamento igual no comutador. Algumas características comuns, bem comoa definição básica das 4 classes PHB (Best Effort (BE), Expedited Forwarding (EF),Assured Forwarding (AF) e Class Selector (CS)) são:

� BE: pacotes com bits DSCP 0 e que não estejam nas outras classes sãoencaminhados como pacotes melhor esforço;

� EF: encaminhamento expresso é utilizado em pacotes com característicade baixo atraso, perda e variação de atraso, além de banda garantida. Ospacotes EF recebem prioridade de enfileiramento acima de outras classesde tráfego. Os fluxos EF competirão entre si;

� AF: encaminhamento garantido é análogo à carga controlada de Intserv.Ele fornece garantia de entrega, desde que o tráfego não exceda uma taxaespecífica. Com AF, é possível utilizar 4 subclasses nos pacotes (comreservas diferente de banda para cada uma), e dentro de cada classe é


possível definir 3 níveis de precedência de descarte, conforme podemosobservar no quadro 2.3;

Quadro 2.3: Subclasses e probabilidades de descarte AF PHB

Classe AF Baixa Média AltaSublasse 1 AF11 (DSCP 10) AF12 (DSCP 12) AF13 (DSCP 14)Subclasse 2 AF21 (DSCP 18) AF22 (DSCP 20) AF23 (DSCP 22)Subclasse 3 AF31 (DSCP 26) AF32 (DSCP 28) AF33 (DSCP 30)Subclasse 4 AF41 (DSCP 34) AF42 (DSCP 36) AF43 (DSCP 38)

Fonte: adaptado de HEINANEN et al. (1999)

� CS: seletor de classe é definido para preservar a compatibilidade retroativacom o esquema de precedência de IP da versão antiga do Diffserv;

O Diffserv é mais escalável do que o Intserv, pois age em fluxos agregados e nãoprecisa guardar estados por fluxo, reduzindo significativamente a sinalização neces-sária. Também não possui atraso de configuração, uma vez que não há processo deadmissão.

RIFAI; MOHAMMED; MELLOUK (2011) apresenta uma visão geral de técnicas exis-tentes de QoS e QoE. Uma comparação entre as duas técnicas, bem como uma melhoria doserviço, combinando-os também são tratadas.

2.1.12 As Métricas de avaliação de Qualidade de Vídeo

No âmbito de avaliação de QoS e QoE em transmissões de vídeo, a pesquisa de GEOR-GOPOULOS et al. (2015) mostra que as métricas de QoS existentes, como taxa de perda depacotes, vazão, atraso e jitter são muito utilizadas para indicar o impacto sobre a qualidade devídeo do ponto de vista do operador de rede, mas não representam de forma real a qualidadedo vídeo percebida pelo usuário. Além disso, dizem que não é simples utilizar a tradicionalmétrica de Peak Signal-to-Noise Ratio (PSNR), onde os quadros de referência (do vídeo originalenviado) e os quadros recebidos (transmitidos) são comparados para medir a QoE do vídeo. Essemecanismo de comparação quadro a quadro é impreciso para Streaming de vídeo móvel, porexemplo, pois a perda de quadros ocorre com frequência ao longo do canal sem fio. Devidoàs razões mencionadas, foram sugeridas outras métricas de QoE para Streaming de vídeo naInternet, como o atraso de início do vídeo, taxa/latência de buffering, taxa de bits e de status dobuffer de reprodução.

O trabalho acima apresenta o Multicast como sendo uma tecnologia que pode distribuiros mesmos recursos de mídia para vários usuários simultaneamente, reduzindo a vazão dedistribuição no servidor de origem para um fluxo apenas. Deixando de lado os vários problemasde implantação no mundo real, multicast é uma solução eficiente para streaming de vídeo ao vivo,onde todas as solicitações de todos os usuários são para o mesmo conteúdo ao mesmo tempo.


No entanto, com Video On Demand (VoD), isto não acontece, já que as solicitações podemocorrer em qualquer tempo depois que o conteúdo estiver disponível. Os autores observaram queos trabalhos relacionados que usaram multicast para melhorar a eficiência de entrega de VoD,muitas vezes envolveram uma complexidade desnecessária, através de técnicas como a fusãode fluxos; aceleração ou retardamento da taxa de visualização dos clientes; reserva fixa de umaparcela da largura de banda dos clientes; recebimento pelos clientes múltiplos fluxos de vídeosimultaneamente, em múltiplas taxas de reprodução. Além disso, viram que essas soluções nãosão transparentes e requerem modificações no cliente ou no servidor.

As métricas de QoS, e que determinam o nível de degradação da rede, estão definidasem BRADNER; MCQUAID (1999).

2.2 TRABALHOS RELACIONADOS

Alguns trabalhos mais recentes utilizaram diversas abordagens para resolver diferentestipos de problemas relacionados à otimização do tráfego multimídia, ou de vídeo, em SDN:


Qua

dro

2.4:

Det

alhe

sdo

str

abal

hos

rela

cion

ados

RE

F.T

IPO

MÉ

TR

ICA

SD

EQ

OS

MÉ

TR

ICA

SD

EQ

OE

VAL

IDA

ÇÃ

OC

ontr

olad

or

LIU

etal

.(20

13)

HT

TP

RT

T

Buf

feri

zaçã

oin

icia

l,fr

equê

n-ci

ade

rebu

ffer

izaç

ão,d

uraç

ãom

édia

dare

bufe

rizaç

ão,p

erda

,M

OS

porc

orre

laçã

o

Plat

afor

ma

expe

ri-m

enta

lCD

Nco

mSD

NSD

Nco

ntro

ller

NA

Met

al.(

2014

)H

TT

PTe

mpo

dere

prod

.eV

a-zã

oA

tras

ode

inic

ializ

ação

deví

-de

o,ta

xae

stat

usde

buff

erJu

nos

spac

esd

kJu

nos

LA

GA

etal

.(20

14)

HT

TP

Atr

aso

ela

rgur

ade

band

aN

/aM

inin

etB

eaco

n

WA

NG

etal

.(20

14)

HT

TP

Nen

hum

aC

onge

lam

ento

edi

stor

ção

doqu

adro

GE

NI

Floo

dlig

ht

TAN

G;

HU

A;

WA

NG

(201

4)M

ultic

ast

Cam

adas

rece

bida

s,pa

-co

tes

rece

bido

sn/

aM

inin

et,O

Fv1

.3N

OX

TSU

NG

-FE

NG

;W

AN

G;H

SU(2

015)

SVC

Perd

ade

paco

tes

N/a

Min

inet

Floo

dlig

ht

II;D

UR

RE

SI(2

015)

HT

TP

Núm

ero

dem

ensa

gens

porr

equi

siçã

oN

/aSi

mul

ador

Vid

eoco

ntro

ller

(VSD

N)

UZ

AK

GID

ER

;CE

TIN

-K

AYA

;SA

YIT

(201

5)R

TP

Nen

hum

aPe

rda

dequ

adro

s,m

udan

ças

dequ

alid

ade,

mud

ança

sde

ca-

min

hoM

inin

etFl

oodl

ight

GE

OR

GO

POU

LO

Set

al.(

2015

)H

TT

PN

enhu

ma

Tem

pode

inic

ializ

ação

,m

u-da

nças

deta

xa,

taxa

méd

ia,

taxa

mín

ima

GE

AN

TO

penc

ache

cont

rolle

r

CA

RA

GU

AY

;FE

R-

NáN

DE

Z;V

ILL

AL

BA

(201

5)R

TP

Atr

aso,

vazã

oPS

NR

,SSI

M,M

OS

Min

inet

Floo

dlig

ht

OA

utor

RT

PR

TT,

Vaz

ão,

Jitte

r,Pe

rda

(qua

dro/

paco

te)

PSN

R,V

QM

eSS

IMA

EV

(oA

utor

)R

yu

Font

e:el

abor

ado

pelo

auto

r


O trabalho de LIU et al. (2013) aproveita o controle central e programabilidade das SDNpara definir um esquema de distribuição de conteúdo de vídeo para melhorar a qualidade devídeo HTTP. Foram analisadas as características do tráfego de vídeo HTTP e os defeitos (comoescalabilidade e inteligência) das CDN amplamente utilizadas. Eles consideraram CDN umasolução complexa e carregada.

Em NAM et al. (2014) foi observado que os prestadores de serviços de vídeo diretamentesobre a internet, Over The Top (OTT) utilizam as CDN’s para acelerar a distribuição de vídeoatravés da associação de nós mais próximos aos clientes, e com as CDN sendo operadas porterceiros é difícil medir QoE pela visão limitada da rede do lado do cliente (última milha).Outros mecanismos são úteis para melhorar a qualidade, como ABR, mas não resolvem as causasfundamentais dos congestionamentos. Para identificar gargalos e melhorar a QoE foi propostauma aplicação SDN que utiliza a visão global SDN do OTT para monitorar as condições da redede streaming em tempo real e de forma dinâmica mudar os caminhos de roteamento utilizandoMPLS e Engenharia de Tráfego. A complexidade da solução em CDN atende à necessidade deprestadores de serviços OTT.

O trabalho de LAGA et al. (2014) aborda a transmissão HTTP adaptativa (HAS) comSVC, já utilizadas na distribuição de vídeo em Internet de melhor esforço, adicionando oroteamento baseado em fluxos. O HAS realiza a transmissão do vídeo camadas com taxas dequalidade diferentes, adaptando dinamicamente a qualidade recebida pelo cliente às condiçõesda rede. SVC elimina a redundância entre as camadas do vídeo. Com SDN foi realizado oajuste dinâmico das tabelas de encaminhamento para redirecionar fluxos diferentes. Com estaabordagem, o número de congelamentos de vídeo foi reduzido. A abordagem priorizava atransmissão da camada básica para garantir a reprodução contínua, levando em consideração ainfluência, principalmente, do atraso e da largura de banda. O desacoplamento entre o plano decontrole e de dados permitiu configurar fatias de rede distintas para a transferência de camadasde qualidade diferentes. Trata-se de mais uma proposta que foca nas técnicas de transmissão.

A proposta de WANG et al. (2014) traz um sistema para streaming de vídeo ao vivoescalável, baseado na orientação dinâmica do tráfego em SDN orientado à instanciação deservidores de retransmissão em nuvem. O objetivo deste serviço foi suportar streaming de vídeoao vivo de conteúdos Educacionais via portal web. No artigo foi descrito um protótipo conceitualdo arcabouço.

TANG; HUA; WANG (2014) abordam a necessidade, e a dificuldade de se realizarstreaming de vídeo multicast, já que requer o suporte dos dispositivos de rede ao roteamentomulticast e garantias de QoS. Neste trabalho, foi criada uma aplicação de streaming de vídeomulticast baseado no controle central e visão global proporcionados por SDN, para distribuirstreaming de vídeo SVC para múltiplos destinatários com a melhor qualidade possível. Elesrealizam uma simulação, mas demonstram a vontade de implementar num ambiente real.

TSUNG-FENG; WANG; HSU (2015) traz mais uma abordagem de encaminhamentoadaptativo para streaming de vídeo com suporte a QoS em SDN. Eles observam a relevância das


aplicações de IPTV e VoD e as lacunas de Diffserv das redes melhor esforço, destacam aindaos requisitos de altas taxas para serviços multimídia em tempo real, baixo atraso para VoIP ebaixa variação de atraso para VoIP e videoconferência. Na abordagem, os pacotes da camadabase e da camada de reforço são tratados separadamente, em dois níveis de fluxos QoS (em duastabelas de fluxo). Durante o streaming eles monitoram o atraso e priorizam a camada base paraum caminho ideal baseado na largura de banda do caminho congestionado. É mais uma formade contornar os congestionamentos.

No artigo de II; DURRESI (2015) o QoS baseia-se na seleção de um caminho ideal, paraaplicações de vídeo interativo em tempo real como videoconferência. Encontrar um caminhoalternativo é difícil devido ao alto acoplamento e design complexo da rede. Foi apresentadaa solução VSDN (vídeo sobre SDN) uma arquitetura de rede (com controlador VSDN) queseleciona o caminho ideal baseado na visão global da rede. Uma solução abrangente, que tambémé baseada na seleção de caminhos.

UZAKGIDER; CETINKAYA; SAYIT (2015), propõem outro sistema de streaming devídeo adaptativo sobre SDN, mas que tem uma abordagem baseada em aprendizagem. Elesutilizaram um modelo de aprendizagem novo para determinar o tempo ideal para reencaminharos fluxos e alterar a taxa do vídeo. O modelo teve como objetivo minimizar a taxa de perda depacotes, variações da qualidade e custo do controlador, adaptando as rotas de fluxo e qualidadede vídeo. Seu desempenho superou os de outras propostas comparadas em termos de QoE ecustos de rede. Os autores reforçam que esta foi a primeira abordagem na qual o controladorfornece adaptação, tanto do roteamento de fluxo, quanto na qualidade de vídeo. Para calculara largura de banda disponível nos caminhos, o controlador periodicamente enviava mensagens"port_stats", esta é uma forma eficiente de se realizar cálculos de custo na rede.

O estudo de GEORGOPOULOS et al. (2015) menciona que o streaming de VoD de altaqualidade tornou-se algo essencial e que coloca um fardo sobre a rede. Menciona ainda que asCDN’s não resolvem o problema da utilização de banda em última milha. É abordada a questãoda distribuição de VoD que usa fluxo unicast, resultando em vários fluxos duplicados na rede. Oartigo apresenta o OpenCache, um serviço de caching configurável, eficiente e transparente paraVoD trazendo o vídeo para perto usuário. OpenCache aproveita o paradigma SDN em ambientesde última milha, melhorando a utilização da rede e aumentando QoE do usuário.

Outro artigo de CARAGUAY; FERNáNDEZ; VILLALBA (2015) reforça que o aumentodo tráfego de na Internet está concentrado em conteúdo multimídia. No entanto, a rigidezda arquitetura tradicional das redes tem limitado o desenvolvimento de serviços inovadores.Os serviços multimídia exigem redes flexíveis e personalizáveis, a fim de fornecer segurançaeficiente, mobilidade, disponibilidade e QoS. Neste contexto, SDN é inovador e torna personali-zável o comportamento da rede em função de necessidades específicas. O trabalho apresentaum framework SDN para fornecimento de QoS em diferentes serviços multimídia com OF,virtualização de redes e caixas funcionais e interfaces para testes de algoritmos de roteamento.As vantagens do framework são testadas com a implementação das funções de desempenho de


rede e algoritmos de roteamento.

2.3 QUALIDADE DE SERVIÇO (QOS) EM SDN

Os trabalhos comentados até então mostraram a relevância desta pesquisa e apresentamos caminhos que são adotados quando o problema está relacionado ao tráfego de vídeo em redes,o que foi muito útil também para que fossem verificadas as várias formas de se avaliar as soluçõesdesta área já no contexto de SDN. Os trabalhos a seguir tiveram importância equivalente, poisapresentam as soluções de arquiteturas de QoS quem vêm se baseando no paradigma SDN.

O provisionamento de QoS é indispensável em grandes redes e o suporte a QoS estavafaltando em Testbeds experimentais OF atuais como o OFELIA8. SONKOLY et al. (2012) des-creve uma possível extensão do OFELIA que adiciona suporte à QoS, baseado em gerenciamentode filas. Foi proposta uma plataforma de gerenciamento de QoS com integração completa naestrutura existente, onde as configurações de QoS do OFELIA poderiam ser ajustadas de formaamigável.

QoS em redes de comutação de pacotes de hoje é afetada por vários fatores que incluema confiabilidade, disponibilidade, atraso, escalabilidade e nível de serviço. Propriedades dessasredes podem causar baixo rendimento. Numa abordagem usando SDN e recursos do OF 1.0 comofilas, gerenciamento de fluxos, classificação e políticas de QoS), é mostrada em WALLNER;CANNISTRA (2013) uma proposta de QoS gerenciada e definida por um controlador. O trabalhoapresenta a arquitetura com Traffic shaping com limitação de taxa, Diffserv DSCP.

O agendamento de pacotes é essencial para suporte de aplicações SDN, mas QoS só éconfigurada com garantias de largura de banda e agendamento FIFO. Continuando seu trabalhoanterior, ISHIMORI et al. (2013) apresenta o QoSFlow, que controla vários agendadores depacotes no núcleo do Linux. O documento avalia o desempenho QoSFlow analisando o tempode resposta das operações de QoS, vazão máxima, taxa de utilização da Central ProcessingUnit (CPU) e isolamento em termos de largura de banda. Agendadores além de FIFO, comoSFQ, podem ser encontrados no rico subsistema Traffic Control (TC) do Linux. Executando oOF em switches baseados em Linux é possível utilizar o TC, porém as especificações OF nãosuportam controle de agendadores de pacotes. QoSFlow faz o TC fazer parte da rede. O trabalhomostrou que o consumo da CPU e memória não está relacionado ao número de filas e sim àrelação entre a capacidade máxima da fila e sua utilização.

OF foi originalmente proposto para experimentação de redes de campus e empresas,mas observou-se que havia limitações em escalabilidade e flexibilidade. Em KO et al. (2013) éproposto OpenQFlow, uma variante escalável e flexível do OF. OpenQFlow fornece um sistemade acompanhamento de fluxo refinado com separação de tabelas de fluxo em três: de estado defluxo, de encaminhamento de regras e de regras de QoS. Também foi desenvolvido um arcabouçode QoS baseado em fluxo, de duas camadas.

8http://www.fp7-ofelia.eu/


Para BHATTACHARYA; DAS (2013), serviços em tempo real com QoS são necessáriosna internet, mas representa um desafio fornecer QoS fim a fim. Os provedores de serviços devemestar aptos a implementar suas políticas e estratégias de negócio dinamicamente e SDN vem,nesse sentido, permitindo repensar e experimentar inovações. O referido trabalho propõe umaarquitetura inovadora e um algoritmo para fornecer QoS na internet, abrindo a oportunidade paraavanços nas relações dinâmicas entre provedores de serviço. As simulações mostraram que aarquitetura SDN é vantajosa em aplicações com QoS.

Conforme já foi observado, os operadores de rede devem fornecer serviços com garantiade QoS adaptada às características das aplicações. Em BUENO et al. (2013) é proposta uma ca-mada de controle de rede (NCL), um arcabouço de software baseado em SDN, OF e Redes comoserviço (NaaS). Eles inserem uma inovação importante no campo do controle e gerenciamentoda rede, fornecem serviços sob demanda e provisionamento de rede fim a fim com garantiasde QoS baseada nos requisitos de aplicações interativas OTT. A NCL inclui mecanismos paramonitoramento da rede e configuração de switches SDN. Foi demonstrada a utilidade de NCLusando um caso de uso prático. A proposta realiza o encaminhamento baseado nos recursos darede (atraso, banda e jitter), aplicando filas e prioridades.

AKELLA; XIONG (2014) enfatiza a importância de QoS baseada em alocação debanda em aplicações de tempo real, como VoIP, teleconferência e jogos. Com isso, os serviçosprecisam ser diferenciados de acordo com prioridades e necessidades. No trabalho, considerou-sealocação de largura de banda num provedor de nuvem onde as solicitações dos usuários sãoprocessadas pelo provedor sujeitas a requisitos de QoS e priorização. A abordagem utilizaOvS em ambiente SDN e foi implementada e testada sobre o ambiente Global Environment forNetwork Innovations (GENI)9. Os resultados experimentais mostram a eficácia da proposta.Foram utilizadas as técnicas HTB e HFSC para enfileiramento, classificação, priorização ealocação de banda. Os fluxos foram classificados em melhor esforço; e serviço QoS.

EGILMEZ; TEKALP (2014) apresenta extensões de QoS com plano de controle distri-buído para a entrega de multimídia através de SDN em larga escala e multi-operadora. Cadacontrolador realiza roteamento de QoS ideal dentro de seu domínio e compartilha informaçõesde roteamento QoS resumidas com outros controladores de domínio. Para este efeito, o trabalhopropõe: (a) agregação de topologia e métodos de compactação de links; (b) um arcabouçogeral para QoS fim a fim baseada em fluxo em redes multi-domínio; (c) dois projetos de planode controle distribuído abordando as mensagens entre controladores. Foram aplicadas essasextensões para streaming de vídeo em camadas e comparado o desempenho de diferentes planosde controle em termos de qualidade de vídeo recebidos, custos de comunicação e sobrecarga dememória. O projeto do controlador apresenta mecanismos de controle como o gerenciamento defluxo, controle de admissão, políticas de tráfego, cálculo de rotas, gerenciamento de recursos,topologia e filas. São definidos três tipos de fluxos: QoS nível 1 (prioritário), QoS nível 2 oumais, e melhor esforço. Eles reforçam que as aplicações de multimídia interativas possuem

9http://www.geni.net/


requisitos de atraso fim a fim (150 ms a 200 ms para videoconferência) e que o atraso total deveser controlado.

Em GOVINDARAJAN et al. (2014) foi implementado o sistema "QoS Controller"(Q-Ctrl) para obter as restrições de QoS requeridas por usuários de uma infraestrutura de nuvembaseada em SDN. Q-Ctrl pode ser executado numa rede sobreposta virtual através OvS e umcontrolador; ou em ambiente SDN simulado via Mininet. Demonstraram como um aplicativode streaming de vídeo pode utilizar o Q-Ctrl para atingir QoS numa infraestrutura de nuvemSDN. Os parâmetros de QoS incluem garantias de largura de banda, atraso, perda de pacotes, econtrole de congestionamento. O controle de QoS é essencial para aplicações sensíveis ao atraso,como vídeo streaming. A proposta utiliza um Testbed real com controlador Floodlight, switches

OF, OpenNebulafootnotehttps://opennebula.org/, KVM10 e QEMU11. A métrica de avaliação utilizada foi a vazão.

Real-Time Online Interactive Applications (ROIA) é uma categoria de aplicações emer-gentes que geram elevada demanda de QoS. Redes tradicionais têm possibilidades limitadas deatender as demandas de QoS dinâmico baseadas em melhor esforço. GORLATCH; HUMERN-BRUM; GLINKA (2014) analisa os requisitos de ROIA e descreve uma API SDN Northbound

que permite que tais aplicações especifiquem suas necessidades de rede dinâmicas e as atinjamusando SDN. O trabalho também destaca as aplicações de e-learning onde existe uma grandequantidade de dados em tráfego, especialmente no streaming de áudio e vídeo. Foram realizadosexperimentos com jogo Frames per Second (FPS) e utilizadas métricas de largura de banda,carga de processamento na CPU e tempo de resposta. A saturação do link foi de 90%, portanto amétrica de carga de processamento pela CPU não foi adequada. O módulo SDN calcula vazão,atraso, jitter e perda.

Outro trabalho de GORLATCH; HUMERNBRUM (2015) teve como objetivo melhoraro gerenciamento de QoS nas aplicações ROIA. O foco foi em mecanismos para especificar econtrolar métricas de alto nível QoS relacionadas à aplicação, ao invés de métricas tradicionaisde baixo nível extraídas da rede. Foram utilizados recursos de gerenciamento dinâmico SDNpara expressar, acompanhar e controlar as demandas de QoS das aplicações. Foi demonstradocomo a métrica "tempo de resposta"pode ser traduzida em métricas de rede compreendidaspelo controlador SDN. Nos experimentos foi utilizado um jogo online (Cliente x servidor) numtestbed OF com OvS, links de 10 Mbps para simular um gargalo, as variações de cenários forambaseadas na adição de robôs ao jogo. Foram testados dois tipos de clientes, com QoS (50 msmáximo de tempo de resposta) e sem QoS.

Em YAN et al. (2015) foi proposto. HiQoS faz uso de vários caminhos entre origem edestino e mecanismos de filas para garantir QoS para diferentes tipos de tráfego (Diffserv). Elesusaram a correspondência de IP para simplificar a classificação de tráfego. HiQoS conseguereduzir atrasos e aumentar a vazão para garantir QoS. HiQoS também se recupera rapidamente de

10https://www.linux-kvm.org11http://www.qemu.org/


uma falha de conexão reencaminhando o tráfego para outros caminhos disponíveis. A propostafaz uso de mecanismos de enfileiramento para garantir largura de banda para os diferentes tiposde tráfego. São descritos dois componentes, o componente Diffserv, e o de roteamento demúltiplos caminhos.

TSUNG-FENG; WANG; HSU (2015) apresenta ARVS, uma proposta de roteamentoadaptativo para streaming de vídeo com suporte a QoS sobre SDN. Na abordagem, pacotes decamada base e pacotes da camada de reforço, de fluxos de vídeo, são tratados separadamente,em dois níveis de fluxo QoS. A qualidade do vídeo seria reforçada devido ao congestionamentodo caminho mais curto ter sido mitigado. Os resultados das simulações mostraram que, emcomparação com OpenQoS, essa abordagem pode reduzir em até 77,3% a taxa de perda depacotes para os pacotes da camada base e também melhorar a cobertura, pelo menos 51,4%sob várias cargas de rede, no caminho mais curto e no caminho viável. Eles avaliaram PSNRcomparando com outras soluções.

Em linhas gerais, podemos dizer que os artigos descritos nesta seção trazem abordagensdiversas e auxiliaram em nossa proposta em vários aspectos, desde a demonstração da relevânciade diferentes tipos de tráfego e cenários reais, até a definição dos experimentos e avaliaçõesque se aplicavam a situações distintas apresentadas. Percebe-se uma grande heterogeneidadenas arquiteturas de avaliação de desempenho das soluções, que utilizavam principalmente assimulações em mininet, mas em alguns casos também se optou por ambientes reais ou Testbeds

globais. Muitos destes artigos também nos ajudaram a compreender e definir as métricas deavaliação de QoS, nas quais houve uma variação grande de escolha, mas a maior parte optoupor métricas extraídas da rede. Observamos também que algumas soluções já apontavam para aeficácia da utilização das filas OF aliadas à priorização por classes de serviço. Já em relação àescolha de controladores específicos, nos fazem crer que está relacionada à opção que forneciamais recursos no momento, ou a que estiver disponível no ambiente de testes, no entanto todosos softwares parecem funcionar de forma semelhante e eficaz. Devido a essa heterogeneidadeem diversos aspectos, nos baseado em todo esse estudo prévio, a nossa proposta pode pretendeconsolidar essas técnicas em uma metodologia aplicada que define ambiente de experimentação,métricas de QoS e uma proposta de QoS em redes SDN.

2.4 QOS E A QUALIDADE DE EXPERIÊNCIA (QOE) EM SDN

Outros trabalhos além da abordagem de QoS, estudam mais a fundo o reflexo na QoE dousuário. Além de tudo reforçam a importância do QoE.

O streaming de conteúdos multimídia (como a TV móvel) é um serviço de uso intensode largura de banda. O objetivo dos operadores de rede é proporcionar uma experiência deusuário aceitável com uso mínimo de recursos. AGBOMA; LIOTTA (2008) trata da obtenção deQoE, uma técnica de modelagem estatística é empregada correlacionando parâmetros de QoScom estimativas de percepções de QoE e identifica o grau de influência de cada parâmetro QoS


sobre a percepção do usuário. O operador de rede poderá realizar com precisão estratégias dedimensionamento da rede e oferta de serviços. A metodologia proposta é aplicada para demons-trar estratégias de gerenciamento de QoS considerando QoE. Os parâmetros para streaming

multimídia são agrupados em QoS em nível de aplicação (AQoS), como resolução de conteúdo,taxa de quadros e tipo de codec; e QoS em nível de Rede (NQoS), como largura de banda, jitter eperda de pacotes. O experimento utilizou o Darwin streaming server12 monitorado via tcpdump.

KIM et al. (2008) propôs um método de medição objetiva de QoE através dos parâmetrosde QoS. É descrito um modelo de correlação entre QoS e QoE, e um método de avaliação deQoE usando parâmetros de QoS. O artigo também aborda os métodos de medição de QoS devídeo e voz (objetiva e subjetiva) baseado nas recomendações e padrões do ITU. Mencionama medição objetiva PSNR, que considera características de visão humana para imagens emmovimento. Os serviços são classificados em serviço garantido (Prioritário), serviço Premium ede melhor esforço. O serviço VoIP e videoconferência é prioritário, já os serviços de streaming

de filmes, VoD, IPTV e jogos interativos compõem o Serviço premium. Eles descrevem a formade interferência das métricas de QoS, atraso, jitter e perda na percepção do usuário e mostramum guia de classe de QoS para diferentes tipos de aplicação.

ALRESHOODI; WOODS (2013) apresenta uma revisão dos modelos de correlaçãoexistentes que tentam mapear QoS para QoE em serviços multimídia. O termo QoS refere-seao comportamento onde os dados podem ser transportados com mínimo de perda de pacotes eatraso, com largura de banda máxima. QoE é uma medida mais subjetiva que envolve dimensõeshumanas, unindo percepção do usuário, expectativas, experiência da aplicação e desempenho derede. O desafio da medição subjetiva é prever isso de medições objetivas.

O requisito QoS e suporte a serviços multicast de redes IP são dois fatores importantespara a prestação de serviços multimídia baseados em nuvem. No entanto, QoS carece de umelemento importante: a percepção do usuário. Em HSU; LO (2014) é proposto um modelo deajuste e mapeamento QoS para QoE numa infraestrutura multimídia em nuvem. O modelo écomposto de três partes: função QoE; medição prática e análise estatística; e uma plataformade streaming de vídeo simulado. Primeiro foi discutida a forma de projetar a função de QoEe, em seguida, foi usada a medição prática e análise estatística para derivar os valores ideaisde oito parâmetros de QoE na função proposta. Para mapear os parâmetros de QoS de rede emQoE de usuário, uma plataforma de streaming de vídeo simulada foi utilizada. Os resultadosdas simulações mostram que QoE de usuário e QoS de rede são consistentes entre si. Avaliaçãofoi feita no simulador NS-2 Diffserv com vídeo de 60 segundos, tráfego de fundo (até 6 Mbps)foi injetado para interferir no vídeo (até de 5 Mbps), foram utilizados links de 10 e 15 Mbps, einjetados atrasos entre 10 ms e 30 ms.

Para CHEN; WU; ZHANG (2015), no serviço de vídeo, a relação entre QoE e QoSé complicada por que a qualidade de vídeo percebida é subjetiva e variada para diferentesambientes. Tradicionalmente, QoE é obtida a partir do teste subjetivo humano em laboratório.

12https://macosforge.github.io/dss


Modelos objetivos são desenvolvidos para prever QoE indiretamente, com base nos parâmetrosde QoS objetivos. Neste artigo, foi realizada uma ampla pesquisa sobre a evolução dos métodosde avaliação de qualidade de vídeo. O artigo menciona um esforço de pesquisa para melhorar aqualidade de vídeo percebida pelo usuário ajustando os parâmetros de QoS e alocação de largurade banda. Eles definem quatro estágios da medição de qualidade de vídeo: a) Monitoramentode QoS (parâmetros objetivos); b) Teste Subjetivo (Mean Opinion Score (MOS)); c) Modelode Qualidade Objetiva (Correlação com MOS), d) Análise dirigida a dados (Métricas de QoEmensuráveis). O trabalho também explica as típicas distorções visuais de percurso (Bloqueio,borragem de borda e de movimento brusco). São apresentadas as técnicas de transmissão,métricas objetivas e fatores externos interferentes. É apresentado um teste subjetivo, um modelode qualidade objetivo e uma análise de QoE orientada a dados. No final apresentam abordagensde avaliação de qualidade de vídeo orientada a QoE.

Streaming de vídeo online via transmissão HTTP adaptativa (HAS) está se tornandoo mecanismo de entrega de conteúdo mais popular em serviços de comunicação. Os prove-dores de rede e de conteúdo querem garantir alto nível de QoE de vídeo para seus usuários.Em FARSHAD et al. (2015) foi introduzido um arcabouço IQMF de medicação que fornecemonitoramento de QoE para streams HAS como um serviço. O arcabouço utiliza SDN pararealizar o monitoramento da qualidade de forma não intrusiva considerando QoE. IQMF adotaduas métricas de QoE em fluxos HAS para fidelidade de vídeo e impacto de comutação. O artigoapresenta três casos de uso de otimização: a) de cache VoD; b) de Streaming ao vivo; c) deutilização da rede. Utilizaram o Testbed pan-europeu de larga escala com OF e OvS. Foramdistribuídos servidores VoD, caches e clientes de vídeo em Voice over Internet Protocol (VM)em diferentes sites. Foi utilizado o controlador Floodlight e Dummynet13 para emulação da redee introdução de perda de pacotes, atraso e jitter.

2.5 DISCUSSÕES SOBRE OS TRABALHOS

Em primeiro lugar, diferente das abordagens citadas, a nossa foca, essencialmente,num ambiente voltado para instituições públicas federais, e nessas instituições observa-seuma série de especificidades que vão sendo melhor elucidadas no decorrer do documento, emresumo, é necessário desenvolver soluções de baixa complexidade, baixo CAPEX e OperationalExpenditure (OPEX), que utilizem tecnologias abertas e personalizáveis (sem dependência defornecedor), e que possam ser implementadas gradualmente com baixo impacto na rede emprodução, sendo compatíveis (ao máximo) com as tecnologias legadas.

No âmbito da UFPE, onde foram realizados os experimentos na rede em produção, nãoobservamos iniciativas anteriores de monitorar tão profundamente a rede, nem especificamente otráfego de vídeo, não encontramos formas de avaliar QoS e QoE da rede, nem haviam mecanis-mos para classificação e priorização de tráfego crítico. Em particular, tratamos o problema do

13http://info.iet.unipi.it/ luigi/dummynet


tráfego de vídeo em tempo real (RTP) nessas instituições, por ser considerado um tipo de tráfegomais sensível às degradações da rede, e a partir disso seria possível inferir e projetar hipóteses arespeito de outros serviços multimídia de características similares, como streaming HTTP, VoDna distribuição de vídeo institucional, videoconferência, conferência web, entre outros.

Utilizamos ambas abordagens, QoS para análise das métricas objetivas da rede e QoEpara medir o reflexo na percepção do usuário. Aproveitamos as facilidades SDN para controlara qualidade, principalmente as características de desacoplamento do plano de controle; gra-nularidade da solução por fluxo; programabilidade centralizada com visão global da rede. Aabordagem proposta, em sua maior parte, se contrapõe a soluções dos trabalhos relacionados,que utilizam Multicast, CDN e Caches, que são soluções que se posicionam mais no nívelde provedor de serviço e exigiriam investimentos e modificações importantes, além disso sãosoluções que não tratam a essência dos congestionamentos baseada na distinção entre os tipos deserviço e tráfego numa rede institucional. A nossa proposta pode ainda ter uma implementaçãohíbrida SDN/não SDN para migração incremental aproveitando uma infraestrutura existente,pois utiliza mecanismos que podem estar presentes em comutadores tradicionais (não SDN).

Os trabalhos citados usam tipicamente a característica de roteamento dinâmico (ideal emredes de maior porte de múltiplos percursos), visão global da rede e monitoramento em temporeal (muito importantes como ponto de partida do nosso trabalho) fornecidos em SDN. A maioriadas soluções de avaliação também possui uma característica diferente, elas testam suas propostasem ambientes controlados, emulados, normalmente utilizando Mininet. Na nossa visão (e emtestes preliminares), para analisar esse tipo de tráfego, de vídeo em tempo real em SDN, essesambientes (bem mais simples de se construir e operar) não são adequados. Foi personalizadoaqui um Ambiente virtual capaz de executar máquinas com aplicações e tráfegos reais, e comdegradações da rede emuladas no link de conexão entre os comutadores. Esta solução se mostroueficiente e seria um ponto de partida para evoluções desta pesquisa. Esse ambiente tem tambémuma característica de portabilidade, que nos permite migrar facilmente as máquinas virtuaiscontendo os elementos de comunicação para qualquer ponto da rede real a qualquer momento.

535353

3PROPOSTA DE CONTROLE

Nossa proposta consiste em um conjunto de requisitos, configurações e módulos sistêmi-cos para proporcionar o controle de QoS baseado em OF com foco em instituições educacionais.O objetivo da proposta baseada em SDN e OF é o fornecimento de garantias para fluxos depacotes considerados prioritários. Essa abordagem é baseada em necessidades identificadas e éamparada em outro estudo recente de KRISHNA; ADRICHEM; KUIPERS (2016), com caracte-rísticas semelhantes ao trabalho de TOMOVIC; PRASAD; RADUSINOVIC (2014). O sistemade controle de QoS é composto pelos seguintes elementos: Priorização (3.1), Procedimentode admissão no controlador (3.2), Garantia de largura de banda no switch (3.3), Agregação detráfego (3.4), Classes de serviço (3.5), Classificação de tráfego (3.6), Múltiplas tabelas de fluxo(3.7), Módulos básicos (3.8).

3.1 PRIORIZAÇÃO

Do ponto de vista dos fluxos, define-se dois tipos básicos, QoS e BE, para serem tratadosdistintamente pela rede. Os fluxos QoS representam os serviços sensíveis às condições derede (prioritários), em que há necessidade de garantia de largura de banda mínima, como avideoconferência e VoD institucionais e VoIP; os do tipo BE representam os demais serviçossem garantias (não prioritários) e que estão espalhados pela rede.

3.2 PROCEDIMENTO DE ADMISSÃO NO CONTROLADOR

É realizado um teste de admissão momento em que são recebidos novos fluxos QoS.Nesse processo, o controlador vai tentar encaminhar o fluxo QoS por um caminho compatívelcom a taxa necessária para aquele fluxo, ele rejeita a solicitação e dá um retorno ao cliente casoum caminho com a características desejadas não esteja disponível. Para os fluxos BE o processoé diferente, eles usarão sempre o caminho mais curto entre os hosts, não passando por essaetapa de admissão. O procedimento de admissão de fluxos QoS, com a mencionada alocação de"segmentos livres"de largura de banda, evita que os fluxos de QoS admitidos disputem largurade banda entre si. O controlador monitora a quantidade de banda alocada na rede e através dessainformação toma as decisões de roteamento. Para cálculo de rotas é proposta a utilização do

CAPÍTULO 3. PROPOSTA DE CONTROLE 54

Widest Shortest Path algorithm (WSP), por ser uma solução comumente adotada e que atende anossa necessidade.

3.3 GARANTIA DE LARGURA DE BANDA NO SWITCH

A implementação dos mecanismos de garantia de largura de banda no switch é baseadana configuração das filas para priorização de tráfego. Como já vimos, filas são associadasa portas do switch, então para cada porta configuramos três filas (0, 1 e 2). A fila 2 possuimenor valor de prioridade (maior precedência) para encaminhar o tráfego QoS. O tráfego QoSexcedente (considerado aquele tráfego acima da taxa mínima garantida) seguirá pela fila 1, comvalor de prioridade intermediário. A fila 0 tem valor de prioridade maior (menor precedência) eencaminha o tráfego geral BE.

Uma reserva rígida de QoS só começa quando existe uma solicitação de fluxo de QoS nocontrolador. Com essa abordagem não são enviadas consultas periódicas ao controlador, o queaumentaria o overhead. Um pedido é sinalizado atraavés de uma mensagem OFPT_PACKET_INcom valor DSCP específico, já a liberação dos recursos é realizada quando a entrada de fluxo éremovida dos switches, depois de sinalizada por uma mensagem OFPT_FLOW_REMOVED.

3.4 AGREGAÇÃO DE TRÁFEGO

Esta parte é baseada na operação com os Medidores OF. Cada fluxo de QoS é registradona tabela de medidor do seu switch de entrada com taxa de medidor igual à taxa garantida. Umfluxo de QoS excedente, onde taxa é superior à taxa do medidor, sofrerá remarcação dos bitsDSCP dos pacotes em excesso, de modo que recebam um valor de prioridade maior que o deQoS. Desta forma, usando a operação “dscp_remark”, o switch altera os bits DSCP do tráfegoQoS excedente, realizando a separação entre tráfego QoS e QoS excedente. Os fluxos QoS, QoSexcedente e BE são agregados e encaminhados por filas específicas.

3.5 CLASSES DE SERVIÇO

O OF fornece um mecanismo de configuração de QoS baseado em enfileiramento egarantia de taxas mínimas para um determinado tipo de tráfego. Baseado nas classes de serviçoDiffserv para priorização de serviços, conforme mostra o Quadro 3.1 projetamos a seguintedivisão por classes:

3.6 CLASSIFICAÇÃO DE TRÁFEGO

Propõe-se a criação de fluxos baseados nos endereços físicos (MAC) das interfacesde rede das estações que distribuem os tipos de serviço prioritários. Por exemplo, os codecs

de videoconferência, os servidores e terminais VoIP, os servidores de conteúdo de vídeo. O


Quadro 3.1: Classes PHB

Classe ToS Garantia ServiçoEF DSCP 46 Baixa latência VideoconferênciaAF1 DSCP 10 Banda 1 VoDAF2 DSCP 18 Banda 2 VoIPBE DSCP 0 Nenhum Melhor esforço

Fonte: elaborado pelo autor

administrador da rede terá a opção de inserir outros dispositivos de forma temporária ou definitiva,utilizando uma interface de gerenciamento. Os fluxos serão instalados para corresponder com osendereços MAC com a ação de alterar o Byte Type of Service (ToS) dos pacotes correspondentes.Desta forma os pacotes prioritários receberiam os níveis de prioridade necessários sempre queentrassem na rede controlada.

3.7 MÚLTIPLAS TABELAS DE FLUXO

Nossa proposta inclui utilizar uma vantagem da versão 1.3 do protocolo OF, as múltiplastabelas, utilizando as vantagens mencionadas em OPEN NETWORKING FOUNDATION(2015b), melhorando a escalabilidade no gerenciamento de fluxos de modo a permitir tambémum pré processamento nos pacotes antes de realizar alguma outra função. Um pipeline demúltiplas tabelas no OF permite o processamento dos pacotes através de consulta a várias tabelasencadeadas. Neste caso, a classificação básica dos fluxos é realizada na tabela 0 (QoS ou BE).A Tabela 5 verifica a correspondência de fluxos QoS baseada em DSCP e a tabela 10 ficaresponsável pelo encaminhamento de pacotes.

3.8 MÓDULOS BÁSICOS

A próxima parte da proposta se baseia em três módulos de uma aplicação para o contro-lador Ryu:

� Módulo de monitoramento

� Módulo de controle de QoS

� Módulo de gerenciamento

A Figura 3.1 dá uma visão geral dos módulos


Figura 3.1: Visão gera da proposta de QoS


3.8.1 Módulo de controle de QoS

Esse módulo é responsável pelo controle de todos os mecanismos e políticas de QoS.Ele recebe os eventos e estatísticas do módulo de monitoramento. Ele deve garantir que o QoSseja implementado em todos os switches e portas conectados. É responsável por manter todosos switches em conformidade com a política institucional. Cada fila é definida com limites egarantias de vazão adequada ao tipo de serviço ou conforme determinar o administrador. Omódulo contempla funções que podem ser acionadas pelo módulo de gerenciamento para ajustesde configuração mais fácil pelo administrador da rede. Um módulo auxiliar do módulo decontrole realiza a reserva de recursos, fornecendo garantias de largura de banda de ponta a pontapara fluxos prioritários, configurando filas de saída nos dispositivos de rede. Devido à limitaçãodo protocolo OF em controlar filas, ele apenas consulta suas estatísticas, o controlador deveenviar comandos de configuração remotamente.

3.8.2 Módulo de Monitoramento

O módulo de monitoramento é responsável por coletar e armazenar informações sobreestado da rede, ele realiza a descoberta de topologia e coleta estatísticas de tráfego. O controlador


envia periodicamente mensagens de solicitação de estatísticas por fluxo e por interface. Osvalores dos contadores informados pelos switches fornecem informações sobre o quantidadede bytes enviados por fluxo e por interface. Esses dados são usados para calcular informaçõescomo largura de banda do fluxo e a carga do link, que são disponibilizadas ao algorítimo querealiza os cálculos das rotas. O processamento de estatísticas pode ser custoso, uma vez quepoder ser necessário repeti-lo para um grande número de fluxos e links, para aliviar o controladorconsideramos a consulta apenas do switch de entrada sobre estatísticas. Isso mantém a precisão,uma vez que as estatísticas coletadas não vão levar em conta a perda de pacotes dentro da rede.O intervalo entre medições consecutivas é definido considerando a carga de processamento,valores inadequados também podem impactar negativamente a precisão. Este módulo possibilitabasear a tomada de decisões, por exemplo, programar uma reconfiguração nas quantidades debandas garantidas nas filas de acordo com a utilização, reaproveitando a parte da banda que nãoestiver sendo utilizada. A definição mais precisa dessa tomada de decisão só é possível com umestudo mais aprofundado do perfil de tráfego da rede, projeta-se realizar o controle dinâmico dosrecursos que são alocados às filas, aproveitando melhor os recursos ociosos. Outra utilidade é sebasear no monitoramento para gerar eventos (como os de sobrecarga) e enviar ao administrador,ou mesmo ao sistema de controle que monitora tais eventos, através de alertas e mensagens.

3.8.3 Módulo de Gerenciamento

Este módulo fica responsável por fornecer uma interface de gerenciamento amigável aoadministrador da rede, o objetivo é fornecer a ele uma visão geral e melhor produtividade nogerenciamento, uma vez que ele não precisa conhecer comandos, como ovs-vsctl, para aplicaruma configuração na rede. Aqui estão concentradas todas as funcionalidades gráficas, sãofornecidas telas de administração, visualização da rede e das estatísticas de QoS, fluxos, filase tráfego. O módulo também contempla uma interface para executar ações de configuração emanipulação de fluxos, permitindo instalar, modificar, filtrar e remover fluxos QoS e filas, atravésdesse módulo, o administrador pode facilmente adicionar novos dispositivos e redes, associandoas prioridade às classes baseadas em ToS. A intenção básica é disponibilizar um ambiente ondepossa se realizar facilmente todas as operações relacionadas ao controle (incluindo QoS) da rede,no entanto novas funcionalidades podem ser implementadas posteriormente.

3.9 CONSIDERAÇÕES DE IMPLANTAÇÃO

A proposta deve atingir os benefícios que SDN pode trazer para a instituição.Atualmente, na UFPE, não há uma forma prática de identificar e controlar o tráfego

na rede, muito menos sem que seja necessário utilizar soluções complexas e de fabricantesespecíficos. Portanto, não é possível imaginar hoje qualquer solução aberta e centralizada paracontrole de rede sem considerar em SDN. Para fins de inovação e pesquisa, como já se sabe,SDN também vai permitir o isolamento do tráfego, de modo a separar um ambiente experimental.


O administrador da rede possui um controle centralizado, com visão global da redeinstitucional através de uma interface gerenciável e amigável. Olhando o comportamento da redecomo um ponto único de políticas, ele pode mais facilmente identificar gargalos e limitações epropor soluções através de aplicações de controle. Fica mais fácil estabelecer níveis de serviço egarantir que o tráfego esteja em conformidade com as políticas institucionais.

Desta forma também se consegue uma padronização de interfaces de dispositivos eindependência de fabricantes e tecnologias/funcionalidades proprietárias, muito diferente doque ocorre hoje, onde há uma grande heterogeneidade nesse contexto. Torna-se possível odesenvolvimento de aplicações próprias ajustadas às especificidades da instituição.

Uma solução simples de QoS por enfileiramento OF orientada à classes de serviço,como a proposta, ainda permite a compatibilidade com alguns switches legados, que suportema configuração de filas (via firmware ou Linux) e associação de campo ToS, isso pode terfundamental importância ao permitir uma implementação híbrida e migração incremental para oparadigma SDN.

Em relação à Educação a Distância, diante de um cenário de pleno crescimento, alémde se esperar que soluções de QoS possam melhorar os sistemas de distribuição multimídia ecomunicação em tempo real, espera-se implementar nos polos de apoio presencial aos cursosEaD, nas cidades do interior, estações de monitoramento através da instalação de dispositivosde borda baseados em SDN executando OvS. Estes dispositivos possibilitam que os polosparticipem das políticas de rede institucionais, com pouca necessidade de configurações locais.

3.10 DELIMITAÇÃO DO ESCOPO PARA TESTES

Finalizando este capítulo faremos algumas definições necessárias para o desenvolvimentodos testes.

Inicialmente, este trabalho se propôs a estudar o comportamento do tráfego de vídeoem tempo real na rede em produção na UFPE, nos limitamos a coletar e analisar métricas deavaliação objetivas, de QoS e QoE. Com o objetivo de utilizar um cenário que representassea comunicação inter-campi, analisamos e escolhemos a comunicação entre os campi Recifee Caruaru, distantes a aproximadamente 137 Km1. Conforme UNIVERSIDADE FEDERALDE PERNAMBUCO (2017a), observado através da página de monitoramento do tráfego emtempo real, dentre os dois campi fora da capital, o de Caruaru é que apresenta o maior volumede tráfego, além de possuir a maior infraestrutura de cursos (UNIVERSIDADE FEDERAL DEPERNAMBUCO, 2017b).

Em teoria, seria ideal que fossem realizados testes com injeção de tráfego na rede,para simular uma sobrecarga e nos permitir a análise nesse tipo de cenário, o que inviabilizoua realização de tais testes na rede real, em produção. Desta forma, optamos por realizar areprodução desse cenário da forma mais semelhante possível, caracterizando essa comunicação

1fonte: http://maps.google.com


real, em termos de "vazão", "atraso"e "perda"e virtualizando essas características num AmbienteVirtual.

3.10.1 Experimentação

Um dos focos do trabalho foi analisar o comportamento do tráfego de vídeo em temporeal, cada vez mais utilizado pela comunidade acadêmica, sobretudo nas aplicações do sistemade EaD. Foram realizados experimentos para tentar reproduzir casos de uso reais, situaçõesonde há tráfego comum concorrendo pelos recursos da rede com aplicações que deveriam terprioridade, como uma videoaula ao vivo, por exemplo, muito sensível às condições de rede.Para realizar a caracterização inicial da rede real inter-campi de forma minimamente intrusiva esegura, realizamos a transmissão de um vídeo via RTP e o tráfego de fundo (concorrente) foio tráfego normal gerado na rede real utilizada em horário comercial, entre 8h e 18h do horáriolocal.

Devido ao nosso compromisso com a geração de tráfego por uma aplicação real noexperimento na forma concorrente mencionada, porém onde a análise de tráfego pudesse serfeita de forma separada, na montagem do ambiente de experimentação, optou-se por utilizarvirtualização (de computadores, dispositivos e redes) o que trouxe a desejada flexibilidade paraconstrução e configuração dos cenários e execução dos testes. Nesse formato, as máquinasvirtuais constituíram verdadeiros protótipos que podem até migrar para a rede em produção,muito diferente do que ocorre nas simulações em geral. Observou-se em testes preliminares, queexperimentos no simulador de rede Mininet2 não foram flexíveis o suficiente, principalmentepelas limitações de software das máquinas virtuais criadas dinamicamente, e devido ao compar-tilhamento mínimo de recursos físicos da máquina real, o que não foi adequado à instalação eexecução de aplicações reais, cliente e servidor, no mesmo hardware.

Para comprovação das hipóteses e eficácia das técnicas foram utilizadas métricas deQoS "vazão", "perda de pacotes", "perda de quadros", "jitter", "PSNR", "Video Quality Metric(VQM)"e "Structural Similarity (SSIM)", e de QoE popularmente utilizadas no meio científico.Foram utilizadas, preferencialmente, ferramentas livres, para diferentes fins como captura eanálise de pacotes, medição de tráfego, virtualização, análise de rede, além de utilizadas versõesde avaliação de ferramentas para tratamento e a exibição dos dados.

3.10.2 Proposta

A nossa proposta consiste na distinção do tráfego baseada em 4 classes de serviço, comofoi mostrado anteriormente, porém para simplificar os cenários de testes, no AEV definimosapenas duas filas de prioridade apenas, uma para vídeo e outra para background. A propostainclui a utilização de medidores OF, o que não pode ser utilizado nos cenários do AEV, devido auma incompatibilidade da versão do OF presente no OvS, no entanto os objetivos foram atingidos

2http://mininet.org


de forma semelhante, a utilização de medidores apenas facilitaria e nos traz uma nova abordagemde monitoramento e limitação de taxa baseada em fluxos.

O controlador escolhido foi o Ryu por ser um software atualizado, com muita documen-tação disponível e devido à produtividade fornecida pela utilização da linguagem python.

616161

4AMBIENTE DE EXPERIMENTAÇÃO

Nesta seção, é detalhada toda a estrutura envolvida na concepção e montagem dosexperimentos, incluindo a criação de um Ambiente de Experimentação Virtual (AEV) e definiçãodos cenários de avaliação.

Conforme visto na literatura, o ambiente de experimentação e validação de técnicas,onde são realizadas avaliações de qualidade em vídeo (QoS e QoE), normalmente, possuemcaracterísticas específicas dos cenários que se pretende avaliar, sendo assim as configuraçõesdestes ambientes variam muito em cada abordagem. Como não houve uma metodologia eum conjunto de ferramentas bem definidas que fosse comum a todos os casos, foi feito umlevantamento de tudo que foi utilizado nos principais trabalhos relacionados.

As informações do Quadro 4.1 serviram de base para definição do nosso experimento,sempre mantendo em mente o nosso compromisso de tornar o ambiente o mais próximo darealidade. Assim, conforme foi feito em todos os trabalhos, avaliamos a solução comparandoas métricas em cenários antes e depois da solução, vimos que apenas LAGA et al. (2014) eUZAKGIDER; CETINKAYA; SAYIT (2015), analisam realmente um cenário de sobrecarga,simulando cenários com pouca banda disponível.

Vimos também que em termos de estatística de avaliação, NAM et al. (2014), II; DUR-RESI (2015), UZAKGIDER; CETINKAYA; SAYIT (2015), GEORGOPOULOS et al. (2015),CARAGUAY; FERNáNDEZ; VILLALBA (2015) utilizaram 20 ou mais repetições e UZAKGI-DER; CETINKAYA; SAYIT (2015) utilizaram 30, o que entendemos como suficiente depois deconsultar LARSON; FARBER (2010, p. 221).

Apenas em II; DURRESI (2015) não percebemos a realização de emulação de condiçõesdo link. Em todos eles, pelo menos a restrição de banda foi realizada, o que seria mais simplesde fazer, mas além dessa restrição, adicionamos a emulação da perda de pacotes ao que foi feitona avaliação de TSUNG-FENG; WANG; HSU (2015).

Sobre o tipo de vídeo utilizado, apenas LIU et al. (2013),NAM et al. (2014) e GEORGO-POULOS et al. (2015) utilizaram vídeos em HD, que exigiram maiores taxas de transferência.Já em relação à duração do vídeo, não existiu um consenso, escolhemos utilizar uma duração de150 segundos, pois já seria possível extrair as métricas e observar o comportamento do tráfego devídeo RTP (do ponto de vista pedagógico, GUO; KIM; RUBIN (2014) aponta para a eficiência

CAPÍTULO 4. AMBIENTE DE EXPERIMENTAÇÃO 62

de vídeo aulas curtas, de até 3 minutos de duração).Sobre o tráfego concorrente, os únicos que tentaram usá-lo para congestionar a rede

foram TANG; HUA; WANG (2014) e CARAGUAY; FERNáNDEZ; VILLALBA (2015). Emnosso caso definimos como indispensável simular tal concorrência de tráfego.

Com base nessa análise pudemos montar a nossa infraestrutura para experimentação.


Qua

dro

4.1:

Exp

erim

ento

sdo

str

abal

hos

rela

cion

ados

Ref

.R

epet

içõe

sC

enár

ios

Em

ulac

ãolin

kV

ídeo

Dur

ação

Con

corr

ente

LIU

etal

.(20

13)

8D

ifer

ente

sR

TT

Atr

aso

720p

N/a

N/a

NA

Met

al.(

2014

)10

0C

ombi

naçõ

esA

BR

/QoE

100M

bps

80a

90%

deoc

upaç

ão48

0pa

1080

p24

a50

min

Pois

son

dist

.

LA

GA

etal

.(20

14)

N/a

Lin

kva

zio

eso

-br

ecar

rega

doA

tras

oSV

C4

cam

adas

2se

gN

/a

WA

NG

etal

.(20

14)

N/a

Qua

lidad

em

í-ni

ma

eal

tare

solu

ção

Dla

y,ba

nda

res-

trita

1080

pN

/aN

/a

TAN

G;

HU

A;

WA

NG

(201

4)N

/aD

ifer

ente

spr

opo-

ções

detr

áfeg

oco

mba

ckgr

ound

Ban

dare

stri

taN

/a40

s22

Flux

osip

erf

TSU

NG

-FE

NG

;W

AN

G;H

SU(2

015)

N/a

Com

para

com

Ope

nQoS

Ban

da,A

tras

oat

é20

0ms

2flu

xos

mod

ela-

dos

N/a

Mel

hore

sfor

ço

II;D

UR

RE

SI(2

015)

4000

req.

Dif

eren

tes

topo

lo-

gias

6e

13ho

sts

N/a

N/a

N/a

N/a

UZ

AK

GID

ER

;CE

TIN

-K

AYA

;SA

YIT

(201

5)30

Red

eA

ltam

ente

carr

egad

aes

tátic

avs

dinâ

mic

aB

anda

3ca

mad

as60

0sN

/a

GE

OR

GO

POU

LO

Set

al.(

2015

)20

Com

Atra

soe

sem

atra

soA

tras

oe

perd

aSD

/HD

9m

ine

56s

Para

lelo

CA

RA

GU

AY

;FE

R-

NáN

DE

Z;V

ILL

AL

BA

(201

5)20

0B

anda

,per

da,

cif_

264

352x

288

80s

Satu

raçã

o

OA

utor

30Se

mQ

oS,

Com

QoS

Vaz

ão,

Atr

aso,

Perd

a72

0p15

0se

gip

erf3

UD

P25

Mbp

sFo

nte:

elab

orad

ope

loau

tor


Como prova de conceito a respeito da eficiência da abordagem baseada em SDN emecanismos de QoS do protocolo OF, e pelo fato de o ambiente real ter suas especificidades aindamais complexas por se tratar do protocolo de comunicação em tempo real (RTP), realizamos umaexperimentação onde observamos o comportamento do tráfego e dos mecanismos implementados.

Como já mencionamos, a situação ideal seria realizar medições e injeções de tráfegodentro da rede real, em produção. No entanto, nosso intuito sempre foi observar uma situaçãoonde houvesse sobrecarga de utilização da rede (com escassez de largura de banda para o tráfegode vídeo), forçar uma situação como essa seria um sério risco ao funcionamento da rede dainstituição.

Sendo assim, optamos por reproduzir o cenário da rede real da maneira mais fidedignapossível, dentro de um ambiente que pudesse ser manipulado de forma segura, isso só foi possibi-litado através da construção de um ambiente dentro de uma plataforma comercial de virtualização,o que chamamos de AEV. Com os dados coletados inicialmente (sem a sobrecarga) da rede emprodução, foram extraídas métricas de atraso, largura de banda e perda, que caracterizaram essarede e que foram, em seguida, emuladas num link virtual criado dentro da estrutura do nossoAEV.

4.1 VISÃO GERAL

O Ambiente de experimentação virtual (AEV), cuja visão geral é apresentada na Fi-gura 4.1 foi idealizado para permitir a análise em separado do tráfego prioritário de vídeo RTP,estando este sobre efeito de tráfego concorrente (de fundo). Para isso foram utilizados doisclientes (C1 e C2) e dois servidores (S1 e S2).

Figura 4.1: Visão geral da topologia do experimento



4.2 OS CLIENTES

Os clientes foram chamados de C1 e C2, e foram responsáveis pela requisição e rece-bimento de tráfego de fundo e prioritário, respectivamente. As principais configurações dosclientes são exibidas no quadro 4.2.

Quadro 4.2: Software nos servidores

Ferramenta versão utilizaçãoLinux Desktop mínimo 64 bits 16.04 Sistema Operacionaliperf3 3.1 Recepção de tráfego e teste de redeVLC 2.2.5.1 Reprodução e recepção de vídeoSpeedometer 2.8 Monitoramento de vazão de entradawireshark Tshark 1.10 Analisador de pacotesLibcap 1.5.3 Bibliotecas de captura de pacotes


4.3 OS SERVIDORES

Os servidores foram denominados S1 e S2 e foram responsáveis pela geração e envio detráfego de fundo e prioritário, respectivamente, para os clientes. As principais configurações dosservidores são exibidas no quadro 4.3.

Quadro 4.3: Software nos clientes

Ferramenta Versão UtilizaçãoLinux Desktop mínimo 64 bits 16.04 Sistema Operacionaliperf3 3.1 Geração de tráfego e teste de redeVLC 2.2.5.1 Geração do tráfego e transmissão de vídeoSpeedometer 2.8 Monitoramento de vazão de saída nas interfaces


4.4 SWITCHES

Os switches OvS com suporte a OF (switch1 e switch2) foram conectados entes si e aosclientes e servidores, eles receberam os softwares e configurações necessárias para comunicaçãoentre as máquinas, conforme o quadro 4.4.

Para facilitar a configuração do switches, foi criado um shell script Linux, esse script foicomposto por uma rotina de execução de comandos Linux para: remover todas as configurações(reconfigurar); criar o switch; inserir e configurar as interfaces de rede; estabelecer a conexãocom controlador (no cenário com SDN); habilitar a versão 1.3 do OF; entre outras configuraçõesbásicas.


Quadro 4.4: Softwares nos switches

Ferramenta Versão UtilizaçãoLinux Desktop mínimo 64 bits 16.04 Sistema OperacionalOpen vSwitch 2.5.2 switch virtual OFWireshark Tshark 1.10 Analisador de pacotesLibcap 1.5.3 Bibliotecas de captura de pacotes


4.5 O CONTROLADOR

Foi criada uma VM básica e configurado o ambiente para o controlador conforme oQuadro 4.5. No controlador, para fins de comunicação do switch, foi necessário executar umaaplicação Ryu de comutação em camada 2, ou L2 switching, que na prática faz o mapeamento deMAC por porta do switch, permitindo assim que todas as máquinas conectadas ao switch fossemencontradas na rede, são instalados fluxos nas tabelas dos switches, automaticamente, de acordocom as requisições que chegam. Com essa aplicação já foi possível habilitar a conectividadeentre as máquinas virtuais.

Quadro 4.5: Softwares no Controlador

Ferramenta versão utilizaçãoLinux Desktop mínimo 64 bits 16.04 Sistema OperacionalRyu 1.x Controlador SDN


4.6 AS REDES

No âmbito do Hipervisor, que fornece a virtualização de computadores e de redes,optamos pelo Esxi1 da VMware, somente porque já possuíamos uma versão instalada e disponívelpara os testes de imediato, também já havíamos tido experiências anteriores de configuração deinterfaces e redes virtuais nesta plataforma de virtualização. Vale ressaltar que poderíamos terutilizado outras plataformas como Xenserver2 ou Hiper-V3.

Ainda no Esxi, utilizamos as redes virtuais denominadas Virtual Machine Network

(VMN) para configurar cada conexão virtual entre máquinas e switch, e entre switches possibili-tando a comutação via OvS. Para tal também foi necessário habilitar nas interfaces das máquinascom OvS o modo promiscuo para fazer que o OvS pudesse receber todos os pacotes, mesmoos que não eram diretamente endereçados a ele. As redes virtuais do Esxi foram configuradasconforme o quadro 4.6. A rede lógica configurada para tráfego interno foi a 192.168.0.0/24

1https://www.vmware.com/br/products/vsphere-hypervisor.html2https://www.citrix.com.br/products/xenserver/3https://msdn.microsoft.com/pt-br/library/hh831531(v=ws.11).aspx


Quadro 4.6: Redes virtuais Esxi

Rede virtual DescriçãoVMN1 Conexão entre C1 e ovs1VMN2 Conexão entre C2 e ovs1VMN3 Conexão entre S1 e ovs2VMN4 Conexão entre S2 e ovs2VMN5 Conexão entre ovs1 e ovs2


Para estabelecimento do canal de controle OF, foi utilizada outra sub-rede, 10.10.10.0/24,que utilizou no Esxi a VMN6, conectando ovs1 e ovs2 ao Controlador de rede Ryu.

4.7 A VIRTUALIZAÇÃO

O servidor físico onde foi executado o Esxi é de propriedade da UFPE e encontra-seinstalado no prédio da Biblioteca Central ao qual tivemos acesso físico e remoto via Rede privadavirtual (VPN), o que permitiu acesso para realização das operações. O hardware desse servidorestá listado no Quadro 4.7. No AEV foram posicionados, logicamente, os clientes conectados

Quadro 4.7: Especificações de Hardware

Modelo Processador Memória RAM Armazenamento HipervisorDell PoweredgeR720

Intel Xeon E5-2609 4x 2,4Ghz 48 GB 2TB Esxi 5.5


ao ovs1, de um lado, e os dois servidores na outra extremidade, conectados ao ovs2. Na redeespecífica para controle, foi posicionado o controlador de rede conectado aos dois switches.Na plataforma de virtualização, o provisionamento de recursos de hardware para as máquinasvirtuais envolvidas nos testes foi realizado de acordo com os requisitos mínimos para que fossepossível executar todas as aplicações sem travamentos, que poderiam interferir nos resultadosdos testes. Para verificarmos isso, preliminarmente, foram medidos os consumos de recursosem todas as máquinas durante os testes, através da ferramenta top4 atingimos uma configuraçãoadequada de hardware mostrada no Quadro 4.8.

4.8 O TRÁFEGO DE FUNDO

Em relação ao tráfego de fundo, o mesmo seguiu o caminho 1 (C1 <-> S1), representadona Figura 4.1 pelas linhas e setas vermelhas, os testes foram realizados utilizando dois tipos deprotocolos de transporte para geração de tráfego, Transmission Control Protocol (TCP) e UserDatagram Protocol (UDP). O UDP foi escolhido para nossa comparação final, foi mais propício

4http://man7.org/linux/man-pages/man1/top.1.html


Quadro 4.8: Especificações de Hardware

Nome CPUs virtuais Redes virtuais Memória RAM Armazenamentohost1-c1 1 vCPU 1 vNICs 2048 20GBhost11-s1 1 vCPU 1 vNICs 2048 20GBhost2-c2 1 vCPU 1 vNICs 2048 20GBhost22-s2 1 vCPU 1 vNICs 2048 20GBhost3-ovs1 1 vCPU 4 vNICs 2048 20GBhost33-ovs2 1 vCPU 4 vNICs 2048 20GBhost4-ryu 1 vCPU 1 vNICs 2048 20GB


a esta análise por gerar uma maior degradação das condições de rede (a principal intenção dapresença do tráfego concorrente foi simular uma situação de congestionamento) interferindo maisnegativamente no tráfego prioritário, além de ter mantido a taxa de envio constante do tráfego defundo, característica do protocolo UDP. O tráfego foi gerado pela ferramenta "iperf3"com osparâmetros exibidos no Quadro 4.9

Quadro 4.9: Configuração do tráfego de fundo: AEV

Parâmetro ValorVersão do iperf 3.1Protocolo de transporte UDPSentido Reverso (cliente >servidor)Intervalo entre relatórios 1 segundoPorta 5201Fluxos 1Duração 150 segundosVazão 25 MbpsLog salvo em arquivo


4.9 O TRÁFEGO PRIORITÁRIO

O tráfego prioritário seguiu naturalmente o caminho (C2 <-> S2), representado naFigura 4.1 pela seta azul. Foi utilizado tráfego real através da transmissão de um vídeo em HD,com duração de 139 segundos. A ferramenta utilizada para transmissão e recepção desse vídeofoi o VLC5, utilizando o protocolo RTP. Foram configurados os parâmetros de servidor e cliente.Durante toda a transmissão do vídeo houve presença do tráfego de fundo.

Todos os dados coletados da comunicação e necessários à análise posterior foram salvoslocalmente em tempo real e, ao final de cada teste, transferidos para um diretório compartilhadonum storage (servidor de armazenamento) organizados em subpastas separadas por tipo deexperimento.

5https://www.videolan.org/vlc/


Como se tratava de analisar um conteúdo real, utilizamos um vídeo no formato AudioVideo Interleave (AVI), codificado em MPEG-4 a 5,5 Mpbs, em HD, resolução 720p, com taxa de24 FPS, tendo tamanho de 83,3 MB em arquivo e total de 3349 quadros, configurações típicas devídeos em HD. O vídeo utilizado foi um trailler livre de um filme aleatório adquirido da internet,disponível em banco de dados de vídeo6. Durante a transmissão não foi aplicada nenhuma formade compressão e transcodificação adicional, o vídeo foi simplesmente transportado pela rede, oque exigiu ainda melhor desempenho da mesma.

4.10 O LINK

A topologia com dois switches conectados foi utilizada para que houvesse a emulação deum link entre eles, e consequentemente, entre as duas partes da rede (lado do cliente representandoo campus Caruaru; lado do servidor representando o campus Recife). Dessa forma, foi possívellimitar a conexão, reproduzindo uma saturação de 94% da capacidade nominal do link, assimapenas 6 Mbps ficaram disponíveis para tráfego nesse link.

Intencionalmente, o vídeo, que já necessitava de 5,5 Mpbs (taxa de referência da codifi-cação), precisaria ocupar durante todo o tempo de transmissão mais de 90% da vazão disponívelpara manter a qualidade, esse vídeo experimentou uma forte concorrência com o tráfego de fundoque requisitava vazão bem superior à disponível. Para modelar esse link com as característicasda conexão real, utilizamos a ferramenta TC7, e seus utilitários Network Emulator (Netem) eToken Bucket Filter (TBF) do Linux, as interfaces foram configuradas via shell script com osparâmetros do Quadro 4.10, o que impôs limites ao link virtual.

Quadro 4.10: Configuração do link: AEV

Parâmetro ValorTaxa de codificação do vídeo (referência) 5,5 MbpsLargura de banda 6 MbpsAtraso 4,2 msPerda 4,3%Latência máxima suportada 200 ms


4.11 OS CENÁRIOS

Com tudo configurado temos uma topologia como ilustra a Figura 4.2Para avaliar os mecanismos de QoS na rede SDN foram feitas medições em dois macro

cenários: Cenário SQ - Rede tradicional (não SDN) sem QoS; Cenário CQ - SDN com QoSbaseado em OF. Para cada cenário foram especificadas baterias de testes, variando o tráfegoconcorrente (TCP e UDP) nos dois cenários:

6http://www.dvdloc8.com/7http://lartc.org/manpages/tc.txt


Figura 4.2: Detalhes da topologia


� Cenário SQ - Sem garantia de QoS:

� Tráfego RTP + tráfego TCP de fundo;

� Tráfego RTP + tráfego UDP de fundo.

� Cenário CQ - Com garantia de QoS (SDN):

� Tráfego RTP + tráfego TCP de fundo;

� Tráfego RTP + tráfego UDP de fundo.

Como já foi comentado, os resultados dos testes com tráfego de fundo TCP não foramutilizados nas análises posteriores, pois geraram uma concorrência controlada, característica doprotocolo de transporte TCP. Como possibilitou a topologia dos experimentos, também foramexecutados testes e coletas de tráfego de forma isolada (apenas TCP, apenas UDP, apenas RTP),apenas para verificação do comportamento geral de cada tipo e para nos ajudar a entender eajustar os parâmetros dos testes antes deles serem iniciados. Como se tratava de tráfego real,muitas variações poderiam ocorrer, e comportamentos inesperados, tanto que foi necessárioreiniciar os testes e reajustar parâmetros de configuração das ferramentas diversas vezes. Essesdados das coletas isoladas também não foram utilizados diretamente nas análises pois fugiuao escopo do trabalho. Em cada macro cenário, os testes foram executados e vários tipos dearquivos com dados da comunicação foram coletados:


� Arquivo de log do teste no cliente do "iperf3"8;

� Arquivo "pcap"com dados coletados do Wireshark9;

� saída em texto do monitoramento de vazão do speedometer10;

� saída do VLC11 em "avi"capturado no recebimento do cliente;

� arquivo de texto com mensagens para depuração do VLC.

Vimos que utilizar o protocolo UDP como transporte de tráfego concorrente foi a melhormaneira de reproduzir um cenário em que tal concorrência gerava alta utilização da largura debanda, deixando pouca capacidade disponível para tráfego institucional prioritário, por exemplo.Nossos testes tentam comprovar que em situações como esta, sem o devido tratamento, teremosum cenário de baixa qualidade de serviço e de experiência do usuário.

4.11.1 As configurações de QoS e filas

Para habilitar o Cenário CQ (com SDN e QoS), um script foi criado e utilizado paracriar uma política de QoS geral de 6 Mbps máximo nos switches (limitação baseada na situaçãode congestionamento do link) e criar duas filas, conforme ilustrado na Figura 4.3 fila 1 paratráfego melhor esforço com taxa máxima de 6 Mbps (sem garantia de taxa mínima), e a fila 2para tráfego prioritário com garantia de 6 Mbps (taxa mínima). Em seguida, instalamos os fluxospara correspondência nas tabelas no OvS, criamos outros dois scripts para configuração de cadaswitch e instalação desses fluxos.

Figura 4.3: Visão geral das filas


Durante a execução dos testes no Cenário CQ, pudemos observar os status das filas comincrementação dos contadores de tráfego à medida que novos pacotes iam correspondendo com

8https://iperf.fr/iperf-doc.php9https://www.wireshark.org/docs/

10https://excess.org/speedometer/11https://wiki.videolan.org/


os fluxos e sendo encaminhados para as filas. Configurado o cenário CQ, os mesmos testes (jádescritos) do cenário SQ foram realizados.

4.12 AS FERRAMENTAS DE GERAÇÃO E COLETA

Como ferramentas para medição e coleta de dados da comunicação serão utilizadas:Wireshark é baseado na ferramenta "tcpdump"e biblioteca "libcap", é muito utilizada

para realização de sniffer em redes, realiza a captura de todos os pacotes que trafegam atravésdas interfaces monitoradas. Permite a escrita em arquivo que possibilitou a análise posterior dosdados. O Wireshark auxiliou neste trabalho na coleta do tráfego e extração das métricas de vazão,jitter e perda de pacotes. Com os dados coletados foi possível aplicar filtros que separarampacotes específicos, e realizar uma análise específica em pacotes RTP.

A ferramenta speedometer monitora interfaces de rede e exibe graficamente a taxa coma qual os dados estão trafegando em tempo real, ela coletou a vazão do tráfego RTP recebidonas interfaces dos clientes. O comando "timeout"(linux) também foi utilizado em conjunto paraprogramar a execução do comando por 150 segundos, o modo simplificado da ferramenta foihabilitado para possibilitar salvar os dados em arquivo de texto;

Utilizamos o "iperf3"versão 3.1, ele é um redesenho do "iperf"tradicional, essa novaversão possibilitou o uso de alguns comandos específicos como a opção "reverse", que baseadona requisição do cliente, envia tráfego no sentido servidor para o cliente, além da opção de salvaro log em arquivo de texto, que utilizamos para analisar posteriormente os dados. O "iperf3"foiutilizado para manipular o tráfego de fundo injetado na rede. Ele nos permitiu extrair métricasdesse tráfego, como vazão, Jitter e perda de pacotes;

O software VLC foi utilizado para gerar e transmitir fluxo de vídeo RTP entre um servidore um cliente. Como a intenção era representar uma transmissão de vídeo real que representasse osconteúdos de educacionais de alta qualidade, utilizamos um arquivo de vídeo em alta resolução(HD) transmitido pelo VLC, sem realizar nenhuma compressão adicional ou transcodificação. OVLC permitiu automatizar as suas ações através de sua versão em linha de comando simplificada,o "cvlc". No lado do cliente foi habilitada a opção de salvar a saída do vídeo (em avi), o quefoi necessário no cálculo das métricas de QoE onde foi feita a comparação entre vídeo original(referência) e saída de vídeo no destino (processado).

Para extração da métrica "perda de quadros"foi utilizada a ferramenta ffmpeg12 quepossibilitou calcular a quantidade de quadros no vídeo processado e comparar com a quantidadeoriginal. A ferramenta MSU13 foi utilizada para calcular as métricas de QoE (PSNR, VQMe SSIM), para isso utilizamos a sua versão de avaliação por 30 dias (tempo suficiente), quepossibilitou análise de vídeos em HD (não contemplado na versão livre). Foram construídosscripts para automatizar os cálculos das métricas, utilizando a versão de linha de comando do

12https://www.ffmpeg.org/13http://www.compression.ru/video/quality_measure/video_measurement_tool.html


MSU, foi necessário varrer os 30 vezes o arquivo de vídeo original e comparar 30 vezes com oarquivo processado, em cada cenário.

4.13 CONSIDERAÇÕES GERAIS

Em resumo e como já temos observado, para sistematizar o processo de execução dosexperimentos foram criadas várias rotinas em linguagem shell script para Linux. Para cadacenário, um ou mais scripts executaram comandos que representaram as ações de cliente,servidor, switch, controlador, e analisador de tráfego, sequencialmente. Os scripts, ao finalde cada execução, copiaram seus arquivos salvos localmente para um diretório compartilhadonum servidor de armazenamento com capacidade para 100 GB, que ficou disponível em todosos sistemas operacionais do AEV. Com base em (LARSON; FARBER, 2010, p. 221), paradar confiança estatística aos dados, foi determinada a quantidade de 30 repetições para cadacenário de teste, o que permitiu um nível de confiança de 95%. Os testes foram planejadosem conformidade com RFC’s como (CONSTANTINE; KRISHNAN, 2015) que descreve umametodologia para benchmarking de tráfego indicando apenas números mínimos de 10 repetiçõese duração de 60 segundos para cada iteração nos testes.

Neste capítulo, definimos todos os aspectos relativos à montagem e execução dos experi-mentos no cenário real inter-campi e dentro do AEV. Mostramos todos os detalhes necessáriospara medir e configurar as características do cenário real inter-campi, além de mostrar as es-pecificidades para execução dos cenários no AEV, antes e depois da solução com SDN e QoS.Todos os scripts aqui mencionados foram executados por vários dias e geraram um volume dedados considerável no storage, esses dados foram organizados (muitas vezes manualmente) comauxílio das ferramentas e são apresentados e explicados no próximo capítulo.

747474

5ANÁLISE E APRESENTAÇÃO DOS DADOS

Neste capítulo tratamos da análise dos dados coletados e apresentação dos mesmosgraficamente.

Primeiro é realizada a caracterização da rede inter-campi (UFPE Recife - Caruaru) e sãofeitos comentários sobre os gráficos e métricas apresentadas. Destacamos ainda as ferramentasque foram utilizadas nesse cenário

Em seguida, avaliamos os gráficos gerados com base nos resultados dos experimentosno AEV. Em geral, utilizaremos gráficos de dois tipos, a) série de dados que mostra o valor damétrica para cada iteração no experimento; b) Intervalo de dados médios, calculados em funçãode um nível de confiança de 95%, mostrando a evolução do cenário SQ para o 2 CQ no mesmográfico, para facilitar a visualização.

Em alguns casos, no mesmo gráfico serão comparadas várias variações de uma determi-nada métrica, como é o caso do jitter, que mostra 4 linhas, de (jitter médio SQ, jitter máximoSQ, jitter médio SQ e jitter máximo CQ), também com a intenção de facilitar a visualização e acomparação.

5.1 CENÁRIO REAL INTER-CAMPI

Para caracterizar o tráfego inter-campi, analisamos a rede em produção da UFPE, emparticular a comunicação entre os campi Recife e Caruaru, localizados nas cidades de mesmonome, no estado de Pernambuco. Dentro da rede de cada campus foi utilizada uma máquinavirtual, e foi liberada a comunicação específica para que os testes de tráfego ocorressem de formasegura entre os dispositivos. Nestas máquinas foram instaladas as ferramentas para geração detráfego, recepção do tráfego e análise da comunicação, como mostra o Quadro 5.1.

Durante as transmissões de vídeo foi realizada coleta de todos os pacotes que trafegaram,com auxílio da ferramenta tshark, que executa as funções do wireshark em linha de comando.Com a ferramenta speedometer foi medida a vazão nas interfaces e com o cvlc, opção de linhade comando do VLC, foi realizada a transmissão e o recebimento do vídeo, via RTP.

A estrutura básica da comunicação inter-campi (Recife - Caruaru) é mostrada na Fi-gura 5.1. A universidade possui atualmente uma conexão de 100 Mbps de largura de banda

CAPÍTULO 5. ANÁLISE E APRESENTAÇÃO DOS DADOS 75

Quadro 5.1: Ferramentas utilizadas no cenário em produção

Ferramenta Principal funçãoIperf31 medidor de tráfegoVLC2 servidor/cliente RTPping3 testes ICMP (RTT)wireshark/tshark4 coletor e analisador de pacotes RTPssh5 acesso remotospeedometer6 monitoramento de vazão


Figura 5.1: Visão geral da rede real


disponível entre as redes dos seus dois campi. Para caracterizar o tráfego de vídeo na rede, foramrealizados testes (30 repetições) na rede em produção, isso para reproduzir uma suposta situaçãoreal de uso da rede, em que um servidor de vídeo estaria localizado em Recife disponibilizandoum conteúdo de vídeo em HD, um usuário no campus Caruaru requisita esse conteúdo que éenviado pelo servidor. Para isso foram configurados um servidor de vídeo em Recife e um cliente(receptor) de vídeo em Caruaru. A requisição do cliente, no experimento, foi realizada durantehorário normal de experiente da Universidade, e assim, o tráfego do vídeo foi misturado a umtráfego real sendo consumido ao fundo. Vale ressaltar que na rede real inter-campi, atualmente,nenhum tipo de tratamento de prioridade é dado a nenhum tipo de aplicação.

Antes de iniciar o tráfego de vídeo RTP, foram realizados alguns testes mais básicos coma ferramenta "iperf3", com envio de tráfego do cliente ao servidor. No primeiro teste, injetandotráfego TCP, verificou-se a capacidade máxima da conexão atingida durante aquele período.Como essa análise isolada não faz parte do nosso escopo, é possível apenas comentar que em100% das repetições de medição com TCP, a média de vazão real disponível no link variouabaixo de 40% da sua capacidade nominal de 100 Mbps.

Na injeção de tráfego UDP, foi necessário definir a carga de banda em Mbps. Porsegurança, esse teste foi realizado no período da madrugada, visto que o UDP não tem controle


e poderia gerar uma sobrecarga prejudicial à rede num horário de funcionamento normal doscampi. Num primeiro momento foi realizada a coleta com essa vazão definida ao valor máximode de 100 Mbps, durante o experimento percebemos que mesmo solicitando o envio de dados a100 Mbps, o tráfego não ultrapassou os 30 Mbps. Em se tratando de tráfego UDP e verificadosos logs do "iperf3", percebemos que muitos pacotes estavam sendo descartados, algo em tornode 70%. Baseados nessa resposta dos logs, no teste seguinte essa vazão foi reduzida para 30Mbps e ainda se observou perda. Apenas quando reduzida para 25 Mbps obtivemos um tráfegoUDP normal com descarte mínimo. A relação entre vazão configurada e perda de pacotes obtidaé mostrada no Figura 5.2

Figura 5.2: Gráfico: Relação Configuração da vazão vs. Perda: Inter-campi


O último teste realizado no ambiente real foi com o tráfego de vídeo RTP. Utilizamoso vídeo em HD em experimentos de 150 segundos. Todos os pacotes foram capturados e osarquivos de saída do vídeo foram armazenados. Após serem definidos os parâmetros e comandosnecessários locais e remotos, a rotina das 30 repetições da transmissão do vídeo foi automatizadaatravés de shell script e os dados foram coletados. Os parâmetros de configuração do script paratodas as ferramentas utilizadas foram utilizados conforme o Código 6.6

Os detalhes acerca dos resultados dessa análise do cenário real inter-campi são apresen-tados nas próximas seções para cada métrica avaliada.

5.1.1 Atraso

Foi avaliado o tempo que um pacote levou entre o servidor e o cliente, através do RoundTrip Time (RTT), foram realizadas requisições Internet Control Message Protocol (ICMP) atravésda ferramenta "ping", disponível no Linux, a ferramenta calculou os tempos (médio e máximo)que o cliente ICMP levou entre o envio da sua requisição e recebimento da resposta. Foramenviados 30 vezes o comando que requisitava 30 respostas (no final eram calculadas as estatísticasde RTT). Com isso fizemos um cálculo da média dos 30 valores médios. Podemos observar os


resultados na Figura 5.3. O intervalo de valores médios de atraso com nível de confiança de 95%foi de 4,11 ms chegando o pico ao valor máximo de 28,18 ms. Com esses valores pudemos fazeruma estimativa de atraso da rede.

Figura 5.3: Gráficos de RTT: Inter-campi

(a) RTT (b) Intervalos de RTT (95% IC)


5.1.2 Rede real inter-campi: Vazão

Em relação à métrica vazão que foi observada no tráfego de vídeo entre Recife e Caru-aru, foi verificado que o vídeo precisava trafegar a uma taxa próxima à taxa de referência dacodificação, em torno de 5,5 Mbps, no entanto, observamos na Figura 5.4 a) uma taxa que varioumuito em cada experimento, o que demostrou que poderia haver alguma instabilidade no link. AFigura 5.4 b) apresenta o valor médio e as barras referentes ao nível de confiança de 95%. Otráfego alcançou uma média de 5,08 Mbps.

Figura 5.4: Gráficos de Vazão: Inter-campi

(a) Vazão (b) Intervalo de Vazão (95% IC)


Vale ressaltar que foi possível ficar próximo da velocidade requerida pelo vídeo, o que é oideal, mas os testes foram realizados numa rede em situações normais, sem sobrecarga aparente,dessa forma podemos dizer que a velocidade do vídeo foi compatível. É necessário compreender


para esta métrica, que caso o vídeo trafegasse a uma taxa muito abaixo da taxa de referência dovídeo (menor que 5 Mbps), muitos pacotes seriam descartados, o que implicaria em quadrosfaltando na visualização do vídeo, degradando a sua percepção pelo usuário final.

5.1.3 Rede real inter-campi: Perdas

Para a métrica "perdas", optamos por colocar no mesmo gráfico as perdas de quadros eperdas de pacotes, por serem valores que apresentam valores similares, haja visto o comporta-mento das linhas da Figura 5.5 a). Em teoria, um quadro é formado por vários pacotes, e a perdade um pacote pode implicar na perda deste quadro. Portanto espera-se um número absoluto maiordo número de pacotes perdidos, porém proporcionalmente as duas perdas se assemelham, o queocorreu na comunicação de vídeo entre Recife e Caruaru. O valor médio de perda de pacotescom nível de confiança de 95% foi de 4,27% de pacotes perdidos, que devido às oscilações darede e do tráfego real, chegou a atingir um valor máximo de 13,7% de perda. Esse valor de perdaé aceitável num tráfego de vídeo, quadros são perdidos no vídeo, mas a informação geral dovídeo continua inteligível. Muitas vezes esses quadros faltantes nem são percebidos pelo usuário,já que nesse vídeo, por exemplo, são exibidos cerca de 24 quadros em um segundo.

Figura 5.5: Gráficos de Perdas (de Pacotes e de Quadros): Inter-campi

(a) Perda (b) Intervalos de Perda (95% IC)


5.1.4 Rede real inter-campi: jitter

A métrica jitter, ou variação do atraso, é uma métrica objetiva de QoS, calculada emmilissegundos, que pode ter influência negativa na qualidade dos vídeos. Durante o tráfegodo vídeo inter-campi, avaliamos duas medidas, a do jitter médio e o jitter de pico (máximo).Além da importância do valor médio de jitter, que quando adequados denotam a estabilidadeno recebimento dos pacotes em tempo certo no cliente, nessas situações onde ocorrem ospicos (variações de atraso muito altas), pode significar que um pacote se perdeu, o que podeocasionar cortes na comunicação (espaços vazios) e ruídos, quando o pacote chegar fora detempo, interrompendo a fluidez da comunicação. Para comunicações em multimídia, em geral,


RAHRER; FIANDRA; WRIGHT (2006) recomenda variações de atraso abaixo de 50 ms parafluxos de alta definição codificados em MPEG-4. Nos testes visualizados na Figura 5.6 obtivemosvalores médios de jitter baixos, já os de pico se aproximaram do limite recomendado, chegandopróximo dos 45 ms, o que pode ser considerado aceitável, mas pode ser um fator a ser deixadoem observação. Analisamos então que para essa métrica, o vídeo trafegou normalmente, podendoter ocorrido falhas durante a reprodução, mas que provavelmente não interferiram na percepçãode qualidade e muito menos no entendimento geral do vídeo.

Figura 5.6: Gráficos de jitter: Inter-campi

(a) jitter (b) Intervalos de jitter (95% IC)


Finalizamos aqui a coleta de métricas da rede real inter-campi. Essas informaçõesserviram de base para montarmos o experimento e definirmos as características da rede deteste. Como já relatamos, na rede real seria quase impossível observar o comportamento de umcongestionamento por conta de tráfego concorrente, são emulados nos cenários do experimentovirtual tais situações de baixa capacidade de vazão.

5.2 CENÁRIOS DO AEV

Após a coleta das métricas do cenário real inter-campi, nas seções anteriores, foramgerados parâmetros para emulação das características do link do nosso Ambiente de Experimen-tação Virtual (AEV). Após a emulação do link e execução dos experimentos nos cenários SQ eCQ, foram realizadas as análises das métricas, comparações entre os cenários, cujos gráficos einformações são apresentadas a seguir.

5.2.1 Comparação Cenários SQ vs. SQ: Vazão

Para a métrica vazão, o intervalo de valores para um nível de confiança de 95% nãofoi relevante, pois houve uma sobreposição (não houve aumento real nas médias de vazão)na comparação entre os dois cenários, foi visto que a diferença significativa, mostrada pelaFigura 5.7, através do gráfico em série, é estabilidade da vazão. Como podemos observar no


cenário sem QoS, representado pela linha azul, a vazão oscilou entre valores muito altos, e outrosmuito baixos (reduzindo a algo próximo de 1 Mbps), o que demonstra que no cenário sem QoS, otráfego de vídeo foi prejudicado em alguns testes. Quando habilitada a priorização e as políticasde QoS, representado pela linha vermelha, percebe-se claramente uma comunicação muitomais estável (sem muitas variações), com garantia de taxas sempre acima dos 5 Mbps, como édesejável. Isso comprova que as filas conseguiram redirecionar o tráfego de vídeo corretamente,isolando o tráfego prioritário de interferência do tráfego de fundo (BE) e garantindo as taxasmínimas de vazão.

Figura 5.7: Gráfico de vazão (Mbps): Experimentos AEV


5.2.2 Comparação Cenários SQ vs. SQ: jitter

Para a métrica jitter, ou variação de atraso, no ambiente de experimentação, vimosoutra evolução significativa do cenário sem priorização para o com priorização, percebe-sena Figura 5.8 que antes de habilitarmos os mecanismos de priorização e enfileiramento, osvalores de jitter médio e máximo (representados pelas linhas azul e verde) eram oscilantes emais altos, reflexo da interferência do tráfego de fundo, ou seja, bem piores e bem acima dos50 ms. Habilitando a priorização, QoS os valores se estabilizaram e baixaram, o que é ideal, erepresenta de fato uma garantia de serviço. Nos valores médios de vazão, com nível de confiançade 95% , como mostra a Figura 5.9, obtivemos redução de 7 ms para 1 ms de média, quase ideal,enquanto o jitter de pico, que podem ocorrer em momentos pontuais, também foi de 50 ms demédia para 40 ms, num intervalo com 95% de confiança.


Figura 5.8: Gráficos de jitter: Experimentos AEV


Figura 5.9: Intervalos de jitter (95% IC): Experimentos AEV

(a) jitter médio (b) jitter máximo


5.2.3 Comparação Cenários SQ vs. SQ: Perdas

Em relação à métrica "perda"(na qual agregamos as perdas de pacotes e de quadros,calculadas para mostrar a similaridade entre as duas), os resultados mostram um valor muitobaixo quando se utilizou as técnicas de QoS. Na Figura 5.11 é possível observar uma evoluçãogrande nos intervalos de confiança, do cenário sem QoS para o cenário com QoS, onde a médiade pacotes perdidos caiu consideravelmente, de 64% dos pacotes perdidos para 0,6%, já emrelação aos quadros, a perda caiu de 49% para 0,5%. O que demonstrou uma grande eficiênciada priorização em relação a esta métrica.

5.2.4 Comparação Cenários SQ vs. SQ: PSNR

Na métrica de QoE PSNR, com os valores calculados pela comparação dos quadros dovídeo original com os quadros do vídeo recebido nos experimentos, pudemos observar melhorias


Figura 5.10: Gráfico de Perdas: Experimentos AEV


Figura 5.11: Intervalos de Perda (95% IC): Experimentos AEV

(a) Perda de pacotes (b) Perda de quadros


a partir do momento em que se habilitou a priorização, ou seja, houve aumento da relação de sinalem relação ao ruído de pico, conforme mostra a Figura 5.12. E vimos também que os valoresvariaram bem menos no cenário com QoS. Observamos que foram obtidos melhores valores nointervalo de confiança do PSNR, aumentando o valor da métrica em decibéis. Enfatizaremosaqui a melhoria que houve no vídeo, em relação à métrica PSNR depois que foi habilitadaa priorização via OF. Essa medida de PSNR foi calculada em termos da sua componenteluminância (Y).

5.2.5 Comparação Cenários SQ vs. SQ: VQM

Similarmente, a métrica VQM, que é mais eficiente do que PSNR e realiza o cálculobaseado na transformada discreta dos cossenos (DTC) levando em consideração a sensibilidadehumana ao contraste para calcular as distorções de imagens ou vídeo, após habilitarmos QoS ea priorização no cenário CQ, isso proporcionou melhores valores como mostra a Figura 5.13.Diferente do PSNR, quanto menor o valor de VQM, melhor é a qualidade percebida. Isso vem a


Figura 5.12: Gráficos de PSNR: Experimentos AEV

(a) PSNR (b) Intervalos PSNR (95% IC)


comprovar a melhoria da qualidade do vídeo no cenário com QoS.

Figura 5.13: Gráficos VQM: Experimentos AEV

(a) VQM (b) Intervalos VQM (95% IC)


5.2.6 Comparação Cenários SQ vs. SQ: SSIM

E por último, calculamos a Similaridade Estrutural, outra métrica comparativa pós PSNRque utiliza a distorção estrutural para calcular as distorções em imagens. Como podemos ver naFigura 5.14, confirma-se a melhoria na qualidade da percepção do vídeo, onde obtivemos valoresmelhores, que no caso do SSIM deve ser o mais próximo de 1. Nos gráficos também observamosmenos variações, o que demonstra mais uma vez um comportamento mais estável no cenárioapós a configuração de QoS.

Finalizando este capítulo de análise e apresentação dos dados podemos concluir que aabordagem de caracterização da rede inter-campi foi adequada e permitiu realizar os experimentosno AEV. Sobre os experimentos no AEV, podemos concluir que foram eficazes permitindoobservar o comportamento de tráfego. Em linhas gerais, obtivemos melhores valores de métricasde qualidade quando habilitamos o cenário com QoS, isso fica comprovado após a presentação


Figura 5.14: Gráficos de SSIM: Experimentos AEV

(a) SSIM (b) Intervalos SSIM (95% IC)


dos gráficos e valores neste capítulo.No capítulo seguinte faremos as considerações finais sobre o trabalho e sobre a elaboração

deste documento.

858585

6CONCLUSÕES

Nessa proposta, identificamos como principal contribuição a construção de uma me-todologia flexível e adequada à experimentação em SDN / OvS / OF para análise de tráfegosconcorrentes, onde podemos tomar como exemplo a nossa abordagem que utilizou vídeo RTP ede background. Depois de testes em alguns cenários como mininet, chegamos à conclusão deque nosso objetivo só seria atendido com a criação desse cenário baseado em máquinas e redesvirtuais. A partir deste nosso trabalho torna-se possível o surgimento de vários outros usandoessa mesma metodologia e personalizando o Ambiente virtual de experimentação.

Após todo o processo de pesquisa, avaliação do cenário real e prova de conceito sobrepriorização com OF, tivemos algumas realizações.

Foi realizada uma análise do estado da arte em pesquisas relacionadas QoS e QoEbaseadas em SDN. Muitas outras soluções foram vistas, o que já nos deixa atentos para novasabordagens futuras. Nessa análise conseguimos fazer comparações a respeito das característicasdas principais soluções. Outros artigos ainda foram analisados, mas não foi possível inseri-losneste trabalho. Concluímos que muito trabalho foi realizado e muito conhecimento foi adquirido;

Do ponto de vista profissional, como é objetivo desse trabalho, observamos que poucosmétodos de controle institucionais existem atualmente. Essa iniciativa é de certa forma pioneirae desperta o interesse em se estudar o tráfego institucional de ambientes reais e propor soluçõesdiversas baseadas no promissor paradigma SDN e nos recursos do protocolo OpenFlow;

Outra realização do trabalho foi a análise de métricas de QoS no tráfego de vídeo dentroda estrutura real em produção, avaliando a comunicação entre dois campi universitários, Recifee Caruaru. Essa iniciativa também teve um certo pioneirismo e a partir dela pode-se pensarem formas de monitorar e controlar as características desse tipo de comunicação. Esse estudomostrou que foi viável fazer experimentações sem prejudicar o funcionamento da instituição;

Sobre a análise do tráfego, em linhas gerais observamos que as técnicas de priorização eclassificação de tráfego proporcionadas pelo protocolo Openflow no paradigma SDN são eficazes.Para todas as métricas coletadas obtivemos valores melhores quando habilitamos a priorização, oque pode ser muito bem utilizado dentro de um ambiente educacional onde existem aplicaçõesque podem ser consideradas prioritárias.

CAPÍTULO 6. CONCLUSÕES 86

6.1 PERGUNTAS DE PESQUISA

E em relação à pergunta de pesquisa inicialmente realizada: É eficaz prover o controle deQoS, através de priorização de tráfego institucional, em redes definidas por software, avaliandoQoE em ambientes em produção?

Após todo o processo de testes e prova de conceito, podemos afirmar que sim, atravésdos recursos do protocolo OF é possível obter Qualidade de serviço nas redes institucionais, e,consequentemente melhorar a Qualidade de experiência do usuário. No entanto, precisaremosverificar melhor a eficiência dos métodos de avaliação das métricas de QoE quando realizadas noâmbito do tráfego sobre um meio onde há perdas de quadros até o seu recebimento no destino.

6.2 OBJETIVOS ALCANÇADOS

Sobre o objetivo geral traçado desde o início, o desempenho da solução baseada em SDNpara QoS com priorização de tráfego foi analisado e um modelo inicial foi proposto para permitiro desenvolvimento de uma aplicação para controle de QoS.

Em relação os objetivos específicos:

� Um Ambiente de experimentação virtual específico foi construído desde o início,como esperado. Foram testadas muitas ferramentas até a escolha final das mais ade-quadas, o AEV funcionou perfeitamente atendeu inteiramente aos nossos propósitos,esse modelo permite no futuro até mesmo aumentar a escala e a configuração dosexperimentos. Vários scripts foram gerados para criação dos cenários facilitandotrabalhos futuros. Isso foi de fato importante, até mesmo para permitir que a pesquisapossa sair mais facilmente do papel, numa estrutura como essa, além de mostrar-mos viabilidade de configuração, nos permite a montagens de cenários na forma deprotótipos que podem ser migrados para produção muito rapidamente;

� A transmissão real inter-campi foi analisada. Avaliamos o máximo possível dacomunicação, sempre com a preocupação de ter base em aplicações reais e cuidadopara que o funcionamento da rede real não fosse prejudicado. Esse trabalho deavaliação real também pode ser considerado um ponto de partida, a partir dele novasanálises podem ser propostas baseadas no mesmo modelo, e como os cenários foramexecutados através de scripts fica muita mais fácil ajustar esse modelo;

� Técnicas de transmissão e métricas de Qualidade utilizadas nos paradigmas tradicio-nais e foram analisadas e associadas ao funcionamento em SDN, em geral as mesmastécnicas foram aplicadas e o funcionamento foi adequado;

� As principais métricas objetivas de Qualidade de Serviço e Qualidade de Experiênciaforam analisadas em cenários de utilização com RTP, desta forma foi possível


compreender as formas e ferramentas para calculá-las, e aprender sobre os modos defuncionamento para melhor utilizá-las posteriormente;

� Foi testada uma proposta uma solução de controle de QoS, baseada em técnicas debaixa complexidade através da classificação e enfileiramento Openflow, o que seriacompatível com mecanismos de muitos switches legados, e ao mesmo tempo habilitaSDN;

� Ao fim, confirmamos que as estratégias de priorização são eficientes para melhoriadas métricas de qualidade de vídeo em tempo real. Baseado na proposta de sistemade controle de QoS, será desenvolvida uma solução para ajuste dinâmico de QoSbaseado em SDN/OF.

6.3 LIMITAÇÕES DO TRABALHO

Vale a pena ainda ressaltar algumas limitações que tivemos que impor a este trabalho:Inicialmente, trabalharíamos com duas hipóteses, mas que não acabamos não encontra-

mos meios e ferramentas institucionais que nos permitissem prová-las justificando ainda mais anecessidade da nossa proposta: a) que o tráfego de vídeo é relevante dentro de uma instituiçãoeducacional; e b) o referido tráfego inter-campi é relevante e representativo para uma instituição;

Por restrições de tempo, e visto que a UFPE não possuía dispositivos SDN disponíveis narede de produção para realização de experimentos, nem foi possível instalar, não realizamos ostestes na rede real com dispositivos SDN. Desta forma não foi possível num segundo momento,na rede real, avaliarmos o impacto que SDN causaria na rede e compararmos os cenários antes edepois de SDN.

Devido à problemas de implementação no controlador Opendaylight (DOL) utilizadoinicialmente, migramos deste software o controlador de rede Ryu, o utilizamos por pouco tempo,o que acabou impossibilitando o desenvolvimento das aplicações de controle dinâmico (iniciamoso módulo de cálculo de estatísticas do tráfego), o que acabou limitando a implementação daproposta.

6.4 DIFICULDADES ENCONTRADAS

Algumas dificuldades encontradas foram:Devido ao trabalho envolver três temas grandes como SDN, QoS e QoE, Foi preciso

dedicar muito tempo à análise de literatura de várias áreas, vários artigos ainda ficaram defora desse documento. Houve muita dificuldade em encontrar um modelo de experimento, foinecessário agir inicialmente por tentativas alternando entre acerto e erro, em seguida aprovei-tando as abordagens de trabalhos relacionados, mas o nosso acabou sendo feito de forma bempersonalizada. De qualquer forma isso acabou demandando tempo acima do esperado.


A montagem do experimento foi feita toda do zero, como não haviam, precisamos definirtodos os parâmetros, comandos e configurações testando um a um, diversas repetições adicionaisforam realizadas. No início, muito foi feito manualmente, só depois de definido cada parâmetrofoi possível testar e montar os scripts dos experimentos.

Outra dificuldade encontrada foi o grande volume de dados coletados, tanto que ao finalchegamos a uma base de aproximadamente 1500 arquivos armazenados, o que inclui os dadosdos experimentos feitos com tráfego isolado (UDP, TCP e RTP). Se contarmos a quantidade devezes que foi necessário repetir os experimentos e gerar novos arquivos e apagar, teríamos umaquantidade de arquivos ainda bem superior.

Diferentemente dos trabalhos que utilizam experimentação em ambientes controlados,como no mininet, Ns-2 e "evalvid", trabalhar com tráfego e aplicações reais é um desafio bemcomplicado e transformamos esse desafio num compromisso, isso por que tentamos tornar otrabalho factível e não apenas deixá-lo como mais uma pesquisa em laboratório a ser arquivada.Uma série de plataformas, sistemas e ferramentas tiveram que ser analisadas até se definir ummodelo para experimentação, o que também acabou tomando muito tempo;

6.5 TRABALHOS FUTUROS

Como possíveis trabalhos futuros e como continuação dessa pesquisa, teremos pelafrente:

Pretendemos avançar com a criação da aplicação de monitoramento e controle dinâmicode QoS baseado em SDN e controlador Ryu aqui proposta;

Pretendemos avaliar uma implementação incluindo o protocolo OF-Config que pode terum papel importante no controle de QoS, sendo muito útil na configuração remota de dispositivosOF;

Esse trabalho poderia ser estendido a mais casos de uso, avaliando o tráfego de vídeos emaltíssima resolução (4K e futuramente 8K) e de maior duração. É possível pensar numa soluçãopara distribuição de vídeo que incorpore esquemas SVC, ABR, e outras métricas e abordagens deavaliação QoE. Seria interessante também variar os tipos de vídeo utilizados e incluir aplicaçõesreais como os sistemas de web e videoconferência da instituição;

Cogitamos expandir os testes e até comparações utilizando outros switches SDN, comoOpenWRT e ofsoftswitch do CPQD, habilitando a utilização dos Medidores para limitação detráfego. Nesse último, com suporte completo ao OF 1.3, é possível se adotar uma abordagembaseada na medição em tempo real das taxas de fluxos de forma ainda mais eficiente;

Foi inicialmente idealizado e pretende-se evoluir a pesquisa para a elaboração de umaabordagem para classificação de tráfego em SDN, de forma automatizada, integrada a ferramentasde Deep Packet Inspection (DPI);

Numa transferência em tempo real por um canal de comunicação é comum ocorreremperdas. E as métricas objetivas que calculam QoE como PSNR, VQM e SSIM realizam com-


paração quadro a quadro de um vídeo original (enviado) com o vídeo processado (recebido).Percebemos durante este trabalho, que ao compararmos os vídeos, os valores das métricasabsolutos de QoE representavam sempre uma qualidade considerada na literatura como baixa(per exemplo, PSNR < 20). Visualizando os vídeos percebemos que isso não corresponde àrealidade. No nosso entendimento, as perdas acontecem desde o início do vídeo, então os espaçosdos quadros perdidos vão sendo ocupados pelos próximos, o que se propaga por todo o vídeo,tirando quase todos os quadros de ordem. Na hora do cálculo da métrica, não há uma referência(um ID) do quadro, e a comparação é baseada na ordem de chegada dos mesmos. Com essadesordenação do vídeo recebido, a comparação é sempre feita com os quadros errados. Asferramentas populares (como "ffmpeg"e "msu") detectam, mas não criticam antes do cálculo quehá diferença na quantidade de quadros entre original e o processado, e calculam normalmentedando a falsa impressão de que sincronizam os vídeos, o que na prática não ocorre ocorreu.Como concluímos que essas métricas não são tão eficientes para esse tipo de avaliação, emtrabalho futuro, gostaríamos de estudar melhor esse problema com o objetivo de propor outrasmétricas de avaliação de QoE nesse ambiente de transmissões com perda.

6.6 CONSIDERAÇÕES FINAIS

Ao final deste trabalho, podemos concluir que SDN é um paradigma relativamente novoe que traz muitas possibilidades às redes de computadores do presente e do futuro, desta formanão é possível se conceber soluções de rede, atualmente, sem pensar na migração para SDN. Istojá é uma necessidade imediata dada a demanda e requisitos que temos das aplicações atuais. Ealém de tudo, numa instituição de educação é importante ter-se também um ambiente propício ainovação. Desde o nosso estudo inicial da literatura, identificamos várias técnicas que foramutilizadas em diversos ambientes e que podem ser aproveitadas dentro do ambiente educacional.Nesse estudo inicial, dada a demanda crescente de vídeos e multimídia educacional, fizemoseste trabalho de priorização de tráfego, que é algo que não vemos sendo realizado na UFPE,por exemplo. Soluções como esta não seriam fáceis de experimentar na rede real, por issocriamos um ambiente de virtual capaz de provar os nossos conceitos e hipóteses de forma segura.Posteriormente, poderemos avançar no sentido de trazer uma solução real aplicada diretamenteà instituição. Neste trabalho pudemos verificar, analisando cenários de restrição de banda,que a solução de priorização se mostra eficiente, restando agora montar um arcabouço (nãomais teórico) para implementar e testar as soluções que forneçam controle dinâmico trazendoa inteligência para a o centro da rede. Nossos dados mostraram que é possível analisar o QoSda rede e que é possível avaliar a rede real reproduzindo-a num ambiente de experimentaçãovirtual. Por fim, destacamos que utilizando todo esse conhecimento aqui adquirido, sobretudoem SDN, QoS e QoE, deixamos aberto um promissor caminho para o surgimento de aplicaçõesque possam melhorar os serviços e aplicações institucionais.

909090

REFERÊNCIAS

AGBOMA, F.; LIOTTA, A. QoE-aware QoS management. Proceedings of the 6thInternational Conference on Advances in Mobile Computing and Multimedia MoMM 08,[S.l.], p.111–116, 2008.

AKELLA, A. V.; XIONG, K. Quality of Service (QoS)-Guaranteed Network ResourceAllocation via Software Defined Networking (SDN). In: IEEE 12TH INTERNATIONALCONFERENCE ON DEPENDABLE, AUTONOMIC AND SECURE COMPUTING, 2014.Anais. . . [S.l.: s.n.], 2014. p.7–13.

ALRESHOODI, M.; WOODS, J. Survey on QoeQos Correlation Models Formultimedia Services. International Journal of Distributed andParallel systems, [S.l.], v.4, n.3, p.53–72, may 2013.

BHATTACHARYA, B.; DAS, D. SDN based architecture for QoS enabled services acrossnetworks with dynamic service level agreement. In: IEEE INTERNATIONAL CONFERENCEON ADVANCED NETWORKS AND TELECOMMUNICATIONS SYSTEMS (ANTS), 2013.Anais. . . IEEE, 2013. p.1–6.

BLAKE, S. et al. An Architecture for Differentiated Services. [S.l.]: RFC Editor, 1998. RFC,http://www.rfc-editor.org/rfc/rfc2475.txt. (2475).

BRADEN, B.; CLARK, D.; SHENKER, S. Integrated Services in the Internet Architecture:an overview. [S.l.]: RFC Editor, 1994. RFC,http://www.rfc-editor.org/rfc/rfc1633.txt. (1633).

BRADNER, S.; MCQUAID, J. Benchmarking Methodology for Network InterconnectDevices. [S.l.]: RFC Editor, 1999. RFC,http://www.rfc-editor.org/rfc/rfc2544.txt. (2544).

BUENO, I. et al. An OpenNaaS Based SDN Framework for Dynamic QoS Control. In: IEEESDN FOR FUTURE NETWORKS AND SERVICES (SDN4FNS), 2013. Anais. . . IEEE, 2013.p.1–7.

CARAGUAY, A.; FERNáNDEZ, J.; VILLALBA, L. Framework for optimized multimediarouting over software defined networks. Computer Networks, [S.l.], v.92, Part 2, p.369 – 379,2015.

CHEN, Y.; WU, K.; ZHANG, Q. From QoS to QoE A Tutorial on Video Quality Assessment.IEEE Communications Surveys & Tutorials, [S.l.], v.17, n.2, p.1126–1165, 2015.

CISCO AND AFFILIATES. The Zettabyte Era. Trends and Analysis. Cisco white paper, [S.l.],p.1–32, 2017.

CISCO AND AFFILIATES. Cisco Visual Networking Index. Technical Report, Cisco, Tech.Rep., [S.l.], p.1–3, 2017.

http://www.rfc-editor.org/rfc/rfc2475.txt



REFERÊNCIAS 91

COLEMAN, D. A DOE handbook : a simple approach to basic statistical design ofexperiments. United States: publisher not identified, 2014.

CONSTANTINE, B.; KRISHNAN, R. Traffic Management Benchmarking. [S.l.]: RFCEditor, 2015. RFC. (7640).

CPqD; ERICSSON INNOVATION CENTER. OpenFlow 1.3 Software Switch. Online;accessed 24-June-2017, https://github.com/CPqD/ofsoftswitch13.

EGILMEZ, H. E.; TEKALP, A. M. Distributed QoS Architectures for Multimedia StreamingOver Software Defined Networks. IEEE Transactions on Multimedia, [S.l.], v.16, n.6,p.1597–1609, oct 2014.

FARSHAD, A. et al. Leveraging SDN to provide an in-network QoE measurement framework.In: IEEE CONFERENCE ON COMPUTER COMMUNICATIONS WORKSHOPS(INFOCOM WKSHPS), 2015. Anais. . . IEEE, 2015. v.2015-Augus, p.239–244.

GEORGOPOULOS, P. et al. Using Software Defined Networking to enhance the delivery ofVideo-on-Demand. Computer Communications, [S.l.], v.69, p.79 – 87, 2015.

GORANSSON, P.; BLACK, C. Software Defined Networks. A Comprehensive Approach.[S.l.]: Elsevier, 2014.

GORLATCH, S.; HUMERNBRUM, T. Enabling high-level QoS metrics for interactive onlineapplications using SDN. In: INTERNATIONAL CONFERENCE ON COMPUTING,NETWORKING AND COMMUNICATIONS (ICNC), 2015. Anais. . . IEEE, 2015. p.707–711.

GORLATCH, S.; HUMERNBRUM, T.; GLINKA, F. Improving QoS in real-time internetapplications. from best-effort to Software-Defined Networks. 2014 International Conferenceon Computing, Networking and Communications (ICNC), [S.l.], p.189–193, 2014.

GOVINDARAJAN, K. et al. Realizing the Quality of Service (QoS) in Software-DefinedNetworking (SDN) based Cloud infrastructure. In: INTERNATIONAL CONFERENCE ONINFORMATION AND COMMUNICATION TECHNOLOGY (ICOICT), 2014. Anais. . .IEEE, 2014. p.505–510.

GUO, P. J.; KIM, J.; RUBIN, R. How Video Production Affects Student Engagement: anempirical study of mooc videos. In: FIRST ACM CONFERENCE ON LEARNING @ SCALECONFERENCE, New York, NY, USA. Proceedings. . . ACM, 2014. p.41–50. (L@S ’14).

HALEPLIDIS, E. et al. Software-Defined Networking (SDN): layers and architectureterminology. [S.l.]: RFC Editor, 2015. RFC,http://www.rfc-editor.org/rfc/rfc7426.txt. (7426).

HEINANEN, J. et al. Assured Forwarding PHB Group. [S.l.]: RFC Editor, 1999. RFC.(2597).

HSU, W.-H.; LO, C.-H. QoS/QoE Mapping and Adjustment Model in the Cloud-basedMultimedia Infrastructure. IEEE Systems Journal, [S.l.], v.8, n.1, p.247–255, mar 2014.

II, H. O.; DURRESI, A. Video over Software-Defined Networking (VSDN). ComputerNetworks, [S.l.], v.92, Part 2, p.341 – 356, 2015.

https://github.com/CPqD/ofsoftswitch13


REFERÊNCIAS 92

ISHIMORI, A. et al. Control of Multiple Packet Schedulers for Improving QoS onOpenFlow/SDN Networking. In: SECOND EUROPEAN WORKSHOP ON SOFTWAREDEFINED NETWORKS, 2013. Anais. . . IEEE, 2013. p.81–86.

KIM, H. J. et al. The QoE Evaluation Method through the QoS-QoE Correlation Model. In:FOURTH INTERNATIONAL CONFERENCE ON NETWORKED COMPUTING ANDADVANCED INFORMATION MANAGEMENT, 2008. Anais. . . IEEE, 2008. v.2, p.719–725.

KO, N.-S. et al. OpenQFlow. Scalable OpenFlow with Flow-Based QoS. IEICE Transactionson Communications, [S.l.], v.E96.B, n.2, p.479–488, 2013.

KRISHNA, H. Providing End-to-end Bandwidth Guarantees with OpenFlow. 2016.Dissertação (Mestrado em Ciência da Computação) — Delft University of Technology,Netherlands.

KRISHNA, H.; ADRICHEM, N. L. M. van; KUIPERS, F. A. Providing bandwidth guaranteeswith OpenFlow. In: SYMPOSIUM ON COMMUNICATIONS AND VEHICULARTECHNOLOGIES (SCVT), 2016. Anais. . . [S.l.: s.n.], 2016. p.1–6.

LAGA, S. et al. Optimizing scalable video delivery through OpenFlow layer-based routing. In:NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM (NOMS), 2014 IEEE.Anais. . . [S.l.: s.n.], 2014. p.1–4.

LARSON, R.; FARBER, B. Estatística Aplicada. 4.ed. São Paulo, Brasil: Pearson PrenticeHall, 2010.

LINUX FOUNDATION. Open vSwitch Documentation. Online; accessed 30-June-2017,http://docs.openvswitch.org/en/latest/.

LIU, H. et al. Software Defined Networking for HTTP video quality optimization. In:COMMUNICATION TECHNOLOGY (ICCT), 2013 15TH IEEE INTERNATIONALCONFERENCE ON. Anais. . . [S.l.: s.n.], 2013. p.413–417.

LIU, R. et al. Flow entries installation based on distributed SDN controller. In: IEEE/CICINTERNATIONAL CONFERENCE ON COMMUNICATIONS IN CHINA (ICCC), 2015.Anais. . . [S.l.: s.n.], 2015. p.1–6.

MOSHREF, M. et al. Flow-level state transition as a new switch primitive for SDN. In: HOTTOPICS IN SOFTWARE DEFINED NETWORKING. Proceedings. . . [S.l.: s.n.], 2014.p.61–66.

NAM, H. et al. Towards QoE-aware video streaming using SDN. In: GLOBALCOMMUNICATIONS CONFERENCE (GLOBECOM), 2014 IEEE. Anais. . . [S.l.: s.n.], 2014.p.1317–1322.

NUNES, B. A. A. et al. A Survey of Software-Defined Networking. Past, Present, and Future ofProgrammable Networks. IEEE Communications Surveys Tutorials, [S.l.], v.16, n.3,p.1617–1634, 2014.

OPEN NETWORKING FOUNDATION. Software-Defined Networking (SDN) Definition.Online; accessed 01-September-2017,https://www.opennetworking.org/sdn-definition/.

http://docs.openvswitch.org/en/latest/

https://www.opennetworking.org/sdn-definition/

REFERÊNCIAS 93

OPEN NETWORKING FOUNDATION. OpenFlow Switch Specification 1.5.1. [S.l.]: OpenNetworking Foundation, 2015. 277p.

OPEN NETWORKING FOUNDATION. The Benefits of Multiple Flow Tables and TTPs.[S.l.]: Open Networking Foundation, 2015. 9p.

PROJECT FLOODLIGHT. What are meters. Online; accessed 23-June-2017,https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/15040523/How+to+Use+OpenFlow+Meters.

RAHRER, T. et al. Triple-play services quality of experience (QoE) requirements. In: DSLFORUM TR-126. Anais. . . [S.l.: s.n.], 2006. v.2006.

RAHRER, T.; FIANDRA, R.; WRIGHT, S. Triple-play Services Quality of Experience(QoE) Requirements. [S.l.]: DSL Forum, 2006. TR,https://www.broadband-forum.org/technical/download/TR-126.pdf.

RIFAI, H.; MOHAMMED, S.; MELLOUK, A. A brief synthesis of QoS-QoE methodologies.In: INTERNATIONAL SYMPOSIUM ON PROGRAMMING AND SYSTEMS, 2011. Anais. . .IEEE, 2011. p.32–38.

RYU SDN FRAMEWORK COMMUNITY. Ryu SDN Framework. Online; accessed30-June-2017, https://osrg.github.io/ryu/.

SOCOLOFSKY, T. J.; KALE, C. J. TCP/IP tutorial. [S.l.]: RFC Editor, 1991. RFC,http://www.rfc-editor.org/rfc/rfc1180.txt. (1180).

SONKOLY, B. et al. On QoS Support to Ofelia and OpenFlow. In: EUROPEAN WORKSHOPON SOFTWARE DEFINED NETWORKING, 2012. Anais. . . IEEE, 2012. p.109–113.

TANG, S.; HUA, B.; WANG, D. Realizing video streaming multicast over SDN networks. In:COMMUNICATIONS AND NETWORKING IN CHINA (CHINACOM), 2014 9THINTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2014. p.90–95.

TOMOVIC, S.; PRASAD, N.; RADUSINOVIC, I. SDN control framework for QoSprovisioning. In: TELECOMMUNICATIONS FORUM TELFOR (TELFOR), 2014. Anais. . .[S.l.: s.n.], 2014. p.111–114.

TSUNG-FENG, Y.; WANG, K.; HSU, Y.-H. Adaptive routing for video streaming with QoSsupport over SDN networks. In: INFORMATION NETWORKING (ICOIN), 2015INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2015. p.318–323.

UNIVERSIDADE FEDERAL DE PERNAMBUCO. página de panorama da rede da UFPE.2017.

UNIVERSIDADE FEDERAL DE PERNAMBUCO. números institucionais - informaçõessobre Centros acadêmicos. 2017.

UZAKGIDER, T.; CETINKAYA, C.; SAYIT, M. Learning-based approach for layered adaptivevideo streaming over {SDN}. Computer Networks, [S.l.], v.92, Part 2, p.357 – 368, 2015.

WALLNER, R.; CANNISTRA, R. An SDN Approach. Quality of Service using Big Switch’sFloodlight Open-source Controller. Proceedings of the Asia-Pacific Advanced Network,[S.l.], v.35, p.14, jun 2013.

https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/15040523/How+to+Use+OpenFlow+Meters

https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/15040523/How+to+Use+OpenFlow+Meters

https://www.broadband-forum.org/technical/download/TR-126.pdf

https://osrg.github.io/ryu/


REFERÊNCIAS 94

WANG, Q. et al. GENI Cinema. An SDN-Assisted Scalable Live Video Streaming Service. In:NETWORK PROTOCOLS (ICNP), 2014 IEEE 22ND INTERNATIONAL CONFERENCE ON.Anais. . . [S.l.: s.n.], 2014. p.529–532.

XIA, W. et al. A Survey on Software-Defined Networking. IEEE Communications SurveysTutorials, [S.l.], v.17, n.1, p.27–51, Firstquarter 2015.

YAN, J. et al. HiQoS. An SDN-based multipath QoS solution. China Communications, [S.l.],v.12, n.5, p.123–133, may 2015.

959595

APÊNDICE A — SCRIPTS DE CONFIGURAÇÃO

1 vs−v s c t l add−p o r t s1 e t h 0 −− s e t i n t e r f a c e e t h 0 o f p o r t _ r e q u e s t =12 ovs−v s c t l add−p o r t s1 e t h 1 −− s e t i n t e r f a c e e t h 1 o f p o r t _ r e q u e s t =23 ovs−v s c t l add−p o r t s1 e t h 2 −− s e t i n t e r f a c e e t h 2 o f p o r t _ r e q u e s t =34 ovs−v s c t l de l−br s15 ovs−v s c t l add−br s16 i f c o n f i g e t h 0 0 . 0 . 0 . 0 up7 i f c o n f i g e t h 1 0 . 0 . 0 . 0 up8 i f c o n f i g e t h 2 0 . 0 . 0 . 0 up9 ovs−v s c t l add−p o r t s1 e t h 0 −− s e t i n t e r f a c e e t h 0 o f p o r t _ r e q u e s t =1

10 ovs−v s c t l add−p o r t s1 e t h 1 −− s e t i n t e r f a c e e t h 1 o f p o r t _ r e q u e s t =211 ovs−v s c t l add−p o r t s1 e t h 2 −− s e t i n t e r f a c e e t h 2 o f p o r t _ r e q u e s t =312 ovs−v s c t l s e t−c o n t r o l l e r s1 t c p : 1 0 . 1 0 . 1 0 . 1 0 : 6 6 3 313 ovs−v s c t l s e t b r i d g e s1 p r o t o c o l s =OpenFlow1314 ovs−v s c t l s e t c o n t r o l l e r s1 c o n n e c t i o n−mode=out−of−band15 ovs−v s c t l s e t b r i d g e s1 f a i l _ m o d e = s e c u r e

Código 1: Exemplo de script de configuração OvS1

1 sudo t c q d i s c d e l dev e t h 2 r o o t ;2 sudo t c q d i s c add dev e t h 2 r o o t h a n d l e 1 : netem d e l a y 4 . 2 ms l o s s 4 .3%;3 sudo t c q d i s c add dev e t h 2 p a r e n t 1 : h a n d l e 2 : t b f r a t e 6 mbi t b u r s t 128 kb

l a t e n c y 200ms ;4 sudo t c q d i s c show dev e t h 2 ;

Código 2: Script de configuração da ferramenta tc para modelagem do link

1 sudo ovs−v s c t l −− s e t p o r t e t h 0 qos=@newqos −− s e t p o r t e t h 1 qos=@newqos −−s e t p o r t e t h 2 qos=@newqos −− −−i d =@newqos c r e a t e qos t y p e = l i n u x−h t b

o t h e r−c o n f i g : max−r a t e =6000000 queues =1=@q1,2=@q2 −− −−i d =@q1 c r e a t equeue o t h e r−c o n f i g : max−r a t e =6000000 −− −−i d =@q2 c r e a t e queue o t h e r−c o n f i g : min−r a t e =6000000 o t h e r−c o n f i g : max−r a t e =6000000

Código 3: Script de configuração de filas OvS

1 sudo ovs−o f c t l add−f low s1 p r i o r i t y =1111 , d l _ t y p e =0x0800 , nw_src = 1 9 2 . 1 6 8 . 0 . 1 ,a c t i o n s = s e t _ q u e u e : 1 , normal −O openf low13

2 sudo ovs−o f c t l add−f low s1 p r i o r i t y =1111 , d l _ t y p e =0x0800 , nw_src = 1 9 2 . 1 6 8 . 0 . 2 ,a c t i o n s = s e t _ q u e u e : 2 , normal −O openf low13

3 sudo ovs−o f c t l add−f low s1 p r i o r i t y =1111 , d l _ t y p e =0x0800 , nw_src= 1 9 2 . 1 6 8 . 0 . 1 1 , a c t i o n s = s e t _ q u e u e : 1 , normal −O openf low13

4 sudo ovs−o f c t l add−f low s1 p r i o r i t y =1111 , d l _ t y p e =0x0800 , nw_src= 1 9 2 . 1 6 8 . 0 . 2 2 , a c t i o n s = s e t _ q u e u e : 2 , normal −O openf low13

Código 4: Script de instalação dos fluxos associados às filas

1 f o r c o n t i n { 1 . . 3 0 } ;2 do

APÊNDICE 96

3 echo " i n i c i a n d o i t e r a c a o $ c o n t de 30 " ;4 t s h a r k − i e t h 0 − l −a d u r a t i o n :130 −w / home / u fpe / a r q u i v o s / caa−

r t p $ c o n t . pcap &5 t i m e o u t 130 s p e e d o m e t e r −t x e t h 0 −s −p&>/home / u fpe / a r q u i v o s / caa−r t p−

s p e e d $ c o n t . t x t &6 s s h u s u a r i o @ s e r v i d o r r t p ’ c v l c −vvv / home / u fpe / a r q u i v o s / VideoHD . a v i

−−s o u t " # r t p { d s t = c l i e n t e r t p , p o r t =5004 ,mux= t s } " −−run−t ime 130 −−s top−t ime 130 v l c : / / q u i t ’ ;

7 c v l c r t p : / /@:5004 −−s o u t f i l e / a v i : " / home / u fpe / caa−r t p−v l c $ c o n t . a v i " −−s t a r t −t ime =00 −−no−drop−l a t e −f r a me s −−no−sk ip−f r a me s −−v e r b o s e =1 −− f i l e −l o g g i n g −− l o g f i l e = / home / u fpe / caa−vlc−l o g $ c o n t . t x t −−run−t ime =130 −−s top−t ime =130 v l c : / / q u i t &

8 echo " f i n a l i z a n d o c o l e t a $ c o n t " ;9 s l e e p 1 0 ;

10 done11 echo " f im " ;

Código 5: Pseudo rotina de execução dos testes RTP: Caruaru - Recife

1 C e n a r i o 10−cq−udp−r t p2 ! / b i n / bash3 s s h lubuntu@192 . 1 6 8 . 0 . 1 ’ k i l l a l l −9 i p e r f 3 ’ ;4 f o r c o n t i n { 1 . . 3 0 } ;5 do6 echo " i n i c i a n d o medicao c e n a r i o com QoS − UDP + RTP , i t e r a c a o $ c o n t de

30 " ;7 s s h lubuntu@192 . 1 6 8 . 0 . 2 2 ’ k i l l a l l −9 vlc ’ ;8 k i l l a l l −9 v l c ;9 t i m e o u t 150 s p e e d o m e t e r −rx e t h 0 −s −p&>/home / l u b u n t u / a r q u i v o s /10−cq−udp−

r t p / cq−udp−r t p $ c o n t . speed &10 t s h a r k − i e t h 0 − l −a d u r a t i o n :150 −w / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p

/ ComQoS−UDP−RTP$cont . pcap &11 s s h lubuntu@192 . 1 6 8 . 0 . 2 2 ’ c v l c −vvv / home / l u b u n t u / Downloads / VideoHD . a v i

−−s o u t " # r t p { d s t = 1 9 2 . 1 6 8 . 0 . 2 , p o r t =5004 ,mux= t s } " −−run−t ime 150 −−s top−t ime 150 v l c : / / q u i t ’ &

12 c v l c r t p : / /@:5004 −−s o u t f i l e / a v i : " / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p /ComQoS−UDP−RTP−v l c $ c o n t . a v i " −−s t a r t −t ime =00 −−no−drop−l a t e −f r a me s −−no−sk ip−f r a me s −−v e r b o s e =1 −− f i l e −l o g g i n g −− l o g f i l e = / home / l u b u n t u / a r q u i v o s/10−cq−udp−r t p / ComQoS−vlc−l o g $ c o n t . t x t −−run−t ime 150 −−s top−t ime 150v l c : / / q u i t &

13 s s h lubuntu@192 . 1 6 8 . 0 . 1 ’ i p e r f 3 −u −R −c 1 9 2 . 1 6 8 . 0 . 1 1 −P 1 − i 1 −p 5201 −t 150 −b 25M −V −T 1 −− l o g f i l e / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p /ComQoS−UDP−RTP− i p e r f . log ’ $ c o n t ;

14 echo " f i n a l i z a n d o c o l e t a $ c o n t " de 3 0 ;15 s l e e p 1 0 ;16 done17 echo " f i n a l i z a n d o s c r i p t − c o p i a n d o a r q u i v o s p a r a p a s t a c o m p a r t i l h a d a " ;18 echo " f i n a l i z a n d o s c r i p t − c o p i a n d o l o g s i p e r f e a r q u i v o s pcaps " ;

APÊNDICE 97

19 s s h lubuntu@192 . 1 6 8 . 0 . 1 ’mv / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p / ComQoS−UDP−RTP− i p e r f * / home / l u b u n t u / sha red10−cq−udp−r t p ’ &

20 mv / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p / * . pcap / home / l u b u n t u / s h a r e d /10−cq−udp−r t p ;

21 echo " f i n a l i z a n d o s c r i p t − c o p i a n d o s a i d a s em a v i " ;22 mv / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p / * . a v i / home / l u b u n t u / s h a r e d /10−cq−

udp−r t p ;23 echo " f i n a l i z a n d o s c r i p t − c o p i a n d o l o g s do v l c " ;24 mv / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p / * . t x t / home / l u b u n t u / s h a r e d /10−cq−

udp−r t p ;25 echo " f i n a l i z a n d o s c r i p t − c o p i a n d o l o g s do s p e e d o m e t e r " ;26 mv / home / l u b u n t u / a r q u i v o s /10−cq−udp−r t p / * . speed / home / l u b u n t u / s h a r e d /10−cq−

udp−r t p ;27 echo " f im da medicao do c e n a r i o com QoS − UDP + RTP , v e r i f i q u e os

d i r e t o r i o s " ;28 e x i t ;

Código 6: Exemplo de Script de manipulação de clientes e servidores do experimento no AEV

David Carlos Pereira da Cunha...David Carlos Pereira da Cunha Proposta de suporte à qualidade de...

Documents

Transcript of David Carlos Pereira da Cunha...David Carlos Pereira da Cunha Proposta de suporte à qualidade de...