Universidade Federal do Espírito Santo
Mestrado em Informática
Internet do Futuro
A QoS-Enabled OpenFlow Environment
for Scalable Video Streaming
Seyhan Civanlar - Murat Parlakisik - A. Murat Tekalp
Burak Gorkemli - Bulent Kaytaz - Evren Onem1
José Alexandre Macedo
IEEE Globecom 2010 Workshop on Network of the Future
Informações sobre o Paper
Origem dos Autores
Istanbul
Turquía
Citado por 1 paper
(mesmos autores)
SCALABLE VIDEO STREAMING OVER OPENFLOW
NETWORKS: AN OPTIMIZATION FRAMEWORK
FOR QOS ROUTING
Número de citações = 17
Agenda
• Introdução
• Formulação do Problema
• Arquitetura do Controller
• Resultados dos Testes
• Conclusões
• Trabalhos Futuros
Introdução
• Nas últimas décadas diversas arquiteturas para
Qualidade de Serviço (QoS) tem sido
exploradas...
• Nenhuma realmente bem sucedida e
globalmente implementada
– Uma das razões é a falta de uma visão ampla dos recursos
da rede
Introdução
• O artigo explora uma possível arquitetura
QoS no GENI utilizando OpenFlow
• Define ainda
– Um framework analítico simples
– Uma plataforma experimental para transportar
streaming de vídeo
Introdução
• Aplicações de streaming tem se tornado muito
popular na internet
• Necessita de recursos de rede estável
– Pouca ou nenhuma perda de pacotes e variação de
atraso
• Infelizmente não é possível obtê-los sempre com
as redes de melhor esforço
Introdução
• Scalable Video Coding (SVC)
– Codifica o vídeo em múltiplas camadas
• Uma “camada base”
• Múltiplas camadas de aprimoramento
– É muito importante que a camada base seja
transportada sem qualquer perda de pacote
• As camadas de aprimoramento dependem dela!
Introdução
A ideia do artigo é realizar o stream de video
de forma que a camada base seja modelada
com fluxo QoS e as camadas de
aprimoramento sejam tratadas com melhor
esforço
Introdução
Formulação do Problema
• Investigar rotas de fluxo QoS possíveis entre
a origem e o destino
– Minimizando a soma ponderada do tamanho
total da rota (tráfego QoS) e da perda de
pacote para o tráfego de melhor esforço
Formulação do Problema
𝑗
𝑁𝑖𝑘 = 𝑟𝑜𝑡𝑎𝑠 𝑝𝑜𝑠𝑠í𝑣𝑒𝑖𝑠
𝑁 = 𝑛º 𝑑𝑒 𝑛ó𝑠 𝑐𝑜𝑛𝑡𝑟𝑜𝑙𝑎𝑑𝑜𝑠
𝑝𝑒𝑙𝑜 𝑐𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟
𝐿𝑖𝑘 = 𝑡𝑎𝑚𝑎𝑛𝑕𝑜
𝑑𝑒 𝑢𝑚𝑎 𝑟𝑜𝑡𝑎 𝑄𝑜𝑆
𝑗
𝑃𝐿𝐵𝑖𝑘 𝑡 = 𝑡𝑎𝑥𝑎 𝑑𝑒 𝑝𝑒𝑟𝑑𝑎
𝑑𝑒 𝑝𝑎𝑐𝑜𝑡𝑒 𝑝𝑎𝑟𝑎 𝑚𝑒𝑙𝑕𝑜𝑟 𝑒𝑠𝑓𝑜𝑟ç𝑜
𝑗
𝑄𝑖𝑘 𝑡 = 𝑞𝑢𝑎𝑛𝑡𝑖𝑑𝑎𝑑𝑒𝑑𝑒 𝑡𝑟á𝑓𝑒𝑔𝑜
𝑄𝑜𝑆 𝑒𝑚 𝑢𝑚 𝑡𝑒𝑚𝑝𝑜 𝑡
Formulação do Problema
𝑗
𝑁𝑖𝑘 = 𝑟𝑜𝑡𝑎𝑠 𝑝𝑜𝑠𝑠í𝑣𝑒𝑖𝑠
𝑁 = 𝑛º 𝑑𝑒 𝑛ó𝑠 𝑐𝑜𝑛𝑡𝑟𝑜𝑙𝑎𝑑𝑜𝑠
𝑝𝑒𝑙𝑜 𝑐𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟
𝐿𝑖𝑘 = 𝑐𝑜𝑚𝑝𝑟𝑖𝑚𝑒𝑛𝑡𝑜
𝑑𝑒 𝑢𝑚𝑎 𝑟𝑜𝑡𝑎 𝑄𝑜𝑆
𝑗
𝑗
𝑃𝐿𝐵𝑖𝑘 𝑡 = 𝑡𝑎𝑥𝑎 𝑑𝑒 𝑝𝑒𝑟𝑑𝑎
𝑑𝑒 𝑝𝑎𝑐𝑜𝑡𝑒 𝑝𝑎𝑟𝑎 𝑚𝑒𝑙𝑕𝑜𝑟 𝑒𝑠𝑓𝑜𝑟ç𝑜
𝑄𝑖𝑘 𝑡 = 𝑞𝑢𝑎𝑛𝑡𝑖𝑑𝑎𝑑𝑒𝑑𝑒 𝑡𝑟á𝑓𝑒𝑔𝑜
𝑄𝑜𝑆 𝑒𝑚 𝑢𝑚 𝑡𝑒𝑚𝑝𝑜 𝑡
Formulação do Problema
𝑗
𝐶𝑖𝑘 = 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒
𝑗
𝑑𝑒 𝑢𝑚𝑎 𝑟𝑜𝑡𝑎 𝑅𝑖𝑘
𝑗
𝐵𝑖𝑘 𝑡 = 𝑞𝑢𝑎𝑛𝑡𝑖𝑑𝑎𝑑𝑒𝑑𝑒 𝑡𝑟á𝑓𝑒𝑔𝑜
𝑚𝑒𝑙𝑕𝑜𝑟 𝑒𝑠𝑓𝑜𝑟ç𝑜 𝑒𝑚 𝑢𝑚 𝑡𝑒𝑚𝑝𝑜 𝑡
Arquitetura do Controller
Arquitetura do Controller
• Funções de policiamento precisam ser
implementadas na camada de forwarder
– Monitoramento de recurso
• Forwarders mantem o controle de quanto dos recursos
estão disponíveis
– Sinalização de recurso
• Forwarders sinalizam a disponibilidade de recursos em
tempo real para que ações necessárias possam ser
tomadas no controlador
– Reserva de recurso
• Controlador deve instruir forwarders na alocação adequada
de recursos
Resultados dos Testes
Resultados dos Testes
• Video dos testes codificado usando o Joint
Scalable Video Model (JSVM)
– Camada base codificada em 1059 kbps
– 2 sub-camadas codificadas
• 2706 kbps e 3274 kbps
• Servidor que transmite o streaming SVC
– Envia o vídeo usando TCP
– Usa duas conexões para cada sessão de streaming
• Lógica do controlador escrita para o NOX
Resultados dos Testes
• Limitações da versão atual do OpenFlow
– Temos que sondar cada forwarder para obter
estatísticas
– Traz uma sobrecarga para o controlador
continuamente sondar, medir e avaliar caminhos
Resultados dos Testes
Resultados dos Testes
Resultados dos Testes
Conclusões
• O trabalho utiliza o OpenFlow para um
possível apoio na garantia da QoS
• Descreveu ainda
– Uma arquitetura para o controlador
– Uma possível formulação para roteamento QoS
– Uma configuração para os testes
Meus comentários...
• No início o autor diz
“QoS traffic is treated losslessly”
• Como os forwarders não comunicam os
problemas temos
“some base layer packets will already be dropped
when congestion starts, which may not be
recoverable due to play-out constraints”
Ou seja, o autor vende uma coisa no início
e entrega outra no fim 
Meus comentários...
• Com relação ao uso de um cenário mais
realístico o autor diz
“To represent a more realistic case, we assumed that
Forwarder 2 is not QoS-configurable”
A escolha parece ter sido estratégica, já
que o Forwarder 2 não é policiado pelo
controlador
Trabalhos Futuros
• Forwarders devem relatar condições de
congestionamento autonomamente
• Desenvolver uma heurística para o problema
de otimização
• Investigar questões de escalabilidade
• Fazer comparações com modelos de QoS
tradicionais como IntServ e DiffServ